ultra-builder-pro-cli 0.22.0 → 0.23.0

package/skills/ultra-dev/SKILL.md

@@ -5,102 +5,48 @@ description: Implement one authoritative Ultra task through a fresh-context, tes
 
 # Implement one task
 
-The host model owns code reasoning and edits. Ultra owns the task and workflow state,
-fresh context contract, session lease, evidence references, and recovery.
+The model owns code reasoning and edits. Ultra owns the durable task contract, current
+Context Manifest, execution lease, evidence references, and checkpoint.
 
-## Bind and resume
+## Bind execution
 
-1. Read doctor, `task.ledger_get`, breadcrumb `accepted_intent`, active decisions, task
-   contract, dependencies, dev runs, sessions, HEAD, and worktree. Import a newer
-   descendant team checkpoint before taking a lease. Stop on a typed baseline, Change,
-   task, ancestry, or active-session conflict; do not merge authority by editing JSON.
-2. Resume the matching dev run or start one with `change_id` and `task_id`.
-3. Record `bind-task` with current authority and dependency evidence.
-4. Compile `change.context` with `role: implement` and `gate: implementation`. The
-   public seam, verification command, and context refs come from the DB-backed task
-   contract; update that contract before compilation instead of overriding it in the
-   call. Persist any changed external-provider metadata with `change.update` first.
-   Context compilation itself is read-only with respect to Change and provider
-   authority.
-5. Confirm the manifest contains the selected task, its direct dependencies, direct
-   dependents needed for integration, and relevant integration checkpoints—not the
-   entire task graph. Referenced file bodies stay lazy. The token estimate includes
-   inline Change/task authority as well as file estimates; budget overflow is
-   advisory, while a missing or stale required reference is blocking. Record the
-   immutable manifest as `compile-context`.
-6. Reuse an existing valid session. Otherwise pass admission and call `session.spawn`.
-   Work only in the returned worktree and preserve unrelated changes.
+1. Call `ultra.context { stage: dev, scope: { change_id, task_id }, detail: full }`.
+2. Import a newer team checkpoint with `ultra.sync`; stop on a real same-record or
+   active-session conflict.
+3. Reuse a valid lease or call `ultra.session { action: admission }`, then
+   `ultra.session { action: acquire }`. Work only in the returned worktree.
+4. Confirm purpose, acceptance, dependencies, public seam, verification command,
+   non-goals, recovery, and required context refs. Update the task contract before
+   implementation when accepted intent changed.
 
-Do not spawn recursively from a parent-owned worker session. Process exit is transport
-evidence, never task completion.
+## Implement adaptively
 
-## Focused inner loop
+Reproduce the failure, write a failing test, or establish a characterization signal
+before changing logic. Implement the smallest complete vertical slice. Ask the owner
+only when new evidence changes product intent, compatibility, security, material cost,
+external effects, or recovery.
 
-1. Reproduce the bug, write a failing test, or establish a characterization signal
-   before a logic change. Record `establish-feedback-loop`.
-2. Mark the task `in_progress` and implement the smallest complete slice through the
-   declared public seam.
-3. Keep the loop adaptive. The model may choose implementation details inside the
-   accepted contract. If new evidence changes product intent, compatibility, security,
-   material cost, external effects, or recovery, use the host's native question UI and
-   the decision protocol; do not ask about ordinary reversible details.
-4. Record `implement-slice`, then run focused tests plus the adjacent checks justified
-   by the task risk. Record exact results under `verify-slice`.
-5. Run a task-scoped independent review on specification fidelity and relevant
-   engineering risks. Record `review-slice`. Fix blocking findings and refresh affected
-   evidence.
-6. In direct mode, update the task to `completed` only after verification and review
-   are current. This publishes the durable team ledger checkpoint. Create one
-   authorized local task commit containing code, semantic artifacts, and that
-   checkpoint. Read the resulting `HEAD`, then record it as `completion_commit`;
-   that hash remains checkout-local and must not create another Git commit. Do not
-   push, publish, tag, or deploy unless the user separately authorized that external
-   effect.
+Use `ultra.record` batches for task status, bounded events, artifacts, decisions, and
+documentation candidates. Live ownership, `in_progress`, session ids, leases,
+worktrees, telemetry, and completion hashes remain local runtime state; durable task
+outcome and evidence may enter the team checkpoint.
 
-The tracked team checkpoint contains durable task status and contract evidence, not
-live ownership. `in_progress`, `session_id`, leases, worktrees, telemetry, and
-`completion_commit` remain checkout-local. The local generated task view lives under
-`.ultra/.runtime/projections/` and is never committed.
+Run focused and adjacent risk-justified checks, then a task-scoped independent review.
+Fix blocking findings and refresh affected evidence.
 
-Treat the compiled task-context contract as the handoff boundary: purpose, why,
-constraints, non-goals, target seams/files, pattern refs, acceptance, documentation
-impact, recovery, and definition of drift. If accepted intent, the task contract, or a
-digest-bound reference changes, update the owning authority and recompile rather than
-continuing from a stale packet.
+## Commit one semantic checkpoint
 
-Keep implementation findings and documentation candidates inside the owning Change
-root. When code changes invalidate or extend maintained documentation, update the
-Change documentation overlay and its evidence rather than editing accepted baseline
-specifications. Hooks may remind the host to reconcile documentation; they must not
-block ordinary development or choose the semantic update.
+Call `ultra.checkpoint` once with `stage: dev`, the exact Change/Task scope, evidence,
+and stable idempotency key. It compiles or reuses the implementation Context Manifest
+and validates the durable outcome. A rejection leaves the draft mutable.
 
-Task-level tests and review belong to this inner loop. They do not replace aggregate
-change testing or review when multiple slices, integrations, or broader risks require
-those capabilities.
+After acceptance, mark the task durably completed, publish with `ultra.sync`, and
+create at most one authorized local task commit containing code and semantic
+artifacts. Record its SHA only in local state; never create a bookkeeping commit.
 
-## Complete or recover
+Release the lease through `ultra.session`. Preserve a dirty or unintegrated worktree
+on interruption. Commit, push, tag, publish, deploy, or destructive cleanup require
+separate owner authority.
 
-In direct mode, integrate the task commit through the repository's accepted path,
-verify ancestry and the public seam, close the session, record `record-completion`,
-and complete the dev workflow. If commit creation fails after the pre-commit
-completion checkpoint, move the still-session-owned task to `blocked`, preserve the
-worktree, and record the failure. A completion with a recorded commit remains
-terminal.
-
-Change convergence revalidates the exact latest
-`change_id + task_id + implement + implementation` snapshot for every executable
-task. A newer review, test, or plan packet cannot substitute for it.
-
-In a parent-supervised worker, record completion evidence and exit without closing the
-parent-owned lease. The primary host verifies the exact session commit, performs any
-integration, refreshes review if the reviewed checkout changed, settles the lease, and
-completes the workflow.
-
-Preserve worktrees by default. Remove one only when Git proves it is clean and
-integrated. On interruption, record the current step and task as blocked, preserve
-worktree and evidence, and resume the same run later.
-
-Return outcome, changed paths, public seam, exact checks, review axes, commit and
-session state, residual risk, and allowed transitions.
-
-Never invoke the recommended capability here; wait for an explicit user invocation.
+Return changed paths, public seam, exact checks, review result, checkpoint, commit,
+session state, and residual risk. Do not invoke the next capability automatically.

package/skills/ultra-doctor/SKILL.md

@@ -1,63 +1,41 @@
 ---
 name: ultra-doctor
-description: Diagnose and mechanically recover Ultra schema, workflow, projection, session, archive, hook, and installed-asset faults. Use when authority is degraded, stale, contradictory, or unavailable.
+description: Diagnose and mechanically recover Ultra schema, projection, session, archive, hook, and installed-asset faults. Use when authority is degraded, contradictory, or unavailable.
 ---
 
 # Diagnose before repair
 
-Doctor owns deterministic health and supported recovery. It cannot decide product
-scope, invent evidence, approve a baseline, answer a user decision, or mark semantic
-work complete.
-
-## Read-only diagnosis
-
-Run `system.doctor` without repair and inspect:
-
-- SQLite integrity, schema 20 migration, required tables, and backups;
-- artifact registration, ownership, digest freshness, dependency edges, consumers,
-  and orphan or duplicate authority;
-- baseline and research provenance, gaps, digests, and Git/worktree drift;
-- workflow status, obsolete-step migration, blockers, and output freshness;
-- decisions and checkpoint artifact freshness;
-- Git team-checkpoint schema, ancestry, per-baseline, per-Change, and per-task drift,
-  plus checkout-local baseline revalidation requirements;
-- projection jobs and event cursors;
-- sessions, preserved worktrees, incidents, circuit state, and archive journals;
-- external provider boundaries.
-
-An expected workflow pause or awaiting user decision is a warning, not corruption.
-Missing or changed required evidence is an authority failure but cannot be reconstructed
-by doctor.
-
-## Recovery boundary
-
-With explicit repair authorization, `system.doctor` may:
-
-- apply backup-first supported schema migrations;
-- migrate incompatible rigid workflows into recoverable adaptive state;
-- requeue or regenerate projections from healthy DB authority;
-- reconcile orphan sessions without deleting unrelated or dirty worktrees;
-- resume supported archive journals;
-- recover missing workflow provenance as a blocked run requiring real evidence.
-
-It may not create a Git checkpoint, replace a healthy baseline, accept known failures,
-resolve decisions, regenerate semantic content, import or publish the team checkpoint,
-or edit application code. A missing or drifted valid checkpoint is a warning; invalid
-content or conflicting ancestry is degraded authority. Resolve semantic checkpoint
-state explicitly with `task.ledger_import` or `task.ledger_publish` after reviewing
-the typed conflict.
-
-Corrupt SQLite requires preservation of DB, WAL, and SHM followed by an explicit
-restore-or-rebaseline choice. Missing hook adapters or stale cache paths require
-`ubp --doctor` and adapter reinstall; never patch plugin cache contents by hand.
-A legacy task projection is never rewritten by doctor. The supported publication path
-first proves its durable task fields match SQLite and preserves its original bytes in
-the local runtime backup directory.
-
-After repair, rerun doctor read-only and verify backup paths, schema, installed hashes,
-entry points, MCP startup, and hook smoke tests as applicable.
-
-Return health first, failed checks, mechanical repairs performed, preserved recovery
-paths, unresolved owners, and allowed transitions plus any unique required transition.
-
-Never invoke the recommended capability here; wait for an explicit user invocation.
+Doctor owns deterministic health and supported recovery. It cannot choose product
+scope, invent evidence, accept a baseline, resolve a user decision, or declare
+semantic work complete.
+
+## Diagnose
+
+Call `ultra.doctor { repair: false }` and inspect:
+
+- SQLite integrity, schema, backups, WAL/SHM, and migration state;
+- artifact ownership, digest freshness, edges, orphans, and duplicate authority;
+- team-checkpoint ancestry and real concurrent record conflicts;
+- projection jobs, sessions, leases, worktrees, and recovery journals;
+- installed plugin assets, MCP startup, and hook paths.
+
+An expected workflow pause, editable draft, failed semantic checkpoint, or awaiting
+owner decision is a warning, not corruption.
+
+## Repair
+
+With explicit repair authority, call `ultra.doctor { repair: true }`. It may apply
+backup-first schema migration, regenerate local projections, recover supported
+journals, reconcile orphan sessions, and repair installed mechanical assets.
+
+It may not manufacture semantic evidence, import or publish a team checkpoint, replace
+a healthy baseline, resolve decisions, edit application code, or force a draft to
+accepted. Use `ultra.sync` for reviewed checkpoint import/publish and
+`workflow.abandon` through `ultra.record` for intentional draft cancellation.
+
+Preserve corrupt DB/WAL/SHM and dirty worktrees. Never patch plugin cache files by
+hand; reinstall through `ubp` and verify the installed manifest and hook targets.
+
+Rerun doctor read-only after repair. Report health, exact failed checks, backups,
+repairs, preserved recovery paths, and remaining owner or semantic work. Do not invoke
+another capability automatically.

package/skills/ultra-init/SKILL.md

@@ -1,94 +1,53 @@
 ---
 name: ultra-init
-description: Create or recover Ultra project authority for a new repository, an existing codebase, or an older Ultra installation. Use when `.ultra` is absent, initialization is incomplete, or doctor reports a migration or initialization fault.
+description: Create or recover Ultra project authority for a new repository, an existing codebase, or an older Ultra installation. Use when `.ultra` is absent, initialization is incomplete, or doctor reports a migration fault.
 ---
 
 # Initialize project authority
 
-Initialization is a bounded setup capability. It creates or repairs the repository and
-Ultra authority; it does not perform product research, approve a baseline, or choose
-the next semantic workflow.
+Initialization creates the repository-local Ultra authority. It does not perform
+research, accept a product baseline, choose a Change, or start another public
+capability.
 
-## Inspect before mutation
+## Inspect and align
 
-1. Identify the repository root, existing `.ultra` state, Git state, meaningful source,
-   monorepo boundaries, and current owner request.
-2. If `.ultra/.runtime/state.db` exists, run `system.doctor` read-only and resume with
-   `task.init_project` only when its report permits it.
-3. Read the Git-facing team checkpoint when present. Never parse a legacy
-   `.ultra/tasks/tasks.json` as current authority or edit it directly.
-4. Otherwise call `task.init_project` with `mode: "auto"`, the project name, and an
-   explicit scope only when the repository contains multiple plausible roots.
-5. Leave `git_mode` as `auto` unless the user explicitly requires a non-Git workspace.
+1. Inspect the repository root, Git state, meaningful source, existing `.ultra`,
+   monorepo boundaries, and the current request.
+2. When authority already exists, call `ultra.doctor { repair: false }` and preserve
+   healthy state. Never replace or delete it merely to obtain a clean init.
+3. Classify the repository from evidence:
+   - `greenfield`: no meaningful delivered behavior exists;
+   - `brownfield`: source, runtime, API, data, deployment, or tests describe an
+     existing maintained system;
+   - `migrated`: older Ultra authority was preserved but is not yet a trusted baseline.
+4. Ask the owner only when scope, healthy-authority replacement, destructive recovery,
+   or another material choice cannot be derived. Reuse explicit intent.
 
-Use repository evidence to classify:
+Read `../ultra-think/references/decision-dialogue.md` before asking a material
+question.
 
-- `greenfield`: no meaningful delivered application behavior is present;
-- `brownfield`: source, runtime, API, data, deployment, or tests describe an existing
-  maintained system;
-- `migrated`: older Ultra authority was preserved but is not a trusted baseline.
+## Initialize once
 
-The model may override an automatic classification only with evidence or an explicit
-user decision. Classification must not infer product scope, an MVP, or a release plan.
+Call `ultra.record` with one entry:
 
-## Interaction boundary
+```text
+operation: task.init_project
+data: target_dir, project_name, mode=auto, git_mode=auto, optional scope
+idempotency_key: stable init attempt id
+```
 
-Read `../ultra-think/references/decision-dialogue.md` before asking a material question.
-Inspect observable facts yourself. Use the host's native question UI when available and
-plain direct interaction otherwise. Ask only when repository scope, replacement of
-healthy authority, destructive recovery, or another material owner decision is truly
-unresolved. Normalize clear intent already present in the request without asking again.
+This stateless bootstrap is the only `ultra.record` operation allowed before
+`state.db` exists. It must create or migrate `.ultra/.runtime/state.db`, preserve
+existing artifacts and Git history, install only missing scaffold assets on resume,
+validate or safely upgrade a legacy task ledger, and read back the result.
 
-## Deterministic initialization contract
+An unborn Git repository may require a local initial commit, but init never creates a
+remote, tag, push, publish, or deployment. Corrupt DB/WAL/SHM and backups remain
+preserved until an explicit recovery choice is made.
 
-`task.init_project` owns these steps:
+## Return control
 
-1. `inspect-authority`
-2. `classify-repository`
-3. `scaffold-authority`
-4. `verify-initialization`
-
-The operation must:
-
-- create or migrate `.ultra/.runtime/state.db` with a backup before schema migration;
-- install only missing scaffold assets on resume;
-- create an empty `.ultra/tasks/tasks.json` team checkpoint for a new project;
-- import a validated team checkpoint on clone or resume, while requiring
-  checkout-local revalidation before an imported ready baseline can authorize work;
-- preserve existing artifacts and unrelated work;
-- preserve an existing Git repository and HEAD;
-- initialize Git and a safe `.gitignore` entry when Git is absent;
-- report an unborn repository as `initial_commit_required` without manufacturing a
-  commit, remote, tag, or push;
-- read back the created DB, classification, local runtime projection, team checkpoint,
-  and Git result before completing the init workflow.
-
-Projection-only projects must use the exact backup-first migration command returned by
-the runtime. On the first supported team-checkpoint publication, a matching legacy
-task projection is copied byte-for-byte into `.ultra/.runtime/backups/task-ledger/`
-before replacement; any task-id or durable-field mismatch stops with a typed conflict.
-A migrated compatibility baseline requires a new brownfield adoption with
-`replace_migrated: true`. Replacing a healthy baseline requires explicit replacement
-authority. Corrupt DB, WAL, SHM, and backups must be preserved until the user chooses
-a documented recovery operation.
-
-## Completion and handoff
-
-Initialization is complete when the init workflow is `completed`, the current schema is
-healthy, the scaffold is readable, and repository classification and Git state are
-durable. Research status may still be `not_started`; that is not incomplete init.
-
-Read the returned `allowed_transitions` and `required_transition`:
-
-- a required transition represents a hard recovery invariant and must be followed;
-- otherwise the host model recommends among the allowed capabilities using the user's
-  goal and current evidence;
-- never invoke another public Ultra workflow automatically; recommend the best allowed
-  capability and wait for an explicit user invocation.
-
-Report classification, scope, schema and backup result, Git state, init workflow id,
-team-checkpoint import or revalidation state, baseline state, and allowed transitions.
-Do not claim that a baseline is ready until a separate research/adoption workflow has
-recorded and converged it in the current checkout.
-
-Never invoke the recommended capability here; wait for an explicit user invocation.
+Report classification, scope, schema and backup result, Git state, imported team
+checkpoint state, and any mechanical blocker. Recommend the next useful capability
+from current evidence, usually `ultra-research`, `ultra-change`, `ultra-status`, or
+`ultra-doctor`; do not invoke it automatically.

package/skills/ultra-plan/SKILL.md

@@ -5,135 +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, `task.ledger_get`, baseline, change, breadcrumb `accepted_intent`,
-   decisions, existing plan runs, tasks, and current checkout. If a new Git checkpoint
-   arrived after this MCP process started, call `task.ledger_import` before planning.
-   Stop on a typed baseline, Change, task, ancestry, or active-session conflict; never
-   choose one side by editing the ledger.
-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 the MCP-published Git team checkpoint, while
-`.ultra/.runtime/projections/tasks.json` is the generated checkout-local view.
-
-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.
-An accepted export also publishes the portable baseline, Change, task contracts,
-dependencies, and durable statuses to the team checkpoint. Local sessions, leases,
-`in_progress` ownership, telemetry, and completion hashes remain in `.ultra/.runtime`.
-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.