docs: sync guide/technical docs to the capability-aware bridge (LOT-018)

[davidp57]

Documentation-only follow-up to the LOT-018 epic: several guide/technical pages still described the pre-epic model. Brings them in line with what shipped.

Changes

• configuration (EN+FR) — Bearer token + role model, new dcs-tokens.yaml (roles/levels), tokens_file; /config.json no longer serves a key and the browser only gets ephemeral WS tickets; replaced the now-obsolete "API key exposure" warning.
• cli-reference (EN+FR) — dcs-client web keeps the token server-side and hands the browser tickets via /ws-ticket.
• architecture / index (EN+FR) — Bearer role-based auth (not X-API-Key), capability-aware actions.
• README — fixed the ASCII diagram (TCP port 7777, role-based Bearer auth) and the MCP tool list (catalogue-driven).

No code changes. (This doc-only PR is mergeable thanks to LOT-019.)

🤖 Generated with Claude Code

Summary by Sourcery

Update user and technical documentation to reflect the capability-aware bridge with role-based Bearer authentication and the new token/ticket model.

Documentation:

• Revise EN/FR configuration guides to describe Bearer tokens, role-based dcs-tokens.yaml, and client token usage without exposing credentials in the browser.
• Update EN/FR CLI reference for the web client to document server-side token handling and ephemeral WebSocket ticket flow.
• Adjust EN/FR architecture and index docs to replace X-API-Key with role-based Bearer auth and capability-aware actions.
• Refresh README to reflect the corrected TCP port, role-based Bearer auth, and catalogue-driven MCP tooling.
• Extend CHANGELOG with a note on syncing docs to the LOT-018 capability-aware bridge changes.

[sourcery-ai]

Reviewer's Guide

Documentation-only PR that updates configuration, CLI, architecture, index, README, and changelog texts (EN/FR) to match the new capability-aware, role-based Bearer auth bridge, including the token-store configuration and the no-credential-in-browser web flow.

Sequence diagram for the no-credential-in-browser web flow

sequenceDiagram
actor Browser
participant dcs_client_web
participant dcs_serve

Browser->>dcs_client_web: GET /config.json
dcs_client_web-->>Browser: host, port

Browser->>dcs_client_web: POST /ws-ticket
dcs_client_web->>dcs_serve: POST /api/ws-ticket (Authorization: Bearer token)
dcs_serve-->>dcs_client_web: WebSocket ticket
dcs_client_web-->>Browser: WebSocket ticket

Browser->>dcs_serve: CONNECT /ws/stream?ticket=... (WebSocket)

Loading

File-Level Changes

Change	Details	Files
Update configuration docs to describe Bearer tokens, role-based token store, and the new web client flow that keeps durable tokens server-side.	Describe api_key as a durable Bearer token used as superuser during transition instead of an X-API-Key. Introduce optional tokens_file pointing to dcs-tokens.yaml and document its YAML schema with role/label/ucid/expiry fields. Explain that REST clients now send Authorization: Bearer <token> and that the legacy api_key continues to work as a superuser token if the store is absent. Clarify that the client api_key must match an accepted Bearer token and that its role gates which actions succeed. Revise web client description so /config.json exposes only host/port and the browser obtains short-lived WS tickets via /ws-ticket, with an explicit note that no credentials reach the browser.	docs/guide/configuration.en.md docs/guide/configuration.fr.md
Align CLI reference docs with the server-side token handling and ephemeral WebSocket ticket mechanism for the web client.	Explain that the local web server reads host/port/token from dcs-client.yaml and keeps the token server-side. State that GET /config.json now returns only host/port, and the browser receives short-lived WS tickets via POST /ws-ticket. Remove previous wording about exposing the API key via /config.json and the associated warning.	docs/guide/cli-reference.en.md docs/guide/cli-reference.fr.md
Update high-level architecture and index docs to reflect capability-aware actions and role-based Bearer authentication instead of X-API-Key.	Change FastAPI middleware description from X-API-Key to Bearer-token role-based auth. Update dcs-serve feature bullets to mention capability-aware actions and role-based auth rather than API key authentication. Adjust French index wording to match the new role-based Bearer auth and capability-aware actions.	docs/technical/architecture.en.md docs/technical/architecture.fr.md docs/index.en.md docs/index.fr.md
Correct README diagrams and feature bullets to match the current bridge behavior and capability/catalogue model.	Update the TCP port in the ASCII diagram from 9999 to 7777. Replace X-API-Key auth with role-based Bearer auth and capability-aware actions in the dcs-serve line. Refresh client feature bullets to mention capability-aware semantic actions, catalogue-driven MCP tools, and capability-filtered UI panels.	README.md
Record the documentation sync in the changelog, tying it to LOT-018 and summarizing the new auth and catalog-driven behavior.	Add a changelog entry describing the docs sync: Bearer + role-based auth, dcs-tokens.yaml configuration, no-credential-in-browser web flow, catalogue-driven MCP tools, and removal of stale X-API-Key/port 9999/old tool references.	CHANGELOG.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• In the configuration docs, api_key is now described as a durable Bearer token but the field name remains api_key; consider adding a brief inline note clarifying that the legacy field name is intentional to avoid confusion for existing users scanning the YAML examples.
• The description of the WebSocket ticket flow is spread across configuration, CLI reference, and changelog; adding a short, centralized subsection that diagrams or summarizes the GET /config.json + POST /ws-ticket interaction could make the browser-no-credentials story easier to follow end-to-end.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the configuration docs, `api_key` is now described as a durable Bearer token but the field name remains `api_key`; consider adding a brief inline note clarifying that the legacy field name is intentional to avoid confusion for existing users scanning the YAML examples.
- The description of the WebSocket ticket flow is spread across configuration, CLI reference, and changelog; adding a short, centralized subsection that diagrams or summarizes the `GET /config.json` + `POST /ws-ticket` interaction could make the browser-no-credentials story easier to follow end-to-end.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}