Follow-up: deferred review findings from PR #822

[philcunliffe]

Triage of PR #822 (fix/issue-819, head 7bd43f63) after its two review rounds found no blocking residue. Every item below was re-verified against the tree at head, not taken from the review records. At head: npm test 4277 pass / 0 fail / 1 skipped, npm run typecheck clean, smokes client_attach_idempotent and status_diagnostics green. Both rounds' fixes are present and correct in the tree (src/core/commands/clients.js:374-380 carries the round-2 proxyStateChanged disqualifier; the remint/enabled/daemonInstalled reporting branches at clients.js:984-1010 and :1151-1180; the enabled: false guard at src/core/daemon/status.js:1237). These deferred items remain:

1. hyp status goes quiet again while a base-URL attach persists (medium, needs a new diagnostic)

proxy_mode_ca_missing (src/core/daemon/status.js:1235-1252) is keyed purely on config-vs-CA disagreement, so this sequence ends with every surface silent over a wrong-mode client:

1. Stranded install (proxy_mode: true, no CA). hyp attach claude warns; the user declines the repair; a base-URL marker is written at the live port. All loud and correct so far.
2. The daemon later restarts for any reason (reboot). prepareInterception re-mints the CA on launch (hypaware-core/plugins-workspace/ai-gateway/src/source.js:343-348), so proxy_mode_ca_missing clears and hyp status is healthy.
3. hyp attach claude now no-ops at the LLP 0086 alreadyCurrent branch (src/core/commands/clients.js:374-380): the CA is present so the repair gate returns silently, proxyStateChanged is false, and the marker names the live port. The client stays on ANTHROPIC_BASE_URL, keychain trust is never re-granted, Remote Control inbound stays dead, exit 0.

Why deferred rather than a blocker on #822: the message printed in step 3 ("already attached") is incomplete, not false; the state is only reachable through an explicit, informed decline (on master today the same terminal state is reachable with zero warnings ever, so #822 strictly narrows it); and closing it needs data probeClientAttachFromDescriptor does not return - the probe carries version and port (src/core/daemon/status.js:~1676), not the attach mode the marker records. LLP 0259 #status-names-it deliberately settles its diagnostic as the config-versus-disk pair. The fix is a different diagnostic (attached-mode-vs-config, e.g. client_attach_mode_stale), plus optionally teaching the alreadyCurrent comparison to read the marker's recorded mode against the CA-implied one so re-attach repairs it. Round-2 record: "Worth a follow-up issue, not a change here."

2. Unconditional macOS / Remote Control wording in both proxy prompts (low, fix both or neither)

The repair prompt (src/core/commands/clients.js:~1120) says "macOS will then ask to trust the HypAware Local CA" and the downgrade warning (:1076-1080) says a base-URL attach "breaks Remote Control inbound", both unconditionally on every platform, while LLP 0237 makes Remote Control inbound darwin-only (the adapter itself says so elsewhere, hypaware-core/plugins-workspace/claude/src/index.js:241). The phrasing is copied verbatim from the pre-existing LLP 0244 migration prompt (clients.js:939-942), which has the same issue; diverging one of the pair would be worse than the shared inaccuracy. Fix all of them together, platform-gating the two claims.

3. maybeOfferProxyModeMigration's gateway lookup does not read enabled: false (low)

src/core/commands/clients.js:861-863 finds the gateway entry without the enabled !== false guard the status lookup gained in round 1 (status.js:1237). On a disabled gateway carrying stale proxy_mode: true with no CA, the repair is offered; accepting restarts the daemon for nothing and fails honestly at the bind wait ("could not restore proxy mode (... did not publish a bound port in time)"), falling back to base-URL attach. No misreporting, one wasted restart, in a state attach can barely reach. Add the same guard for symmetry.

4. hasLocalCa / attach all nits (info)

• attach all prints the downgrade warning once per proxy-attach client; today exactly one manifest declares compose.gateway_proxy_mode (hypaware-core/plugins-workspace/claude/hypaware.plugin.json:45). Revisit when a second proxy-attach client lands.

5. PR #817 collision (medium, merge-time action for whichever merges second)

Recorded in detail from the other side in #830 (item 1); restated here so either merge order finds it:

• Textual conflict in llp/0244's metadata block: Proxy mode by default: design of record for LLP 0242, plus the missing --json non-interactive pin #817 appends , LLP 0251 to the Related: line; detach --purge then attach no longer downgrades claude to base URL in silence #822 inserts the **Extended-by:** LLP 0259 block right after it. Trial-merge confirms the conflict. Resolution: keep both; nothing settled is touched. (test/core/attach-proxy-migration.test.js was reported to auto-merge cleanly at Proxy mode by default: design of record for LLP 0242, plus the missing --json non-interactive pin #817's head; both PRs touch the makeCtx helper and the fake adapter's attach, so re-verify the merged suite runs green.)
• LLP 0251 #migration becomes false in four places once detach --purge then attach no longer downgrades claude to base URL in silence #822 lands: the offer keyed on config not CA, the idempotence claim ("Once the key is set the offer never appears again"), the fleet-managed report-only claim (a re-mint restarts the daemon on a fleet host by design, LLP 0259 #repair-is-a-restart), and section 3's "The write." paragraph, which predates the no-write remint outcome. Cheapest reconciliation: append **Extended-by:** LLP 0259 (#migration: the offer gate also reads the CA; key-on with no CA reaches a repair instead of returning; a re-mint restarts a fleet host and writes nothing) to LLP 0251's metadata, with a scoping word in those sentences if edited at all (0251 is Status: Active; extend, do not rewrite).

#817 is unmerged, so today's tree needs nothing; this fires at the second merge.

6. Real-Mac acceptance items (both rounds; run before a release that ships this path)

Everything below the CA-file abstraction is Linux-provable; nothing above it is.

1. The detach --purge then attach silently downgrades claude to base-URL mode, with no warning on any surface #819 repro end to end: attach in proxy mode, hyp detach claude --purge, hyp attach claude. Downgrade warning appears; accept; exactly one keychain trust dialog follows (Follow-up: F1 and F2 from #790, plus proxy-trust status findings deferred from PR #792 #793's two-dialog report is the neighbouring bug; this path must not add a third).
2. Decline the repair, then run hyp attach claude a second time and accept. Confirm the client's settings.json actually flips from ANTHROPIC_BASE_URL back to HTTPS_PROXY + NODE_EXTRA_CA_CERTS, and that keychain trust is re-granted (the round-2 finding; on Linux only provable through the fake adapter).
3. hyp status on the stranded machine before the repair: proxy_mode_ca_missing present, overall: healthy, proxy trust block absent.
4. After the repair: launchd NODE_USE_SYSTEM_CA set, and Remote Control inbound actually alive.
5. Both rounds recommend a docs/ACCEPTANCE.md entry for the sequence, since it is now a documented lifecycle state (LLP 0259) rather than an accident.

---

Backlink: PR #822. Review records: round 1 3b4776c6 and round 2 6294f0f4 comments on that PR. Cross-reference: #830 (item 1 there is the same #817 merge-time action).

[philcunliffe]

Picked this up as a neutral:fix follow-up and worked every finding against a clean worktree at origin/master (a14246d9, npm install, suite green), splitting per finding as the issue is written. None of the six is fixable from master today. This is a sequencing block rather than a failed attempt: the code each finding names either does not exist here yet, or sits in a region PR #822 rewrites, so a fix now would be a conflict rather than a contribution.

What each finding needs, and where it lives:

1. hyp status goes quiet while a base-URL attach persists; wants a client_attach_mode_stale diagnostic. The diagnostic this one extends does not exist on master: grep -r proxy_mode_ca_missing returns nothing outside PR detach --purge then attach no longer downgrades claude to base URL in silence #822's branch (fix/issue-819), and neither does proxyStateChanged, the round-2 disqualifier at src/core/commands/clients.js:374-380 the described sequence runs through. src/core/daemon/status.js on master has no proxy_mode_ca_missing block at all, so there is no sibling diagnostic to add one beside, and LLP 0259 (which settles the existing one as the config-versus-disk pair, and which a new diagnostic would have to be scoped against) is detach --purge then attach no longer downgrades claude to base URL in silence #822-only. Needs detach --purge then attach no longer downgrades claude to base URL in silence #822 merged.

2. Unconditional macOS / Remote Control wording in both proxy prompts. Mixed, and deliberately left whole. The pre-existing LLP 0244 migration prompt is on master (src/core/commands/clients.js, inside maybeOfferProxyModeMigration, the "macOS will then ask to trust the HypAware Local CA" question). The repair prompt and the downgrade warning are detach --purge then attach no longer downgrades claude to base URL in silence #822-only. The finding's own instruction is "fix both or neither ... diverging one of the pair would be worse than the shared inaccuracy", and platform-gating only the master copy would do exactly that, on top of landing in a function detach --purge then attach no longer downgrades claude to base URL in silence #822 rewrites (its diff touches 245 lines of clients.js). Left for the post-merge pass that can gate all three together.

3. maybeOfferProxyModeMigration's gateway lookup does not read enabled: false. The missing guard is on master, but the defect it causes is not: the finding's scenario is "a disabled gateway carrying stale proxy_mode: true with no CA, the repair is offered", and the repair path is detach --purge then attach no longer downgrades claude to base URL in silence #822's. On master that same state hits if (effectiveGateway?.config?.proxy_mode === true) return and the function exits silently, harming nothing. The guard to mirror (src/core/daemon/status.js:1237) is also detach --purge then attach no longer downgrades claude to base URL in silence #822's; grep -r "enabled !== false" src/ on master shows the pattern elsewhere but not there. Adding it now would patch a master line for a branch-only symptom, inside detach --purge then attach no longer downgrades claude to base URL in silence #822's diff. Needs detach --purge then attach no longer downgrades claude to base URL in silence #822 merged.

4. hasLocalCa / attach all nits. Filed as info, and explicitly deferred to "revisit when a second proxy-attach client lands". Exactly one manifest declares compose.gateway_proxy_mode today, so there is nothing to change.

5. PR Proxy mode by default: design of record for LLP 0242, plus the missing --json non-interactive pin #817 collision. A merge-time action by construction, and the mirror of item 1 in Follow-up: deferred review findings from PR #817 #830. llp/0251 and llp/0259 are both absent from master (ls llp/ confirms 0245, 0248, 0249, 0251, 0259 all missing), so neither side of the conflict is present to pre-resolve.

6. Real-Mac acceptance items. A human gate on macOS hardware against the detach --purge then attach no longer downgrades claude to base URL in silence #822 code path, including the suggested docs/ACCEPTANCE.md entry for the LLP 0259 lifecycle state, whose LLP is detach --purge then attach no longer downgrades claude to base URL in silence #822-only. Not automatable and not reachable.

One correction while I was here, on a neighbouring issue rather than this one: #831's item 5 (master's aigw.proxy_mode_stale_ca naming a remedy that cannot work) was reachable, and it is fixed in PR #833. That message sat in hypaware-core/plugins-workspace/ai-gateway/src/source.js, which neither #815 nor #822 touches, so it did not need the sweep this issue's item 2 territory does. Item 2 above is still open.

No PR was opened here, because every fix would be either a no-op or a conflict against #822.

Concrete action for a human: merge PR #822, then this issue can be worked. Items 1, 2 and 3 become ordinary in-tree edits at that point (item 2 gating all three prompts together, item 3 adding the guard beside the one #822 introduces), item 5 is resolved by the merge itself in whichever order it lands relative to #817, and items 4 and 6 stay parked by design.

Reply on this issue; neutral monitors this thread and will re-engage with your guidance on its next tick.