~bigbes/agents-dev · events

rkjlicmsuo2l2qdddrjgbh3o0rmns9ao · 502 rows

idissue_idevent_typeactorold_valuenew_valuecommentcreated_at
019fcf4d-6b0c-7226-84bf-6954423c12efah-1cx.11closedEugene BlikhDone in 8716a2a. Confirmed as filed: createChildTasks logged and continued past a RecordChild failure, so a child could exist on the board with no task_parents row — invisible to ChildIDsOf, to the Blocked join, and to the per-parent lifetime cap — leaving the parent parked on a strictly smaller set than it created and undercounting ah-1cx.2's before/after guard. Took the DURABLE-RETRY option rather than a plain abort, because an abort that holds the card would hold it forever. createChildTasks now stops at the FIRST lost lineage row (creating more children a broken store cannot record only widens the hole) and returns the orphaned ids alongside created. delegateAndBlock refuses to park while any id is orphaned: it records them in the park marker's payload (armed:<before>,<id>,<id> — the no-orphan form is unchanged so older markers decode), holds the card in In Progress, and posts a comment naming every created card plus the untracked ones, stamped alarmed so a persistent fault does not spam. reparkDelegatedParent retries the lineage write before anything counts children (RecordChild is idempotent; the generation is re-derived from GenerationOf(parent)+1 rather than stored), then parks normally and records a delegation_lineage_recovered event. ToolTaskCreate reports the same condition as a 500 naming the card id — a fire-and-forget child deadlocks nobody, but a silent success would still corrupt the cap and any later join. Cover: TestDelegationLineageFailure, TestToolTaskCreateLineageFailureIsReported. FOLLOW-UP: nothing reconciles board reality against task_parents, so a child card created by hand or a lineage row whose card was deleted is still undetectable — a periodic lineage audit would close that.NULL2026-08-05T03:23:05Z
019fcf4d-a970-7822-9012-d72fa3dc5ad0ah-1cx.16closedEugene BlikhDone in 8716a2a. Confirmed: prepareTaskDir writes s.Prompt verbatim and nothing upstream checked it, so a role template rendering to whitespace produced a pi run that did nothing and exited 0 — caught by ah-tqc's second Errored() arm, but only AFTER a worktree, a zellij pane and an attempt number were spent, and with no way to say which role or template was at fault. The guard went on the RECONCILE side, inside renderPrompt: the single seam both claim and launchResume render through, and the only layer holding the role name and the template path — the two facts an operator needs. The error flows into the existing SPEC §12 claim-failure path (card → failed, 'claim failed' comment, claim_failed event) with no new machinery. The port is deliberately NOT guarded twice: ah-tqc's arm is the port's own backstop and stays intact, so a blank prompt reaching Start by some future route still finalizes as an error rather than sailing to In Review; ports.StartSpec.Prompt now documents that split as the contract. Note the check is on the TEMPLATE's output, before the artifact manifest and Context Pack are appended — a role whose own template says nothing is a broken config even if the card happens to carry text. Cover: two prompt_test.go subtests plus TestClaimRejectsBlankRenderedPrompt.NULL2026-08-05T03:23:21Z