Follow-up: deferred review findings from PR #520

[philcunliffe]

Deferred, non-blocking findings from PR #520

Triage rung (LLP 0017) ran after two review rounds on #520 exhausted their
budget with these two residuals still open. Both were judged non-blocking
(preference / doc-completeness, not a production defect), so #520 is not held
on them. Filing here so they don't get lost.

Backlink: #520 (hyp session states that the control responder is never authenticated (#451), head f27e093).

1. hyp session status --help does not restate the trust bound

hypaware-core/plugins-workspace/ai-gateway/src/index.js:84-92 documents the
exit codes and the folder-governor caveat but says nothing about
endpoint_authenticated / the trust: note that #520 added beside every
confirmed answer.

Round 2 of #520's review considered this and concluded it's the consistent
state, not an oversight: two pre-existing caveats of the same shape
(EPHEMERAL_NOTE - the opt-out is in-memory only - and the endpoint_source
weak-evidence note) also live only beside the answer and never in --help.
Adding only the newest caveat to --help would be the inconsistent move.

Re-judged at triage: not a blocker. A reader who only reads --help and never
runs the command has no "confirmed" answer to be misled by; anyone who runs the
command (human or --json consumer) sees the caveat inline every time, so the
guarantee itself is never silently asserted. This is a documentation-completeness
nicety, not a behavioural defect.

Suggested resolution (either is fine): either leave as-is (matches house
pattern), or - if a future pass touches --help text generally - add one line
to all three verbs' --help blocks summarizing the trust bound, for the
benefit of a reader who never runs the command interactively.

2. The skill shell paths still curl the control route with no trust note

hypaware-core/plugins-workspace/claude/skills/hypaware-ignore/SKILL.md,
.../hypaware-unignore/SKILL.md, .../hypaware-privacy/SKILL.md, and
hypaware-core/plugins-workspace/codex/skills/hypaware-privacy/SKILL.md all
curl /_hypaware/ignore/session directly and print a confirmed answer
(Ignored session <id>. Total ignored: N / opt-out confirmed for session <id>) with no disclosure that the responder was never authenticated - same
responder, same gap as #451, on a louder surface (an agent narrating the result
straight to the user).

Both review rounds on #520 judged this correctly out of scope for that PR: the
maintainer's direction on #451 named hyp session output specifically, #520
touches no skill file, and LLP 0166 §membership-not-grain assigned the
skill-path work to #460's change set.

Status update since the second review round: PR #522 (fix/issue-460,
open) has since added the echo check (session_id compared byte-exactly,
ignored/total type-checked) to all four of these skill files - see its test
test/plugins/ai-gateway-session-ignore-receipt.test.js (tests 4-6) and its
own scope note: "Deliberately does not touch §cli-response-check's open
question about proving the responder is the gateway - that is #451, in
flight separately." So the membership-validation half of this gap is being
closed by #522, but the responder-authentication trust note is still
missing on all four skill surfaces after both #520 and #522 land - neither
PR adds it there.

Re-judged at triage: still not a blocker for #520 specifically (#520 never
touched these files and the maintainer scoped it out explicitly), but it is a
real, currently-unassigned gap worth closing once #522 lands: the highest-stakes
caller is hypaware-privacy Step 1, which gates the rest of a sensitive-content
privacy review on "opt-out confirmed" with no caveat that a local impostor could
produce the identical confirmation.

Suggested resolution: once #522 merges, port responderTrustNote's message
(or a short skill-appropriate paraphrase) into the four SKILL.md shell blocks'
printed output, alongside the echo check #522 already added. Natural home:
whichever change set implements #435 (skills stop resolving independently),
since that is already named as the point where "the trust note rides along" was
flagged as worth confirming.

Not filed here (already tracked)

The #520 / #522 documentation overlap (LLP 0166 §membership-not-grain states
#460's contract in prose while #522 states it as LLP 0066 R14 and implements
it) is already surfaced to the maintainer directly on both PR threads and is
explicitly the maintainer's call to resolve; not duplicated as a new issue.

[philcunliffe]

🤖 neutral: stuck - blocked until PR #520 merges (not a failed attempt)

The issue-fix rung did not dispatch a worker. The code this issue's findings concern lives only on the unmerged fix/issue-451 branch, so a branch off today's master has nothing to edit.

Verified: responderTrustNote is absent from origin/master; it is #520's own addition. The 36 skill files are on master, so residual 2 (the skill shell paths lacking a trust note) looks superficially actionable - but the note would have to state the LLP 0166 contract, and LLP 0166 does not exist on master either. Writing it now would document a guarantee the shipped code does not yet make. Residual 1 (hyp session status --help) concerns help text for output that is likewise #520's.

PR #520 is currently held, green, reviewed and neutral:approved, waiting on a human merge. That is the blocker, and it needs no decision from you beyond merging when you are ready.

What happens next - automatically. Merge PR #520 and this issue becomes workable on the following tick; neutral re-observes from git every tick and will pick it up without being told.

Why this was not attempted anyway. A PR opened against master could not carry a reproduce -> root-cause -> fix cycle for findings whose subject code is absent, and its body would have to end in Fixes #533, closing an issue whose findings remain unaddressed.

This is the same shape as #511 and #531: a neutral:fix follow-up filed against a PR that has not merged yet is unworkable by construction until it does.

How to unstick: merge PR #520, or reply here; neutral monitors this thread and will re-engage on its next tick.