29368l5vdmlaftf5p6f6lhpt1n55011r · 503 rows
| id | issue_id | event_type | actor | old_value | new_value | comment | created_at |
|---|---|---|---|---|---|---|---|
| 019fcf4d-6b0c-7226-84bf-6954423c12ef | ah-1cx.11 | closed | Eugene Blikh | Done 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. | NULL | 2026-08-05T03:23:05Z | |
| 019fcf4d-a970-7822-9012-d72fa3dc5ad0 | ah-1cx.16 | closed | Eugene Blikh | Done 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. | NULL | 2026-08-05T03:23:21Z | |
| 019fcf4d-ab8f-7753-9ecc-a9273a36f78a | ah-i0v | closed | Eugene Blikh | Done in 8716a2a. All three package doc-comments described a surface two stages old, and each is what a reader hits FIRST when opening the code. taskfiles.go reproduced a five-file .task/ layout calling question.json 'reserved for Stage 4' in the very file that defines TasksFileName/SummaryFileName/PublishFileName/AnswerFileName/ToolAuthFileName; it now lists all eleven entries with their writer, and states the inbound/outbound split and the per-attempt clearing rule that SPEC §9 fixes. runner.go's bullet claimed only PROMPT.md and meta.json are written at Start; it now names the whole inbound set (including tool-auth.json and artifacts/) and the outbound clearing, and points at taskfiles.go for the layout so the two cannot drift again. httpapi.go was the ACTIVELY MISLEADING one: it listed four routes and asserted 'The server trusts loopback (no auth in Stage 1)' while tools.go registers three bearer-authenticated /api/tool/* routes in the same package. It is now split into an unauthenticated loopback group and a bearer-authenticated group, spelling out the token's (task id, attempt) binding, the constant-time compare, the uniform 401, the Deps.Tools registration gate, and WHY loopback trust is not sufficient for those three. Verified against docs/SPEC.md §9 and §11 as of 119b84d; no spec file was touched. | NULL | 2026-08-05T03:23:21Z |