main · 517 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 | |
| 019fcf4e-1a0d-73f3-bc2b-54daa24394fd | ah-gg3 | created | Eugene Blikh | NULL | 2026-08-05T03:23:50Z | ||
| 019fcf4e-1c26-7cd9-bc3b-0a92caefdae6 | ah-x5d | created | Eugene Blikh | NULL | 2026-08-05T03:23:50Z | ||
| 019fcf4e-1e3e-7a4c-8a90-61b99ba9a1aa | ah-if2 | created | Eugene Blikh | NULL | 2026-08-05T03:23:51Z | ||
| 019fcf4e-204a-7052-ba43-8c65b2309fe6 | ah-yq0 | created | Eugene Blikh | NULL | 2026-08-05T03:23:51Z | ||
| 019fcf4e-46bd-735b-b1bb-996030730afe | ah-1cx | label_added | Eugene Blikh | NULL | NULL | Added label: milestone:v0.2.0 | 2026-08-05T03:24:01Z |
| 019fcf4e-4828-7b00-b3cb-1ce3844b4ed4 | ah-x5d | label_added | Eugene Blikh | NULL | NULL | Added label: milestone:v0.2.0 | 2026-08-05T03:24:01Z |
| 019fcf4e-4a32-7c9a-9c83-b9493b78d924 | ah-gg3 | label_added | Eugene Blikh | NULL | NULL | Added label: milestone:v0.2.0 | 2026-08-05T03:24:02Z |
| 019fcf4e-4bb3-7b5e-a489-66285bfc414d | ah-wd4 | label_added | Eugene Blikh | NULL | NULL | Added label: milestone:v0.2.0 | 2026-08-05T03:24:02Z |
| 019fcf4e-4d0d-74de-93fd-c4af82c8fb5f | ah-yq0 | label_added | Eugene Blikh | NULL | NULL | Added label: milestone:v0.2.0 | 2026-08-05T03:24:03Z |
| 019fcf4e-4e70-7e48-81c2-cf1337f2b9e1 | ah-if2 | label_added | Eugene Blikh | NULL | NULL | Added label: milestone:v0.2.0 | 2026-08-05T03:24:03Z |
| 019fcf4e-4fda-753b-bdcd-faf68e638b30 | ah-46h | label_added | Eugene Blikh | NULL | NULL | Added label: milestone:v0.2.0 | 2026-08-05T03:24:03Z |
| 019fcf4e-5147-78b2-a8f8-6caeea964bf4 | ah-a0y | label_added | Eugene Blikh | NULL | NULL | Added label: milestone:v0.2.0 | 2026-08-05T03:24:04Z |
| 019fcf4e-52bb-7897-b763-24d4a4e7167c | ah-oeq | label_added | Eugene Blikh | NULL | NULL | Added label: milestone:v0.2.0 | 2026-08-05T03:24:04Z |
| 019fcf52-a329-705d-8f02-18479994e488 | ah-1qq | updated | Eugene Blikh | {"id":"ah-1qq","title":"Release infra: version stamping via ldflags + first tagged release","description":"The daemon hardcodes version = dev (cmd/agenthubd/main.go:44) and nothing stamps it: the repo has zero git tags and neither the justfile nor .build.yml passes -ldflags -X main.version. Live agent-1 therefore logs version=dev on every boot and there is no way to tell which build is deployed. Add ldflags stamping (git describe) to the justfile and the CI deploy lane, surface the version in the status API, and cut the first tag. Release-blocking for v0.1.0. Filed 2026-07-20.","notes":"STAMPING DONE in 1c96c00; only the tag itself remains, and it is deliberately blocked on the rest of milestone v0.1.0 (a milestone is frozen at its tag, so nothing may be added after).\n\nWhat landed: the justfile derives 'git describe --tags --always --dirty' into a version variable and passes -X main.version to go build ./cmd/... — ONE flag stamps all three mains, because -X's 'main' resolves per link. --always degrades to a short sha before the first tag exists, --dirty marks a build made from an uncommitted tree so a hand-built binary can never be mistaken for a release, and a '|| echo dev' arm covers a tree with no git at all. 'just show-version' prints what the tree would stamp. .build.yml does the same and then runs 'ahub version' as a build-time assertion that the stamp actually landed — so a broken stamp fails CI instead of silently deploying a 'dev' binary.\n\nahub-run gained a version var and a --version flag (answered before the required-flag check, since it is a question about the binary not a request to supervise anything): it is the binary that runs INSIDE the pane, so that is how a human attached to a keep-pane shell identifies the build that supervised the run in front of them.\n\nGET /api/v1/status now carries the build string via httpapi.Deps.Version, which defaults to 'dev' when empty so a test server or unstamped build never reports blank — a blank version reads as a serialization bug rather than as 'nobody stamped this'. The boot log line is invisible once the journal has rotated, and status is the one surface an operator can reach without shell access to the box. Cover: TestStatusVersion, both arms.\n\nVerified end to end locally: just build produced binaries reporting f11ef03-dirty.\n\nREMAINING: cut v0.1.0 once the milestone's other beads close, then confirm on agent-1 that the deployed binary reports the tag rather than a sha.","status":"in_progress","priority":2,"issue_type":"task","owner":"bigbes@gmail.com","created_at":"2026-07-20T00:10:40Z","created_by":"Eugene Blikh","updated_at":"2026-08-04T23:48:55Z","started_at":"2026-08-04T23:48:55Z","labels":["milestone:v0.1.0"]} | {"notes":"STAMPING DONE in 1c96c00; deploy-lane hardening added in a4fac87 after an independent review of the series. Only the TAG itself remains, deliberately blocked on the rest of milestone v0.1.0 (a milestone is frozen at its tag).\n\nLanded: the justfile derives 'git describe --tags --always --dirty' and passes -X main.version to go build ./cmd/... — ONE flag stamps all three mains, because -X's 'main' resolves per link. --always degrades to a short sha before the first tag exists, --dirty marks a build from an uncommitted tree, '|| echo dev' covers a tree with no git. 'just show-version' prints what the tree would stamp. ahub-run gained a version var and a --version flag (answered before the required-flag check) since it is the binary running INSIDE the pane. GET /api/v1/status carries the build string via httpapi.Deps.Version, defaulting to 'dev' when empty so a test server never reports blank. Cover: TestStatusVersion, both arms. Verified end to end: just build produced binaries reporting f11ef03-dirty.\n\nCI hardening (a4fac87), both from review findings:\n- The version check was a PRINT, not an assertion. 'git describe --always' degrades to a short sha before the first tag, so 'dev' can only mean git itself failed (dubious ownership, no .git) — an unstamped binary would have deployed while the build looked green. Now 'test \"$VERSION\" != dev' fails the build and the smoke check greps for the expected string.\n- CONFIG PRE-FLIGHT added to the deploy task. This series tightened validation four times (ah-1cx.3, ah-1cx.6, ah-1jy, ah-w4r) and /etc/agent-hub/agenthub.yaml is hand-maintained, NOT CI-managed; agenthubd turns a load error into exit 1, so a restart into a rejected config is a crash loop with the previous binary already overwritten by the tar. The deploy now runs the NEW binary's 'ahub validate-config' against the LIVE file while the OLD daemon still serves.\n\nREMAINING: cut v0.1.0 once ah-1cx.8 and ah-ydx close, then confirm on agent-1 that the deployed binary reports the tag rather than a sha."} | NULL | 2026-08-05T03:28:47Z |