Follow-up: deferred review findings from PR #626

[philcunliffe]

Deferred, non-blocking findings from the round-2 review and triage of PR #626 (the LLP 0063 D4 exclusivity gate fail-closed fix, fix/issue-623). Triage confirmed none of these are production defects; they are worth their own follow-up rather than blocking or re-widening #626 further.

1. hyp status collapses an unreadable/unresolvable central layer into hasCentral: false

src/core/daemon/status.js:265-268:

const centralConfigPath = resolveCentralLayerPath({ stateRoot })
const centralLoaded = centralConfigPath ? await loadConfigFile(centralConfigPath) : null
const centralConfig = centralLoaded?.ok ? centralLoaded.config : null
const hasCentral = centralConfig !== null

This collapses three distinct states (no central layer at all, a central layer that fails to parse, and a central-layer path that cannot even be resolved) into a single false. After #626, hyp remote login correctly refuses in the latter two states with "this machine's central config layer ... cannot be read", but hyp status reports hasCentral: false for the exact same machine state, i.e. the two surfaces disagree about whether this machine has a central layer. Every consumer of hasCentral (buildClientActionsReport, the layered report block, the wizard's managed hint) is display/reporting, not a permission gate, so this is confusing rather than unsafe. Fix: give hyp status its own three-state read (mirroring CentralEnrollment/centralLayerResolutionFailure) with its own message and tests.

2. enrollCentralSink's seed-time D4 recheck throws after the first-sync hold marker is written

src/core/commands/central.js:209-212 (the seed-time D4 recheck) can throw before anything is written for this enrollment, but the attended-login caller (src/core/cli/remote_commands.js:720-725) writes the first-sync hold marker (LLP 0101) before calling enroll(...), so a throw here (like every other throw in enrollCentralSink) leaves that marker on disk with no clearing enrollment behind it. This is pre-existing behavior, not introduced by #626, and is bounded by LLP 0101's own design (best-effort marker, no clear-on-exit, an absolute deadline caps how long a stray hold can last) — it delays exports, it does not leak or lose data. Noted for completeness; no action required unless LLP 0101's bound is revisited.

3. Informational: the new fail-closed helper's contract is easy to violate by construction

centralLayerResolutionFailure in src/core/config/apply.js documents (in its own JSDoc) that any future permission check keyed on resolveCentralLayerPath() === null reopens the exact fail-open hole #626 just closed, because resolution is deliberately lossy for every other caller (boot, hyp status). This is already documented in-code; flagging here only so a future reviewer auditing a new central-layer-gated feature knows to grep for this note.

---

Backlink: #626

[philcunliffe]

Parked: one actionable finding, and it wants #626 merged first

What neutral was doing. This issue carries neutral:fix, so the maintenance reconciler picked it up to produce a fix PR.

What is actually actionable here. Of the three findings, only #1 asks for a change:

• [codex] Add durable cache spool #1 (hyp status collapsing three central-layer states into hasCentral: false) - real, and unlike the sibling issue Follow-up: deferred review findings from PR #622 #627 this code is on master today, unchanged, at src/core/daemon/status.js:265-268. So neutral could branch from master and write it now.
• [codex] Remove OpenTelemetry npm dependencies #2 (seed-time recheck throwing after the LLP 0101 hold marker) - the issue itself concludes "no action required unless LLP 0101's bound is revisited". Pre-existing, bounded by design.
• [codex] Add root tests and remove donor tree #3 - explicitly informational, already documented in the helper's own JSDoc. Nothing to change.

Why neutral is waiting anyway. The fix this issue asks for is a three-state read "mirroring CentralEnrollment/centralLayerResolutionFailure". Those live on fix/issue-623 (PR #626), which is green, reviewed, triaged and held for you to merge - not blocked on anything neutral can do.

Writing the status-side read now means implementing the same three-state concept a second time, from scratch, days before the canonical helper lands. There would be no merge conflict (#626 does not touch status.js), but there would be two mechanisms for one idea, and the first reviewer to see them side by side would reasonably ask for them to be unified. That is rework neutral would be creating on purpose.

This session already paid that bill once in the other direction: PR #625 was stacked on PR #608, and when #608 was squash-merged the rewritten history put #625 into conflict. The lesson generalises - coordinate with the merge, do not race it.

What it needs from you. Nothing but the merge of #626. Once it lands:

• this issue unsticks on a later tick (reply here, or just drop neutral:stuck), and
• finding [codex] Add durable cache spool #1 becomes a small, clean fix that imports the helper instead of duplicating it, with findings [codex] Remove OpenTelemetry npm dependencies #2 and [codex] Add root tests and remove donor tree #3 closable as no-action.

If you would rather have it now, say so on this thread and neutral will branch from master and write the standalone version on its next tick. This is a judgement call about rework, not a blocker, and it is yours to overrule.

How to unstick. Merge #626, or reply here. Neutral monitors this thread and re-engages on its next tick.