feat(plan): plan 1.8, the plan gate, the design part and the plan-side checks

Wave 1, order 3 (P3 plan mode as the start, P2 design as its own part, P9
plan side). Contracts K3-K6 for the later merges.

- plan_version 1.8 (1.7 plans stay valid): Test first on every step, one
  End-to-end ("run the thing") step, optional Interface in / Interface out /
  Review focus fields, a ceremony class in the header (absent =
  architectural), and for architectural plans a ## Design part: module map
  without cycles, architecture rules that name their enforcer and the step
  that proves them, a requirements check asked as keep / change.
- K3 lib/validators/plan-gate.mjs: the critic verdict is recorded INSIDE the
  plan (Claude Code's plan approval hands a hook only the plan file's text),
  bound to the hash taken before the reviewers read it; 0 go / 1 stop / 2
  could not run; at most 3 critic rounds, then stop and ask.
- K5 lib/verification/arch-rules.mjs: runs the target repo's own
  dependency-cruiser or import-linter (installs nothing; 2 = not measured,
  never green); --prove --rule shows pass -> fail on a planted violation of
  that rule -> pass. Verified against dependency-cruiser 18.5.0 and
  import-linter 2.15; madge 8.0.0 left out (missed a planted .mjs cycle).
- K6 lib/verification/plan-scope-sweep.mjs: changed files no step names.
- /trekplan Phases 8-10: design part, bounded critic loop, the gate before
  "execute", a plan-mode path through ExitPlanMode (not yet run end to end
  inside plan mode). plan-critic 10 -> 12 dimensions; scope-guardian checks
  the ceremony.
- Fixed on the way: plan-validator and plan-review-dedup used the
  file://argv[1] main guard (no-op under a symlink or a space); CRLF plans
  failed every manifest; the dedup dropped finding severity.

Borrowed, credited in place: obra/superpowers, Kiro (docs), addyosmani/
agent-skills, mattpocock/skills, GitHub Spec Kit, bashebr/ai-native-sdlc,
Boris Cherny's public threads.

Suite 1497 (1495 / 0 / 2), 86 new tests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

agents/plan-critic.md

@@ -134,6 +134,12 @@ questions, which defeats the purpose.
 - Are there assertions about behavior that have no corresponding test?
 - Do the verification steps cover error paths, not just happy paths?
 - Are the verification commands correct and runnable?
+- `plan_version: 1.8`: does every step's `Test first:` name a test that would
+  FAIL before the step and pass after it (not a test that already passes)?
+- Is there a "run the thing" step (`End-to-end:`), and does its command run
+  the product the way a user does — not a unit test renamed? A plan whose only
+  end-to-end check is a unit test is a **blocker**: its result could only be
+  "not verified end to end".
 
 ### 9. Headless readiness
 
@@ -185,6 +191,59 @@ a single advisory note ("Plan is v1.6 legacy format — manifests will be
 synthesized by trekexecute with reduced audit precision") and skip this
 dimension's scoring.
 
+### 11. Interfaces and slices
+
+- Does every value a step consumes (`Interface in:`) come from an earlier
+  step's `Interface out:` or from existing code — same name, same type? A step
+  that consumes something nothing produces is a **blocker**.
+- Do two steps produce conflicting versions of one interface?
+- Is each step a vertical slice — a narrow but complete path through the layers
+  it touches, verifiable on its own? "All the tests, then all the code" or
+  "all the models, then all the handlers" is a **major** finding.
+- Does preparatory refactoring come first, as its own steps? Does a wide change
+  go expand → migrate → contract?
+- Are the brief's Constraints and NFRs that bind several steps quoted
+  **verbatim** in `## Global Constraints`, and quoted again in the
+  `Review focus:` of each step that could break one? A paraphrased constraint
+  whose exact value matters is a **major** finding.
+- Does each `Review focus:` input name the test that pins it?
+
+(Borrowed: obra/superpowers@8ca22db writing-plans — interfaces, Global
+Constraints, Review Focus (MIT, © 2025 Jesse Vincent); mattpocock/skills@c55ee46
+to-tickets — vertical slices (MIT, © 2026 Matt Pocock); GitHub Spec Kit —
+constraints quoted into the task (MIT).)
+
+### 12. Design and architecture rules
+
+Applies when the plan's `ceremony` is `architectural` (or absent — absent
+means architectural). For `small` and `bounded` plans, check only that the
+ceremony matches the brief's.
+
+- Does `## Design` answer, for each changed module: what does it do, how is it
+  used, what does it depend on — and can its internals change without breaking
+  its users? Would the deletion test keep it (deleting it would scatter real
+  complexity), or is it a shallow pass-through?
+- Is the module map consistent with the steps — no step adds a dependency the
+  map does not show, and no edge points against the map's direction?
+- Does every architecture rule name what enforces it ("checked by `<command>`"
+  the target repo actually has, or "advisory — `.claude/rules/<file>.md`"), and
+  does every checked rule's proving step really show pass → fail on a planted
+  violation → pass? A checked rule with no such proof is a **blocker**.
+- Does any step break a rule the target repo already declares (its
+  `.claude/rules/`, CLAUDE.md, or the plan's own Architecture Rules) without a
+  written justification in `### Gotchas` or `### Decisions (ADR)`? Unjustified
+  is a **blocker**.
+- Is each ADR earned (hard to reverse, surprising without context, a real
+  trade-off)? An ADR for an ordinary choice is a **minor** finding.
+- Does the Requirements Check list the conflicts and gaps you can see between
+  the brief's requirements, each with a recorded keep / change answer?
+
+(Borrowed: Kiro's design.md sections and requirements analysis, docs only;
+obra/superpowers@8ca22db brainstorming design questions; mattpocock/skills@c55ee46
+deep modules, the deletion test and the ADR bar; GitHub Spec Kit's
+constitution check, changed so each rule names its enforcer;
+addyosmani/agent-skills@9d0c60d module map (MIT, © 2025 Addy Osmani).)
+
 ## Rating system
 
 Rate each finding:
@@ -192,6 +251,15 @@ Rate each finding:
 - **Major** — high risk of bugs, rework, or failure
 - **Minor** — worth fixing but won't derail the implementation
 
+Your rating decides what happens next: `/trekplan` records your findings with
+`plan-gate.mjs --record`, and the plan gate stops the plan while any BLOCKER
+is open. A finding with no valid severity counts as a blocker. You may be run
+up to 3 times on successive revisions of the same plan; judge the plan in
+front of you, and do not repeat a finding the revision has fixed.
+
+Dimensions 11 and 12 are scored inside the existing weights: 11 under Step
+quality, 12 under Coverage completeness and Specification quality.
+
 ## Plan scoring
 
 After reviewing all findings, produce a quantitative score:
@@ -274,7 +342,8 @@ this block inline *is* the hand-off; do not attempt to write a file.
 
 One object per finding. `file`/`line` point at the plan section (use the plan
 path + the step's line) or the source the finding concerns; `rule_key` is a
-short, stable id for the finding class (used for exact-match dedup). Emit
+short, stable id for the finding class (used for exact-match dedup).
+`severity` is exactly one of `blocker`, `major`, `minor`. Emit
 `"findings": []` when the plan is clean.
 
 Be specific. Reference exact plan sections, step numbers, and file paths.