feat(pipeline-cli): review-head materialization verb — de-quadruplicate the gate skills' PR-head checkout (#3690)#3700
Conversation
|
review-code: advisory — blocking-set PR (manual merge) Reviewed-head: @ 0ff7f3f Verdict: PASS (advisory). Re-review after the conflict-resolving rebase (was §CP classification confirmed against the live Silent-revert scrutiny (the priority ask) — CLEANThis rebased over many landed siblings. Verified independently against
The one deletion (+18/-1) is confirmed the PR's own header-docblock line being extended, not a dropped entry. The full diff is exactly two hunks: the docblock continuation line, and the appended Exemptions block is byte-identical to main — verified by a direct
Diff scope —
Acceptance criteria (#3690)
The §RO / §HEAD invariants
Adoption-lint teeth — I verified the reasoning myself, and I agree with the framingI did not take the author's account on trust; I ran both falsification tests against the real CI scope. Test A — strip the citation only. Replaced every Test B — re-introduce an uncited hand-copy. Appended a (Both mutations were made in a throwaway detached worktree and reverted; the PR was not touched.) I agree the forward-guard framing is correct. adoption-lint's contract is precisely "a re-derivation present in the text that fails to cite the owning verb" — the signature must be present for the rule to fire. Same-commit adoption removes the re-derivation, so the signature is gone and the rule has nothing to match. That is the entry working as designed (#3254), not a hole: the entry's job is to catch the re-introduction, which Test B proves it does, naming the right decision. Calling the post-adoption clean "structurally vacuous for this decision" is an honest and accurate description, and proving teeth by injection is the right method. Two things worth recording rather than blocking on:
Gates run at this head
Non-blocking nits (not defects; no action required to land)
VerdictPASS — advisory. No silent reverts, the §RO/§HEAD invariants are enforced by construction rather than convention, the ACs are met, and the adoption-lint teeth claim holds up under my own falsification. Merge is manual per §CP; this comment is advisory only. |
|
review-skill: advisory — blocking-set PR (manual merge) Reviewed-head: @ 0ff7f3f Verdict: PASS (advisory). Fresh re-review after the conflict-resolving rebase (was Behavioral surface reviewed at head: The de-quadruplication is complete and correctly directedThe load-bearing question for a skill gate here is whether the behavior still fully specifies itself after the mechanism moved into a verb — a skill that cites a tool but drops the invariant the tool enforces is a regression even when the tool is right. Zero residual re-derivation. A grep of all four gate SKILL.md files at head finds no hand-rolled Each gate takes the right mode, and the SKILL text explains why rather than just what:
The invariants survive the extraction — they were not thinned into a bare tool call. Each migrated block still states, at the call site, that the verb never runs
The §HEAD contract rewrite (
|
|
§CP bank — reviewed-ready, awaiting control-plane approval. Both gates PASS (advisory) at head
CI green. Per ADR 0135 this control-plane PR needs a non-author |
…te the gate skills' PR-head checkout (#3690) Extract the "materialize the PR's current review head" logic the gate skills each hand-copied (#793 / #1807) into one tested `pipeline-cli review-head` verb, and adopt it across the four gate skills same-commit (#3254 same-commit adoption). - `review-head/resolve-head.ts` — the IO-free core: resolve the latest head SHA/ref from the REST pull payload (fail-safe on a missing/closed/partial head), and the detached-only checkout plan (per-run `refs/pr/` ref, never a `git checkout <branch>`, §RO). Unit-tested for latest-head, detached-vs-branch, and missing-PR fail-safe. - `review-head/materialize.ts` + `git-io.ts` — the `gh` REST + `git` IO shell: `resolve --pr N` (head SHA only, review-design) and `materialize --pr N [--worktree]` (fetch pull/<pr>/head into a per-run ref, assert the fetched ref IS the head, add a throwaway detached worktree). Registered in the tool registry. - adoption-lint: declare the `review-head materialize` decision and migrate all four gate skills (review-code / review-doc / review-skill / review-design) + the §HEAD contract to cite the verb in the same landing commit — no grandfathered entries. §CP change (packages/pipeline-cli + gate skills). Guards: typecheck, biome, adoption-lint, 1580 pipeline-cli tests green. Fixes #3690 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
5eb9839 to
0ff7f3f
Compare
|
§CP re-bank — reviewed-ready at the NEW head, awaiting fresh control-plane approval. Rebased to resolve conflicts with landed siblings (#3696/#3697/#3702/#3703/#3704); head moved to Fresh gates both PASS (advisory) at
Silent-revert scrutiny clean, verified against Adoption-lint verified as a genuine forward guard: stripping the citation alone is clean (expected — same-commit adoption removed the antecedent, per #3254), while injecting a re-introduced uncited hand-copy FAILS exit 1 naming the decision. Per ADR 0135 this needs a fresh non-author |
What
Extract the quadruplicated "materialize the PR's current review head" logic the gate skills each hand-copied (#793 / #1807) into one tested
pipeline-cli review-headverb, and adopt it across the four gate skills same-commit (#3254 same-commit adoption).The verb (
packages/pipeline-cli/src/tools/review-head/)resolve-head.ts— the IO-free resolution core: extract the latest head SHA + ref from the REST pull payload (fail-safe tounresolvableon a missing/closed PR, a null head, or a non-40-hex SHA), plus the deterministic detached-only checkout plan (per-runrefs/pr/<pr>-<nonce>ref,detach: true, never agit checkout <headRef>branch switch — §RO). Unit-tested for the three AC cases: latest head, detached-vs-branch, missing-PR fail-safe.materialize.ts+git-io.ts— theghREST +gitIO shell (ReviewHeadservice,ReviewHeadLivelayer):pipeline-cli review-head resolve --pr N— the current head SHA/ref only (review-design reviews a preview URL, not a tree).pipeline-cli review-head materialize --pr N [--worktree]— fetchpull/<pr>/headinto a per-run ref (never the launched tree), assert the fetched ref IS the resolved head (§HEAD web: phoenix-relay-idiom — every page on @connection + idiomatic Relay #2, aborts on a moved head), and with--worktreeadd a throwaway detached worktree (review-head-<pr>-*, the shapeworktree-sweepreclaims).pipeline-cli commands compact.Adoption, same-commit (#3254)
adoption-lint/manifest.tsdeclares thereview-head materializedecision (fingerprint: thepull/<pr>/head:fetch refspec AND the per-runrefs/pr/ref — narrow enough that review-design's SHA-only.head.sharead isn't a false finding).gh-issue-intake-formats.md§HEAD contract migrated to cite the verb in the same commit — so noreview-headgrandfathered entry is needed (born drawn-down to zero).adoption-lint checkover the full corpus is clean.Out of scope
Verdict resolution (
verdict read, story 1) and any per-gate review judgment (must-not-cross #3251) — untouched.Guards
pnpm typecheckclean ·biome checkclean ·adoption-lint checkclean (8 decisions, full 62-file CI corpus) · 1580 pipeline-cli tests green · live end-to-end verified (resolve/materialize --worktreeagainst a real PR, plus the missing-PR fail-safe).This is a §CP change (packages/pipeline-cli + the gate skills) — it banks for human approval, not auto-merge.
Fixes #3690
🤖 Generated with Claude Code