Enforce Code Cannon's hard workflow rules through git and platform gates instead of relying on agent instructions

[sebastientaggart]

Problem to Fix

Code Cannon's non-negotiable workflow rules — work only on an approved feature branch, one change per ticket, always open a pull request, pass review before merging — currently live as written instructions that each developer's AI agent is asked to follow. Different agents on different tools honor them to different degrees, and a rule written as a suggestion can simply be skipped. Nothing actually stops a rule from being broken.

Why it Matters

Consistent enforcement of business rules across a team using different AI tools is the entire point of Code Cannon. Instructions that agents "should" follow drift — that is the exact problem Code Cannon was built to escape. For rules that must never be broken (especially in compliance-sensitive work), enforcement has to sit outside the agent so it binds everyone identically, no matter which tool they use. This backbone is also a prerequisite for extending Code Cannon to new domains: it becomes the reusable pattern for how any future skill group enforces its own rules.

General Approach

Move the hard, non-negotiable rules out of written skill instructions and into automated gates that live in the code repository and on the hosting platform — checks that run automatically and block the action when a rule is violated, regardless of which agent or person triggered it. Written skills continue to guide the normal flow; the automated gates become the backstop that makes compliance mandatory rather than voluntary. Document the setup as a repeatable pattern a future skill group can adopt.

Complexity

Verification / QA effort: significant
Requires standing up repository-side and platform-side checks and confirming they block violations when driven by different agent tools, while ensuring they don't obstruct the legitimate happy path. Part of the effort is design: deciding exactly which invariants belong in local repository checks versus platform-side merge gates.

Acceptance Criteria

• Committing or pushing outside an approved feature branch is automatically rejected, regardless of which agent or tool is used.
• Merging a change that has not passed the required review is blocked at the hosting-platform level, not merely discouraged in instructions.
• The normal, compliant workflow proceeds without new friction for developers who follow the rules.
• The enforcement setup is documented as a repeatable pattern that a future skill group can adopt.

[sebastientaggart]

Agent Implementation Notes

Origin: Strategy discussion on whether Code Cannon stays relevant given the current harness. Conclusion: CC's durable value is policy distribution (PM defines rules once → they compile to every developer's harness via the sync/adapter layer). But distribution and enforcement decouple, and the value is enforcement. Today CC's hard invariants live in skill-prose — each harness's agent chooses whether to comply. This ticket moves them to substrate-level gates.

Why not harness hooks (Claude settings.json)

They only fire on Claude. CC is multi-harness by requirement (colleagues may be on Cursor/Codex/Gemini). The portable substrate is git + GitHub, which binds every developer and every agent because it lives outside the harness.

Proposed split (design work is part of this ticket)

• Local git hooks (pre-commit / pre-push) committed to the consumer repo: reject commits off a feature/* branch; enforce sync.py up-to-date (a variant of the existing pre-commit hook); block direct commits to BRANCH_PROD/BRANCH_DEV.
• GitHub branch protection / required status checks: block merge to protected branches without a passing review status and a linked issue. This is what makes the review gate real rather than a prose instruction the agent may skip.
• Skills keep guiding the happy path; the gates are the backstop.

Key design decisions to make

• Which invariants are local-hook-enforceable vs. only platform-enforceable (e.g. "review passed" is a platform status; "on a feature branch" is a local hook).
• How consumers install the hooks (CC is vendored as a submodule at CodeCannon/ — a make install-hooks target, or a setup step, that symlinks/copies hooks into .git/hooks).
• How the review status gets recorded so branch protection can require it (see submit-for-review aborts at merge when the review agent leaves the shared working tree on a different branch #197-area review flow; ties into ticket "delegate review to /code-review").

Strategic role

This backbone becomes the reusable enforcement pattern every future skill group adopts. It is a prerequisite for expanding CC to new domains (e.g. proposal writing) — a domain earns a CC group only if it has a machine-checkable gate, and this defines what "a gate" looks like.

Dependencies / relationships

• Complements the "delegate review to native /code-review" ticket (that ticket produces the review; this ticket enforces that it happened).
• Prerequisite for the deferred proposal-writing group.