Add deck-contribute workflow (deck triage → mechanic-clustered PRs)

.cargo/config.toml

@@ -14,6 +14,7 @@ rules-audit = "run --profile tool --bin rules-audit --features audit --"
 semantic-audit = "run --profile tool --features cli --bin oracle-gen -- semantic-audit"
 scrape-feeds = "run --release -p feed-scraper --"
 tune-ai = "run --release --features tune --bin ai-tune --"
+ai-gate = "run --bin ai-gate --"
 engine-inventory = "run --quiet -p engine-inventory-gen"
 
 [env]

.claude/agents/engine-implementation-executor.md

@@ -125,12 +125,12 @@ If any modified file is under `crates/engine/src/parser/`, inspect added lines f
 ```bash
 git diff --name-only | grep 'crates/engine/src/parser/' | while read f; do
   git diff "$f" | grep '^+' | grep -v '^+++' | grep -vE '^\+\s*//' \
-    | grep -E '\.(contains|starts_with|ends_with|find)\(' \
+    | grep -E '\.(contains|starts_with|ends_with|find|rfind|split|splitn|rsplit|split_once)\(' \
     | grep -v '#\[test\]' | grep -v '#\[cfg(test)\]'
 done
 ```
 
-Any output is a hard failure unless it is a test, comment, explicitly annotated non-dispatch structural use, or `oracle_util.rs` dual-string `TextPair` helper work.
+The `rfind`/`split`/`split_once`/`rsplit` arms are deliberate: `scripts/check-parser-combinators.sh` does not catch them, so a green gate is not proof of combinator compliance — this inline grep covers that blind spot. Any output is a hard failure unless it is a test, comment, explicitly annotated non-dispatch structural use, or `oracle_util.rs` dual-string `TextPair` helper work.
 
 For parser changes always run additionally:
 
@@ -140,17 +140,41 @@ cargo coverage
 cargo semantic-audit
 ```
 
+### Discriminating-test gate
+
+Every behavioral change MUST ship at least one test that drives the real pipeline (`apply()` / the scenario runner / the cast-pipeline harness) and **would fail if the fix were reverted**. A test that only asserts the parsed AST shape — an `assert_eq!` on a parsed `AbilityDefinition` / `Effect` / `StaticMode` without resolving it through the engine — does NOT satisfy this gate. It is a shape test, not a regression test.
+
+Confirm discrimination concretely before returning:
+
+- For the primary fix, name the assertion that flips when the fix is reverted. If you cannot name one, the test does not discriminate — add one that does.
+- Trace each test fixture through the fix's first input-shape dispatches (`is_none()` / `is_empty()` / variant `match` / "has-X" guards). If every fixture is degenerate in the same way (no ability, no targets, empty or single-element collection, all-generic cost), the test likely takes a different internal branch than production inputs and silently passes — reach the real arm instead. (Precedent: an Emerge cost-reduction test whose all-generic sacrifice made the wrong reduction coincide with the right one; an Undaunted test that called a function the reduction never runs in, so the positive case could not pass.)
+
+This is the single most common defect the `/review-impl` loop catches (shape-only tests on keyword and parser PRs). Catch it here, before review.
+
+### CR-annotation diff gate
+
+Before returning, grep every CR number you added or changed **in the diff** against `docs/MagicCompRules.txt` — not just the ones you remember writing:
+
+```bash
+git diff | grep -E '^\+' | grep -oE 'CR [0-9]{3}(\.[0-9]+[a-z]?)?' | sed 's/^CR //' | sort -u \
+  | while read -r n; do grep -qE "^${n}([^0-9]|$)" docs/MagicCompRules.txt || echo "UNVERIFIED: CR ${n}"; done
+```
+
+Any `UNVERIFIED:` line is a hard stop — the rule number does not exist in the rules text (a hallucinated subpart, e.g. the recurring `702.808` / wrong-keyword-subpart class) or is malformed. Re-derive the correct rule or flag it explicitly; never ship an unverified CR annotation. A clean grep is necessary but not sufficient: also confirm the cited rule actually *describes* the annotated code, not merely that the number exists.
+
 ## Output
 
 Return a structured report to the orchestrator:
 
 1. **Diff summary** — files touched, grouped by subsystem, with a one-line purpose per file.
 2. **Verification results** — which Tilt resources are green; any failures with `tilt logs` excerpts (own vs unrelated).
 3. **Parser diff gate** — pass/fail with offending lines if any.
-4. **Judgement calls** — any place you had to choose between two readings of the plan, with the reasoning.
-5. **Stop-and-return items** — any places you stopped rather than improvise.
-6. **CR annotations added/changed** — each one with the grep command that verified it.
-7. **Deviations from the plan** — what changed vs. the plan and why.
-8. **Risks** — anything the orchestrator's `/review-impl` loop should pay extra attention to.
+4. **Discriminating-test gate** — for the primary fix, the assertion that flips when the fix is reverted, and confirmation no production-reachable arm is left covered only by a degenerate fixture. State if any test is shape-only.
+5. **CR-annotation diff gate** — the grep result; list any `UNVERIFIED:` rule, or confirm zero.
+6. **Judgement calls** — any place you had to choose between two readings of the plan, with the reasoning.
+7. **Stop-and-return items** — any places you stopped rather than improvise.
+8. **CR annotations added/changed** — each one with the grep command that verified it.
+9. **Deviations from the plan** — what changed vs. the plan and why.
+10. **Risks** — anything the orchestrator's `/review-impl` loop should pay extra attention to.
 
 Do NOT commit. Do NOT push. The orchestrator decides what to stage and when.

.claude/agents/pr-review-comment-resolver.md

@@ -52,14 +52,43 @@ Accept:
 
 ### 2. Fetch Review Feedback
 
-Fetch all relevant feedback:
+Fetch all feedback in ONE GraphQL call. **Most actionable feedback on this repo is top-level — PR review bodies (where Gemini's summary review and most human reviews land) and issue/conversation comments — not file/line-anchored inline threads.** GraphQL is the idle rate-limit bucket, so one query avoids the per-PR REST `--paginate` walk that drains `core`; more importantly it fetches all three feedback objects **comprehensively**, which the "all blocking review comments resolved" gate requires:
 
 ```bash
-gh pr view <PR> --repo phase-rs/phase --json reviewDecision,reviews,comments
-gh api repos/phase-rs/phase/pulls/<PR>/comments --paginate
-gh api repos/phase-rs/phase/issues/<PR>/comments --paginate
+# First page: omit the cursor vars (they default to null = from the start).
+# To paginate, pass the connection's endCursor back via -F <conn>Cursor=<endCursor>.
+gh api graphql -F owner=phase-rs -F name=phase -F pr=<PR> -f query='
+query($owner:String!,$name:String!,$pr:Int!,$reviewsCursor:String,$commentsCursor:String,$threadsCursor:String) {
+  repository(owner:$owner, name:$name) {
+    pullRequest(number:$pr) {
+      reviewDecision
+      reviews(first:100, after:$reviewsCursor) {              # top-level review bodies (Gemini summary, human reviews) — the MAJORITY
+        pageInfo { hasNextPage endCursor }
+        nodes { author{login} body state submittedAt url }
+      }
+      comments(first:100, after:$commentsCursor) {            # top-level issue/conversation comments
+        pageInfo { hasNextPage endCursor }
+        nodes { author{login} body url createdAt }
+      }
+      reviewThreads(first:100, after:$threadsCursor) {        # inline (file/line) threads + resolved state — the minority
+        pageInfo { hasNextPage endCursor }
+        nodes { isResolved isOutdated path line
+                comments(first:50) { pageInfo { hasNextPage endCursor }
+                                     nodes { author{login} body url createdAt } } }
+      }
+    }
+  }
+}' --jq '.data.repository.pullRequest'
 ```
 
+Comprehensiveness rules for the gate:
+
+- **Top-level `reviews` and `comments` have no `isResolved` flag** — read every one's **body** for actionable findings and judge whether each is addressed in the current commits. Do NOT gate on review `state`: the dominant reviewer here (Gemini) posts its findings in a `COMMENTED` review with `reviewDecision: null` (verified on live PRs), so a `state`-based gate would skip the majority of review content. Treat `state == CHANGES_REQUESTED` as an *additional* hard block, never the sole blocking signal. Compare reviews by each author's **latest** `submittedAt` — a later approval from the same author supersedes their earlier change-request, and vice-versa.
+- **Inline `reviewThreads`** are the minority here but still binding: filter to `isResolved == false` for actionable items.
+- If ANY connection's `pageInfo.hasNextPage` is true, paginate by passing that connection's `endCursor` back via its cursor variable (`-F reviewsCursor=<endCursor>`, `-F commentsCursor=…`, `-F threadsCursor=…`) and re-running — do not stop at the first page; this is the comprehensive gate, not a triage slice. Truncating `reviews`/`comments` would silently hide top-level blockers, the majority case. The nested per-thread `comments` connection also exposes `pageInfo`: if a single thread's `comments.pageInfo.hasNextPage` is true (50+ replies — rare), refetch that thread's comments with its own `after` cursor.
+
+Never substitute a per-PR `gh api .../pulls/<PR>/comments --paginate` REST walk (drains `core`, inline-only, lacks resolved-state) or a time-windowed `since=` sweep (risks dropping old unaddressed top-level feedback).
+
 For each item, extract source, author, body, file path and line/range, timestamps, and whether it is resolved, outdated, duplicated, or still actionable. Skip resolved and informational comments. If uncertain, keep the item and mark it `needs-human-confirmation`.
 
 ### 3. Categorize And Prioritize