Follow-up: deferred review findings from PR #630

[philcunliffe]

Neutral triage on PR #630 (head 3a7a3312ce114752ee4361a4a7a450ff0a4243b5, the option-2 "quiet the probe" rework of the hyp leave reverse path) found no blockers. These items were deliberately deferred during review and the maintainer's decision, and are recorded here so they do not silently rot. In particular, #630 carries Fixes #627, which will close that issue on merge with one of its items still unaddressed; that item is carried forward here.

1. Carried from #627: reverse() returning refused falls into the generic failure branch (still unaddressed)

src/core/config/action_reconciler.js:341-361. ActionOutcome is one type shared by perform() and reverse(), so widening it for the terminal refused state (LLP 0186) also made refused expressible as a reverse() return value. If a future reverse() ever returns it, the reverse gap's else treats it exactly like failed: keep the marker, retry forever. Verified dead code today: src/core/config/action_attach.js:316 holds the only reverse() in the tree and returns only done or failed. The inline comment at action_reconciler.js:344-358 documents the retry as the deliberately safe half of an unsettled pair (LLP 0138#refusal-is-not-failure vs LLP 0138#marker-undo). Follow-up: when a real reverse-refusal need appears, settle terminal-undo semantics in a new LLP extending LLP 0186 rather than letting the fallback stand in by accident. This is the item Fixes #627 would otherwise bury (item 1 in #627's body; referred to as "finding 2" throughout PR #630's review thread).

2. The marker-schema gap: a done to failed/refused rewrite records assets but not the settings write

PR #630's review round 2 reproduced that the reconciler's marker rewrite (src/core/config/action_reconciler.js, the failed and refused branches around lines 184-224) carries installed_assets forward but records nothing about a prior done state's settings write. The reconciler's own reverse gap (src/core/config/action_reconciler.js:316-324) therefore still drops an assetless failed/refused marker for a request key the config stops naming, even when that marker was rewritten from a done whose settings edit is still on disk (routine for openclaw, which installs no assets). PR #630 removed this hazard from hyp leave (the one cell it had introduced) by never consulting marker status there, but the reconciler-side cells are inherited master behaviour, governed by LLP 0186, and remain. The maintainer's decision on #630 explicitly deferred this: "The marker-schema question ... needs its own design pass and review." Follow-up: a new LLP extending LLP 0138/0186 that teaches the rewrite to record the effect it overwrites (for example a prior-done bit), then revisits the reverse gap's drop condition.

3. PR #630's body is stale (fix before or at merge)

The body still describes the abandoned shared-predicate approach (markerRecordsNoEffect), which is absent from the tree at head (verified by grep). The accurate description of what merges lives in commit eb9eb5d's message and the neutral-ack-applied comment on the PR. Preference, not a blocker, but the body is what a future reader finds first; it should be rewritten to describe the option-2 fix before merge.

4. Minor, optional: hyp detach all narrates every unattached client

src/core/commands/clients.js:111-128 (via expandDetachClientNames, clients.js:1411) sweeps every descriptor and prints No HypAware marker found ...; nothing to do. once per client with nothing to reverse. Pre-existing master behaviour at a call site #630 does not touch, and deliberately left loud there (for hyp detach <client> that line is the whole answer). If anyone wants detach all quiet on no-ops, the quietNoop option #630 added to detachClientViaCore (clients.js:1041, gate at clients.js:1311) is the ready-made mechanism. Preference only.

None of these block PR #630.

Backlink: #630

[philcunliffe]

The stale-PR-body item in this issue is done. PR #630's description was rewritten on 2026-08-15 so it describes what actually merges, and the rewrite preserved the neutral-triage marker and the Fixes trailer (both re-read from GitHub afterwards to confirm).

Recording it here so the item is not worked twice. Neutral does not close issues, so whatever else this issue tracks still stands and a maintainer decides when it is done.

[philcunliffe]

This issue cannot be fixed on master yet: its targets exist only on PR #630's branch, which is held and unmerged.

Verified against origin/master: quietNoop in src/core/commands/clients.js is not present there.

Neutral is therefore not opening a fix/issue-780 PR. There would be nothing to edit, and pushing the change onto #630's branch instead would move its head and send a currently mergeable, green, reviewed PR back through triage. That tradeoff belongs to the maintainer.

The practical options are to land the change as a fixup on #630 before merging it, or to leave this issue for after #630 merges, at which point a normal fix PR against master works.

Until then this issue keeps reading as needs-fix to the reconciler, because no fix branch exists and none should. Recording that here so it is not re-attempted every tick.