forge-core: full label→plan→implement→inner-gates→review→PR run in Actions

[ALLiDoizCode]

Parent

Part of toon-protocol/toon-meta#198 — Epic: build Forge, the factory manager. Second forge-core slice — the load-bearing orchestration run.

What to build

Drive a complete label → plan → implement → inner-gates → review → PR run in GitHub Actions from a manifest, on the org auth secret, with the toon-protocol/toon-meta#178 label vocabulary unchanged. This is the acceptance-defining forge-core behaviour: a real factory cycle, not a stub. Per-role model tiering is applied from the manifest throughout.

Acceptance criteria

• forge-core drives a full label→plan→implement→inner-gates→review→PR cycle in Actions from a factory.toml.
• Runs on the org CLAUDE_CODE_OAUTH_TOKEN; agent:implement / agent:review label vocabulary unchanged from Epic: stand up a sandcastle software factory in every execution repo; retire the old agent loops toon-meta#178.
• Per-role tiering (planner Opus 4.8, implementer + reviewer Sonnet-5) applied from the manifest during the live run.
• The run is CI-verified (Actions on the PR ref is the check of record; inner gates remain advisory).

---

Rescoped 2026-08-12 — this is now agent-buildable, and needs:human is removed.

The gating rationale was that this is "a human-driven live-run + observation slice (labeling a
real issue, watching an Actions run, recording proof)". Every step of that is now mechanisable:

• Agents can dispatch workflows. The claude App carries actions: write, verified live
  today — an agent runs gh workflow run and reads the result back. That is how
  toon-meta#335, #309 and connector#577 were un-gated.
• "Watching a run" is the Actions API. Run status, per-job conclusions, per-step outcomes
  and logs are all queryable. An assertion over them is stronger evidence than a person
  watching, because it is repeatable and it fails loudly.
• "Recording proof" is a file the run writes, not a note somebody takes.

So build the proof as a workflow, not as an observation. A committed, reviewed workflow
that seeds a throwaway issue, applies the label, polls for the run it started, asserts the
acceptance criteria against the API, and writes its findings — then fails if any assertion
does not hold.

That inverts the value: today this ticket produces a paragraph somebody wrote once. Rescoped,
it produces a regression test for the factory itself that runs whenever you want it to.

Correlating the run you started is the one genuinely fiddly part, and it is already solved:
see reap-evaluator.mjs's findRunForLabel in toon-meta — exact match on run-name, falling
back to a time window. Note run-name is currently present only in toon-meta
(toon-meta#359), so add it here or use
the fallback deliberately.

Keep the throwaway seeded issue disposable and clearly marked, and have the workflow clean
up after itself — a proof run that leaves debris in the tracker is its own small wedge.

Blocked by

• forge-core: every agent push fails — pushBranch's mint script uses set -o pipefail under dash #62