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.

agents/planning-orchestrator.md

@@ -215,10 +215,14 @@ Write a comprehensive implementation plan including:
   criterion must be an executable command or observable condition
 - **Estimated Scope** — file counts and complexity
 
-**Plan-version header:** Include `plan_version: 1.7` in the metadata line below
-the title. This signals to trekexecute that the plan includes per-step
-verification manifests and enables strict audit mode. Plans without this
-marker are treated as legacy v1.6 with synthesized minimal manifests.
+**Plan-version header:** Include `plan_version: 1.8` and the brief's
+`ceremony:` in the metadata line below the title. This signals to trekexecute
+that the plan includes per-step verification manifests and enables strict
+audit mode. Plans without this marker are treated as legacy v1.6 with
+synthesized minimal manifests. 1.8 adds `Test first:` on every step, one
+`End-to-end:` step, the optional `Interface in:` / `Interface out:` /
+`Review focus:` fields and, for an architectural plan, `## Design`
+(`commands/trekplan.md` Phase 8 is the full text). 1.7 plans stay valid.
 
 ### Mandatory step format — copy this exactly
 
@@ -331,7 +335,9 @@ Internally the validator enforces (same checks as before, now in one place):
 - Step count == manifest count
 - Zero forbidden narrative headings (`### Fase N`, `### Phase N`, `### Stage N`,
   `### Steg N`)
-- `plan_version: 1.7` declared (warning only if older / missing)
+- `plan_version` 1.7 or 1.8 declared (warning only if older / missing)
+- From 1.8: `Test first:` per step, an `End-to-end:` step, non-empty optional
+  fields, a valid `ceremony`, and the design part for an architectural plan
 
 Each error has a `code` field — read these to localize the fix. Common codes:
 - `PLAN_FORBIDDEN_HEADING` — narrative drift; rewrite the section using the
@@ -425,6 +431,14 @@ merge. The merged array attributes each finding to `[plan-critic, scope-guardian
 if both reviewers raised it. Revise the plan once for the merged set, not
 twice for the duplicates. Source: research/05 R1 + R2.
 
+The dedup output is piped on to `lib/validators/plan-gate.mjs --record
+<plan> --reviewed <hash>` (the hash `--hash` printed before the reviewers read
+the plan), which writes the round's verdict into the plan's `## Critic Verdict`.
+This is a loop of at most 3 rounds: revise, then review again; after round 3
+with a BLOCKER open, stop and ask the operator. `plan-gate.mjs <plan>` (K3)
+exits 0 only for a valid plan whose current text carries a verdict with no
+open BLOCKER (`commands/trekplan.md` Phase 9 is the full text).
+
 After both complete:
 - Address all blockers and major issues by revising the plan
 - **Manifest quality is a hard gate:** any manifest-related `major` finding

agents/scope-guardian.md

@@ -72,6 +72,23 @@ Evaluate:
 - A critical migration should not have only 3 steps
 - Does the estimated scope (file count, complexity) match the actual plan?
 
+### 6. Ceremony and design scope
+
+- Does the plan's `ceremony:` (header line) equal the brief's `ceremony:`
+  frontmatter? An absent field means `architectural` on both sides. A plan made
+  lighter than its brief (e.g. `small` for an `architectural` brief, so no
+  design part) is a **blocker**.
+- For an architectural plan: does `## Design` stay inside the brief — no module,
+  interface or rule that serves no requirement (creep), and no requirement the
+  design leaves out (gap)?
+- Does the Requirements Check record a "change" answer that alters the brief's
+  Intent, Goal or Success Criteria? That cannot be settled in the plan: it is a
+  **blocker** until the brief is re-run through `/trekbrief`.
+
+Your findings go through `plan-gate.mjs --record` with plan-critic's; an open
+blocker stops the plan. `severity` is exactly `blocker`, `major` or `minor`;
+an unrated finding counts as a blocker.
+
 ## Output format
 
 ```