Document protected main workflow (#5)

* Document protected main workflow

* Tighten CodeRabbit review policy

Author: skel84

AGENTS.md

@@ -45,7 +45,9 @@ Project-specific design and engineering rules live in:
   issue-less.
 - Keep each PR scoped to one planned task such as `M2-T08`, or one tightly related bundle small
   enough to review in one pass.
-- Treat CodeRabbit as advisory but mandatory to triage. Apply correctness, safety, recovery, test,
+- Treat CodeRabbit as part of the required review path when it is enabled on the repository.
+  Address every substantive CodeRabbit comment explicitly before merge by either applying the
+  change or documenting why it is not being applied. Apply correctness, safety, recovery, test,
   and docs-alignment feedback by default; document why you reject suggestions that would weaken
   determinism, boundedness, or trusted-core discipline.
 - After review-driven edits, rerun the relevant validation commands before considering the work

CONTRIBUTING.md

@@ -72,18 +72,22 @@ Add narrower commands too when they strengthen confidence for the specific chang
 
 - human review focuses first on correctness, regressions, missing tests, recovery behavior, and
   docs drift
-- CodeRabbit is advisory, but every substantial suggestion must be triaged explicitly
+- CodeRabbit is part of the review path when enabled on the repository
+- every CodeRabbit suggestion or comment that affects the PR must be addressed explicitly before
+  merge
 - apply CodeRabbit suggestions by default when they improve correctness, safety, testing,
   observability, or documentation
 - reject CodeRabbit suggestions when they add churn without value or weaken determinism,
   boundedness, dependency discipline, or trusted-core isolation
 
-Keep a short triage note in the PR description or comments:
+Addressing CodeRabbit means one of:
 
 - `applied`
 - `not applied`
 - short reason when not applied
 
+Do not leave substantive CodeRabbit comments unresolved or silently ignored.
+
 ## Merge Policy
 
 Until the repository has more human reviewers, self-merge is acceptable only after:
@@ -94,6 +98,19 @@ Until the repository has more human reviewers, self-merge is acceptable only aft
 
 When the team grows, switch to at least one human approval before merge.
 
+## Repository Guardrails
+
+The GitHub repository is configured so that `main`:
+
+- requires pull requests before merge
+- requires the `checks` CI job and uses strict status checks
+- requires resolved review conversations
+- requires linear history
+- disallows force pushes and branch deletion
+
+When enabled on the repository, CodeRabbit is part of the normal review path and its feedback must
+be addressed before merge.
+
 ## Labels And Milestones
 
 Recommended milestone shape: