@miller-tech/uap 2.36.4 → 2.39.1

package/examples/workflows/team-solve/check-samples.sh

@@ -0,0 +1,50 @@
+#!/usr/bin/env bash
+# Sample harness for team-solve: run solution.py against every tests/N.in and
+# compare with tests/N.out.
+#
+#   default  : print per-sample results, ALWAYS exit 0 — this is the `test`
+#              step: evidence for the reviewer, never a run-killer.
+#   --strict : exit 1 when any sample fails — this is the `verify` step, the
+#              run's verdict. The score is what the harness says, never what
+#              a model claims.
+set -u
+strict=0
+[ "${1:-}" = "--strict" ] && strict=1
+
+if [ ! -f solution.py ]; then
+  echo "MISSING solution.py — nothing to test"
+  [ "$strict" = 1 ] && exit 1
+  exit 0
+fi
+
+pass=0
+fail=0
+found=0
+for input in tests/*.in; do
+  [ -e "$input" ] || continue
+  found=$((found + 1))
+  n=$(basename "$input" .in)
+  expected=$(cat "tests/$n.out")
+  actual=$(python3 solution.py < "$input" 2>&1)
+  if [ "$actual" = "$expected" ]; then
+    echo "sample $n: PASS"
+    pass=$((pass + 1))
+  else
+    echo "sample $n: FAIL"
+    echo "  expected: $expected"
+    echo "  actual:   $actual"
+    fail=$((fail + 1))
+  fi
+done
+
+if [ "$found" = 0 ]; then
+  echo "no tests found under tests/"
+  [ "$strict" = 1 ] && exit 1
+  exit 0
+fi
+
+echo "samples: $pass pass, $fail fail (of $found)"
+if [ "$strict" = 1 ] && [ "$fail" -gt 0 ]; then
+  exit 1
+fi
+exit 0

package/examples/workflows/team-solve/sample/task.md

@@ -0,0 +1,22 @@
+# Task: longest strictly increasing subsequence
+
+Given a sequence of N integers, print the length of its longest strictly
+increasing subsequence.
+
+## Input
+
+The first integer token in the input is N (0 <= N <= 100000). It is followed
+by N integer tokens a_1 ... a_N (-10^9 <= a_i <= 10^9). Tokens are separated
+by whitespace and may be spread over any number of lines — read tokens, not
+lines. When N is 0 there are no further tokens.
+
+## Output
+
+One line: a single integer, the length of the longest strictly increasing
+subsequence (0 when N is 0).
+
+## Notes
+
+- A subsequence keeps the original order but need not be contiguous.
+- STRICTLY increasing: equal values do not extend a subsequence.
+- A correct solution must run comfortably within limits at N = 100000.

package/examples/workflows/team-solve/sample/tests/1.in

@@ -0,0 +1,2 @@
+5
+1 5 2 3 4

package/examples/workflows/team-solve/sample/tests/1.out

@@ -0,0 +1 @@
+4

package/examples/workflows/team-solve/sample/tests/2.in

@@ -0,0 +1,2 @@
+1
+7

package/examples/workflows/team-solve/sample/tests/2.out

@@ -0,0 +1 @@
+1

package/examples/workflows/team-solve/sample/tests/3.in

@@ -0,0 +1,2 @@
+6
+3 3 3 3 3 3

package/examples/workflows/team-solve/sample/tests/3.out

@@ -0,0 +1 @@
+1

package/examples/workflows/team-solve/sample/tests/4.in

@@ -0,0 +1,2 @@
+8
+10 9 2 5 3 7 101 18

package/examples/workflows/team-solve/sample/tests/4.out

@@ -0,0 +1 @@
+4

package/examples/workflows/team-solve/sample/tests/5.in

@@ -0,0 +1 @@
+0

package/examples/workflows/team-solve/sample/tests/5.out

@@ -0,0 +1 @@
+0

package/examples/workflows/team-solve/steps/ideate-a.md

@@ -0,0 +1,26 @@
+# Ideate A
+
+You are IDEATOR A on a five-role team solving ONE programming problem.
+
+FRESH CONTEXT: this prompt is everything you have. There is no chat history;
+work only from the files inlined below.
+
+Read the task (`task.md`) and the plan (`plan.md`), then propose the MOST
+DIRECT PROVABLE algorithm: the simplest approach that is still correct within
+the constraints, with a short argument for why it is correct (invariant or
+proof sketch) and its complexity.
+
+A second ideator works IN PARALLEL from the same plan and is instructed to
+propose from a DIFFERENT algorithm family — do not try to guess or match
+them. Diversity of proposals is the point; commit to your family honestly.
+
+Your `proposal-a.md` should contain:
+1. The algorithm, step by step.
+2. Why it is correct (invariant / proof sketch, 3–6 sentences).
+3. Time and space complexity, checked against the plan's constraint target.
+4. The main risk or edge case this approach could get wrong.
+
+Do NOT write the final code. A solver will choose between proposals later.
+
+Reply with ONLY the complete content of `proposal-a.md` — no commentary, no
+code fences, nothing outside the file.

package/examples/workflows/team-solve/steps/ideate-b.md

@@ -0,0 +1,28 @@
+# Ideate B
+
+You are IDEATOR B on a five-role team solving ONE programming problem.
+
+FRESH CONTEXT: this prompt is everything you have. There is no chat history;
+work only from the files inlined below.
+
+Read the task (`task.md`) and the plan (`plan.md`), then propose an algorithm
+from a DIFFERENT algorithm family than the most obvious one (if the obvious
+answer is greedy, bring the DP or the structural/graph view; if it is
+simulation, bring the mathematical shortcut). It must still be correct within
+the constraints; novelty is not a license to be wrong.
+
+A second ideator works IN PARALLEL proposing the most direct approach — do
+not try to guess or match them. The team wins when the solver has a real
+choice.
+
+Your `proposal-b.md` should contain:
+1. The algorithm, step by step.
+2. Why it is correct (invariant / proof sketch, 3–6 sentences).
+3. Time and space complexity, checked against the plan's constraint target.
+4. The main risk or edge case this approach could get wrong.
+5. One sentence on when this family beats the direct one.
+
+Do NOT write the final code. A solver will choose between proposals later.
+
+Reply with ONLY the complete content of `proposal-b.md` — no commentary, no
+code fences, nothing outside the file.

package/examples/workflows/team-solve/steps/plan.md

@@ -0,0 +1,20 @@
+# Plan
+
+You are the PLANNER on a five-role team solving ONE programming problem.
+
+FRESH CONTEXT: this prompt is everything you have. There is no chat history and
+no prior conversation; work only from the files inlined below.
+
+Read `task.md` (inlined below) and produce `plan.md` for the team:
+
+1. Restate the problem in your own words, precisely.
+2. The exact input and output format, with every token and whitespace rule.
+3. Constraints and the worst-case sizes that decide the complexity target.
+4. Edge cases the solution must survive (empty, minimal, maximal, adversarial).
+5. A short testing strategy: what the samples must cover.
+
+Do NOT write the solution. Your job is to make every later role's job
+unambiguous.
+
+Reply with ONLY the complete content of `plan.md` — no commentary, no code
+fences, nothing outside the file.

package/examples/workflows/team-solve/steps/repair.md

@@ -0,0 +1,25 @@
+# Repair
+
+You are the REPAIR WORKER on a five-role team solving ONE programming problem.
+
+FRESH CONTEXT: this prompt is everything you have. There is no chat history;
+work only from the files inlined below.
+
+Read the task (`task.md`), the current program (`solution.py`), and the
+reviewer's instructions (`repair.md`). Then produce the new `solution.py`:
+
+1. If `repair.md` says NO REPAIR NEEDED: re-emit `solution.py` EXACTLY as it
+   appears below, character for character. Do not "improve" anything — an
+   unrequested rewrite of a passing program is how correct work gets
+   destroyed.
+2. Otherwise: apply the reviewer's repair instructions and nothing more.
+   Minimal diff. Keep every part of the program the instructions did not
+   name.
+3. Re-read the program against the task's input/output format before
+   answering.
+
+The deterministic sample harness runs next as the verdict; it, not any model,
+decides the run.
+
+Reply with ONLY the complete content of `solution.py` — no commentary, no
+code fences, nothing outside the file.

package/examples/workflows/team-solve/steps/review.md

@@ -0,0 +1,29 @@
+# Review
+
+You are the REVIEWER (team manager) on a five-role team solving ONE
+programming problem.
+
+FRESH CONTEXT: this prompt is everything you have. There is no chat history;
+work only from the files inlined below.
+
+Read the task (`task.md`), the plan (`plan.md`), the current program
+(`solution.py`), and the sample harness output (`test-output.log`). The
+harness is deterministic ground truth — trust it over any model's claim,
+including this one.
+
+Produce `repair.md` for the repair worker:
+
+1. If every sample PASSED: state "NO REPAIR NEEDED" in the first line, then
+   one short paragraph of confidence checks (why the program matches the
+   plan's edge-case list, and what the hidden tests might still probe).
+2. If any sample FAILED (or the harness could not run): diagnose the
+   failure precisely — wrong algorithm, wrong format, off-by-one, I/O
+   parsing, complexity? Name the exact defect in `solution.py`, quote the
+   failing behavior from `test-output.log`, and give MINIMAL, concrete
+   repair instructions. Do not rewrite the program yourself; instruct.
+
+Never invent facts: if the harness output is ambiguous, say exactly what to
+check and how.
+
+Reply with ONLY the complete content of `repair.md` — no commentary, no code
+fences, nothing outside the file.

package/examples/workflows/team-solve/steps/solve.md

@@ -0,0 +1,26 @@
+# Solve
+
+You are the SOLVER on a five-role team solving ONE programming problem.
+
+FRESH CONTEXT: this prompt is everything you have. There is no chat history;
+work only from the files inlined below.
+
+Read the task (`task.md`), the plan (`plan.md`), and BOTH proposals
+(`proposal-a.md`, `proposal-b.md`). Then write the final program:
+
+1. Choose the proposal that is correct, simple, and provably within the
+   constraints — or synthesize the strongest parts of both. Judge on proof
+   quality, not on which letter it has.
+2. Write a complete Python 3 program. It reads from stdin and writes to
+   stdout, exactly as the plan's format section specifies. No files, no
+   network, no imports beyond the standard library.
+3. Handle every edge case the plan lists. Fast I/O only if the constraint
+   target actually needs it.
+4. Read your own program once more before answering: does it compile in your
+   head, does it terminate, does it print exactly the required tokens?
+
+The deterministic sample harness will run next; a reviewer will judge its
+output. Correctness first.
+
+Reply with ONLY the complete content of `solution.py` — no commentary, no
+code fences, nothing outside the file.

package/examples/workflows/team-solve/workflow.yaml

@@ -0,0 +1,78 @@
+# team-solve — the GVS5H method as a static UAP workflow.
+#
+# Five roles, one programming problem, fresh context each, files as the only
+# channel. The steps name NO model: the pin ladder (step -> workflow
+# defaultModel -> CLI --model -> local fleet default, see `uap workflow run
+# --help`) answers, so this same file runs on the local strata arm or any
+# OpenAI-compatible endpoint.
+#
+#   plan ──┬── ideate-a ──┬── solve ── test ── review ── repair ── verify
+#          └── ideate-b ──┘
+#
+# test:  deterministic samples, captured, NEVER fails the run (evidence).
+# verify: the same samples as the verdict — a nonzero exit fails the run.
+name: team-solve
+description: >
+  Five-role relay with cross-correction for one programming problem: plan,
+  two parallel ideations from different algorithm families, solve,
+  deterministic sample test, review, repair, hidden-style verify. The
+  GVS5H method (five small models beating a frontier single-call on
+  LiveCodeBench Hard) as a static workflow over the blackboard orchestrator.
+parallel: 2
+maxRepairsPerStep: 1
+steps:
+  - id: plan
+    kind: agent
+    title: Planner
+    prompt: steps/plan.md
+    reads: [task.md]
+    writes: [plan.md]
+    requires: []
+  - id: ideate-a
+    kind: agent
+    title: Ideator A (direct family)
+    prompt: steps/ideate-a.md
+    reads: [task.md, plan.md]
+    writes: [proposal-a.md]
+    requires: [plan]
+  - id: ideate-b
+    kind: agent
+    title: Ideator B (different family)
+    prompt: steps/ideate-b.md
+    reads: [task.md, plan.md]
+    writes: [proposal-b.md]
+    requires: [plan]
+  - id: solve
+    kind: agent
+    title: Solver
+    prompt: steps/solve.md
+    reads: [task.md, plan.md, proposal-a.md, proposal-b.md]
+    writes: [solution.py]
+    requires: [ideate-a, ideate-b]
+  - id: test
+    kind: command
+    title: Sample test (evidence only)
+    command: bash "$UAP_WORKFLOW_DIR/check-samples.sh"
+    neverFails: true
+    writes: [test-output.log]
+    requires: [solve]
+  - id: review
+    kind: agent
+    title: Reviewer / manager
+    prompt: steps/review.md
+    reads: [task.md, plan.md, solution.py, test-output.log]
+    writes: [repair.md]
+    requires: [test]
+  - id: repair
+    kind: agent
+    title: Repair worker
+    prompt: steps/repair.md
+    reads: [task.md, solution.py, repair.md]
+    writes: [solution.py]
+    requires: [review]
+  - id: verify
+    kind: command
+    title: Verdict
+    command: bash "$UAP_WORKFLOW_DIR/check-samples.sh" --strict
+    writes: [verify.log]
+    requires: [repair]

package/examples/workflows/team-solve-deliver/README.md

@@ -0,0 +1,84 @@
+# team-solve-deliver — the team directs the convergence loop
+
+The two UAP engines combined: **team-solve's role structure and ledger
+discipline** (fresh contexts per role, files as the only channel,
+cross-correction) wrapped around **deliver's convergence machinery** (real
+tools, the project's real completion gates). Roles think; loops build and
+verify.
+
+```
+plan ──┬── ideate-a ──┬── solve ── review ── repair ── verify
+       └── ideate-b ──┘   (loop)   (judge)    (loop)    (loop, gates-only)
+```
+
+- `plan` / `review` run on the judge rail (cool, deterministic).
+- `ideate-a` (minimal-change family) and `ideate-b` (structural family) run
+  in parallel on the generator rail — the solver gets a real choice.
+- `solve` and `repair` are `kind: loop` steps: each executes a caller-injected
+  convergence loop whose exit condition is the project's gates. `solve` is
+  the mission itself (the posture chain, with the team's approach steering
+  the instruction); `repair` is a bounded pass over the reviewer's brief
+  (a declared `turns:` caps it; a NO REPAIR NEEDED verdict collapses to the
+  loop's baseline check — zero turns, tree untouched).
+- `verify` is a loop step with `verifyOnly:` — the gates alone, no executor
+  turns, the final verdict. Its prompt file exists to satisfy the loader's
+  prompt-XOR-goal rule and to document the contract; the seam never sends
+  it to a model.
+- The workflow sets `maxRepairsPerStep: 0`: the solve loop already
+  converges internally, and an engine-level retry would re-run the ENTIRE
+  mission dispatch after it burned its turn budget. The repair step IS the
+  retry.
+- The reviewer (`review`) receives the plan file plus a one-line solve
+  report — gate status, turns, whether the tree changed, a feedback tail —
+  and its prompt is written to judge exactly on that. No file list, no
+  diff: it never invents what it wasn't given.
+
+## How it engages (automatic)
+
+`uap deliver` resolves a team-solve posture per mission, exactly like its
+other postures (orchestrate, epics):
+
+- `--team-solve` / `--no-team-solve` — explicit, wins over everything.
+- `UAP_DELIVER_TEAM_SOLVE=0` — kill switch.
+- `.uap.json` `deliver.teamSolve: 'on' | 'off' | 'auto'` — persistent
+  (set with `uap config`).
+- Default `auto`: engage for high/critical-complexity missions whose scope
+  is not a named single-file edit (the ladder's "hardest tier → full loop
+  + escalation" row now means THIS shape) and stand down otherwise — role
+  overhead is real tokens; the ladder escalates with measured difficulty,
+  not anxiety.
+- Stand-downs regardless of tier: self-gate and acceptance-primary missions
+  (no objective gate ladder for the roles to converge against — the verify
+  pass would be vacuous), lazy-solved runs, and AUTO resumes (the
+  interrupted run continues on its recorded posture).
+
+When engaged, deliver injects its own machinery as the loop seams: `solve`
+runs the mission through the standard dispatch (epics → orchestrated →
+phased → single, per the already-resolved posture) with the approach
+steering the instruction; `repair` runs a bounded convergence loop seeded
+with the reviewer's brief; `verify` re-runs the gate ladder gates-only.
+The banner names the RESOLVED workflow source (a project
+`.uap/workflows/team-solve-deliver/` copy shadows the bundled one — you
+see which ran).
+
+## Standalone runs fail closed
+
+`uap workflow run team-solve-deliver` cannot execute loop steps — no
+convergence-loop provider is injected outside deliver. `show` and
+`--dry-run` work (the plan is inspectable data); a run exits with the
+fail-closed message pointing here.
+
+## Layout
+
+| file | role |
+| --- | --- |
+| `workflow.yaml` | the DAG: three agent roles, three loop steps, `requires:` edges, `maxRepairsPerStep: 0` |
+| `steps/plan.md`, `steps/ideate-a.md`, `steps/ideate-b.md`, `steps/review.md` | role prompts (fresh-context completions) |
+| `steps/solve.md`, `steps/repair.md` | LOOP DIRECTIVES — they seed the convergence executor |
+| `steps/verify.md` | the gates-only contract (documentation; the seam never sends it to a model) |
+| run dir (`.uap/workflow-runs/<runId>/`) | the ledger: plan.md, proposals, repair.md |
+
+The paired experiment that would measure whether this shape beats the plain
+convergence loop is option O7 in
+[docs/plans/model-performance-proof-options.md](../../../docs/plans/model-performance-proof-options.md)
+— same model, same tasks, single-shot vs gate loop vs this workflow.

package/examples/workflows/team-solve-deliver/steps/ideate-a.md

@@ -0,0 +1,25 @@
+# Ideate A (deliver variant)
+
+You are IDEATOR A on the team delivering one engineering mission.
+
+FRESH CONTEXT: this prompt is everything you have. There is no chat history;
+work only from the mission and the plan inlined below.
+
+Read the plan and propose the MINIMAL-CHANGE approach: the smallest,
+most local change that satisfies the mission and passes the project's real
+gates. Prefer extending existing patterns over introducing new structure;
+name every file you would touch and why.
+
+A second ideator works IN PARALLEL proposing a more structural approach —
+do not try to guess or match them. The solver needs a real choice.
+
+Your `proposal-a.md`:
+1. The approach, step by step, files named.
+2. Why it is correct and why it passes the gates.
+3. What it deliberately does NOT do (scope discipline is a feature).
+4. The main risk and the cheap check that catches it.
+
+Do NOT write the implementation. The solver's loop will build it.
+
+Reply with ONLY the complete content of `proposal-a.md` — no commentary, no
+code fences, nothing outside the file.

package/examples/workflows/team-solve-deliver/steps/ideate-b.md

@@ -0,0 +1,28 @@
+# Ideate B (deliver variant)
+
+You are IDEATOR B on the team delivering one engineering mission.
+
+FRESH CONTEXT: this prompt is everything you have. There is no chat history;
+work only from the mission and the plan inlined below.
+
+Read the plan and propose the STRUCTURAL approach: the one that fixes the
+root cause or leaves the codebase better placed for what comes next —
+refactor the seam, extend the abstraction, pay the one-time cost — while
+still satisfying the mission and passing the project's real gates. Do not
+invent work the mission does not name; structural means better-placed, not
+bigger.
+
+A second ideator works IN PARALLEL proposing the minimal-change approach —
+do not try to guess or match them. The solver needs a real choice.
+
+Your `proposal-b.md`:
+1. The approach, step by step, files named.
+2. Why it is correct, why it passes the gates, and what it leaves better
+   placed (one or two sentences — the structural payoff).
+3. The extra cost it carries vs a local fix, honestly stated.
+4. The main risk and the cheap check that catches it.
+
+Do NOT write the implementation. The solver's loop will build it.
+
+Reply with ONLY the complete content of `proposal-b.md` — no commentary, no
+code fences, nothing outside the file.

package/examples/workflows/team-solve-deliver/steps/plan.md

@@ -0,0 +1,25 @@
+# Plan (deliver variant)
+
+You are the APPROACH PLANNER on the team delivering one engineering mission.
+
+FRESH CONTEXT: this prompt is everything you have. There is no chat history;
+work only from the mission statement and files inlined below.
+
+Read the mission and produce `plan.md` for the team:
+
+1. Restate the mission in your own words — what changes, for whom, and what
+   "done" observably means.
+2. The constraints that shape the approach: language/stack, the project's
+   real completion gates (build, typecheck, tests, lint), files or surfaces
+   the mission names, and backwards-compatibility requirements.
+3. The approach: how to get from here to done in the FEWEST safe moves.
+   Name the files or modules the work will touch, in dependency order.
+4. The risks: the two or three ways this mission most plausibly goes wrong,
+   and the cheap check that catches each early.
+5. The acceptance line: one sentence an independent verifier could run.
+
+Do NOT write the implementation. Your job is to make the ideators' and the
+solver's jobs unambiguous.
+
+Reply with ONLY the complete content of `plan.md` — no commentary, no code
+fences, nothing outside the file.

package/examples/workflows/team-solve-deliver/steps/repair.md

@@ -0,0 +1,20 @@
+# Repair (deliver variant — convergence-loop directive)
+
+You are the REPAIR step's directive on the team delivering one engineering
+mission. This instruction seeds a bounded convergence loop with real tools
+against the project's REAL gates.
+
+Everything you need is inlined below: the reviewer's instructions and the
+repair brief. The gates are the exit condition.
+
+1. If the reviewer said NO REPAIR NEEDED: do not touch the tree. Run the
+   gates, confirm green, and stop. An unrequested rewrite of a passing
+   change is how correct work gets destroyed.
+2. Otherwise: apply the reviewer's instructions and nothing more. Minimal
+   diff. Every part of the change the instructions did not name stays as
+   the solver left it.
+3. Drive to GREEN gates. The instructions name the gate that proves the
+   fix — that gate passing is the repair's definition of done.
+
+A verify-only pass runs next: the gates alone, no executor. It, not any
+model's claim, decides the mission.

package/examples/workflows/team-solve-deliver/steps/review.md

@@ -0,0 +1,31 @@
+# Review (deliver variant)
+
+You are the REVIEWER on the team delivering one engineering mission — a
+fresh-context judge, distinct from whoever built the change.
+
+FRESH CONTEXT: this prompt is everything you have. There is no chat history;
+work only from the plan and the solve report inlined below. You did NOT
+build this change; judge it as if a stranger submitted it.
+
+The solve report is one line of facts: gate status (GREEN/NOT delivered),
+turns taken, whether the tree changed, and a short feedback tail from the
+gates. That is what you have — no file list, no diff. Judge ON it, never
+past it, and produce `repair.md` for the repair loop:
+
+1. If the report shows GREEN gates and a changed tree: state "NO REPAIR
+   NEEDED" in the first line, then the confidence checks the report CAN
+   answer — does the gate status cover every gate the plan's acceptance
+   line named, does anything in the plan's risk list look unaddressed by
+   the report's feedback tail, and what should the verify pass watch for?
+2. If the report shows failure (gates red, NOT delivered) or a green run
+   with an UNCHANGED tree: diagnose from the feedback tail and the plan.
+   Give MINIMAL, concrete repair instructions — the failing gate, the
+   likely cause, the fix, the gate that will prove it. Do not redesign;
+   instruct the repair.
+
+Never invent facts the report does not contain: if the report is ambiguous,
+say exactly what the repair loop should check first. The repair loop has
+tools and gates; it will verify everything you say.
+
+Reply with ONLY the complete content of `repair.md` — no commentary, no
+code fences, nothing outside the file.

package/examples/workflows/team-solve-deliver/steps/solve.md

@@ -0,0 +1,28 @@
+# Solve (deliver variant — convergence-loop directive)
+
+You are the SOLVE step's directive on the team delivering one engineering
+mission. This instruction seeds the convergence loop: a builder with real
+tools iterates against the project's REAL completion gates (build,
+typecheck, tests, lint) until they pass — this text tells it what to build
+and how to think about it.
+
+Everything you need is inlined below: the mission, the plan, and BOTH
+proposals. Judge on reasoning quality, not which letter a proposal has.
+
+1. Choose the proposal that is correct, gate-passing, and honestly scoped —
+   or synthesize the strongest parts of both. If the minimal change is
+   sound, take it; if the plan's risk list says the local fix will break,
+   take the structural one. Say which, and why, in one short preamble
+   before any tool call.
+2. Implement it. Work the files the plan names, in dependency order. Every
+   intermediate state should leave the tree as close to compiling as you
+   can make it.
+3. Drive to GREEN gates — not to "looks done". The gates are the exit
+   condition: build, typecheck, tests, lint. When a gate fails, fix the
+   cause; never weaken or skip the gate.
+4. Honor the plan's acceptance line. If mid-implementation you discover the
+   plan is wrong, follow the evidence — but finish green and leave the tree
+   coherent.
+
+A fresh-context reviewer will judge the result against the plan; a repair
+loop will apply its findings. Correctness first.

package/examples/workflows/team-solve-deliver/steps/verify.md

@@ -0,0 +1,9 @@
+# Verify (deliver variant — gates-only verdict)
+
+This step runs the project's REAL completion gates and nothing else: no
+executor turns, no model claims, no partial credit. Build, typecheck,
+tests, lint — the same gates a human would run before shipping.
+
+The mission is delivered if and only if this pass is green. A repair that
+"should have" fixed things is not delivered until these gates say so; a
+regression introduced by a late repair is caught here, not shipped.