What happens
Two remaining lifecycle-comment detector blind spots, distinct from the
for-loop/variable-command-text gap fixed in #320 (PR #323), which fixed
scanTranscriptForComment's command-text resolution but not either of
these:
1. Background-subagent-posted comments are invisible to the parent transcript
Reported in #320's second comment: a transition made in the parent session
was flagged even though the paired lifecycle comment had been posted by a
background workflow subagent (verified live on the issue). The parent
session's own transcript file has no record of a subagent's tool calls at
all -- they execute and are logged in the subagent's own transcript, not
the parent's -- so scanTranscriptForComment's single-transcript-file scan
structurally cannot see them, no matter how the command was written.
2. Same-turn parallel tool-call dispatch can race ahead of the transcript write
Observed live while working #320/PR #323 in this same session: a lifecycle
comment was posted via gh issue comment 320 ... (a literal number, not a
loop/variable -- the #320 fix does not apply here) in the SAME assistant
message as the paired set_field_value transition call, with the comment
call textually first, per this project's own "pair status comment same
message" convention. The reminder still fired. The likely mechanism: when
two tool calls are dispatched together in one message, they run in
parallel rather than strictly sequentially, so the Bash call's own
tool_result may not yet be flushed to the transcript file at the instant
the set_field_value call's PostToolUse hook fires and reads it --
textual ordering within the message does not guarantee write-ordering in
the transcript file.
Why these are separate from #320
Both are real gaps in the same detector but need their own design decision
rather than a mechanical extension of #320's fix:
- (1) needs either a way to read/merge a subagent's own transcript, or a
different signal entirely (e.g. trusting a live GraphQL comment lookup
instead of a transcript scan for this case).
- (2) needs either a way to force sequential dispatch for a
comment-then-transition pair, or a check that fails open more gracefully
under a known race window (e.g. a live GraphQL check for a very recent
comment on the issue, rather than relying solely on the transcript scan).
Notes
What happens
Two remaining lifecycle-comment detector blind spots, distinct from the
for-loop/variable-command-text gap fixed in #320 (PR #323), which fixed
scanTranscriptForComment's command-text resolution but not either ofthese:
1. Background-subagent-posted comments are invisible to the parent transcript
Reported in #320's second comment: a transition made in the parent session
was flagged even though the paired lifecycle comment had been posted by a
background workflow subagent (verified live on the issue). The parent
session's own transcript file has no record of a subagent's tool calls at
all -- they execute and are logged in the subagent's own transcript, not
the parent's -- so
scanTranscriptForComment's single-transcript-file scanstructurally cannot see them, no matter how the command was written.
2. Same-turn parallel tool-call dispatch can race ahead of the transcript write
Observed live while working #320/PR #323 in this same session: a lifecycle
comment was posted via
gh issue comment 320 ...(a literal number, not aloop/variable -- the #320 fix does not apply here) in the SAME assistant
message as the paired
set_field_valuetransition call, with the commentcall textually first, per this project's own "pair status comment same
message" convention. The reminder still fired. The likely mechanism: when
two tool calls are dispatched together in one message, they run in
parallel rather than strictly sequentially, so the Bash call's own
tool_resultmay not yet be flushed to the transcript file at the instantthe
set_field_valuecall's PostToolUse hook fires and reads it --textual ordering within the message does not guarantee write-ordering in
the transcript file.
Why these are separate from #320
Both are real gaps in the same detector but need their own design decision
rather than a mechanical extension of #320's fix:
different signal entirely (e.g. trusting a live GraphQL comment lookup
instead of a transcript scan for this case).
comment-then-transition pair, or a check that fails open more gracefully
under a known race window (e.g. a live GraphQL check for a very recent
comment on the issue, rather than relying solely on the transcript scan).
Notes
gh issue comment $n) #320 -- reminder noise, no data impact.direction is chosen for either gap.