Security-block findings are written to a comment the re-queued agent can never read #434

New issue

Closed

opened 2026-07-27 20:48:27 +00:00 by igor · 0 comments

igor commented

2026-07-27 20:48:27 +00:00

Collaborator

The problem

When the security review blocks a build, the harness posts its findings as an issue comment and instructs:

Address it, then remove Status/Blocked to re-queue.

Following that instruction cannot work. The issue-work path passes only the issue body to the model:

bin/tick.sh:4216   ISSUE_BODY=$(jq -r ".body // \"\"" <<<"$WINNER")
bin/tick.sh:4356   ${ISSUE_BODY}

Comments are never included in the prompt. So a re-queued ticket hands the agent the same body that produced the rejected diff, with no trace of why it was rejected. The most likely outcome is that it rebuilds the same thing and is blocked again — burning a full build, a security review and a rework cycle per lap, with nothing in the loop that can break it.

Evidence

joshtronic/igor#433, 2026-07-27:

15:11:13  [agent] claiming joshtronic/igor#433: CEO digest steering is unreachable...
15:24:45  [agent] outcome: blocked (security review flagged the diff)
15:24:47  [agent] removing worktree /home/igor/.local/state/agent/worktrees/joshtronic_igor-433

The findings — a real authorization gap, correctly caught — went into a comment. The ticket only re-queued successfully because a human copied the requirement into the body by hand first. Without that step it would have looped.

What "fixed" looks like

Either direction closes it; pick one:

The block flow appends its findings to the issue BODY (under a clear heading) as well as, or instead of, commenting. Keeps the prompt contract as-is.
The issue-work prompt includes the issue's comments. Broader change — it also fixes every other case where a human adds context in a comment and the agent silently ignores it — but it grows the prompt and needs thought about ordering and trust (a comment is not the same authority as a body written by the operator).

Whichever is chosen, the outcome to test is: a ticket blocked for a stated reason, then re-queued, presents that reason to the next run.

Acceptance criteria

A security-blocked ticket, re-queued with no human editing, gives the next agent run the blocking findings.
A test covers it — assert the blocked findings reach the prompt input, not just that they were written somewhere.
The instruction text in the block comment matches whatever mechanism is implemented (today it describes a workflow that does not function).

The blocked build is also discarded entirely — the worktree is removed and nothing is pushed, so the next run starts from zero. There is precedent for the opposite: a build that exceeds the turn cap checkpoints to a draft PR and resumes (igor#356) rather than throwing the work away. Applying the same treatment to a security block would turn "rebuild from scratch" into "fix one predicate." Deliberately out of scope for this ticket — noted so it is not lost, and it should be split into its own if wanted.

## The problem When the security review blocks a build, the harness posts its findings as an issue **comment** and instructs: > Address it, then remove `Status/Blocked` to re-queue. Following that instruction cannot work. The issue-work path passes **only the issue body** to the model: ``` bin/tick.sh:4216 ISSUE_BODY=$(jq -r ".body // \"\"" <<<"$WINNER") bin/tick.sh:4356 ${ISSUE_BODY} ``` Comments are never included in the prompt. So a re-queued ticket hands the agent the *same body that produced the rejected diff*, with no trace of why it was rejected. The most likely outcome is that it rebuilds the same thing and is blocked again — burning a full build, a security review and a rework cycle per lap, with nothing in the loop that can break it. ## Evidence `joshtronic/igor#433`, 2026-07-27: ``` 15:11:13 [agent] claiming joshtronic/igor#433: CEO digest steering is unreachable... 15:24:45 [agent] outcome: blocked (security review flagged the diff) 15:24:47 [agent] removing worktree /home/igor/.local/state/agent/worktrees/joshtronic_igor-433 ``` The findings — a real authorization gap, correctly caught — went into a comment. The ticket only re-queued successfully because a human copied the requirement into the body by hand first. Without that step it would have looped. ## What "fixed" looks like Either direction closes it; pick one: - **The block flow appends its findings to the issue BODY** (under a clear heading) as well as, or instead of, commenting. Keeps the prompt contract as-is. - **The issue-work prompt includes the issue's comments.** Broader change — it also fixes every other case where a human adds context in a comment and the agent silently ignores it — but it grows the prompt and needs thought about ordering and trust (a comment is not the same authority as a body written by the operator). Whichever is chosen, the outcome to test is: a ticket blocked for a stated reason, then re-queued, presents that reason to the next run. ## Acceptance criteria - A security-blocked ticket, re-queued with no human editing, gives the next agent run the blocking findings. - A test covers it — assert the blocked findings reach the prompt input, not just that they were written somewhere. - The instruction text in the block comment matches whatever mechanism is implemented (today it describes a workflow that does not function). ## Related, NOT required here The blocked build is also **discarded entirely** — the worktree is removed and nothing is pushed, so the next run starts from zero. There is precedent for the opposite: a build that exceeds the turn cap checkpoints to a draft PR and resumes (igor#356) rather than throwing the work away. Applying the same treatment to a security block would turn "rebuild from scratch" into "fix one predicate." Deliberately out of scope for this ticket — noted so it is not lost, and it should be split into its own if wanted.

igor added the

Kind/Bug

label

2026-07-27 20:48:27 +00:00

igor self-assigned this

2026-07-27 21:34:35 +00:00

igor referenced this issue from a pull request that will close it,

2026-07-27 21:45:40 +00:00

fix: append block findings to the issue body so a re-queued ticket can see them #436

igor added spent time

2026-07-27 21:45:40 +00:00

10 minutes 32 seconds