Follow-up: deferred review findings from PR #895

[philcunliffe]

Deferred, non-blocking findings from the neutral review rounds on PR #895 (head 30f60d27), triaged at the review-round cap. Every actionable defect found in review was fixed on the branch (a091f802, 30f60d27) and verified; the three items below are the residuals, each deliberate or out of scope for that PR.

1. Subagent body-derived gap rows read null attribution (deliberate trade-off, needs an empirical check)

hypaware-core/plugins-workspace/claude/src/telemetry/projection.js (~line 123): gap messages take attribution solely from their own body event (attributeMessageToEvent(gap, event)), so subagent gap rows carry agent_id / is_sidechain only if api_request_body / api_response_body events carry agent.name. Nothing in the repo shows that they do. Post-PR, a subagent turn's tool_use/tool_result gap rows read null attribution while its text row is sidechain-labeled.

This was left as-is on purpose: deriving attribution from a sibling event would reintroduce the batch-composition-dependent identity the PR removes (the content-hash message_id is scoped by agent_id). Follow-up: on a real Claude Code, confirm whether the body events carry agent.name, and record the answer in the claude_otel_shape_check procedure (docs/ACCEPTANCE.md). If they do not, document the gap as permanent on this path rather than papering over it.

2. is_sidechain is true or null on the OTEL path, never false (design decision, wants its own request)

projection.js (attributeMessageToEvent) sets is_sidechain only for a positively identified subagent, matching the proxy producer (hypaware-core/plugins-workspace/claude/src/projector.js:354) per the LLP 0252 parity requirement, and deviating from issue #881's acceptance text (is_sidechain: false on main-loop rows). The transcript producer writes the real boolean (transcripts.js:692), so a consumer filtering where is_sidechain = false silently drops every OTEL and proxy main-loop row while keeping transcript ones.

Decision needed (a change to the settled shape in LLP 0252 / 0262, so a new LLP request, not a drive-by): either both Claude producers start stamping is_sidechain: false for positively identified main-loop rows, or the three-valued column stays and query guidance moves to is null / is_not_distinct_from.

3. Content-hash scope shift across the upgrade causes bounded one-time duplicates (release-notes line)

Removing the exchange-level agent_id changes the fallback content-hash scope for body-derived blocks with no native uuid. A session live across the upgrade replays its request-body history under the new scope, so previously written blocks land a second time, and because the rows differ in agent_id, compaction's _hyp_cache_row_id dedupe will not collapse them (the live path has no pre-write part_id dedupe; that is backfill-only, hypaware-core/plugins-workspace/ai-gateway/src/dataset.js:578). Bounded and one-time; needs a line in the release notes for the release that ships PR #895.

Backlink: PR #895 (review records in the PR comments carry full repro detail for each item).

[philcunliffe]

neutral cannot land a fix for this issue autonomously

What neutral was doing. Took #920 under neutral:fix, read the issue and both neutral review records on PR #895, checked out origin/master (12154929) in a scratch worktree, and tried to reproduce each of the three findings with a failing test. None of the three yields one, for a different reason each.

Why it cannot proceed.

PR #895 is still open and unmerged. Findings 1 and 3 both describe code that exists only on fix/issue-881. attributeMessageToEvent is not on master; on master agent.name and query_source are still session-level facts (claude/src/telemetry/projection.js:361-362), which is precisely what #895 changes. There is nothing on master to reproduce against and nothing on master to fix.

• Finding 1 (gap-row attribution) is additionally not a code question at all. The issue itself states the resolution: run a real Claude Code and observe whether api_request_body / api_response_body carry agent.name. That is an claude_otel_shape_check acceptance run on real hardware, which neutral has no way to perform, and the follow-up edit (recording the answer in docs/ACCEPTANCE.md) is meaningless until someone has the answer. Doc-only besides: no test in test/** asserts on docs/ACCEPTANCE.md content.
• Finding 3 (one-time duplicates across the content-hash scope shift) asks for a release-notes line for the release that ships Claude OTEL: per-event agent.name and query_source stop becoming session facts #895. There is no CHANGELOG or release-notes file in the repo, so the artifact is the GitHub release body, written by whoever cuts the release after Claude OTEL: per-event agent.name and query_source stop becoming session facts #895 merges. Nothing to commit today.

Finding 2 is escalated, not fixed. Its symptom does exist on master independent of #895: claude/src/projector.js:354 and claude/src/telemetry/projection.js:191 write is_sidechain as true or nothing, while codex/src/exchange-projector.js:1195, codex/src/backfill.js:656, and claude/src/transcripts.js:692 write the real boolean. But the issue and both review records agree this is a decision, not a defect: "Either way it is a change to the settled shape in LLP 0252 / 0262 and wants its own request, not a drive-by." Per neutral's escalate-don't-force rule, neutral filed the request instead of picking a side:

• PR LLP 0282: is_sidechain is three-valued, and the Claude live producers never write false #930 (draft) adds llp/0282-is-sidechain-is-three-valued-on-the-claude-live-producers.issue.md. Request document only, no code, nothing settled. It records the four-producer disagreement with file:line evidence verified on master, why both Claude live paths were written the way they are (they see only positive evidence of a subagent, and LLP 0252 parity forbids changing one path alone), and the two coherent resolutions with the cost of each.

Concrete questions.

1. Finding 2: which resolution? Option A, both Claude live producers stamp is_sidechain: false behind a positive main-loop signal (the OTEL candidate is query_source present and not naming an agent; the proxy path has no equivalent positive signal today, which is Option A's real cost), or Option B, the tri-state becomes the written contract and the hypaware-analyst / hypaware-query guidance moves off = false to is null / is not true? Answer on PR LLP 0282: is_sidechain is three-valued, and the Claude live producers never write false #930 and neutral will implement the chosen option with a test that pins it.
2. Findings 1 and 3: should they be re-scoped onto PR Claude OTEL: per-event agent.name and query_source stop becoming session facts #895's branch (where finding 1's attributeMessageToEvent actually lives), or held until Claude OTEL: per-event agent.name and query_source stop becoming session facts #895 merges and then re-labelled neutral:fix on a fresh issue against master? As written against master today they are unworkable.
3. Finding 1 specifically: can a maintainer with a real Claude Code >= 2.1.214 report whether api_request_body / api_response_body events carry agent.name? That single observation decides whether the gap-row attribution gap is a bug to fix or a permanent limitation to document, and neutral cannot obtain it.

Neutral has left #920 open. Nothing here closes it, and PR #930 deliberately says Refs #920, not Fixes #920, because it addresses one of three findings.

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