One cohesive delivery
Start new work in a clean task branch from currentorigin/main; preserve unrelated
work. Build the complete related capability, including integration, tests, and QA,
in one PR. Split only when separate releases have a concrete operational benefit.
Use the PR template:
outcome, risk tier, scope, acceptance, validation, and rollback. Keep it brief and
accurate. Scope describes behavior; there is no file allowlist or diff-size limit.
Protected changes require critical risk and a reason in Scope. PR metadata is
public, so exclude secrets and private client facts.
Validation and review
Use focused tests while building, then assess the integrated result with a separate QA agent. Reuse sufficient existing coverage and hosted CI rather than repeating it locally. New tests cover meaningful gaps; a source edit does not require a matching test-file edit. Visible UI changes need proof from the running application; API-only and nonvisual changes do not require screenshots. The reviewer assesses completeness, correctness, integration, and realistic risk. The owner resolves concrete findings in the same PR. New code needs current-head approval; unchanged tests and findings can be reused. Valid metadata edits alone need no repeat code review or custom attestation. Required CI and live metadata checks run automatically. Native GitHub protection requires independent approval, resolved conversations, and passing checks before merge queue delivery. The authoritative configuration and check names are in the live protection setup.Holds and recovery
Respecthalt-agents and needs-replan. Use them for an explicit hold or real
impasse, not an ordinary failed test. Recovery uses the existing auto-revert path.
A protection bypass requires an explicit instruction for the named operation.