Autoloop: collapse program / steering / experiment-log into a single issue per program

[mrjf]

Current state

Each autoloop program currently has three separate GitHub issues:

1. Program issue — labeled autoloop-program, body contains the program definition (goal, target, evaluation). Example: Build tsb: pandas → TypeScript migration #1.
2. Steering issue — titled [Autoloop: {name}] Steering, meant for human steering input and status summary. Example: [Autoloop] [Autoloop: build-tsb-pandas-typescript-migration] Steering #107 (now closed because no one used it).
3. Experiment log issue — titled [Autoloop: {name}] Experiment Log {YYYY}-{MM}, a rolling log of accepted/rejected/error iterations. Example: [Autoloop] [Autoloop: perf-comparison] Experiment Log 2026-04 #130 for perf-comparison.

This fragmentation is confusing:

• Steering issues sit empty and get closed as stale ([Autoloop] [Autoloop: build-tsb-pandas-typescript-migration] Steering #107 was closed as completed even though the program was healthy).
• Experiment logs live somewhere no one looks; the program issue is what people actually read.
• State file / PR body / per-iteration comments reference different issue numbers for the same program — hard to follow.
• Per-iteration comments go to the experiment log, so the program issue itself goes silent (see Build tsb: pandas → TypeScript migration #1: no new activity for 8+ days even when the program was running).

Proposed change

One issue per program. Everything lives there.

• The program issue (the one with autoloop-program) is the single source of truth.
• All per-iteration updates comment on that same issue — accepted/rejected/error entries, metric deltas, links to the actions run and PR.
• Human steering is plain prose comments on the same issue; the agent reads all human comments as directives (it already does this for issue-based programs).
• Status summary is the earliest-bot-comment (edited in place each iteration), same pattern as today's "status comment" on issue-based programs.
• No separate steering issue. No separate experiment log issue.

Changes needed in .github/workflows/autoloop.md

1. Remove creation of the steering issue. The program issue already plays this role for issue-based programs; extend to file-based programs too (more on that below).
2. Remove creation of the monthly experiment log issue. Post every iteration as a comment on the program issue. Month rollover doesn't need a new issue — ~365 comments/year on a rolling issue is fine.
3. Unify commenting. The flows at L820 and L869 (accepted / rejected / error) currently post to the experiment log issue. Redirect them to the program issue.
4. Single status comment per program. Keep the "edit the earliest bot comment in place" pattern; it's the dashboard. Everything else is appended as new comments.
5. Update the state file template to show Issue: #{n} once, instead of Steering Issue + Experiment Log + Steering Issue.
6. Update PR body template to link the single issue.

File-based programs

File-based programs (e.g., perf-comparison defined in .autoloop/programs/perf-comparison/program.md) don't currently have a program issue. Two options:

A. Auto-create one on first run. The pre-step creates a program issue titled [Autoloop: {name}] with the program.md body, adds the autoloop-program label, and records the issue number in the state file. Thereafter it behaves identically to issue-based programs.

B. File-based programs skip the issue entirely. Status and iteration comments go on the program's single PR instead. Simpler, but loses the "one place to read" property when a program doesn't have an open PR (post-merge cleanup).

Prefer A — uniform model for all programs, humans always have one issue to read / steer on.

Migration for existing programs

• perf-comparison (file-based): auto-create its program issue on the next run.
• build-tsb-pandas-typescript-migration (issue-based, Build tsb: pandas → TypeScript migration #1): keep Build tsb: pandas → TypeScript migration #1, stop creating the experiment log and steering issues for it. Close [Autoloop] [Autoloop: build-tsb-pandas-typescript-migration] Steering #107 (already closed) and [Autoloop] [Autoloop: perf-comparison] Experiment Log 2026-04 #130.
• Optional: copy the contents of [Autoloop] [Autoloop: perf-comparison] Experiment Log 2026-04 #130 into a pinned comment on Build tsb: pandas → TypeScript migration #1 so historical iteration context isn't lost.

Acceptance

• Exactly one open issue per program (labeled autoloop-program).
• All autoloop activity (status, accepted, rejected, error, human steering) happens on that issue.
• No new Steering or Experiment Log issues are created.
• State file has a single Issue: #{n} field replacing Steering Issue / Experiment Log / PR.
• PR body links the one issue.

Rationale

Today the model optimizes for separation of concerns (program def vs. steering vs. log). In practice nobody uses the separation — everyone reads the program issue and expects activity there. Collapsing removes a steady stream of stale issues (#107 got auto-closed as "completed" despite the program being healthy, which is exactly the kind of confusion that won't happen if there's only one issue).

Related

• Build tsb: pandas → TypeScript migration #1 (program issue with no new activity for 8+ days)
• [Autoloop] [Autoloop: build-tsb-pandas-typescript-migration] Steering #107 (steering issue closed as stale)
• [Autoloop] [Autoloop: perf-comparison] Experiment Log 2026-04 #130 (experiment log, most recent activity is where the actual program runs land)
• Autoloop pre-step can't read state files — build-tsb starved since 2026-04-12 #162 (separate bug: scheduler can't read state — fix that too so the single-issue model has fresh state to display)