~bigbes/agents-dev · parade

main · last commit 13 days ago · 7g0stsfu

← Back to the parade

ah-i0v stale package doc-comments: taskfiles.go, runner.go and httpapi.go describe a surface two stages old Past Stand

status: closed P4 chore
bd reopen ah-i0v
Created byEugene Blikh
Ownerbigbes@gmail.com
Created2026-08-04T23:52:28Z
Started2026-08-04T23:54:12Z
Updated2026-08-05T00:23:22Z
Closed2026-08-05T00:23:22Z
Description
Found by the agent refreshing SPEC §9/§11 — the same staleness it fixed in the spec, still present in the code that spec describes.

1. internal/runner/taskfiles.go:3-12 — the package header reproduces the OLD five-file .task/ layout and still says 'question.json  reserved for Stage 4', in the very file that defines TasksFileName, SummaryFileName, PublishFileName, AnswerFileName and ToolAuthFileName.
2. internal/runner/runner.go:8-10 — the package doc says 'PROMPT.md and meta.json are written at Start'; prepareTaskDir also writes tool-auth.json and the artifacts/ tree, and clears five outbound files plus publish/.
3. internal/httpapi/httpapi.go:1-14 — the package doc lists only four routes and asserts 'The server trusts loopback (no auth in Stage 1)', never mentioning the three bearer-authenticated /api/tool/* routes that tools.go registers in the same package. That sentence is now actively misleading about the package's auth model.

docs/SPEC.md §9 and §11 are correct as of 119b84d; these three comments are what a reader hits FIRST when they open the code, so they should match.
Acceptance criteria
Each of the three package doc-comments matches what its package actually does, and the httpapi one states the split between the unauthenticated loopback routes and the bearer-authenticated tools routes.

Depends on

No outgoing dependencies.

Depended on by

Nothing depends on this issue.

No comments.

Close reason

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.
  • Eugene Blikh created the issue · 2026-08-05T02:52:27Z
  • Eugene Blikh changed status to in_progress · 2026-08-05T02:54:11Z
  • Eugene Blikh closed the issue · 2026-08-05T03:23:21Z
    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.
Stored rows — what this pane was built from, as read
issues 1 row
id ah-i0v
content_hash f80dec59765bb08e0f95b6415363d43fc81e9a986e6ec059d9e8c2e017b50845
title stale package doc-comments: taskfiles.go, runner.go and httpapi.go describe a surface two stages old
description Found by the agent refreshing SPEC §9/§11 — the same staleness it fixed in the spec, still present in the code that spec describes. 1. internal/runner/taskfiles.go:3-12 — the package header reproduces the OLD five-file .task/ layout and still says 'question.json reserved for Stage 4', in the very file that defines TasksFileName, SummaryFileName, PublishFileName, AnswerFileName and ToolAuthFileName. 2. internal/runner/runner.go:8-10 — the package doc says 'PROMPT.md and meta.json are written at Start'; prepareTaskDir also writes tool-auth.json and the artifacts/ tree, and clears five outbound files plus publish/. 3. internal/httpapi/httpapi.go:1-14 — the package doc lists only four routes and asserts 'The server trusts loopback (no auth in Stage 1)', never mentioning the three bearer-authenticated /api/tool/* routes that tools.go registers in the same package. That sentence is now actively misleading about the package's auth model. docs/SPEC.md §9 and §11 are correct as of 119b84d; these three comments are what a reader hits FIRST when they open the code, so they should match.
design
acceptance_criteria Each of the three package doc-comments matches what its package actually does, and the httpapi one states the split between the unauthenticated loopback routes and the bearer-authenticated tools routes.
notes
status closed
priority 4
issue_type chore
assignee NULL
estimated_minutes NULL
created_at 2026-08-04T23:52:28Z
created_by Eugene Blikh
owner bigbes@gmail.com
updated_at 2026-08-05T00:23:22Z
closed_at 2026-08-05T00:23:22Z
closed_by_session
external_ref NULL
spec_id
compaction_level 0
compacted_at NULL
compacted_at_commit NULL
original_size NULL
sender
ephemeral 0
wisp_type
pinned 0
is_template 0
mol_type
work_type
source_system
metadata �{}
source_repo
close_reason 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.
event_kind
actor
target
payload
await_type
await_id
timeout_ns 0
waiters
hook_bead
role_bead
agent_state
last_activity NULL
role_type
rig
due_at NULL
defer_until NULL
no_history 0
started_at 2026-08-04T23:54:12Z
is_blocked 0
events 3 rows
id 019fcf31-6149-7ccd-9890-ce345a004a4e
issue_id ah-i0v
event_type created
actor Eugene Blikh
old_value
new_value
comment NULL
created_at 2026-08-05T02:52:27Z
id 019fcf32-f79a-7660-912d-556791e9f740
issue_id ah-i0v
event_type status_changed
actor Eugene Blikh
old_value {"id":"ah-i0v","title":"stale package doc-comments: taskfiles.go, runner.go and httpapi.go describe a surface two stages old","description":"Found by the agent refreshing SPEC §9/§11 — the same staleness it fixed in the spec, still present in the code that spec describes.\n\n1. internal/runner/taskfiles.go:3-12 — the package header reproduces the OLD five-file .task/ layout and still says 'question.json reserved for Stage 4', in the very file that defines TasksFileName, SummaryFileName, PublishFileName, AnswerFileName and ToolAuthFileName.\n2. internal/runner/runner.go:8-10 — the package doc says 'PROMPT.md and meta.json are written at Start'; prepareTaskDir also writes tool-auth.json and the artifacts/ tree, and clears five outbound files plus publish/.\n3. internal/httpapi/httpapi.go:1-14 — the package doc lists only four routes and asserts 'The server trusts loopback (no auth in Stage 1)', never mentioning the three bearer-authenticated /api/tool/* routes that tools.go registers in the same package. That sentence is now actively misleading about the package's auth model.\n\ndocs/SPEC.md §9 and §11 are correct as of 119b84d; these three comments are what a reader hits FIRST when they open the code, so they should match.","acceptance_criteria":"Each of the three package doc-comments matches what its package actually does, and the httpapi one states the split between the unauthenticated loopback routes and the bearer-authenticated tools routes.","status":"open","priority":4,"issue_type":"chore","owner":"bigbes@gmail.com","created_at":"2026-08-04T23:52:28Z","created_by":"Eugene Blikh","updated_at":"2026-08-04T23:52:28Z"}
new_value {"status":"in_progress"}
comment NULL
created_at 2026-08-05T02:54:11Z
id 019fcf4d-ab8f-7753-9ecc-a9273a36f78a
issue_id ah-i0v
event_type closed
actor Eugene Blikh
old_value
new_value 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.
comment NULL
created_at 2026-08-05T03:23:21Z