docs: require approval before merge deploy

Author: jontsai

AGENTS.md

@@ -21,9 +21,10 @@ If sensitive data is committed, notify the maintainer immediately. Force-pushing
 - Any push to `master` deploys production
 - There is no staging environment in this repo
 
-### Golden rule
+### Golden rules
 
 > Never push directly to `master` without explicit maintainer approval.
+> Never merge a PR or run `make deploy` without explicit maintainer approval in the same conversation. A request to implement, fix, add, or prepare a change is approval to open a PR only; it is not approval to merge or deploy.
 
 ## Required workflow
 
@@ -32,7 +33,8 @@ If sensitive data is committed, notify the maintainer immediately. Force-pushing
 3. Test locally
 4. Build before handing off for review
 5. Open a PR
-6. Merge to `master` only after approval
+6. Stop and wait for explicit maintainer approval before merging or deploying
+7. Merge to `master` or run `make deploy` only after that explicit approval
 
 ## Source of truth
 
@@ -63,6 +65,13 @@ make deploy      # production deploy: build docs/, commit them, and push to orig
 - Confirm changes belong in source files, not accidental edits to generated output only
 - Confirm the branch is intended for PR review, not direct production deploy
 
+## Before you merge or deploy
+
+- Confirm Jonathan/maintainer explicitly approved the merge or deploy in the current conversation
+- Do not infer merge/deploy approval from a request to implement, test, fix, add, or open a PR
+- If approval is unclear, ask once and wait
+- Rollbacks require explicit rollback authorization; rollback permission does not authorize unrelated merges/deploys
+
 ## Project guidance index
 
 - `CONTRIBUTING.md` — human contributor workflow and PR checklist

CONTRIBUTING.md

@@ -19,7 +19,7 @@ Before making changes, read:
 4. Run the smallest validation that matches your change.
 5. Open a pull request with a short summary and the validation you ran.
 
-`master` deploys directly to production through GitHub Pages, so merges should be deliberate and reviewed.
+`master` deploys directly to production through GitHub Pages, so merges should be deliberate, reviewed, and explicitly approved. Implementation requests authorize preparing a branch/PR only; they do not authorize merging or deploying.
 
 ## Common commands
 
@@ -43,6 +43,7 @@ Before requesting review, confirm:
 - Generated output changes are intentional.
 - Relevant validation passed, or any blocker is clearly documented in the PR.
 - The PR description explains what changed and how it was tested.
+- Maintainer approval to merge/deploy is explicit in the current conversation; if not, stop at the PR.
 
 ## Style expectations
 

agent-docs/repository.md

@@ -19,6 +19,8 @@ Do not hand-edit `docs/` unless you are intentionally fixing generated output as
 - GitHub Pages serves the generated `docs/` directory
 - `docs/.nojekyll` is required for GitHub Pages to serve Next.js output correctly
 - `make deploy` is a production deploy command: it builds `docs/`, commits the generated output, and pushes to `origin master`
+- Do not merge to `master` or run `make deploy` without explicit maintainer approval in the same conversation
+- Treat implementation/fix requests as approval to prepare a PR only, not approval to ship production changes
 
 ## Key config files
 
@@ -42,6 +44,7 @@ When changing configuration, keep docs concise and avoid duplicating file conten
 - Open a PR for review
 - Keep commits focused
 - Review generated output before shipping it
+- Stop at the PR until Jonathan/maintainer explicitly approves merge/deploy
 
 ## Public-repo security