Document branch protection governance

Author: Ring-wdr

.github/PULL_REQUEST_TEMPLATE.md

@@ -13,3 +13,4 @@
 
 - Keep the PR focused.
 - Call out any follow-up work explicitly instead of bundling it into this change.
+- Do not relax branch protection, required reviews, or required CI checks to merge this PR. Governance changes should be handled separately from feature or docs changes.

AGENTS.md

@@ -0,0 +1,25 @@
+# Agent Instructions
+
+This repository is maintained under strict branch protection. Treat those protections as part of the repository policy, not as temporary friction to work around.
+
+## Branch Protection Policy
+
+- Never change branch protection rules, rulesets, required reviews, required status checks, or admin enforcement in order to land a change unless the user explicitly asks for that exact repository-governance change.
+- Never disable `CODEOWNERS` review requirements, required approving review counts, required conversation resolution, or required CI checks just to merge a PR.
+- Never push directly to a protected branch to bypass the normal review or CI path.
+- Never use admin merge, force push, or equivalent bypass mechanisms to land a change unless the user explicitly asks for that governance exception.
+- If branch protection blocks a merge, stop and tell the user what requirement is still unmet.
+
+## Preferred Flow
+
+1. Make the change on a feature branch.
+2. Open a PR.
+3. Let required CI checks complete.
+4. Wait for the required review state.
+5. Merge only through the normal repository policy path.
+
+## If Blocked
+
+- Report the exact protection rule that is blocking progress.
+- Ask the user whether they want to satisfy the rule or intentionally change repository governance.
+- Treat repository-governance changes as a separate task from the feature or docs change that triggered the block.

CONTRIBUTING.md

@@ -32,6 +32,7 @@ Thanks for contributing to `react-devtool-cli`.
 - Add or update tests when behavior changes.
 - Preserve the CLI's bias toward deterministic, structured output.
 - Do not bundle unrelated refactors into the same PR.
+- Do not weaken branch protection, bypass required reviews, or disable required CI checks to land a change. If protection blocks a merge, satisfy the rule or ask the maintainer whether repository governance should change as a separate decision.
 
 ## Development
 

docs/public-repo-strategy.md

@@ -51,3 +51,10 @@ This repository is run as a solo-maintainer open source project. The operating m
 - Discussions disabled unless issue volume justifies a separate support channel
 - Secret scanning enabled when available
 - Topic metadata kept current so the repo is discoverable without overselling scope
+
+## 8. Governance Guardrails
+
+- Branch protection is part of the maintenance policy, not a convenience setting.
+- Do not reduce required reviews, required checks, or code owner enforcement just to land an otherwise-ready PR.
+- Do not use admin overrides for normal day-to-day maintenance.
+- If a branch protection rule becomes counterproductive, change that governance intentionally in a separate maintainer decision, not as part of shipping an unrelated fix.