ultra-builder-pro-cli 0.22.0 → 0.23.0

package/skills/ultra-research/SKILL.md

@@ -1,118 +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`, `task.ledger_get`, `baseline.get`, breadcrumb
-   `accepted_intent`, active decisions, and existing research runs. Import a newer
-   descendant team checkpoint before binding coverage; stop on a typed merge conflict.
-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. Successful convergence publishes the portable baseline, Changes, and tasks
-to the Git team checkpoint; the receiving checkout must still revalidate a ready
-baseline against its own HEAD and files.
-
-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,62 +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. Read doctor and `task.ledger_get`. Import a newer descendant checkpoint before
-   binding the review scope; stop on a typed merge conflict.
-3. Bind one explicit diff or plan artifact, full HEAD, worktree digest, task set,
-   acceptance, breadcrumb `accepted_intent`, and current decision state.
-4. Resume or start the review workflow and record `bind-diff`.
-5. 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,63 +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 the Git team checkpoint, generated task
-JSON, prose, or context frontmatter when checkout-local DB authority is missing or
-degraded.
+This Skill is read-only.
 
 ## Read
 
-1. Run `system.doctor` without repair.
-2. Run `task.ledger_get`. Report `current`, `drifted`, `revalidation_required`,
-   `missing`, or a typed invalid/conflict state; do not import or publish from status.
-3. Read baseline classification, revision, worktree, research provenance, gaps, and
-   health.
-4. Read current decision state and breadcrumb `accepted_intent` without exposing hidden
-   future questions.
-5. Read active, blocked, and ready workflows and their current steps.
-6. Read the active Change root, typed delta, plan, deterministic progress projection,
-   documentation reconciliation, findings, tasks, sessions, and current Git state.
-7. 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>
-Team checkpoint: <current|drifted|revalidation_required|missing|invalid> · generation=<n>
-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,74 +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, `task.ledger_get`, change, breadcrumb `accepted_intent`, decisions,
-   task and dev evidence, current checkout, and prior report freshness. Import a newer
-   descendant checkpoint before binding the task set; stop on a typed merge conflict.
-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.

package/skills/ultra-think/SKILL.md

@@ -3,55 +3,36 @@ name: ultra-think
 description: Resolve a consequential product, architecture, or recovery question through evidence-first reasoning and adaptive user alignment. Use when a material decision cannot be derived safely from accepted intent and current evidence.
 ---
 
-# Align without suppressing model judgment
+# Align without suppressing judgment
 
-Thinking is an optional reasoning capability, not a mandatory stage. Answer
-self-contained questions directly. Use durable decision state only when a
-project-bound choice must survive interruption or gate later work.
+Thinking is optional. Answer self-contained questions directly. Persist only a
+project-bound decision that must survive interruption or control later work.
 
-## Reason first
+## Reason and interact
 
-1. Define the actual decision or disputed claim and the constraints that can change
-   its answer.
-2. Inspect current authority, source, runtime, tests, and primary documentation before
-   asking the user for facts.
-3. Separate verified fact, evidence-backed inference, accepted intent, delegated
+1. Call `ultra.context` for the relevant project or Change scope.
+2. Define the real decision and the constraints that can change its answer.
+3. Inspect source, runtime, tests, accepted artifacts, and primary documentation
+   before asking the owner for facts.
+4. Separate verified fact, evidence-backed inference, accepted intent, delegated
    implementation judgment, and unresolved owner choice.
-4. Form credible alternatives only when alternatives materially help the decision.
-   Evaluate them against the real constraints; do not impose a fixed option count,
-   scoring system, or confidence percentage.
-5. Stress-test the leading answer with its strongest counterexample, likely failure
-   path, recovery, and load-bearing assumption.
-
-## Interact adaptively
-
-Read `references/decision-dialogue.md`. If the user already gave a clear decision,
-normalize and use it without asking for confirmation. If the decision is reversible
-and delegated by the accepted contract, decide it and explain the reasoning.
-
-When owner authority is required, use the host's native question UI when available.
-Ask the earliest dependent decision with a recommendation, decisive evidence, and the
-effect of the answer. Keep cognitive load small; group only independent, simple facts.
-Do not expose the hidden decision queue.
-
-For durable project decisions, use `decision.thread_start`, `decision.open`, and the
-appropriate resolve, delegate, defer, or supersede transition. Store normalized
-decisions and artifact references, never transcripts or internal reasoning.
-Apply any resulting change through its owning baseline, change, workflow, task, or
-semantic artifact operation, read it back, and pass typed `applied_refs` to
-`decision.complete`. If the decision record itself is the complete durable authority,
-the list may be empty. Completion is not another owner approval.
-
-Prepare and confirm a checkpoint only when the decision changes a durable contract or
-artifact and a checkpoint is needed for recovery. Do not add a ceremonial approval
-gate to an already explicit user instruction or a reversible implementation detail.
-
-## Return control
-
-Return the conclusion, decisive evidence, material uncertainty, and affected
-contracts. Re-read the invoking workflow or breadcrumb and recommend one of its
-`allowed_transitions`; follow `required_transition` only when a hard invariant leaves
-no alternative. Thinking does not implement code, mutate unrelated state, or invent a
-canonical next action.
-
-Never invoke the recommended capability here; wait for an explicit user invocation.
+5. Stress-test the leading answer with its strongest failure path and recovery.
+
+Read `references/decision-dialogue.md`. Reuse a clear decision already present in the
+request. Decide reversible delegated implementation details yourself. When owner
+authority is necessary, ask one dependent decision through the host-native question
+surface with a recommendation, decisive evidence, and the effect of the answer.
+
+## Persist only the normalized result
+
+Use one `ultra.record` batch for `decision.thread_start`, `decision.open`, the
+appropriate resolve/delegate/defer/supersede operation, the owning artifact mutation,
+and `decision.complete` when they are all known. Store normalized decisions and
+artifact references, never transcripts or internal reasoning.
+
+A semantic rejection remains a mutable diagnostic. Correct the record or intentionally
+abandon the draft; do not invent a new decision merely to satisfy a state machine.
+
+Return the conclusion, decisive evidence, uncertainty, affected authority, and the
+model's recommended next explicit capability. Thinking never performs unrelated
+implementation or an external effect. Do not invoke the next capability automatically.

package/skills/ultra-think/references/decision-dialogue.md

@@ -147,7 +147,9 @@ exists; that exception does not create interaction proof.
 
 ## Return to the capability graph
 
-After alignment, re-read the invoking workflow and breadcrumb. A
-`required_transition` is authoritative only for a hard invariant. Otherwise the host
-model recommends among `allowed_transitions` based on the user's goal and current
-evidence. Do not persist that semantic recommendation as MCP authority.
+After alignment, re-read `ultra.context` for the invoking scope. The host model
+recommends the next explicit capability from the user's goal, accepted intent,
+evidence, recovery cost, and current warnings or blockers. MCP diagnostics describe
+mechanical facts; they do not encode a semantic route or persist the recommendation
+as authority. Only corruption, unsafe paths, true concurrency conflicts, permissions,
+or irreversible external effects are hard blockers.

package/spec/cli-protocol.md

@@ -81,6 +81,13 @@ as a fallback unless `ultra-tools <family> --help` lists it.
 
 | MCP tool                  | CLI subcommand              | Phase | Writer  |
 |---------------------------|-----------------------------|------:|---------|
+| `ultra.context`           | `ultra context`             | 23    | mcp     |
+| `ultra.record`            | `ultra record`              | 23    | mcp     |
+| `ultra.checkpoint`        | `ultra checkpoint`          | 23    | mcp     |
+| `ultra.sync`              | `ultra sync`                | 23    | mcp     |
+| `ultra.session`           | `ultra session`             | 23    | mcp     |
+| `ultra.archive`           | `ultra archive`             | 23    | mcp     |
+| `ultra.doctor`            | `ultra doctor`              | 23    | mcp     |
 | `task.create`             | `task create`               | 2     | mcp     |
 | `task.update`             | `task update`               | 2     | mcp     |
 | `task.list`               | `task list`                 | 2     | any     |
@@ -142,6 +149,11 @@ as a fallback unless `ultra-tools <family> --help` lists it.
 | `plan.export`             | `plan export`               | 8a    | mcp     |
 | `plan.get`                | `plan get`                  | 8a    | any     |
 
+The seven `ultra.*` rows are the public model-facing MCP surface. The remaining
+rows are one-release compatibility operations and CLI naming reservations; they
+are callable by an already-running 0.22 session but are not returned by
+`tools/list`.
+
 Current executable maintenance surfaces are `task init-project`,
 `session close|get|list|admission|heartbeat|subscribe|reap`, `status`, `db`,
 `migrate`, `system doctor|restore|rebaseline`, and `legacy-memory`. In particular, `task create|update|list|get`