Documentation that updates itself on every merged pull request

What happens when a pull request is merged

• The push to your main branch triggers a scan. Pushes to feature branches are ignored, so the docs always describe merged code.
• Only the endpoints whose code changed are documented again. Everything else is reused, so an update takes minutes and costs little.
• Business logic, the data-access map and the endpoint reference are rebuilt from the new facts.
• The new version is synced to Notion, Confluence, GitHub Wiki, Azure DevOps Wiki, GitBook or SharePoint.

A changelog your whole team can read

Each merge adds one short entry to a Recent Changes section. It is written from a real comparison of the code before and after, not from the PR description.

• Merged pull requests, by number and title.
• Endpoints added, removed or changed, and what changed in their behaviour: a new business rule, a new input, a table that is now written, a new external service.
• Data model changes: tables and fields added or removed.
• Two to five plain-language bullets a product manager understands.
• Internal-only changes are described from the diff too, with the files that moved the most.

Why the docs can be trusted

• Every endpoint is documented by reading its handler and everything it calls, not by guessing from file names.
• Every file the documentation cites is checked to exist in your repository.
• Manual edits survive rescans. Your correction is kept and turned into a rule for the next scan.
• Every version is stored, so you can see what the docs said last month.

What this replaces

• The Confluence page that was right in March.
• The onboarding call where one senior engineer explains the payment flow again.
• The Slack thread asking which endpoint writes to that table.
• The release note nobody had time to write.