Collapse Steering Issue + Experiment Log into a single program issue per program

[mrjf]

Summary

Autoloop currently creates up to three separate GitHub issues per program:

1. The program issue (issue-based programs only) — labeled autoloop-program, body is the program definition.
2. A steering issue — titled [Autoloop: {name}] Steering, meant for human steering and persistent links.
3. A monthly experiment log issue — titled [Autoloop: {name}] Experiment Log {YYYY}-{MM}, a rolling per-iteration log.

In practice, the separation causes more confusion than value. Consolidate all three into one issue per program.

Observed problems with the three-issue model

• Steering issues sit empty and get auto-closed as stale. Maintainers treat empty issues as abandoned and close them as completed, which is misleading — the program itself is still healthy.
• Monthly rollover creates clutter. A new experiment-log issue per month per program — none of which anyone looks at because the program issue is what people actually watch.
• Per-iteration comments go to the experiment log, so the program issue itself goes silent. Users wonder if Autoloop has stopped working because the issue they're subscribed to has no activity, even when iterations are happening.
• State-file / PR-body / per-iteration-comment link triangulation is annoying. Each iteration references three different issue numbers for the same program.

Proposed model — one issue per program

Every program has exactly one open GitHub issue labeled autoloop-program, titled [Autoloop: {program-name}]. That one issue hosts:

• The status comment — the earliest bot comment, edited in place each iteration. A dashboard: current best metric, last run, iteration count, PR link, paused state, pause reason.
• One per-iteration comment per iteration (accepted, rejected, error) — the rolling log. Replaces the experiment-log issue.
• Human steering — plain prose comments from maintainers, treated by the agent as directives. Replaces the steering issue.

No separate "Steering" or "Experiment Log" issues. autoloop.lock.yml's create-issue max can drop from 2 → 1.

File-based vs issue-based programs

• Issue-based programs (source issue has autoloop-program label): already use this pattern — the source issue is the program issue. No change.
• File-based programs (.autoloop/programs/<name>/program.md): auto-create their program issue on first run via create-issue. Record the issue number in the state file's Issue field. Thereafter behave identically to issue-based programs.

This removes the special-case split between file-based and issue-based programs — they share the same operational model.

Concrete changes to workflows/autoloop.md

1. Replace ## Steering Issue + ## Issue-Based Program Updates with a single ## Program Issue section

```markdown

Program Issue

Each program has exactly one open GitHub issue (labeled `autoloop-program`) titled `[Autoloop: {program-name}]`. This single issue is the source of truth for the program — it hosts:

• The status comment (the earliest bot comment, edited in place each iteration) — a dashboard of current state.
• A per-iteration comment for every iteration (accepted, rejected, or error) — the rolling log.
• Human steering comments — plain-prose comments from maintainers, treated by the agent as directives.

There are no separate "steering" or "experiment log" issues — they have all been collapsed into this one issue.

Auto-creation for File-Based Programs

If `selected_issue` is `null` in `/tmp/gh-aw/autoloop.json`, the program is file-based and has no program issue yet. On the first run, create one with `create-issue` titled `[Autoloop: {program-name}]`, body = the program.md contents plus a status-comment placeholder, labels `[autoloop-program, automation, autoloop]`. Record the issue number in the state file's `Issue` field.

On subsequent runs, `selected_issue` will be populated by the pre-step (by looking up open issues with the `autoloop-program` label whose title matches `[Autoloop: {program-name}]`).

Per-Iteration Flow

1. Update (edit) the status comment — the earliest bot comment on the program issue. Include: current best metric, last run timestamp, iteration count, PR number, paused state, pause reason, target metric (if set), progress toward halting condition.
2. Post a new per-iteration comment — one per iteration. Status (✅ Accepted / ❌ Rejected / ⚠️ Error), metric, delta, commit SHA, PR link, one-line summary.
3. Read existing comments from the same issue — any human comments since the last iteration are steering directives.
   ```

2. Rename state-file Steering Issue field → Issue

```diff
-| Steering Issue | #{steering_issue_number} |
-| Experiment Log | #{experiment_log_issue_number} |
+| Issue | #{program_issue_number} |
```

3. Update safe-outputs create-issue: max

```diff
safe-outputs:
create-issue:
title-prefix: "[Autoloop] "
labels: [automation, autoloop]

• max: 2

• max: 1
  ```

One create-issue call per run maximum: bootstrapping a file-based program's issue on first run.

4. Migration notes for existing installations

• Existing programs may have all three issues open. The agent should check for an existing [Autoloop: {name}]-titled program issue first; if found, use it. Otherwise auto-create.
• Existing Steering and monthly Experiment Log issues can be manually closed by maintainers; the agent should stop posting to them.
• The state file's Steering Issue / Experiment Log fields can be deprecated (kept for backward compat, but prefer Issue).

Rationale

Three-issue designs optimize for separation of concerns (definition vs. steering vs. log). In practice, nobody uses the separation — everyone reads the program issue and expects activity there. One rolling issue is:

• Cheaper for human attention. One subscription per program, not three.
• Cheaper for notification budget. Iteration comments don't fan out to a separate log issue.
• Removes the file-based vs issue-based asymmetry. Uniform model for all programs.
• Removes stale-issue paper trails. No empty steering issues sitting open for maintainers to misinterpret.

Related

Pairs naturally with sibling issues #34 (scheduler extraction — the existing_program_issue lookup lives in the scheduler) and #35 (single-PR invariant — the state-file Issue field and the existing_pr field sit side by side).