ultra-builder-pro-cli 0.26.2 → 3.0.2

package/skills/ultra-delegate/SKILL.md

@@ -8,6 +8,12 @@ description: Delegate one bounded workflow segment to another installed CLI in a
 Delegation is an execution mode, not another workflow stage. The primary host keeps
 semantic synthesis and remains the only writer of `.ultra/tasks.json`.
 
+Delegation is also not a primary transfer. A delegated worker never becomes the
+work package's canonical writer, whatever its result says; moving that role to
+another Agent requires the owner-directed OFFER → ACK → RESULT protocol in
+`../ultra-change/references/primary-transfer.md`, which stays mutually exclusive
+with this bounded-worker path.
+
 ## Before you start
 
 1. Resolve exactly one active `change_id`, then select one scope and name it in
@@ -54,7 +60,7 @@ worktrees collide in the very files every later session reads to resume. Worker
 and state changes travel back in `result.json` and are applied by the primary host.
 `external_effects` must be empty in this portable launcher: commit, push, publish,
 deployment and other effects stay with the primary host. There is no `readable_roots`
-claim because the five host sandboxes do not share one mechanically enforceable read
+claim because the six host sandboxes do not share one mechanically enforceable read
 policy.
 
 Create `.ultra/.runtime/worktrees/<id>` as a real Git worktree and run:
@@ -63,6 +69,20 @@ Create `.ultra/.runtime/worktrees/<id>` as a real Git worktree and run:
 ubp delegate run --to <host> --instruction <file> --permission <file> --worktree <dir> --timeout <seconds>
 ```
 
+`<host>` is `claude`, `codex`, `opencode`, `kimi`, `grok`, or `zcode`. Kimi accepts an
+optional `--model <id>` when its account has no default headless model. A ZCode primary
+host uses this same command to delegate to any other installed CLI; a different primary
+host can select `--to zcode` through the ZCode headless profile.
+
+The ZCode headless transport is `experimental`: it is an App-internal or PATH CLI with
+no public stability contract, and it is **not** the documented ZCode Desktop
+interactive surface. `delegate run --to zcode` refuses to launch until the invocation
+explicitly carries `--ack-experimental`; every launch then prints a stderr warning and
+records `transport_maturity: "experimental"`, the exact `transport_surface` wording,
+and `experimental_ack: true` in the receipt, the worker spec, and the terminal result
+(including failure and timeout recovery results), so no receipt can imply a documented
+Desktop session. Promotion requires official documentation plus a full recovery drill.
+
 The command returns a receipt. Immediately run `scripts/delegate_wait.py`; read no
 intermediate output. Use `ubp delegate status --delegation <dir>` for a read-only state
 and `ubp delegate cancel --delegation <dir>` to request termination. Never delete a lock
@@ -71,7 +91,9 @@ to manufacture completion.
 The worker returns one schema-constrained JSON final response. The launcher extracts it
 from the host's native structured output, validates digests, process exit, exact schema,
 actual base-HEAD diff and writable roots, then atomically publishes `result.json`. The
-model never writes its own receipt. If owner input is needed, the worker terminates
+launcher embeds the exact digest-bound instruction and permission packet in the prompt,
+so a host that denies external-directory reads never needs authority outside the
+worktree. The model never writes its own receipt. If owner input is needed, the worker terminates
 `blocked` with questions and evidence; start a new id and fresh packet after obtaining
 the answer.
 

package/skills/ultra-delegate/references/delegation-contract.md

@@ -23,6 +23,13 @@ reads to resume. Enforced twice: the launcher rejects a `.ultra` root before the
 delegation starts, and the worker fails an actual diff that touches it with
 `unauthorized_write`.
 
+This boundary also separates delegation from a primary transfer: a delegation result
+is a bounded observation returned to the primary host, and no delegation receipt can
+serve as, upgrade into, or substitute for the OFFER/ACK/RESULT receipts of a primary
+transfer (`../ultra-change/references/primary-transfer.md`). Widening a worker to write
+`.ultra` in order to simulate a transfer is a contract violation, not an integration
+shortcut.
+
 ## Model final response
 
 ```json
@@ -43,12 +50,25 @@ delegation starts, and the worker fails an actual diff that touches it with
 Fields are exact. Status is `finished`, `blocked`, or `failed`; `blocked` requires a
 question. Check status is `passed`, `failed`, or `not_run`. Changed files are unique,
 normalized repository-relative paths and must exactly equal the launcher's Git diff.
+`output_ref` is requested for every check and required in the native schema projection
+used by hosts that accept one. The launcher remains compatible with hosts that return
+the otherwise exact check without that optional evidence pointer.
 
-The launcher extracts this object from native structured output and adds
+The launcher embeds the exact instruction and permission sources with their digests in
+the host prompt, extracts this object from native structured output, and adds
 `delegation_id`, `host`, instruction, permission, and output-schema digests,
 `read_only`, `base_head`, `final_head`, timestamps, `exit_code`, and signal. Launcher
 failures also add `failure_type`. A nonzero process cannot publish `finished`.
 
+Every receipt, worker spec, and terminal result also records the transport truth:
+`transport_maturity` (from the shared host profile) and the exact `transport_surface`
+wording. The ZCode headless transport is `experimental` with no public stability
+contract and is not the documented ZCode Desktop interactive surface; launching it
+requires the explicit `--ack-experimental` flag, prints a stderr warning, and stamps
+`experimental_ack: true` on the receipt, so no delegation record can misrepresent an
+internal CLI run as a documented Desktop session — including failure, cancellation,
+and timeout recovery results.
+
 ## Recovery
 
 - `status` distinguishes running, cancelling, stalled, and terminal artifacts.

package/skills/ultra-deliver/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ultra-deliver
-description: Reconcile one Change whose matching tasks are complete, run aggregate review and refactoring, refresh release documentation, and archive the local workflow record. Use when the owner wants a delivery handoff or separately authorized release effects for the active Change.
+description: Reconcile one Change whose matching tasks are complete, run aggregate review and refactoring, and report the delivery handoff. Use when the owner wants delivery reconciliation and reporting, or — by current explicit owner invocation only — the separately gated finalization that writes delivery.md, fixes version and package posture, and archives the local workflow record.
 ---
 
 # Turn current evidence into a recoverable delivery handoff
@@ -9,18 +9,61 @@ Delivery closes the local Change; readiness grants no commit, push, tag, publish
 
 ## Before you start
 
-1. Resolve exactly one active `change_id`. Read `.ultra/tasks.json`; every matching task
-   must be complete. Read each `context_file`'s Completion and closing Resume Note.
-2. Read `CONTEXT.md`, relevant `.ultra/decisions/`, active Change intent and evidence.
-3. Read `.ultra/test-report.json`, then run the Test Skill's `worktree_digest.cjs` with
+1. If model-selected, verify the live execution grant in `../ultra-change/references/execution-grant.md` — a current session-local activation or a stably verified durable work-package grant; without either, stop. A model-selected Deliver run under that grant may reconcile, review, and report, and then MUST stop before finalization: its inputs, writes, and effects end at the report. Only a current explicit owner invocation of `ultra-deliver` may finalize — writing `delivery.md`, deciding the version decision and package posture, and archiving the stable Change id with `git mv` are owner-invocation-only in every grant mode, and a grant never covers them.
+2. Read `../ultra-change/references/change-contract.md` and apply its **Active Change
+   authority resolution** before reading any active `intent.md` or resolving a current
+   `change_id`. This workflow requires its one valid active authority; any zero result
+   or typed diagnostic stops before finalization input is read until the stated repair
+   or retry succeeds. Read `.ultra/tasks.json`; every matching task must be `completed`
+   in that sole task-status authority. Read each `context_file`'s Completion, Task
+   Review, and closing Resume Note. For every current Change task,
+   require current `ultra-task-evidence-v2` and task-review provenance under
+   `../ultra-plan/references/task-evidence-v2.md`, already consumed by the current Test
+   report. A legacy context Status or Complexity header and v1 evidence are migration
+   diagnostics only and cannot support current delivery.
+3. Read `CONTEXT.md`, relevant `.ultra/decisions/`, active Change intent and evidence.
+   Validate `.ultra/north-star.md`; resolve every recorded `FP-*`, `NS-*`, and `HC-*`
+   for the delivered Change, tasks, findings, and dispositions against that accepted
+   authority. Compare the active Change's recorded **North Star revision** and
+   **North Star digest** with the accepted file's revision and current Git blob digest. Any
+   missing ID or mismatch stops finalization and recommends explicit owner invocation of
+   `ultra-change` for reconciliation; delivery never silently rewrites the trace.
+4. Read `.ultra/test-report.json`, then run the Test Skill's `worktree_digest.cjs` with
    project root and `--change-id`. Require report `task_ids` for the current Change plus
-   matching `change_id`, `git_commit`, worktree digest, and intent digest; otherwise stop.
+   matching `change_id`, `git_commit`, worktree digest, intent digest, and review
+   `admission_digest`, `subject_digest`, and `summary_digest`; otherwise stop. Recheck
+   each projected task's declared review branch as recorded: strict-v4 items keep their
+   strict receipt and transport bindings, while `external-manual` items reverify their
+   receipt bytes and digest through the task-evidence sensor's
+   `--verify-external-receipt` mode and take the sensor's `--projection` output
+   verbatim — a strict SUMMARY never substitutes for an external receipt and neither
+   branch is rewritten into the other.
+   The product-worktree digest has one fixed boundary: it excludes `.ultra/evidence/**`,
+   whose command and external-observation entries bind raw bytes as
+   `raw_evidence_sha256` before stable exact record bytes are bound as `evidence_digest`
+   through the report's ordered `task_evidence` projection. For each projected record,
+   take every `raw_evidence_ref` to bounded stable repository-contained bytes from an
+   ordinary regular non-symlink file opened nonblocking and no-follow, with an 8 MiB
+   ceiling and path/descriptor identity checks around the read. Recompute
+   `raw_evidence_sha256` and require an exact match, then recompute the stable exact
+   `evidence.json` bytes as `evidence_digest` before comparing the projection. Recheck
+   the exact review receipts separately; never treat the product exclusion as permission
+   to ignore evidence drift or add another exclusion.
+   An intent digest changed by North Star reconciliation or any other intent edit always
+   requires a fresh `ultra-test` before Deliver can finalize, even if product bytes did
+   not change.
+5. Preserve every typed acceptance authority. The owner alone supplies the semantic
+   result for `owner-judgment`; Deliver may verify its cited source and freshness but no
+   model, command, digest, schema, or validator may replace it.
 
 ## Definition of done
 
 - Outcome, specs, tests, aggregate review, and every document match the actual diff.
 - Every changed export has a non-test consumer or a recorded owner disposition.
 - Every omitted stage is explicitly recorded with its evidence-based rationale.
+- Delivery explains whether evidence realizes the traced first principles and outcome,
+  and preserves contradictions or stale trace as findings instead of mirroring or
+  silently revising North Star prose.
 - Build and release checks have exact commands and real results.
 - The Change is archived with `git mv`, and rollback remains a normal Git operation.
 
@@ -28,6 +71,12 @@ Delivery closes the local Change; readiness grants no commit, push, tag, publish
 
 Follow `../ultra-review/SKILL.md` across the aggregate Change; refactor only observed
 duplication, coupling, or boundary defects. Rerun affected checks and refresh the report.
+After the aggregate review and the current Test report are consumed, Deliver does not
+refactor product source: it reconciles delivery artifacts and documentation only. A
+post-approval implementation issue routes as at most one new owner-approved Dev task
+for a P0/P1, or as recorded backlog and residual risk for P2/P3; an unbounded
+Test ↔ Deliver bounce is not a valid recovery path, and any re-entry through Test
+requires an explicit owner disposition.
 
 ## Reconcile the handoff
 
@@ -51,11 +100,33 @@ Delivery has two observable passes, not a hidden state machine:
    specifications, maintained documentation, or `intent.md`, stop after writing the
    reconciled files. The existing report is stale; recommend `ultra-test` and make no
    delivery or release claim.
-2. After an unchanged pass or fresh Test, recheck Change/task/HEAD/product/intent
-   identities. Apply the gate, run build and non-publishing package inspection, determine
-   version impact, and use `references/baseline-reconciliation.md` for canonical
-   `delivery.md`. Archive the Change. Excluded delivery metadata and the directory move
-   cannot self-invalidate the product digest; intent stays independently bound.
+2. After an unchanged pass or fresh Test, resolve the report's canonical
+   `review.summary_ref` as `<validated-summary-path>` and run the current strict transport
+   consumer against the current report:
+
+   `node <ultra-test-skill-dir>/scripts/validate_review_transport.cjs --summary <validated-summary-path> --report .ultra/test-report.json`
+
+   Require exit 0 and a JSON `"valid": true` field. This one existing consumer verifies
+   the exact
+   retained `ADMISSION.json` and `SUMMARY.json`, then binds the report's
+   `admission_digest`, `subject_digest`, and `summary_digest` to those bytes. A missing or
+   invalid receipt, summary, or binding makes the current Test claim `INCOMPLETE`: start
+   a fresh Review and Test. Do not write `delivery.md`, archive the Change, create a
+   release package, or make a delivery claim while that receipt evidence is missing or
+   invalid. Never use `--legacy-v4` for this current-session check; v3 and pre-admission
+   v4 are read-only historical evidence, not current Test or Deliver evidence.
+
+   After the transport succeeds, recheck Change/task/HEAD/product/intent identities.
+   Apply the gate, run build and non-publishing package inspection, determine version
+   impact, and use `references/baseline-reconciliation.md` for canonical `delivery.md`.
+   Archive the Change. Excluded delivery metadata and the directory move cannot
+   self-invalidate the product digest; intent stays independently bound. Retain the
+   review session through this successful Deliver consumption; only then may its derived
+   artifacts be garbage-collected.
+
+   Transport and task-evidence validators establish exact structural, identity,
+   provenance, and freshness facts only. Their success never means that the Change is
+   semantically accepted or that its outcome is ready to describe as delivered.
 
 Do not draft a success narrative around stale evidence. A current `passed: false`
 report may still reach finalization only after every finding has an explicit owner
@@ -100,8 +171,11 @@ Without release authority, stop after the recoverable local archive and report i
 
 ## References
 
+- `../ultra-change/references/change-contract.md` — canonical Active Change authority resolution.
 - `../ultra-review/SKILL.md` — read before aggregate review and refactoring.
+- `../ultra-plan/references/task-evidence-v2.md` — canonical current task evidence and task-review contract.
 - `../ultra-think/SKILL.md` — read when version or release posture is a consequential
   trade-off rather than an established repository rule.
 - `../ultra-think/references/autonomy-boundary.md` — read before scope or evidence shrinks.
+- `../ultra-change/references/execution-grant.md` — read only for grant-activated continuation.
 - `references/baseline-reconciliation.md` — exact `delivery.md` reconciliation contract.

package/skills/ultra-dev/SKILL.md

@@ -9,24 +9,77 @@ The model owns code reasoning and edits; repository files own the resumable cont
 
 ## Before you start
 
-1. Resolve exactly one active `change_id`; more than one is a repository conflict. Read
-   `.ultra/tasks.json`, choose one matching `in_progress` or dependency-ready task, then read
-   its full `context_file`, especially `## Resume Note`.
-2. Read `CONTEXT.md` for vocabulary, and the `.ultra/decisions/` entries the task
+1. If model-selected, verify the live execution grant in `../ultra-change/references/execution-grant.md` — a current session-local activation or a stably verified durable work-package grant; without either, stop.
+2. Read `../ultra-change/references/change-contract.md` and apply its **Active Change
+   authority resolution** before reading any active `intent.md` or resolving a current
+   `change_id`. Require its one valid authority; otherwise stop with its typed repair.
+   Then read `.ultra/tasks.json`. Without an exact task id in the owner invocation,
+   select only the uniquely current `in_progress` task and read its full
+   `context_file`, especially `## Resume Note`; if none exists, stop and ask
+   the owner to invoke Dev naming one exact task id — a `pending` row is a frontier
+   candidate, not active work, and Hooks will not have injected its acceptance or
+   Resume. An invocation that names one exact task id supplies invocation-local
+   selection authority for this Dev run only. If more than one row claims
+   `in_progress`, do not manufacture a unique current task; use the explicit recovery
+   below or stop with the Hook diagnostic. The ledger is the sole task-status authority;
+   legacy Status or Complexity never overrides it. A `completed` task with a current
+   invalidation observation may be selected only for the explicit reopen below; record
+   and read back that transition before repair.
+3. Read `CONTEXT.md` for vocabulary, and the `.ultra/decisions/` entries the task
    context names.
-3. Read `.ultra/north-star.md` and the task's acceptance criteria. If you cannot
-   state that acceptance in one sentence, you are not ready to start.
+4. Validate `.ultra/north-star.md` with the shipped Research structural sensor. Resolve
+   every listed `FP-*`, `NS-*`, and `HC-*` in the task and active Change against that
+   accepted authority. Compare the active Change's recorded **North Star revision** and
+   **North Star digest** with the accepted file's revision and current Git blob digest.
+   A missing ID, revision mismatch, or digest mismatch is a stale-plan observation: stop
+   before editing and recommend explicit owner invocation of `ultra-change` to reconcile
+   the active Change. Never inherit approval or silently rewrite the trace.
+5. Read the task's acceptance criteria. If you cannot state that acceptance in one
+   sentence, you are not ready to start.
+
+### Activating one named pending task
+
+When the owner invocation names a dependency-ready `pending` task, perform its
+canonical activation before any implementation work: write that row from
+`pending` to `in_progress` in `.ultra/tasks.json` and read the row back before
+the first implementation edit. This one canonical ledger write is what makes
+the named task live for the task-aware Hooks; without it Hooks correctly remain
+task-silent while you edit, because a trusted invocation is visible only to the
+invocation that carried it. The activation adds no selector, activation flag,
+or workflow state — the ledger row is the only authority — and it must respect
+the single-writer boundary: resolve any conflicting `in_progress` rows through
+the recovery below or an owner decision before writing.
+
+### Recover one exact task from an ambiguous ledger
+
+An explicit owner invocation with one exact task id supplies invocation-local selection
+authority for this Dev run even when multiple ledger rows claim `in_progress`. Before
+editing, read that exact canonical ledger row and context, especially its Resume Note,
+then inspect current Git/worktree evidence for the named task. Do not persist a new
+current-task selector, status, or workflow state to manufacture uniqueness. Hooks remain
+task-silent and progress-silent while the ledger is ambiguous.
+
+Only an explicit owner/Plan correction that establishes a conflicting task never started
+may return that row to `pending`. If multiple tasks contain real partial work, keep every
+task with real partial work `in_progress` and preserve each task's bytes. Recover them by
+separate exact task-id owner invocations or obtain owner-authorized Plan reconciliation;
+use a separate worktree when needed to keep their writes isolated. Completing the
+selected task still requires final review, canonical v2 evidence, context publication,
+ledger write, and readback.
 
 When this task starts from an observed error, failing check or unexpected behavior,
 read `references/debugging.md` and establish the earliest incorrect state before editing.
 
 ## Definition of done
 
-- All six evidence dimensions answer the checkable rules below.
-- `tasks.json` and context status agree after write/read-back.
+- All six evidence dimensions carry honest, current observations under the typed v2
+  evidence contract; a real limitation remains a gap rather than becoming a pass.
+- `.ultra/tasks.json` remains the sole task-status authority after write/read-back.
 - The task still names the active `change_id`; historical unfinished work stays out.
 - The context file carries a Completion entry and a rewritten Resume Note.
-- A task-level review has run and its blocking findings are resolved.
+- A task-level review runs while the ledger task remains `in_progress`; its blocking
+  findings are resolved or owner-dispositioned as required and affected evidence is
+  refreshed before the model writes `completed` to the ledger.
 
 ## Write the implementation plan before the code
 
@@ -38,30 +91,54 @@ buries the design decisions in the details.
 ## Develop through red then green
 
 Follow `../ultra-tdd/SKILL.md`, writing tests only on the seams the plan already
-confirmed, one slice at a time. Do no refactoring here — `ultra-review` owns it,
-because what is worth restructuring only becomes visible after several slices.
+confirmed, one slice at a time. `ultra-review` owns evidence-backed refactoring when
+observed duplication, coupling, or a boundary defect justifies it; a slice count does
+not make that decision.
 
 ## Converge on the task-scoped acceptance set
 
-Development ends when the task's acceptance commands pass, not when the code looks
+Development ends when every task-scoped criterion has its required current evidence and
+responsible semantic disposition, not merely when commands pass or the code looks
 finished. Resolve the context's **Change Acceptance IDs** against the active `intent.md`
-for `<change_id>`
-and use each named row's executable `Verification`. Commands under the context's
-Acceptance Criteria may add task-local checks; they do not replace the Change mapping.
-
-Run one baseline before repairing anything. Track the best-ever passing set of mapped
-IDs and task-local commands, the total repair rounds, and consecutive rounds that add
-nothing to that set. The loop has three explicit exits:
+for `<change_id>`. For each named row consume its exact `Verification type` and
+`Required evidence`. When one outcome needs more than one authority, split it into
+independent criteria with unique IDs and preserve each authority separately; every row
+has exactly one verification type. Task-local acceptance may add evidence requirements,
+but it does not replace or narrow the Change mapping.
+
+Handle the four verification types without converting one authority into another:
+
+- Execute only `command` observations. Record the exact command, working directory,
+  exit status, retained raw output reference, and its exact SHA-256.
+- For `inspection`, cite the exact source and revision or digest, then refresh the
+  observation after any touched source changes.
+- For `owner-judgment`, preserve the cited owner decision. The owner alone supplies its
+  semantic result; a model statement, validator, score, or command cannot proxy it.
+- For `external-observation`, preserve the provider or system receipt without proxying it
+  with a local command, model claim, or synthetic fixture, and bind its exact bytes by
+  SHA-256.
+
+- Missing `owner-judgment` stops at its named owner gate.
+- Missing `external-observation` stops at its named external or authorization gate.
+- If an inspection exists but its semantic implication is unresolved, stop at the
+  responsible model or owner gate; a structural citation is not an automatic acceptance
+  verdict.
+
+Run one baseline before repairing anything. Track a best-ever evidence set keyed by
+criterion, verification type, and source identity to make progress visible, plus the
+current evidence set used for convergence. Stale or regressed evidence remains history
+but cannot satisfy the current set. Do not infer semantic progress or failure from a
+round count. The loop has three explicit exits:
 
 | Exit | Condition | Action |
 |---|---|---|
-| Converged | Every mapped Change verification and task-local command exits zero | Close out below |
-| Stalled | Two consecutive repair rounds add no new item to the best-ever passing set, or three repair rounds finish without convergence | Stop; report the remaining criteria and what each repair tried |
-| Unreachable | A command did not start because its executable, fixture, service or declared environment prerequisite is unavailable | Stop that criterion; report the missing prerequisite and its repair path |
+| Converged | Every mapped and task-local criterion has current required evidence of every named type, and the responsible model or owner has made any semantic disposition | Close out below |
+| Stalled | An in-scope repair yields no new or refreshed evidence and no further evidence-producing repair is justified inside the approved task | Stop; report the missing evidence, the attempted repair, and the responsible next gate |
+| Unreachable | Required evidence cannot be observed because an executable, fixture, provider, service, declared environment prerequisite, or required authorization is unavailable | Stop that criterion; report the unavailable prerequisite or gate and its reachable repair path |
 
-A nonzero exit normally means a failing criterion, not an unreachable one; inspect its
-output. A regression never shrinks the best-ever set, and the total round limit stops
-oscillation where different criteria alternate between pass and fail.
+A nonzero command exit is an observation, not automatically `Unreachable`; inspect its
+output and repair within scope when justified. None of these exits mechanically decides
+semantic sufficiency, owner acceptance, or external truth.
 
 ## Answer the six evidence dimensions
 
@@ -76,14 +153,15 @@ Each has a rule you can check against the work rather than assert:
 | `vertical_slice` | One test's execution path runs from the entry point through to persistence |
 | `spec_trace` | The anchor the task's `trace_to` names exists in the specification |
 
-Record one canonical `.ultra/evidence/<task-id>/evidence.json` with
-`$schema: "ultra-task-evidence-v1"`, `task_id`, `git_head`, `commands`, the six-key
-`dimensions` object, `artifacts`, `limitations`, and `timestamp`. Raw logs and cited
-files stay beside it; no second summary restates the same evidence. Each command has
-`command`, `exit_code`, and `evidence_ref`. Each dimension has `status` (`satisfied`,
-`gap`, or `not_applicable`), `evidence_refs`, and a non-empty `rationale`. Evidence is a
-sensor, not a gate: a gap is reported and handed over, never used to block the work — a
-gate that can be escaped by damaging the work gets escaped by damaging the work.
+Before task review, retain the actual criterion evidence, raw logs, owner records,
+external receipts, and cited artifacts without inventing another completion record.
+Do not write `evidence.json` before the task's validated final `SUMMARY.json` exists.
+The review packet admits those actual pre-review observations together with the ledger,
+context acceptance, and packet-defined task scope. A structural validator may check
+exact fields, types, digests, paths, and freshness observations. It never supplies an
+acceptance disposition, turns a model claim into command evidence, or decides semantic pass.
+Evidence is a sensor: a gap or legacy v1 record is reported with a migration
+diagnostic, never rewritten as v2 truth.
 
 ## When implementation and the specification disagree
 
@@ -95,10 +173,60 @@ classification in the context file's Change Log.
 
 ## Close out
 
-Write the status to both places and read both back. Add the Completion entry and
-rewrite the Resume Note to say where the next session picks up. Then run the
-task-level review through `../ultra-review/SKILL.md`, resolve blocking findings, and refresh
-the evidence they touched.
+Keep the ledger row `in_progress` while running task review through
+`../ultra-review/SKILL.md`. Build its immutable packet from the ledger, task context,
+packet-defined task scope, and actual pre-review evidence; the final v2 record is not an
+admission prerequisite. Route only the exact current P0/P1 findings (or a P2 the owner
+explicitly promoted) as one in-scope repair set, followed by one affected-lens delta
+review per repair set inside the active review budget — an exact current owner grant
+overrides the versioned product default of one initial review plus at most two
+P0/P1 delta reviews per package. When another `REQUEST_CHANGES` would exceed the
+active budget, return to the owner checkpoint with the exact blocking set instead of
+an automatic repair; the same root surviving three failed fixes stops point-patching
+and reports an architecture problem. Budget exhaustion stops execution at `owner checkpoint` /
+`budget_exhausted` and keeps the ledger row `in_progress`.
+It never yields `APPROVE`, `REQUEST_CHANGES`, `INCOMPLETE`, pass, fail, accept, or
+abandon. If a repair changes implementation or evidence in review scope, use a new
+immutable packet and validated review summary before closeout rather than rebinding the
+old review. Worker Packet v1 and its summary do not bind a task worktree digest.
+
+After the final validated `SUMMARY.json`, write one canonical `ultra-task-evidence-v2` record only after completing the raw-receipt binding below.
+When the task's owner-designated review mode is external manual, the final review
+product is instead the external reviewer's real receipt, bound through the
+`review_mode: "external-manual"` branch of
+`../ultra-plan/references/task-evidence-v2.md`: publish that receipt under
+`.ultra/evidence/<task-id>/`, record its exact stable-byte SHA-256, and verify it
+with the sensor's `--verify-external-receipt` mode instead of inventing a strict
+session. Never fabricate one branch's artifacts to satisfy the other's shape.
+The `subject` is an independently captured completion-snapshot freshness observation.
+Before writing `evidence.json`, resolve every
+command and external-observation `raw_evidence_ref` below the real repository root and
+take bounded stable repository-contained bytes from an ordinary regular non-symlink file
+opened nonblocking and no-follow. Reject a missing, escaped, symlinked, special,
+oversized, or replaced file; otherwise compute `raw_evidence_sha256` from that one byte
+snapshot. Publish that canonical record at `.ultra/evidence/<task-id>/evidence.json`,
+read back the stable record and each raw ref,
+and require the same ref bytes and digest before continuing.
+Follow `../ultra-plan/references/task-evidence-v2.md`: `task_review` separately binds the retained strict summary; record one typed acceptance entry per criterion, all
+six dimensions, the exact Execution Packet and review identities, blocking-finding
+dispositions, evidence refresh refs, artifacts, limitations, and retention without
+claiming that the review summary proves `subject.worktree_digest`. Read the record back, then update context
+`## Task Review`, Completion, and `## Resume Note`; the context has no second status.
+Only after those facts are durable may the primary model write `completed` to the
+ledger and read the row back. When the task's work package sits under an
+ACK-ready primary transfer whose newest terminal receipt is a completed v2
+RESULT, this sequence is that contract's prescribed closeout: publish the
+handoff's `CLOSEOUT.json` beside the frozen RESULT — citing the review receipt,
+the closeout-start/end observations, and any recorded owner-authorized
+continuation — instead of refreshing the RESULT or opening a new handoff; the
+closeout starts no review and no repair round
+(`../ultra-change/references/primary-transfer.md`).
+
+If later work invalidates a completed task's criterion evidence, Dev performs an
+explicit reopen. A reopen changes the ledger row from `completed` to `in_progress`;
+Dev must never silently demote the row. Before that write, record the affected criterion IDs and reason in both the context Change Log and Resume Note, preserve the prior review as
+historical evidence, then write and read back the ledger transition. Refresh the named
+evidence, run task review for the new snapshot, and repeat this closeout sequence.
 
 Report the changed paths, the seam, the exact checks run, the review result, the
 evidence gaps and the residual risk. Recommend the next capability from what the
@@ -106,14 +234,16 @@ files now say; do not invoke it.
 
 ## When the owner decides
 
-Any REDUCTION, and each external effect separately.
-At most one authorized local task commit happens here; push, tag, publish and
-deploy each need their own authorization. An interrupted task leaves its worktree
-as it stands and says so in the Resume Note instead of tidying it away.
+The owner decides any REDUCTION and each external effect separately. At most one
+authorized local task commit happens here; push, tag, publish and deploy need separate
+authority. An interruption leaves the worktree as-is and names it in the Resume Note.
 
 ## References
 
+- `../ultra-change/references/change-contract.md` — canonical Active Change authority resolution.
 - `../ultra-tdd/SKILL.md` — read before the first test, for the seam and mock boundary.
 - `../ultra-think/references/autonomy-boundary.md` — read when spec and code disagree.
 - `../ultra-review/SKILL.md` — read when implementation evidence is ready for review.
+- `../ultra-change/references/execution-grant.md` — read only for grant-activated continuation.
+- `../ultra-plan/references/task-evidence-v2.md` — canonical evidence, disposition, and task-review shape.
 - `references/debugging.md` — read for a reproduced failure before selecting a repair.

package/skills/ultra-grilling/SKILL.md

@@ -67,10 +67,11 @@ Order questions so that answering one unlocks the next. Ask the framing question
 before the detail questions — a detail settled inside the wrong frame has to be
 asked again.
 
-**Framing questions** come first — at most five, from the table in
-`references/reframing.md`. They refuse the owner's framing on purpose, which is
-how they surface what the request left out. Stop early once the frame stops
-moving.
+**Framing questions** come first, selecting only prompts from
+`references/reframing.md` that can change the current frame. They refuse the owner's
+framing on purpose, which is how they surface what the request left out. Stop once the
+owner confirms the frame or further prompts cannot distinguish a materially different
+build; a question count never decides that.
 
 **Detail questions** fill in the confirmed frame:
 
@@ -100,8 +101,10 @@ the options rejected and the reason they lost. The caller alone chooses the cano
 destination; Grilling never promotes an answer into project authority by itself.
 
 - **Resolved** — every required field answered or explicitly deferred.
-- **Stalled** — two consecutive turns add no newly confirmed decision. Hand back
-  the open fields and what each one blocks.
+- **Stalled** — the evidence shows that another in-scope question cannot produce a new
+  decision without unavailable owner input or a newly framed choice. Hand back the open
+  fields, the attempted distinctions, and what each one blocks; do not infer this from
+  a turn count.
 - **Unavailable** — the host cannot ask, or the owner stopped answering. Hand back
   the last confirmed state, every unanswered field named.
 
@@ -113,6 +116,6 @@ question per turn instead.
 ## References
 
 - `references/reframing.md` — read before the first question: when to reframe,
-  how it fails, the five framing questions, and what counts as an answer.
+  how it fails, the framing prompts, and what counts as an answer.
 - `../ultra-think/references/autonomy-boundary.md` — read when an answer removes
   something the specification already promised, or otherwise crosses C5.

package/skills/ultra-grilling/references/reframing.md

@@ -36,13 +36,17 @@ Rules that keep this honest:
   a constraint you did not have a minute ago. Record it as a decision.
 - **Never reframe toward what is easier to build.** If your reinterpretation
   happens to shrink the work, say that out loud and let the owner weigh it.
-- **Stop after two rejected reframes.** A third is no longer listening. Take the
-  owner's framing as given and move to the framing questions below.
+- **Stop when the owner rejects the proposed role and confirms their original frame.**
+  Do not keep producing cosmetic reinterpretations. If a materially different reading
+  later becomes evidenced, present that new distinction rather than counting prior
+  attempts.
 
 ## Framing questions
 
 These refuse the owner's framing on purpose, which is how they surface what the
-request left out. Ask at most five, and stop early once the frame stops moving.
+request left out. Ask only the prompts that can distinguish a materially different
+build, and stop when the owner confirms the frame or the remaining prompts cannot
+change it.
 
 | Question | What it recovers |
 |---|---|