ultra-builder-pro-cli 0.21.1 → 0.23.0

package/skills/ultra-plan/SKILL.md

@@ -5,128 +5,55 @@ description: Turn an accepted Ultra Change Contract into dependency-valid, DB-ba
 
 # Build an executable plan
 
-The model owns decomposition and technical design. MCP owns plan state, task contracts,
-dependency integrity, output digests, and recovery. Planning must stay inside the
-accepted Change Contract without adding ceremonial approval.
-
-## Bind current authority
-
-1. Read doctor, baseline, change, breadcrumb `accepted_intent`, decisions, existing plan
-   runs, tasks, and current checkout.
-2. Require one mutable change with a healthy baseline or recorded incident bypass.
-   For the first delivery of a greenfield project, an accepted ready baseline may
-   already contain the complete delivery outcome. When no matching Change exists,
-   materialize one `change.create` contract from that accepted intent and read it back
-   without asking the owner to repeat the same choice. Do not invent scope, expand an
-   incomplete baseline, or use this shortcut for a later change.
-3. Complete the exact change-bound research disposition before planning.
-4. For a standard or major Change, read the current registered `change.delta` and
-   verify its baseline anchors and digest. A Direct Build route supplies the delta
-   directly from accepted intent; it skips Research, not this authority boundary.
-5. Resume the matching plan run. Do not start a new run until planning posture is
-   accepted.
-
-Read `references/semantic-preflight.md` and inspect requirements, real consumers,
-state, tests, deployment, and recovery paths.
-
-## Align planning posture
-
-Use the interaction protocol in `../ultra-think/references/decision-dialogue.md`.
-Normalize a posture already explicit in current intent. Otherwise recommend one based
-on the Change Contract, explain its scope effect, and use the host's native question
-surface:
-
-- `EXPAND`: surface evidence-backed opportunities beyond accepted scope;
-- `SELECTIVE`: hold accepted scope and offer optional expansions individually;
-- `HOLD`: preserve scope and strengthen completeness, failure handling, and recovery;
-- `REDUCE`: propose the smallest outcome that still satisfies revised acceptance.
-
-The user may select, modify, delegate, or defer the posture. Stop on an unanswered
-choice. Start `workflow.start` only after alignment and store `planning_posture` plus
-its rationale in workflow metadata. This is a scope boundary, not approval of the
-eventual technical design.
-
-## Design with model autonomy
-
-Build a candidate plan from the Change Contract, current typed delta, and any selected
-research. Ask the user only if the plan would change accepted
-scope, public behavior, compatibility, security, material cost, external effects, or
-recovery. Use the same host-native interaction protocol.
-
-When the candidate remains inside the accepted Change Contract, proceed without a
-second approval. A user may still request a plan review before persistence; that is an
-interaction preference, not a runtime invariant.
-
-Record:
-
-1. `validate-baseline`
-2. `compile-context`
-3. `analyze-requirements`
-4. `analyze-codebase`
-5. `design-slices`
-6. `validate-dependencies`
-7. `persist-task-contracts`
-8. `verify-plan`
-
-Design a walking skeleton and subsequent vertical slices. Every slice reaches a real
-consumer and owns its validation, side effects, errors, documentation, migration,
-observability, and recovery obligations. Avoid unconsumed horizontal scaffolding.
-
-After starting or resuming the workflow, compile `change.context` with `role: plan`
-and `gate: planning`. Record its immutable manifest as the `compile-context` output.
-The packet is the accepted planning input, not a mutable plan draft. `change.context`
-must not update Change provider references; persist new provider metadata with
-`change.update` before recompiling.
-
-## Persist task contracts
-
-Create each task with:
-
-- observable outcome (`purpose`) and stable trace (`why`);
-- `slice_kind`, public seam, and exact verification command;
-- structured acceptance mapped to Change acceptance ids;
-- target seams and affected files when known;
-- bounded pattern/context refs with a reason, optional anchor and scope, and an
-  explicit freshness policy;
-- documentation impact, ownership, and dependencies.
-
-Use `digest` freshness with `expected_digest` for accepted inputs that must remain
-byte-current. Use `existence` for source targets expected to change during
-implementation. Use `advisory` only when drift should be visible but non-blocking.
-The compiled task context restores constraints and non-goals from the Change Contract,
-plus acceptance, recovery, documentation impact, and the definition of drift. Keep
-large referenced files lazy; do not paste their bodies into the plan packet.
-
-Use estimates only when evidence supports them. A quick change has exactly one task.
-Read every task back from DB. Never read or write `.ultra/tasks/tasks.json` directly;
-it is a generated projection, not authority.
-
-If a semantic `change.update` invalidated existing tasks, reconcile every affected
-task contract against the current intent, acceptance, decisions, and research
-evidence. Rebind the complete execution contract while clearing `stale` through
-`task.update`; MCP rejects a marker-only clear, validates the read-back, and records
-the current Change authority digest. Never clear staleness merely to pass a gate.
-
-Validate the change-scoped graph with `task.dependency_topo`. Export
-the deterministic `<artifact_root>/plan.json` and `<artifact_root>/plan.md` pair with
-`plan.export { change_id }`. The JSON binds the exact planning context snapshot and
-manifest digest; the Markdown is a deterministic human view of the same task graph.
-Read the JSON through `plan.get` and record it as the `verify-plan` output. Do not
-choose an arbitrary output path or overwrite another Change's plan. A legacy global
-`.ultra/execution-plan.json` may be read for migration diagnosis only and is never a
-current write target.
-
-Call `workflow.complete`. `approval` is optional: include it only when a material plan
-decision actually required and received user approval. MCP derives task coverage and
-topology from DB and must reject incomplete contracts, uncovered acceptance, cycles,
-cross-change tasks, stale research, or a mismatched export.
-
-Do not advance or complete the Change workflow; change capture is already complete.
-Compile a separate task context later for each consumer that needs it. Planning,
-implementation, testing, review, and convergence snapshots are not interchangeable.
-
-Return topology, first executable slices, public seams, verification commands, plan
-workflow id, and allowed transitions. The host may recommend parallel or sequential
-execution based on dependency and conflict evidence.
-
-Never invoke the recommended capability here; wait for an explicit user invocation.
+The model owns decomposition and technical design. MCP commits the accepted task graph,
+digests, context, and team checkpoint in one semantic operation.
+
+## Bind and design
+
+1. Call `ultra.context { stage: plan, scope: { change_id }, detail: full }`.
+2. Inspect or import the team checkpoint with `ultra.sync`. Resolve real concurrent
+   record conflicts; do not merge authority by editing JSON.
+3. Require an accepted Change contract and its current typed delta. Direct Build skips
+   extra research, never Plan or task contracts.
+4. Read `references/semantic-preflight.md`; inspect real consumers, source, tests,
+   deployment, and recovery.
+5. Recommend `EXPAND`, `SELECTIVE`, `HOLD`, or `REDUCE` only when posture changes
+   accepted scope. Reuse an explicit posture and ask through the host-native UI only
+   for a material unresolved choice.
+6. Design a walking skeleton and vertical slices. Each task owns an observable outcome,
+   public seam, verification command, acceptance mapping, target seams, bounded
+   context refs, documentation impact, recovery, owner, and dependencies.
+
+Large sources stay lazy. Use digest freshness for accepted inputs that must remain
+byte-current, existence for expected implementation targets, and advisory only when
+drift must be visible without blocking.
+
+Read `../ultra-think/references/decision-dialogue.md` before asking a material
+question.
+
+## Record and checkpoint
+
+Use one `ultra.record` batch for all `task.create` and necessary `task.update`
+operations. Read back the draft with `ultra.context`.
+Never read or write `.ultra/tasks/tasks.json`; use `ultra.sync` for the Git team
+checkpoint, and never edit the local runtime projection directly.
+
+Call exactly one `ultra.checkpoint`:
+
+```text
+stage: plan
+scope: { change_id }
+payload: planning posture, optional approval already obtained, context budget/refs
+idempotency_key: stable semantic Plan checkpoint id
+```
+
+The checkpoint compiles or reuses the content-addressed Context Manifest, validates
+task coverage and dependencies, exports `plan.json` and `plan.md` once, completes the
+durable Plan, and publishes the team checkpoint. Do not export again after validation.
+
+If rejected, the same Plan draft stays mutable. Fix task contracts or evidence and
+retry. To discard it, record `workflow.abandon`; never edit SQLite or open a parallel
+run to escape a blocker.
+
+Return topology, executable slices, public seams, exact checks, checkpoint result, and
+the model's recommended execution order. Do not invoke `ultra-dev` automatically.

package/skills/ultra-research/SKILL.md

@@ -1,119 +1,59 @@
 ---
 name: ultra-research
-description: Build or refresh an evidence-backed product and architecture baseline through recommended, user-selected semantic coverage and low-load alignment. Use when initialization, brownfield adoption, or an active change has a real evidence gap.
+description: Build or refresh an evidence-backed product and architecture baseline through recommended, user-selected semantic coverage. Use when initialization, brownfield adoption, or an active Change has a real evidence gap.
 ---
 
 # Research with adaptive coverage
 
-The model owns investigation, synthesis, and coverage recommendations; the user owns
-the accepted semantic route and material deferrals. MCP owns run state, evidence,
-semantic records, digests, freshness, and convergence, not a questionnaire.
+The model owns investigation and synthesis. The owner controls material scope and
+deferrals. MCP records the accepted draft and commits one durable checkpoint; it is
+not a questionnaire or a step-by-step supervisor.
 
-Read `../ultra-think/references/decision-dialogue.md` before asking a material question.
+## Bind current context
 
-## Bind authority
+1. Call `ultra.context { stage: research, detail: full }`.
+2. If the team checkpoint is newer, call `ultra.sync { action: import }`. Stop only
+   on a real ancestry or same-record conflict.
+3. Inspect code, docs, tests, runtime, accepted intent, decisions, and existing
+   research. Reuse current evidence and the matching mutable draft.
+4. Recommend the smallest sufficient coverage. Offer the adaptive set, the full
+   catalog, and a focused Change-bound set only when all are credible.
+5. Use the host-native question surface only for a material unresolved route. Reuse an
+   explicit owner choice without asking again.
 
-1. Read `system.doctor`, `baseline.get`, breadcrumb `accepted_intent`, active decisions,
-   and existing research runs.
-2. Resume the matching active, blocked, or ready run. Do not create parallel authority.
-3. If none exists, use `full` for greenfield, `adoption` for brownfield, or a bounded
-   mode only for a recorded active-Change disposition. Focused baseline coverage
-   remains `full` or `adoption`; `custom` is Change-bound only.
-4. Before `workflow.start`, inspect current code, docs, tests, runtime, and prior
-   artifacts. Recommend the smallest sufficient set of applicable catalog areas.
-   Explain the net effect without dumping all 17 areas. Offer at most three credible
-   routes: the recommended adaptive set, the full catalog, and a focused or custom set.
-5. If current user intent does not already select a route, use the host's native
-   structured question surface. The user selects, modifies, delegates, or defers.
-   Treat a dismissal as unanswered, stop, and perform no route-dependent write.
-6. Normalize the answer and persist the accepted coverage through `workflow.start`.
-   Use `execute` for fresh evidence, `verify_existing` for source validation, `reuse`
-   for current evidence, `not_applicable` with evidence and rationale, or `deferred`
-   with consequence and owner acceptance when scope or material risk changes.
-7. Pass the evidence-based coverage rationale as `metadata.selection_reason`. Omitted
-   catalog areas create no DB step and need no ceremonial disposition.
-8. Read back the created workflow and accepted coverage. When a durable decision thread
-   recorded the route, complete it with the workflow reference in `applied_refs`.
+Read `../ultra-think/references/decision-dialogue.md` before asking. Load only the
+reference files for research areas that actually apply.
 
-`99-synthesis` must execute, verify, or reuse. A missing disposition is a coverage
-error only for an included area; a recorded exclusion with evidence is not incomplete.
+## Investigate
 
-## Coverage catalog
+For each selected area:
 
-Load only the reference for a step that must execute, verify, or reuse:
+- separate `Observed`, `Verified`, `Decided`, and `Unknown`;
+- resolve observable facts yourself and use primary sources where needed;
+- update the smallest baseline or Change-owned research artifact;
+- never store transcripts, hidden reasoning, raw provider payloads, or copied prompts;
+- record evidence, specification updates, decisions, deferrals, and consequences.
 
-| Area | Reference | Area | Reference |
-|---|---|---|---|
-| `00-problem-validation` | `references/00-problem-validation.md` | `01-opportunity-discovery` | `references/01-opportunity-discovery.md` |
-| `02-market-assessment` | `references/02-market-assessment.md` | `03-competitive-landscape` | `references/03-competitive-landscape.md` |
-| `04-product-strategy` | `references/04-product-strategy.md` | `05-assumptions-validation` | `references/05-assumptions-validation.md` |
-| `10-user-personas` | `references/10-user-personas.md` | `11-user-scenarios` | `references/11-user-scenarios.md` |
-| `20-user-stories` | `references/20-user-stories.md` | `21-features-scope` | `references/21-features-scope.md` |
-| `22-success-metrics` | `references/22-success-metrics.md` | `30-architecture-context` | `references/30-architecture-context.md` |
-| `31-solution-strategy` | `references/31-solution-strategy.md` | `32-building-blocks` | `references/32-building-blocks.md` |
-| `40-deployment` | `references/40-deployment.md` | `41-quality-risks` | `references/41-quality-risks.md` |
-| `99-synthesis` | `references/99-synthesis.md` |  |  |
+Use one `ultra.record` batch for durable facts such as `artifact.record`,
+`decision.*`, `baseline.*`, `change.update`, or `change.delta`. Every entry needs a
+stable idempotency key. A rejected entry is a mutable diagnostic: fix the draft and
+retry; use `workflow.abandon` only when intentionally discarding that attempt.
 
-## Investigate and interact
+## Commit one research checkpoint
 
-For each active area:
+Call exactly one `ultra.checkpoint` with `stage: research`. Put the selected research areas
+and their report outputs in `payload.steps`; include only work actually performed,
+verified, reused, deferred with owner authority, or proved not applicable. Synthesis
+must always be present.
 
-1. Resolve observable facts from the checkout, runtime, tests, existing specifications,
-   and primary sources. Separate `Observed`, `Verified`, `Decided`, and `Unknown`.
-2. Ask the user only for a material intent, scope, compatibility, risk, or recovery
-   decision that evidence cannot answer. Use the host's native question UI when
-   available. Present the recommendation and effect; avoid a questionnaire or a dump
-   of the hidden research queue.
-3. Process dependent decisions one at a time. A small group of independent,
-   low-cognitive-load facts may be asked together when the host UI supports it.
-4. Normalize explicit user intent without redundant confirmation. Create durable
-   decision state only when a project-bound decision must survive interruption.
-5. Update the smallest relevant baseline specification or active-change research
-   artifact. Do not copy prompts, transcripts, provider payloads, or internal chain of
-   thought.
+For baseline research, record and converge the accepted baseline through
+`ultra.record`, then publish the team checkpoint with `ultra.sync { action: publish }`.
+For Change-bound research, keep all findings and delta artifacts below the Change
+root and never edit accepted baseline specs directly.
 
-Every required step writes `Evidence`, `Specification updates`, and `Decisions and
-unknowns` to `.ultra/docs/research/<workflow-id>/<step-id>.md` for a baseline, or
-`<change-root>/research/<workflow-id>/<step-id>.md` for an active Change.
+If the checkpoint returns `accepted: false`, keep the same draft mutable, repair the
+reported evidence, and retry. Do not manufacture evidence or open a replacement run.
 
-Call `workflow.step` with bounded evidence, the report output, and typed semantic
-records. Reused or verified evidence must still produce a current report and digest.
-Block the same step when required evidence or owner authority is missing. For Change
-research, keep `findings.md` and every semantic output inside the same Change root and
-register them through workflow outputs; do not write baseline specifications.
-
-At synthesis, bind the current `discovery.md`, `product.md`, `architecture.md`, and
-`research-distillate.md` only for initial/adoption research. Change-bound synthesis
-updates the Change findings and specification overlay, then records or refreshes
-`change.delta`. It never mutates the accepted baseline.
-
-## Baseline convergence
-
-After `workflow.complete`, initial or adoption research calls `baseline.record` with
-the current repository scope and revision, specification refs, evidence, real
-verification results, unknowns, gap ledger, classification, and external provider
-metadata references.
-
-If Git is initialized but unborn, present the exact local checkpoint paths and purpose
-for user authorization, then create only that local commit. Never create a remote,
-tag, or push through research. If authorization or identity is missing, preserve the
-run as blocked with `BASELINE_GIT_HEAD_REQUIRED`.
-
-Call `baseline.converge` only when the user has accepted the exact baseline snapshot,
-known failures, blocking gaps, and scope. Reuse an unambiguous current approval; do not
-ask twice. MCP must reject stale research, drift, missing evidence, and unaccepted
-failures.
-
-Reuse the final research acceptance or current artifact checkpoint during baseline
-convergence; do not ask for an equivalent approval again. After initial or adoption
-convergence, `ultra-change` becomes an available transition. Bounded change research
-returns to its owning Change authority; the next route is still `ultra-plan`, never
-direct implementation.
-
-Return a compact coverage summary by disposition, current evidence or decision
-blocker, baseline state, gaps, and allowed transitions. Recommend a semantic next
-action from those transitions. If current intent does not already select it, present
-the recommendation and credible alternatives through the interaction protocol, then
-wait. MCP supplies only valid and required transitions.
-
-Never invoke the recommended capability here; wait for an explicit user invocation.
+Return coverage, decisive evidence, remaining gaps, durable artifact paths, and a
+model recommendation for the next explicit capability, such as `ultra-change` after a
+ready baseline. Never invoke it automatically.

package/skills/ultra-review/SKILL.md

@@ -1,60 +1,41 @@
 ---
 name: ultra-review
-description: Independently review one current Ultra plan, task diff, or aggregate change on specification fidelity and engineering standards. Use when current evidence needs a review gate or focused risk analysis.
+description: Independently review one current Ultra plan, task diff, or aggregate Change on specification fidelity and engineering standards. Use when current evidence needs review or focused risk analysis.
 ---
 
 # Review one bounded scope
 
 Keep two independent verdict axes:
 
-- `spec_fidelity`: accepted intent, behavior, documentation impact, and public seams;
-- `engineering_standards`: correctness, safety, tests, integration, maintainability,
-  observability, and recovery.
+- `spec_fidelity`: accepted intent, behavior, docs, and public seams;
+- `engineering_standards`: correctness, safety, tests, integration,
+  maintainability, observability, and recovery.
 
-Neither axis can compensate for the other.
+## Bind and review
 
-## Bind evidence
+1. Read `references/review-modes.md`.
+2. Call `ultra.context { stage: review, scope: { change_id, task_id? }, detail: full }`.
+3. Import a newer team checkpoint with `ultra.sync`; stop on a real conflict.
+4. Bind one explicit diff or Plan, full HEAD, worktree digest, task set, acceptance,
+   decisions, and current evidence. Empty or stale scope cannot pass.
+5. Always run `review-spec`. Select the smallest engineering worker set that covers
+   actual risk; record selected and excluded roles with rationale.
 
-1. Read `references/review-modes.md` and select `plan`, `task`, or `change` from the
-   actual review request.
-2. Bind one explicit diff or plan artifact, full HEAD, worktree digest, task set,
-   acceptance, breadcrumb `accepted_intent`, and current decision state.
-3. Resume or start the review workflow and record `bind-diff`.
-4. Compile `change.context` for `review` and record the immutable manifest under
-   `compile-context`.
+Workers are read-only and use the host-native bounded-worker mechanism. Validate their
+artifacts with `scripts/review_wait.py` and
+`references/unified-schema.md`. Preserve every finding unchanged in `SUMMARY.json`;
+group duplicates only in the human summary.
 
-An empty, ambiguous, or stale scope cannot pass.
+Register specialist and summary artifacts through one `ultra.record` batch.
 
-## Select workers by risk
+## Checkpoint
 
-Always run `review-spec`. Select the smallest engineering worker set that covers the
-actual diff and risk. Record every selected and excluded worker with a specific
-rationale; do not run every specialist ceremonially.
+Call `ultra.checkpoint` once with `stage: review`, exact scope, evidence, and outputs
+tagged `spec_review`, `engineering_review`, or summary. The checkpoint compiles or
+reuses review context and derives both axes from registered artifacts.
 
-Invoke workers through the current host's native bounded-worker mechanism and pass
-only their role, current scope, and relevant evidence. Workers are read-only and may
-not decide owner choices or edit source.
+A rejected checkpoint leaves the draft mutable. Fix stale scope or evidence and retry;
+do not open a replacement run or suppress a finding.
 
-Resolve `references/unified-schema.md` from this Skill directory and pass its absolute
-path as `SCHEMA_PATH`. Validate specialist artifacts with
-`scripts/review_wait.py`. Store all specialist artifacts and `SUMMARY.json` below
-`.ultra/changes/active/<change-id>/review/<workflow-id>/`. Record outputs under
-`review-specification`, `review-engineering`, and `coordinate-findings`.
-
-The coordinator preserves every finding unchanged in `SUMMARY.json`; it may group
-duplicate root causes only in the human summary. A new material owner choice remains a
-finding and routes to the interaction protocol.
-
-## Complete
-
-Recheck HEAD, worktree, context digest, diff, task set, acceptance, artifact schemas,
-and both axes. Record `verify-review-gate`, then call `workflow.complete`. MCP derives
-the durable verdict and rejects missing specialists, lossy coordination, stale
-artifacts, or prompt-supplied conclusions.
-
-Any relevant code, test, specification, or contract edit invalidates the affected
-review evidence through registered provenance edges; unrelated evidence remains
-current. Return both verdict axes, blocking findings, reviewed scope, worker selection
-rationale, artifact digests, and allowed transitions.
-
-Never invoke the recommended capability here; wait for an explicit user invocation.
+Return both axes, findings, reviewed scope, worker rationale, digests, and the model's
+recommended next explicit capability. Do not invoke it automatically.

package/skills/ultra-status/SKILL.md

@@ -1,59 +1,40 @@
 ---
 name: ultra-status
-description: Read authoritative Ultra health, workflows, decisions, changes, tasks, evidence freshness, and valid transitions. Use when the user asks what is complete, blocked, stale, or currently possible.
+description: Read authoritative Ultra health, workflows, decisions, changes, tasks, evidence freshness, and team checkpoint state. Use when the user asks what is complete, blocked, stale, or currently possible.
 ---
 
 # Report authoritative state
 
-This Skill is read-only. Never fall back to generated task JSON, prose, or context
-frontmatter when DB authority is missing or degraded.
+This Skill is read-only.
 
 ## Read
 
-1. Run `system.doctor` without repair.
-2. Read baseline classification, revision, worktree, research provenance, gaps, and
-   health.
-3. Read current decision state and breadcrumb `accepted_intent` without exposing hidden
-   future questions.
-4. Read active, blocked, and ready workflows and their current steps.
-5. Read the active Change root, typed delta, plan, deterministic progress projection,
-   documentation reconciliation, findings, tasks, sessions, and current Git state.
-6. Read test, review, and delivery artifacts only through DB references and verify
-   their digests and revisions.
-
-If authority is unreadable, report the unavailable panel and the required doctor or
-init transition. Do not mutate, compile context, repair, or release.
-
-## Interpret transitions
-
-MCP reports:
-
-- `allowed_transitions`: mechanically valid capabilities;
-- `required_transition`: the sole recovery route only when a hard invariant permits no
-  safe alternative.
-
-The host model recommends among allowed transitions using the user's current goal,
-workflow evidence, and cost of interruption. Do not present the recommendation as DB
-authority. A healthy project may validly allow research, change, thinking, or status at
-the same time.
+Call `ultra.context { stage: project, detail: full }`. Use `ultra.sync { action:
+inspect }` only when the user needs team-checkpoint detail. Do not import, publish,
+repair, compile context, or mutate state.
+Never fall back to the Git team checkpoint, generated task JSON, or report files as
+live authority when `ultra.context` reports missing or unhealthy local state.
 
 Report:
 
 ```text
-Ultra: <healthy|degraded> · <branch>@<head|unborn|non-git> · worktree <state>
-Baseline: <mode>/<status> · research=<run/status> · gaps=<open>/<blocking>
-Workflow: <kind/id/status> · step=<current|complete> · outputs=<fresh|stale>
-Decision: <current|checkpoint|none>
-Change: <id/status|none> · delta=<fresh|stale|missing> · docs=<fresh|stale|missing>
+Ultra: <healthy|degraded> · <branch>@<head|unborn|non-git>
+Baseline: <mode>/<status> · gaps=<open>/<blocking>
+Workflow drafts: <active|blocked|ready> · accepted checkpoints=<current|stale>
+Change: <id/status|none> · delta/docs=<state>
 Task: <id/status|none> · Sessions: <active>
 Evidence: plan=<state> · test=<state> · review=<axes> · delivery=<state>
-Blockers: <codes or none>
-Warnings: <codes or none>
-Allowed transitions: <capabilities>
-Required transition: <capability or none>
+Team checkpoint: <current|drifted|revalidation_required|missing|invalid>
+Blockers: <hard mechanical blockers or none>
+Warnings: <advisory semantic diagnostics or none>
 Host recommendation: <capability and concise rationale>
 ```
 
-Separate verified facts, host inference, and unavailable evidence.
+Treat warnings and failed draft checks as information, not mechanical orders. Only
+corruption, unsafe paths, real concurrency conflicts, permissions, or irreversible
+external effects are hard blockers.
 
-Never invoke the recommended capability here; wait for an explicit user invocation.
+The host model recommends the next useful capability from accepted intent, current
+evidence, cost of interruption, and owner goal. SQLite does not choose the route.
+Separate verified facts, model inference, and unavailable evidence. Never invoke the
+recommendation automatically.

package/skills/ultra-test/SKILL.md

@@ -1,73 +1,38 @@
 ---
 name: ultra-test
-description: Independently verify an Ultra task set or change with an evidence-backed, risk-selected test profile. Use when implementation or current acceptance and recovery evidence needs independent verification.
+description: Independently verify an Ultra task set or Change with an evidence-backed, risk-selected test profile. Use when implementation or current acceptance and recovery evidence needs independent verification.
 ---
 
 # Verify current behavior
 
-Testing is independent checking. Do not reuse implementation conclusions or generated
-projections as proof.
+Testing independently checks the current checkout. Implementation conclusions and
+generated projections are not evidence.
 
-## Bind scope
+## Bind and execute
 
-1. Read doctor, change, breadcrumb `accepted_intent`, decisions, task and dev evidence,
-   current checkout, and prior report freshness.
-2. Resume or start a test workflow bound to the exact change and optional task.
-3. Record `bind-scope`, then compile `change.context` for `check` and record its
-   immutable manifest under `compile-context`.
-4. Record `map-acceptance` after mapping every accepted claim to an executable check
-   or bounded observable seam.
+1. Call `ultra.context { stage: test, scope: { change_id, task_id? }, detail: full }`.
+2. Import a newer team checkpoint with `ultra.sync`; stop on a real conflict.
+3. Bind exact acceptance, task set, HEAD, worktree, decisions, dev evidence, and public
+   seams.
+4. Select a risk-based profile from acceptance, regression, integration, static
+   analysis, build, performance, security, and recovery. Acceptance is mandatory;
+   explain every material exclusion.
+5. Run repository-native commands and real boundaries. A bug or incident needs one
+   deterministic red-to-green regression signal.
 
-## Select verification by risk
+Write an `ultra-test-report-v1` report below the owning Change. Bind exact acceptance
+ids, task ids, HEAD, worktree/context digests, commands, seams, failures, recovery,
+profile, timestamp, blockers, and evidence-derived verdict. Register it with
+`ultra.record` using `artifact.record`.
 
-The model selects from:
+## Checkpoint
 
-- acceptance;
-- regression;
-- integration;
-- static analysis;
-- build;
-- performance;
-- security;
-- recovery.
+Call `ultra.checkpoint` once with `stage: test`, exact scope, evidence, and an output
+for the report (`kind: test-report`). The checkpoint compiles or reuses checking
+context and derives the verdict from the registered report.
 
-Acceptance is always selected. Select other dimensions when the change, repository, or
-failure mode makes them material. Record excluded dimensions and concrete rationales in
-`verification_profile`; omission without a rationale is invalid. A selected dimension
-must be `pass`, `fail`, or `not_run`; `not_run` cannot support a passing gate.
+If rejected, keep the same draft, repair evidence, and retry. Never weaken an
+assertion, hide a skip, or turn a warning into proof.
 
-Run repository-native commands and real boundaries where practical. Test doubles are
-acceptable only at costly or nondeterministic external boundaries when the report
-explains the preserved contract. Do not weaken assertions, hide skips, or validate
-unconsumed code.
-
-For an incident or bugfix, record one deterministic red-to-green `regression_signal`.
-When evidence reveals a material product or recovery choice, use the host's native
-question UI and decision protocol; testing must not choose the desired outcome.
-
-## Report
-
-Write
-`.ultra/changes/active/<change-id>/test/<workflow-id>/report.json` with
-`ultra-test-report-v1`, binding:
-
-- change, exact task ids, current Change acceptance ids, HEAD, worktree digest, and
-  checking-context digest;
-- acceptance mapping, commands, public seams, failures, and recovery evidence;
-- `verification_profile` and the selected `verification_dimensions`;
-- regression signal when required;
-- run count, timestamp, blockers, and evidence-derived `passed`.
-
-Record `execute-checks`, `verify-public-seam`, and `write-report`, then re-read the
-report and current checkout before `verify-test-gate`. `workflow.complete` derives its
-summary from the report and rejects stale, malformed, contradictory, out-of-Change,
-or acceptance-incomplete evidence.
-
-Return the profile, exact results, verified seams, blockers, report digest, workflow
-state, and allowed transitions. Recommend broader review, more implementation, or
-delivery from those transitions. If current intent does not already select the
-semantic next action, use
-`../ultra-think/references/decision-dialogue.md` and wait for the user to select,
-modify, delegate, or defer it.
-
-Never invoke the recommended capability here; wait for an explicit user invocation.
+Return the profile, exact results, verified seams, blockers, report digest, and the
+model's recommended next explicit capability. Do not invoke it automatically.