feat(deliver): build each issue of a program in a fresh subagent

.changeset/deliver-subagent-per-issue.md

@@ -0,0 +1,5 @@
+---
+'aplus': patch
+---
+
+deliver: build each issue of a program in a fresh subagent and keep only its output block, so long audit runs stay small

skills/audit/SKILL.md

@@ -97,6 +97,7 @@ node --experimental-strip-types <this skill's folder>/scripts/new-audit.mts --sy
 Run the program's open change issues with [deliver](../deliver/SKILL.md). Within an audit:
 
 - Deliver's draft folder is the program's `issues/`, so its drafts share the `manifest.json`.
+- Pass each issue's subagent its draft path and the audit entries its `audit` list names. Between issues, this context holds the `manifest.json` and each issue's output block.
 - Before building an issue, match it to its draft in `issues/` (`manifest.json` maps each draft key to its issue) and read the audit entries that draft's `audit` list names. They are the steps, and may change while building; the issue's acceptance is what must hold.
 - A finding that is a program of its own stays a decision draft; propose an audit for it at hand off.
 - Keep audit keys and audit dir paths out of branch names, titles and bodies.

skills/deliver/SKILL.md

@@ -20,7 +20,7 @@ Automatic from spec to PR, every gate included. It waits for the user only to re
 
 1. **Start.** A ticket goes to [triage](../triage/SKILL.md): a `real bug` goes to step 3, a `request` to define. An idea goes to [define](../define/SKILL.md). An issue with acceptance criteria, or a program of them, goes to step 3.
 2. **Review.** Ask define for the drafts with the spec: the spec's issue when the project needs one, every issue of a program, and the ticket edit for a ticket. Define's review is the run's one review; create the issues and publish the edit the user approves.
-3. **Run each issue** through steps 4 to 8, in "blocked by" order, without asking between them unless the user asked for pauses. A decision issue, and the work it blocks, waits for a maintainer. An issue too big to review as one PR, such as one sized `outcome`, ships as a stack: its pass through steps 4 to 8 runs once per reviewable slice, each branch on the slice below ([stacks](../create-pr/references/stacks.md)).
+3. **Run each issue** through steps 4 to 8, in "blocked by" order, without asking between them unless the user asked for pauses. In a program, hand each issue's pass to a fresh subagent briefed with the issue, its draft and the project instructions, and keep only its output block here, so context stays small. A decision issue, and the work it blocks, waits for a maintainer. An issue too big to review as one PR, such as one sized `outcome`, ships as a stack: its pass through steps 4 to 8 runs once per reviewable slice, each branch on the slice below ([stacks](../create-pr/references/stacks.md)).
 4. **Branch** as [create-pr](../create-pr/SKILL.md) says. Set in progress as the host skill's board says.
 5. **Build.**
     - A bug: its [Gherkin scenario](../gherkin/SKILL.md#a-bugs-scenario), in the PR body when the ticket has none, then [debug](../debug/SKILL.md).