Docs Sync

Doc-first pass: review existing pages

• Walk each relevant page under docs/ (excluding docs/ja, docs/ko, and docs/zh).
• Identify missing mentions of important, supported options (opt-in flags, env vars), customization points, or new features from src/agents/ and examples/.
• Propose additions where users would reasonably expect to find them on that page.

Code-first pass: map features to docs

• Review the current docs information architecture under docs/ and mkdocs.yml.
• Determine the best page/section for each feature based on existing patterns and the API reference structure under docs/ref.
• Identify features that lack any doc page or have a page but no corresponding content.
• Note when a structural adjustment would improve discoverability.
• When improving docs/ref/* pages, treat the corresponding docstrings/comments in src/ as the source of truth. Prefer updating those code comments so regenerated reference docs stay correct, instead of hand-editing the generated pages.

Detect gaps and inaccuracies

• Missing: features/configs present in main but absent in docs.
• Incorrect/outdated: names, defaults, or behaviors that diverge from main.
• Structural issues (optional): pages overloaded, missing overviews, or mis-grouped topics.

Produce a Docs Sync Report and ask for approval

• Provide a clear report with evidence, suggested doc locations, and proposed edits.
• Ask the user whether to proceed with doc updates.

If approved, apply changes (English only)

• Edit only English docs in docs/**.
• Do not edit docs/ja, docs/ko, or docs/zh.
• Keep changes aligned with the existing docs style and navigation.
• Update mkdocs.yml when adding or renaming pages.
• Build docs with make build-docs after edits to verify the docs site still builds.