feat(rules): make green-gate shipping actions autonomous #178
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,53 @@ | ||
| --- | ||
| alwaysApply: true | ||
| description: A green gate is the go-ahead; pausing to ask for approval the gate already granted is the violation. | ||
| --- | ||
|
Comment on lines
+1
to
+4
Owner
Author
There was a problem hiding this comment. Declining —
Measured against the repo it's also unremarkable: Your underlying point is fair and I acted on the part that is binding: cut both worked examples ( Separately worth flagging to the maintainer, not fixable here: that budget has no upper bound and the exemption list is open-ended (
Comment on lines
+1
to
+4
Owner
Author
There was a problem hiding this comment. Stale PR-description nit — the description text predates the current head (the rule went 37→51→65 lines across review rounds, gates 4→the full What Still Gates list). The code is correct as it stands; the PR body wasn't kept in lockstep. Not a code finding. |
||
|
|
||
| # Autonomous Shipping | ||
|
|
||
| ## Green Gate Is the Approval | ||
|
|
||
| - A shipping action is the autonomous next step once its gate reads green | ||
| - Read the gate to resolve doubt; never ask the operator what reading it answers | ||
|
|
||
| - Authorization to ship is standing — it lives in this policy and the operator's durable config, in no conversational turn | ||
| - A challenging question, an ambiguous remark, an earlier "ship it when green", or silence is never the grant | ||
| - No standing grant covers the action ⇒ the gate is absent, not green (see What Still Gates) | ||
| - A harness gate this policy does not govern (safety classifier, permission prompt) is a red gate — surface what it blocked; never re-attempt through another tool | ||
|
|
||
|
|
||
| ## What Counts as Approval | ||
|
|
||
| - Review is the paired bot fleet, not a human sign-off — a merge needs no human approval, except where another always-on rule names an owner-approval precondition (see What Still Gates) | ||
| - The merge gate has two halves, both required: `skills/release/SKILL.md` Step 7's executable preconditions hold (watcher-checked) AND no What Still Gates condition applies (agent-checked) | ||
| - Load Step 7 and confirm What Still Gates before merging; this rule restates neither | ||
|
Contributor
There was a problem hiding this comment.
|
||
| - A gating bot that cannot `APPROVE` posts its all-clear as `COMMENTED` — `github-actions[bot]` gets HTTP 422 (see `rules/ci-safety.md` Superseded-Bot-Review Dismissal Carve-Out) | ||
|
|
||
| ## The Autonomous Actions | ||
|
|
||
| - **Open the PR** — Step 1 readiness checks pass (`skills/release/SKILL.md`) ⇒ push and open | ||
| - **Dismiss superseded bot reviews** — a bot's `CHANGES_REQUESTED` its own later all-clear superseded ⇒ dismiss it via `skills/release/dismiss-stale-reviews.sh`, or a hand dismissal meeting both preconditions (see `rules/ci-safety.md` Superseded-Bot-Review Dismissal Carve-Out) | ||
|
|
||
| - **Merge** — Step 7's preconditions hold ⇒ merge and clean up | ||
| - **Watch through publish** — the merge lands ⇒ watch the run, the registry advance, the moderation clear per `rules/ci-safety.md` Always Watch CI; part of the merge, not a separate decision | ||
|
|
||
|
|
||
| ## Asking vs Surfacing | ||
|
|
||
| - An ask on a green gate is a defect | ||
| - Report the action taken, never propose it | ||
|
|
||
| - Never re-ask what the policy grants standing | ||
| - Surface every decision the gate does not answer: scope, base branch, a human's prose hold, whether an out-of-scope discovery belongs in the task | ||
| - A question the gate does not answer is an absent grant, not a green one | ||
| - Re-reading this policy never resolves an absent grant | ||
| - Uncertainty that the rule covers an action means it does not — report and stop | ||
|
|
||
| ## What Still Gates | ||
|
|
||
| - These block a merge even when Step 7's gate reads green; the agent checks them, the watcher does not | ||
|
Contributor
There was a problem hiding this comment.
Owner
Author
There was a problem hiding this comment. Fixed in d3e8caf — tightened 66→46 lines. I declined this from Copilot earlier on the multi-aspect exemption, and the exemption does apply (
Every gate the adversarial rounds added survives — platform bypass, Bootstrap-Red, prose holds, PENDING reviews, draft markers, base branch, standing-auth, the asking/surfacing split. 5 H2 sections, no connectives, cross-refs resolve. At 46 lines it's shorter than testing-standards and five other multi-aspect rules — comfortably inside the exemption now, rather than relying on it at 66. |
||
| - A platform-rejected merge — never `--admin`, never a ruleset or branch-protection bypass; surface the blocking rule | ||
|
|
||
| - An owner-approval precondition named by another always-on rule (`rules/ci-safety.md` Bootstrap-Red Carve-Out); no bullet here retires it | ||
| - An unplanned CI-config edit, even to turn a red gate green (`rules/ci-safety.md` Hands Off CI Config) | ||
| - Force-push over shared or protected history, tag or release deletion — any action with no undo. Force-pushing your own feature branch to land a rebase is routine, not gated | ||
| - Direct push to a protected branch outside `rules/ci-safety.md` Content-Only Direct-Push Carve-Out | ||
| - A human reviewer's `CHANGES_REQUESTED`, a prose hold ("wait", "I'll approve after X"), or a `PENDING` human review — autonomous dismissal covers bot reviews only | ||
| - A PR marked not-ready — draft status, a `do-not-merge` or WIP label, a title marker | ||
| - A base branch the task never named — a stacked or mis-based PR is not the agreed task | ||
| - A repo the operator does not own (`rules/external-repo-contributions.md`) | ||
| - Scope never granted — an out-of-scope boy-scout discovery and drive-by dependency work are new tasks, not ship authorization (in-scope cleanup rolls into the PR per `rules/boy-scout.md` How to Apply) | ||
|
Contributor
There was a problem hiding this comment.
Owner
Author
There was a problem hiding this comment. Surfacing this to the operator rather than tweaking into the opposite violation again — it's a genuine catch-22 with last round's finding. Last round you flagged the Asking vs Surfacing bullets as non-atomic; I split them, growing the rule 46→53 lines. Now you flag 53 > 40. The two context-writing-style requirements — 'atomic bullets, one directive per bullet' AND '~25-40 lines' — cannot both hold for a rule with this many distinct directives: satisfying one violates the other. The multi-aspect exemption (Scope: rules covering one policy area with several sub-aspects may run larger) applies in my reading — this covers shipping autonomy across 5 sub-aspects and at 53 lines is shorter than ci-safety (126), context-artifacts (96), plugin-evals (89), skill-authoring (80), dependency-management (58). You classify it single-concept. That classification is the operator's call on their own policy; flagged for their decision. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rules/context-artifacts.mdsays CHANGELOG consolidation must "retain load-bearing facts (what changed, references)". This entry still describes an older design: it says "the gate is exactly Step 7's preconditions", but the rule now says the merge gate has two required halves, Step 7's executable preconditions plus no What Still Gates condition, and Step 7 now adds that same agent-checked half. Please update this entry to match the final contract and the current section names (Asking vs Surfacing), or trim the stale design detail entirely.