The sidechain branch in parse returns to the top of the loop before the
pending registration and before the usage accumulation:
if rec.IsSidechain {
delegated = append(delegated, *turn)
continue
}
Three consequences, all reproduced against synthetic fixtures:
- A delegated
ToolCall.Result is always nil. toolIDs is never reached for a
sidechain record, so no delegated call is ever indexed and no result is ever
paired, even when the matching tool_result is two lines below.
- Sidechain usage is dropped rather than relocated.
assay.Usage is documented
as exclusive of delegated work, which is right, but Delegation.Usage is left
at zero, so a caller summing both undercounts with no signal that anything was
lost.
- Every sub-agent collapses into a single
Delegation with an empty ID.
Turns from two runs interleave with no boundary between them, and
ToolCall.DelegatedID is never set, so nothing links a delegation back to the
call that spawned it.
This is dead code on the store as it exists: isSidechain appears zero times in
project-root transcripts and only in the sidecar files under a session's
subdirectory, which Discover deliberately skips. capture.go says so
honestly, and marks CanSeeDelegation partial for that reason.
The claim that needs correcting is the next one: "the inline form is read
correctly when it appears". It is not.
Fix
Move the pending registration and the usage accumulation above the sidechain
branch, accumulating sidechain usage into a separate total that becomes
Delegation.Usage. If splitting one delegation per sub-agent is out of scope
for now, say so in the comment and drop the correctness claim rather than
leaving it unbacked.
The sidechain branch in
parsereturns to the top of the loop before thependingregistration and before the usage accumulation:Three consequences, all reproduced against synthetic fixtures:
ToolCall.Resultis always nil.toolIDsis never reached for asidechain record, so no delegated call is ever indexed and no result is ever
paired, even when the matching
tool_resultis two lines below.assay.Usageis documentedas exclusive of delegated work, which is right, but
Delegation.Usageis leftat zero, so a caller summing both undercounts with no signal that anything was
lost.
Delegationwith an emptyID.Turns from two runs interleave with no boundary between them, and
ToolCall.DelegatedIDis never set, so nothing links a delegation back to thecall that spawned it.
This is dead code on the store as it exists:
isSidechainappears zero times inproject-root transcripts and only in the sidecar files under a session's
subdirectory, which
Discoverdeliberately skips.capture.gosays sohonestly, and marks
CanSeeDelegationpartial for that reason.The claim that needs correcting is the next one: "the inline form is read
correctly when it appears". It is not.
Fix
Move the
pendingregistration and the usage accumulation above the sidechainbranch, accumulating sidechain usage into a separate total that becomes
Delegation.Usage. If splitting one delegation per sub-agent is out of scopefor now, say so in the comment and drop the correctness claim rather than
leaving it unbacked.