Docs sync

Goal

Update documentation so it matches the current code and is easy for the target audience to follow.

Inputs to ask for (if missing)

• What changed (feature/bugfix/refactor) and who the docs are for.
• Which docs surfaces matter: README, /docs, wiki, runbooks, API spec, changelog, onboarding.
• Any required format/voice (company style guide, “keep it short”, etc.).

Workflow (checklist)

1. Identify what changed
   • Use the diff to locate impacted areas:
     • git diff --name-only
     • git diff
2. Inventory docs surfaces in the repo
   • Common locations: README.md, docs/, CONTRIBUTING.md, CHANGELOG.md, openapi.*, schema.graphql, adr/, runbooks/.
   • For Spring: check for generated OpenAPI/Swagger docs or endpoint annotations.
   • For Next/TypeScript: check for docs pages, Storybook, or typed API clients.
   • If your repo uses docs/ as the primary doc root, see references/docs-structure.md for a suggested layout.
3. Decide what needs updating
   • Ensure docs cover:
     • setup and local dev commands
     • required env vars / config keys
     • API contract changes (request/response examples)
     • DB migrations and operational steps
     • behavior changes visible to users
   • If the change is an architectural/behavioral decision, add or update an ADR (use references/adr-template.md).
4. Apply edits with minimal churn
   • Prefer small, targeted edits over rewrites.
   • Add examples that are copy/paste runnable.
   • Keep headings stable to avoid breaking deep links.
   • Use templates in references/ when helpful.
5. Verify docs are consistent
   • Run the repo’s existing doc checks if present (md lint, docs build, site build).
   • At minimum: ensure code fences match the actual commands and file paths, and env var names match the code.

Deliverable

Provide:

• The list of docs files updated and why.
• A short “How to verify” section (commands or manual checks).