Versioning and drafts

• /v1/ — published. Frontend, Middleware Backend, and Core Backend implement this.
• /next/ — proposed changes. Review on a PR preview. Do not treat /next as production.

When a route moves (example: create business later goes to Middleware Backend), rewrite the playbook on /next first. After review, promote to a new published version or a changelog bump on v1.

What a change must include

1. Winner URL updated (Middleware Backend if it now owns the job)
2. Status badge (implemented / partial / to implement)
3. Core metadata keys if the payload changed (that playbook’s ENV / Metadata Catalog; Core catalog is canonical)
4. ENV names if a new sample or GitHub Action var appeared (same catalog)
5. Changelog only on the next successful push of this docs repo (one version covering all edits since the last push). Do not add a version per prompt.

Compulsory process: prompts/iterate-docs.md.