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).