refactor(#3186): one shared phase-completion predicate, disk-strict (#3306)

* docs(#3186): record the disk-strict completion decision in ADR-3180 7.4

The maintainer decided #2957 on 2026-08-08: disk state is authoritative and a
ROADMAP checkbox is a human annotation with no machine authority. Section 7.4
still carried the OPEN QUESTION and was marked blocked, so the contract said one
thing and the tracker another.

Recorded per section 7's own rule - a behavior not stated there is not decided,
and amending a rule is an ADR amendment rather than a code change with a comment.
The decision comment names Phase 4's PR as the carrier of this edit and makes it
an acceptance criterion that the text be in the tree before implementation
begins, so this lands first, alone, ahead of any code.

Also clears the stale blocked-on-2957 row in the guard roster.

* refactor(#3186): one shared phase-completion predicate, disk-strict

isPhaseComplete in verification.cts becomes the single owner. It calls
readVerificationStatus UNCONDITIONALLY - plan count is not a precondition - so a
zero-plan phase with a passing VERIFICATION.md is complete. That is #3168: init
gated the read on a plan count and synthesized a not_required sentinel, so
phase.complete succeeded while init.manager reported incomplete for the same
phase.

The guard, built and run before scope was fixed per Amendment 3, found 9
re-derivations where the ADR named 3. Four were unnamed, including one in the
prompt layer: mvp-phase.md ORed a ticked checkbox with disk status, which under
disk-strict is the divergence itself.

Per the #2957 decision, a ticked ROADMAP checkbox is a human annotation with no
machine authority. The overrides in roadmap analyze and init manager are deleted
rather than generalized; the user's checkbox stays in ROADMAP.md, only its
authority goes.

scanPhasePlans.completed and buildWorkstreamInventory are deliberately NOT folded
- they answer 'are all plans summarized', which is a different question, and
folding them would either over-report completion or invert the dependency
direction between Phase 1's owner and this one.

Verified on the remote runner.

* fix(#3186): close seven review findings and record the missing-verdict rule

The isolated review reproduced a write-path regression I introduced: migrating
cmdRoadmapUpdatePlanProgress dropped its summaryCount>=planCount gate, so a phase
with a fresh passing verification plus a newly-added unsummarized plan reported
complete AND wrote a checkbox into ROADMAP.md while phase complete refused. The
owner stays right per 7.4 - plan count is not a completion precondition - so the
gate is restored at the write site as an explicit composition, mirroring the
separate 2648 unexecuted-plan gate cmdPhaseComplete already carries.

The spec axis was right that my 0.x-split reasoning was too permissive. The 2957
decision names buildStateFrontmatter as one of the three that must converge, and
buildWorkstreamInventory combined a summaries-met local with verification data to
decide the same verdict - Decision 4(c)'s named bypass, and it reproduced 3168 in
a third surface. Both now route through the owner. The raw scanPhasePlans helper
stays: it answers are-plans-summarized, which genuinely is a different question.

Maintainer decision recorded in 7.4: a missing verdict is not a passing one, so
an absent VERIFICATION.md means not complete everywhere. That retires 2645's
verifier-disabled tolerance and inverts its Goodhart incentive - deleting the
evidence now lowers completion instead of raising it.

Guard hardened: block-form count gates and algebraic restatements are caught, and
the header now discloses its remaining limits instead of overclaiming.

Verified on the remote runner.

* fix(#3186): route state sync through the owner and catch bare completed reads

The matrix found 52 failures. 51 were fixtures asserting the old semantics: a
phase with plans and summaries but no VERIFICATION.md used to count complete and
correctly no longer does. Each fixture now carries a passing verification where
that is what the test was actually about, rather than having its assertion
weakened.

The 52nd was a real 10th re-derivation the guard could not see. cmdStateSync
destructured scanPhasePlans().completed directly - a bare field read, not a
comparison - and used it as a completion verdict, so state sync and state json
disagreed on completed_phases for identical disk state. Routed through the owner.

Guard gains shape (d): any read of .completed off a scanPhasePlans() result
outside plan-scan.cts, in chained, destructured and indirect forms, function
scoped with no line window. It cannot tell a summaries-met read from a completion
read - that is data flow - so it flags every one and requires a written-reason
exemption, which is the same discipline shapes a-c already use. The blind spot is
disclosed in the header rather than overclaimed.

The emitted-attribution failure was also mine, not pre-existing: the mvp-phase.md
checkbox-OR removal moves emitted bytes, acknowledged in tests/emitted-drift-acks.

Verified on the remote runner.

* test(#3186): give the nested-plans sync fixture a passing verification

Last 3 matrix failures were one failure echoing up two describe levels. Phase
01-alpha had plans and summaries but no VERIFICATION.md, so under disk-strict
completed stayed 0 and no Progress change was emitted - correct new behavior, not
a regression.

Added the passing verification rather than dropping the Progress expectation, so
the test still covers what #3257 is about: that a nested plans/ layout is counted
and not undercounted. Probe against the built lib confirms
Progress: 0% -> 50% alongside Total Plans in Phase: 0 -> 3.

* chore(#3186): backfill changeset PR number

pr:0 placeholder replaced with the real number now that #3306 exists.

---------

Co-authored-by: sim <sim@local>

src/init.cts

@@ -102,7 +102,7 @@ const {
 
 const { determinePhaseStatus } = commandsMod;
 const { extractFrontmatter } = frontmatterMod;
-const { readVerificationStatus } = verificationMod;
+const { isPhaseComplete } = verificationMod;
 const { evaluateUatPassed } = uatPredicateMod;
 const { resolveLoopHooks } = loopResolverMod;
 const { loadRegistry } = capabilityLoaderMod;
@@ -244,9 +244,9 @@ interface PhaseCompletionProjection {
 
 function projectCompletionStatus(
   implementationComplete: boolean,
-  verificationPassed: boolean,
+  phaseComplete: boolean,
 ): string {
-  if (implementationComplete && verificationPassed) return 'complete';
+  if (phaseComplete) return 'complete';
   if (implementationComplete) return 'executed';
   return 'incomplete';
 }
@@ -259,32 +259,42 @@ function buildPhaseCompletionProjection(
   summaryCount: number,
   slashRuntime: string,
 ): PhaseCompletionProjection {
+  // ADR-3180 §7.4 (issue #3186) / DO-NOT-MIGRATE exemption
+  // (scripts/lint-completion-predicate-drift.cjs FUNCTION_SCOPED_EXEMPTIONS,
+  // declared deviation): `implementation_complete` answers "are the plans
+  // done" (a `scanPhasePlans`-shaped different question, per the design's
+  // 0.x-split), NOT "is the phase complete" — it is kept for the
+  // 'executed'-vs-'planned' disk_status distinction downstream consumers
+  // still rely on, which `isPhaseComplete`'s locked `{ complete, verification
+  // }` return shape does not carry.
   const implementationComplete = planCount > 0 && summaryCount >= planCount;
   const phaseFullDir = phaseDir ? path.join(cwd, phaseDir) : '';
-  // #2617: ONE verification-routing seam. init used to re-derive next_command
-  // from the status with its own projector, which had drifted from the router's
-  // table — it appended the phase number and answered `human_needed`; the table
-  // did neither. The router now owns both the content and the runtime
-  // projection, and init passes the phase number it already knows (its phaseDir
+  // #3168 / ADR-3180 §7.4 (disk-strict, #2957): route through the canonical
+  // owner (`src/verification.cts` · `isPhaseComplete`), which calls
+  // readVerificationStatus UNCONDITIONALLY — plan count is NOT a
+  // precondition. A zero-plan phase with a passing `*-VERIFICATION.md` is
+  // complete; init used to gate the read on `implementationComplete` and
+  // synthesize a `not_required` sentinel instead, which is the #3168 defect.
+  // #2617: the router still owns both the message content and the runtime
+  // projection; init passes the phase number it already knows (its phaseDir
   // is unresolved in some branches, where the router could not derive one).
-  const verificationStatus = implementationComplete
-    ? readVerificationStatus(phaseFullDir, { runtime: slashRuntime, phaseNumber })
-    : { status: 'not_required', next_action: '', next_command: '' };
+  const completionResult = isPhaseComplete(phaseFullDir, { runtime: slashRuntime, phaseNumber });
+  const verificationStatus = completionResult.value.verification;
   const projectedVerificationStatus = verificationStatus.status;
   const projectedVerificationAction = verificationStatus.next_action;
   const verificationPassed = projectedVerificationStatus === 'passed';
-  const phaseComplete = implementationComplete && verificationPassed;
+  const phaseComplete = completionResult.value.complete;
 
   return {
     implementation_complete: implementationComplete,
     verification_status: projectedVerificationStatus,
     verification_passed: verificationPassed,
     phase_complete: phaseComplete,
-    completion_status: projectCompletionStatus(implementationComplete, verificationPassed),
+    completion_status: projectCompletionStatus(implementationComplete, phaseComplete),
     verification_next_action: projectedVerificationAction,
     verification_next_command: verificationStatus.next_command,
-    // #3057 B3: only readVerificationStatus's result ever carries this flag —
-    // the `not_required` synthetic object above never does.
+    // #3057 B3: readVerificationStatus's result carries this flag when its
+    // internal staleness check could not run to completion.
     verification_stale_check_indeterminate: 'staleCheckIndeterminate' in verificationStatus
       && verificationStatus.staleCheckIndeterminate === true,
   };
@@ -2282,18 +2292,20 @@ function cmdInitManager(cwd: string, raw: boolean): void {
       /* intentionally empty */
     }
 
+    // ADR-3180 §7.4 (disk-strict, #2957, maintainer decision 2026-08-08):
+    // `roadmapComplete` is reported below as metadata only — it carries NO
+    // machine authority over `diskStatus`. The #3033 checkbox override that
+    // used to live here (treating a zero-plan phase as complete whenever the
+    // ROADMAP checkbox was ticked, layered on top of
+    // buildPhaseCompletionProjection's own output) is DELETED, not
+    // generalized: `diskStatus` now comes entirely from `completion`, which
+    // already routes through the canonical owner (`isPhaseComplete`) and
+    // itself resolves a zero-plan phase as complete whenever a passing
+    // `*-VERIFICATION.md` exists (#3168) — with no dependency on the
+    // checkbox. A zero-plan phase whose completion previously relied SOLELY
+    // on a ticked checkbox (no passing verification) now reports incomplete;
+    // this is the deliberate Tier-2 break (ADR-3180 §7.4 Decision 3).
     const roadmapComplete = _checkboxStates.get(phaseNum) || false;
-    // #3033: a zero-plan phase (split parent — intentionally plan-less, holds
-    // shared context for sub-phases) whose roadmap checkbox is marked complete
-    // must resolve as complete. The original gate required completion.phase_complete
-    // (derived from plan/summary counts), which is always false for zero-plan
-    // phases — so the checkbox override never fired and the parent was permanently
-    // stuck as 'researched' (an in-progress state eligible for current-phase
-    // selection). Now: when the roadmap marks it complete AND it has zero plans,
-    // treat it as complete regardless of the plan-count derivation.
-    if (roadmapComplete && (completion.phase_complete || planCount === 0) && diskStatus !== 'complete') {
-      diskStatus = 'complete';
-    }
 
     phases.push({
       number: phaseNum,