# Update mode

Use this workflow when the input is an existing documentation Markdown file or the user asks to refresh existing component documentation.

## Input handling

- Read the existing documentation first to understand the current structure, terminology, and any front matter metadata.
- Extract the component source path from the `component_path` front matter when present.
- If `component_path` is missing, infer the component path from the documentation content and surrounding repository structure.
- Use the current implementation as the source of truth when the documentation and code disagree.

## Update-specific requirements

- Preserve the existing documentation file as the output target.
- Preserve `date_created`.
- Update `last_updated` to the current date.
- Preserve version history and ownership metadata when still accurate; refresh them only when the code or repository evidence indicates they have changed.
- Maintain the existing organization where it is still useful, but ensure the content remains consistent with the shared template expectations.

## Update-specific analysis focus

- Compare the existing documentation with the current code to identify stale APIs, outdated diagrams, renamed dependencies, and changed usage patterns.
- Highlight breaking changes, deprecated features, or major architectural shifts when they are evident.
- Refresh method tables, examples, diagrams, dependency lists, and quality attribute notes to match the implementation as it exists today.
- Add missing sections only when the component has grown or the current documentation omits information now needed for maintainers.

## Update-specific output guidance

- Keep useful editorial choices from the existing document, but remove stale or misleading content.
- Update examples so they compile conceptually against the current API shape.
- Refresh Mermaid diagrams rather than replacing them with generic placeholders.
- Add migration notes or change history when the update reveals important compatibility or behavior changes.