feat: refine every lane's change in a second session, one tier up

.agents/skills/delivery-implement/SKILL.md

@@ -144,7 +144,8 @@ Report, in this shape, so the next step needs no rebuilt context:
 - the remaining open items or blockers
 
 Write it to the `--report` file when one was given, then stop, leaving the change
-uncommitted.
+uncommitted. In a lane, `delivery-refine` reviews and simplifies the change next,
+from this report: the validation commands it names are the ones it re-runs.
 
 ## When to stop instead
 

.agents/skills/delivery-orchestrator/SKILL.md

@@ -88,7 +88,7 @@ fresh context, so a long session never has to stay alive to carry state.
 | Requirements | `delivery/prd.md` | `delivery-spec` (stage A) | **Human approves** |
 | Design spine | decision records in `docs/adr/`, `docs/decisions/` or `delivery/decisions/`, and `delivery/contracts/<interface>.md` | `delivery-spec` (stage B) | **Human approves** |
 | Decomposition | `delivery/decomposition.md`, plus `delivery/tasks/<id>.md` per task | `delivery-decompose` | **Human approves** |
-| Lanes | a draft pull request per task | `delivery-status`, then `delivery-implement` | none, runs unattended |
+| Lanes | a draft pull request per task | `delivery-status`, then `delivery-implement`, then `delivery-refine` | none, runs unattended |
 | Review | findings on the pull request | the review skill each `REVIEW` row names, else the harness review | **Human approves the merge** |
 | Milestone review, when the plan has milestones | `delivery/milestones/<slug>.md` | `delivery-decompose` | **Human approves** |
 
@@ -121,14 +121,16 @@ Whether a full-route set runs in parallel is decomposition's finding, not a
 choice made here: tasks marked `parallel: false` run alone, and a set that
 serializes marks them all. The phases and gates are the same either way. When
 one person holds a serial set, skip the launcher and invoke `delivery-implement`
-per task in dependency order; the claim only earns its keep when several people
+then `delivery-refine` per task in dependency order; the claim only earns its keep when several people
 pick from the same tasks.
 
 ### Direct implement
 
 Write one task file, `delivery/tasks/<id>.md`, from
 `<delivery-decompose>/assets/task.template.md`, then invoke `delivery-implement`
-on it in the ordinary checkout. Nothing else in this skill applies.
+on it in the ordinary checkout, and `delivery-refine` on the same task file
+after it, on a stronger model when the harness lets you choose one. Nothing else
+in this skill applies.
 
 Skip the claim, the worktree, the launcher, `delivery-status` and all three
 approval gates. Those coordinate concurrent lanes and guard artifacts this path

.agents/skills/delivery-orchestrator/references/conventions.md

@@ -288,13 +288,14 @@ one section per tier, read with `git config`:
     harness = claude
     model = sonnet
     advisor = opus
+    reviewer = opus
 
 [chore]
     harness = copilot
     model = gpt-6-luna
 ```
 
-`harness`, `model` and `advisor` are all optional: a missing `harness` means
+`harness`, `model`, `advisor` and `reviewer` are all optional: a missing `harness` means
 any, and a missing `model` means the harness's own default. `advisor` names a
 stronger model the lane may consult at its own decision points; only Claude
 Code has one, and it must be at least as capable as `model`. Without it, a
@@ -313,6 +314,13 @@ Two files are read, and the first to name a tier decides all of it:
 A lane runs on the first of: `--harness`, the harness its tier maps to,
 `$DELIVERY_HARNESS`, then the first harness found installed.
 
+A lane's second session, `delivery-refine`, reviews on a stronger model than
+the one that wrote the change. It runs on the tier's `reviewer`, a model for the
+tier's own harness, when the tier names one. Otherwise it runs as the tier
+above would: `chore` as `build`, `build` as `plan`, `plan` as `plan`, on that
+tier's harness when it is installed and with its model and advisor.
+`--harness` moves the review with the rest of the launch.
+
 ## Review lenses
 
 A lens is a concern that deserves its own review pass, such as security or
@@ -342,7 +350,9 @@ the file, only the general review is suggested, and it is the harness's own.
 
 ## Commits and pull requests
 
-A lane does not commit. When its session exits cleanly,
+A lane does not commit. Its two sessions, `delivery-implement` then
+`delivery-refine`, leave the change in the worktree. When the first exits
+cleanly,
 `<delivery-orchestrator>/scripts/publish-lane.sh` commits the worktree as
 `<type>(<epic>): <title>`, pushes it, and opens the draft pull request. The body
 is the lane's handoff report, written in the repository's pull request template

.agents/skills/delivery-orchestrator/references/lanes.md

@@ -14,8 +14,13 @@ them.
    `<repository>` is the directory name of the checkout the launcher ran from,
    or `<dir>/<id>` when `DELIVERY_WORKTREE_ROOT=<dir>` is set in the
    environment or `--worktree-root <dir>` is given.
-4. A **session** runs in that worktree, unattended, to a validated working tree.
-5. When the session exits cleanly, the launcher runs
+4. A **session** runs `delivery-implement` in that worktree, unattended, to a
+   validated working tree. When it left a change, a second session runs
+   `delivery-refine` on it, one tier up: it reviews the change, fixes what it
+   finds, simplifies it and re-validates. A refinement that fails takes nothing
+   away: the change goes on as the first session left it, and the report says
+   the review did not run. `--no-refine` skips the second session.
+5. When the first session exits cleanly, the launcher runs
    `sh <skill-root>/scripts/publish-lane.sh`, which commits the change, pushes
    it, and opens a **draft pull request** whose body is the lane's handoff
    report, in the repository's pull request template when it has one. A session
@@ -87,7 +92,8 @@ cannot be reviewed against either one's acceptance criteria.
 
 The task's `tier` says how much capability the lane needs, and a `tiers.conf`
 maps it to a model when the developer has one; otherwise the harness picks its
-default, as the [delivery conventions](conventions.md#tiers) define. `--harness`
+default, as the [delivery conventions](conventions.md#tiers) define. The
+refinement session runs one tier up, or on the tier's own `reviewer`. `--harness`
 overrides a whole batch, for example to move a launch to a harness whose
 allowance still has room.
 

.agents/skills/delivery-orchestrator/references/review.md

@@ -3,8 +3,12 @@
 Review is the final gate. Everything before it ran unattended, so this is where
 a human decides whether the work lands.
 
-The kit ships no reviewer, so these rules apply to whichever one runs: the
-harness's own review capability, or a review skill installed alongside the kit.
+The kit ships no reviewer for this gate, so these rules apply to whichever one
+runs: the harness's own review capability, or a review skill installed alongside
+the kit. A lane's change has already been through `delivery-refine`, which
+reviewed it against its task on a stronger model and fixed what it found; its
+Refinement section in the pull request body says what it fixed, deferred and
+simplified. The human review is still the gate.
 
 ## Choosing the reviewer
 

.agents/skills/delivery-orchestrator/scripts/harness.sh

@@ -22,15 +22,15 @@ is_harness() {
   case " $HARNESSES custom " in *" $1 "*) return 0 ;; *) return 1 ;; esac
 }
 
-# The prompt that starts a lane. Claude Code, and Copilot CLI inside the
-# repository that holds the skills, resolve "/<skill> <args>". Every other case
-# is told to read the skill file, which needs no skill discovery from the
-# harness: the lane may be in another repository, and not every harness reads
-# every skills directory.
+# The prompt that starts one of a lane's sessions. Claude Code, and Copilot CLI
+# inside the repository that holds the skills, resolve "/<skill> <args>", the
+# skill being named by its directory. Every other case is told to read the skill
+# file, which needs no skill discovery from the harness: the lane may be in
+# another repository, and not every harness reads every skills directory.
 #   harness_prompt <harness> <cross-repo: 0|1> <skill file> <arguments>
 harness_prompt() {
   case "$1:$2" in
-    claude:* | copilot:0) printf '/delivery-implement %s' "$4" ;;
+    claude:* | copilot:0) printf '/%s %s' "$(basename "$(dirname "$3")")" "$4" ;;
     *) printf 'Read %s and follow it as a skill, with the arguments: %s' "$3" "$4" ;;
   esac
 }