@zq-silk/yui 0.8.9 → 0.10.0

package/ARCHITECTURE.md

@@ -5,31 +5,32 @@ runtimes. The user talks to one Operator. The Operator routes each request to
 the right Project and Task; that Task's Leader owns decomposition, execution
 choice, review, integration, and completion.
 
-## One outcome model, two delivery paths
-
-`Task` is the bounded user outcome. Its delivery path is derived from existing
-fields rather than stored as another state machine: no Project bindings means
-`no-project`; a Project-backed Task without `requireIntegration` is `direct`;
-and `requireIntegration=true` is `integrated`.
-
-Direct delivery lets the Leader implement and verify a low-risk result in the
-managed Task main without creating a WorkItem. Integrated delivery uses
-`WorkItem` as its only bounded execution unit; it holds the objective,
-acceptance criteria, dependencies, assigned Task Role when applicable,
-lifecycle, and compact reviewed result.
-
-For each integrated WorkItem, a Leader chooses one of three execution paths:
-
-1. **Direct**: the Leader executes a roleless WorkItem.
-2. **Native subagent**: the Leader creates a child through its current Agent
-   conversation. The child inherits the Leader Agent and is not a Yui entity.
-3. **Task Role AgentRun**: Yui dispatches a Role-bound WorkItem to a
-   Task-managed native Agent Session.
-
-There is no Yui subagent launcher or child-session record. A native child on
-direct delivery remains inside the Leader Session and Task-main boundary; a
-native child implementing integrated work uses the WorkItem lifecycle. Managed
-independent execution additionally records an AgentRun.
+## One outcome, Leader-chosen execution topology
+
+`Task` is the bounded user outcome. Its optional `type` describes intent, not
+execution topology; software Projects normally use `feature` or `bugfix`, while
+other Projects may define their own types. Yui does not store a direct versus
+integrated delivery mode.
+
+A software bugfix is Leader-owned: the Leader implements and verifies it in the
+managed Task main without manufacturing a WorkItem. If the scope proves to need
+independent delivery owners, reclassify it as a feature before creating those
+units. For a feature, the Leader judges whether the whole result is small
+enough to own in the same way or large enough to need independently owned
+delivery units.
+
+`WorkItem` means one substantial, independently acceptable requirement with a
+clear owner. Create multiple WorkItems only when multiple Workers can own and
+advance those requirements independently, normally in parallel. Internal
+implementation steps, test runs, review findings, and local fixes remain Run,
+Event, report, or commit evidence under the existing Task or WorkItem; they are
+not new WorkItems.
+
+Each WorkItem may use a native subagent inside the Leader conversation or a
+Task Role AgentRun backed by a durable Worker Session. There is no Yui
+subagent launcher or child-session record. AgentRun is an execution attempt,
+not a requirement, and repeated Runs may continue the same compatible Role
+Session.
 
 ## Profiles, Roles, and Agents
 
@@ -49,8 +50,10 @@ independent execution additionally records an AgentRun.
 - A `WorkItemCandidate` is the explicit result currently awaiting Leader
   acceptance. It snapshots the WorkItem revision, summary, and either a
   yielded execution Run or a Leader-managed direct source.
-- `ReviewRound` records review of one candidate under the same WorkItem and
-  references that immutable candidate. It is not another WorkItem.
+- `ReviewRound` records one semantic judgment. A WorkItem Review references
+  that WorkItem's immutable Candidate. A Task-final Review references the
+  frozen Task heads directly and has no synthetic WorkItem/Candidate anchor.
+  It is never another WorkItem.
 
 Adding another Agent requires an explicit adapter implementation. Profiles do
 not choose adapters, own Sessions, or carry credentials.
@@ -65,7 +68,7 @@ effort, round, result, and checks.
 
 ## Lifecycle and acceptance
 
-Integrated Leader-direct and native-subagent WorkItem execution follows:
+Native-subagent WorkItem execution follows:
 
 ```text
 todo -> running -> done | failed
@@ -92,16 +95,12 @@ Every result awaiting acceptance is stored as an explicit WorkItem candidate.
 `always` dispatches a review AgentRun for every candidate, whether it comes
 from a yielded execution Run or a Leader-managed direct result; `leader`
 leaves every candidate for the Leader to accept directly or review explicitly.
-`final` applies automatically only to integrated delivery: it keeps WorkItem
-acceptance and Integration independent, then `task complete` queues one fresh
-Task-scoped ReviewRound over the frozen committed heads of every bound Project.
-A direct Task may use a bounded native review. When a managed final Review is
-required, it must be promoted before Task main advances; promotion fails after
-a commit or delivery evidence exists so earlier work cannot lose ChangeSet
-provenance.
-Any established immutable Task-final contract or Round remains an obligation.
-A changed integrated head queues a new round; the previous report remains
-evidence. This final Reviewer evaluates the whole
+`final` keeps WorkItem acceptance and Integration independent and supplies the
+default Reviewer Role when the Leader decides the frozen Task result warrants
+an independent final Review. An immutable Task-final contract can require that
+Review. A Leader-requested Round remains evidence without becoming policy: a
+later Task head does not require another Round unless the Leader requests one
+or an explicit Task contract requires it. This final Reviewer evaluates the whole
 Task, so normal delivery does not pay for a complete review of every WorkItem.
 Review Runs complete only their exact ReviewRound, leave the WorkItem awaiting
 acceptance, and never trigger another review or append a Candidate. Successful
@@ -114,9 +113,12 @@ never merges it automatically.
 Roles describe Agent capability, but they do not own repository workspaces. A
 `ManagedWorkspace` is keyed by its durable owner (`Task`, `WorkItem`,
 `ReviewRound`, or `IntegrationAttempt`); an AgentRun carries only a launch
-snapshot. Review workspaces are fresh writable copies at the Candidate's
-frozen commit, so diagnostics cannot redirect Develop or become a ChangeSet
-source. Each ReviewRound has an independent lifecycle and explicit cleanup.
+snapshot. Review workspaces are writable copies at the frozen commit, so
+diagnostics cannot redirect Develop or become a ChangeSet source. Task-final
+Rounds keep independent immutable records but may reassign one clean physical
+workspace to the next Round for the same Reviewer Role. This lets the native
+Reviewer Session continue while every Run remains bound to its exact Round and
+head.
 
 Dependencies are enforced at dispatch. A Role cannot have overlapping active
 Runs, and terminal Task state fences new messages, dispatches, retries, and
@@ -147,8 +149,8 @@ Projects and Task-main context for the rest. The managed dispatch and
 writable set. Provider permission is binding configuration: every managed Role
 defaults to `bypass`, while `default` and `configured` preserve provider-native
 behavior. Provider permission and Profile access intent do not grant Project
-writes. A direct source write requires the exact Leader Task-main owner. An
-integrated source write requires an exact WorkItem write scope and matching
+writes. A Leader-owned source write requires the exact Task-main owner. A
+WorkItem source write requires an exact WorkItem write scope and matching
 managed workspace; a review write instead
 requires an exact ReviewRound owner and frozen Candidate base. Profiles and
 Skills constrain behavior even when provider prompts are bypassed. Provider
@@ -185,9 +187,9 @@ independently acceptable ownership.
 
 Capture at the same HEAD reuses the existing ChangeSet. A repaired HEAD creates
 a new candidate; only the latest reviewed candidate may satisfy acceptance.
-An isolated WorkItem cannot be accepted, or an integrated Task completed, while
-any writable Project's latest result is uncaptured or unintegrated. Direct
-completion instead requires a clean committed exact Task-main snapshot.
+An isolated WorkItem cannot be accepted, or a Task with WorkItems completed,
+while any writable Project's latest result is uncaptured or unintegrated.
+Leader-owned completion instead requires a clean committed exact Task-main snapshot.
 Workspace roots are
 multi-Project; ChangeSets and Integration Attempts remain single-Project Git
 boundaries.

package/README.md

@@ -144,6 +144,21 @@ Input by itself do not block. A blocker reports the total and exact available
 Task/Role/Run/native-session/launch identities and reason, leaves the scene
 unchanged, and tells the user to re-run `yui update` after the listed work clears;
 it never kills, resets, rebinds, retries, or drains on the user's behalf.
+After every listed Turn or Run finishes, the user can stop all idle managed
+Sessions from a normal shell and retry the update:
+
+```sh
+yui session stop --all
+yui update
+```
+
+`session stop --all` first checks every current Session and refuses without
+stopping anything while any Session still has a running Turn/Run or pending
+lifecycle work. Once clear, it fences new Leader dispatch, stops and drains the
+Controller, rechecks the runtime facts, then stops every exact idle Session. The
+Controller remains stopped so `yui update` can enter its offline window. When the
+installed version predates this command, exit every listed managed Session
+manually instead; a staged new CLI cannot write the older migration-required Home.
 
 Only that user re-run may enter the existing full migration. Once its preflight
 is clear, the update parent captures and stops the exact old Controller PID. The
@@ -250,8 +265,8 @@ yui project update app --alias app-cli
 yui project refresh app
 yui project list
 
-yui task create "Fix CSV escaping" --project app --delivery direct
-yui task create "Ship CSV export" --project app --delivery integrated
+yui task create "Fix CSV escaping" --project app --type bugfix
+yui task create "Ship CSV export" --project app --type feature
 yui task update <task-id> --priority high --tags release,csv --due-at 2026-08-01T00:00:00Z
 yui task update <task-id> --clear-priority --clear-tags --clear-due-at
 yui task show <task-id>
@@ -259,18 +274,18 @@ yui task context <task-id>
 yui task activate <task-id>
 ```
 
-Project delivery is explicit but uses the existing Task schema. `direct` means
-the Leader implements and verifies one low-risk result on clean committed Task
-main; it needs no WorkItem, IntegrationAttempt, or policy-created final
-ReviewRound. `integrated` requires WorkItem, ChangeSet, and committed Integration
-evidence and remains the path for guarded, cross-Project, migration,
-authorization, concurrency/recovery, destructive, and release changes. Global
-final-review policy applies automatically only to integrated delivery. A direct
-Task can use a bounded native review. If an independently managed final Review
-is required, promote before Task main advances; promotion fails closed after a
-commit or delivery evidence exists so earlier work cannot lose ChangeSet
-provenance. Legacy `--require-integration` is an alias for
-`--delivery integrated`, and integrated delivery cannot be downgraded.
+Task type describes intent rather than selecting an execution protocol.
+Software Projects use `bugfix` or `feature`: a bugfix is Leader-owned; if it
+grows into independently owned delivery requirements, reclassify it as a
+feature before creating WorkItems. The Leader decides whether a feature is
+small enough to deliver on Task main or large enough for independently owned WorkItems. A WorkItem is
+one substantial requirement for one Worker, not a development step, test run,
+review finding, or local fix. Multiple WorkItems are useful only when distinct
+Workers can advance meaningful requirements independently. A WorkItem's
+governing Candidate defines its delivery obligation: its current ChangeSets
+must reach committed Integration or an explicit superseded queue disposition
+before Task-final Review or completion. Older Candidate and ChangeSet records
+remain audit evidence without keeping the Task open.
 
 `project refresh` is the explicit network operation for a stable Project checkout. It fetches the
 configured stable branch directly from the Project remote URL and advances only through a clean,
@@ -313,9 +328,9 @@ yui config show
 yui config workflow clear review
 ```
 
-For Project-backed software delivery, use `--trigger final` to keep WorkItem
-acceptance and Integration independent and run one fresh ReviewRound over the
-complete frozen integrated Task candidate before completion:
+For Project-backed software delivery, use `--trigger final` to supply the
+default Reviewer Role when the Leader decides the complete frozen Task result
+needs an independent Review:
 
 ```sh
 yui config workflow set review --role reviewer --trigger final
@@ -330,10 +345,13 @@ or a Leader-managed direct result; `leader` leaves the candidate awaiting
 acceptance so the Leader can accept it directly or run
 `yui task work review <task-id>/<work-item-id>`. A configured review rule therefore keeps
 Leader-managed candidates awaiting a decision instead of marking them done.
-`final` does not create WorkItem ReviewRounds; `task complete` queues one
-Task-scoped ReviewRound after every bound Project has a committed Integration,
-and re-queues a new round only when those frozen heads change. The final
-Reviewer follows Project Policy/Knowledge and reports reachable, material,
+`final` does not create WorkItem ReviewRounds or decide Task topology. The
+Leader explicitly requests a Task-scoped Review, unless an immutable Task
+contract requires one. The Round freezes Task main directly, so even a
+Leader-owned Task with no WorkItem can be reviewed. A changed frozen head needs
+a new semantic Round; the same compatible Reviewer Session may continue in its
+stable workspace, while every Run remains bound to its exact Round and head.
+The Reviewer follows Project Policy/Knowledge and reports reachable, material,
 actionable findings across the complete Task.
 A ReviewRound freezes the Candidate's exact Git commit and creates a fresh,
 ReviewRound-owned writable worktree on a unique branch. Its AgentRun may edit,
@@ -385,7 +403,7 @@ expands:
 yui task create "Update authentication" \
   --project backend --project frontend \
   --base backend=develop --base frontend=main \
-  --delivery integrated
+  --type feature
 yui task project add <task-id> shared-sdk --base main
 ```
 
@@ -401,7 +419,9 @@ yui task base status <task-id> --refresh
 The default check is offline and uses local remote-tracking refs. `--refresh`
 is the explicit authorization to query the configured remote; Yui never
 fetches, rebases, merges, or force-pushes as a hidden side effect of Task
-completion.
+completion. Behind, diverged, or unavailable remote state is reported as
+delivery-risk evidence for the Leader; it does not replace the Leader's choice
+of delivery base. A dirty Task workspace remains a completion blocker.
 
 Implementation WorkItems declare the Projects they may modify. Their workspace
 keeps the same relative layout, creates isolated worktrees only for that write
@@ -565,15 +585,15 @@ bounded next options. Yield records immutable Run/Candidate or Review evidence
 only; it does not imply acceptance, WorkItem completion, ChangeSet capture,
 Integration, or Task completion.
 
-For integrated bounded work, the Leader owns one roleless WorkItem and may
-execute it directly or create a native subagent through the current Agent
-conversation. Direct delivery operates on Task main without creating this
-WorkItem:
+For one substantial feature requirement, the Leader may create a WorkItem and
+give it to a native subagent or Task Role Worker. A small Task or bugfix stays
+on Task main. Do not create a WorkItem merely to record implementation steps,
+tests, review, or follow-up fixes:
 
 ```sh
-yui task work create <task-id> "Review the implementation" \
-  --objective "Return source-backed findings" \
-  --accept "Every finding identifies an affected path"
+yui task work create <task-id> "Implement the export API" \
+  --objective "Deliver the independently acceptable export API requirement" \
+  --accept "The API contract and focused validation are complete"
 yui task work update <task-id>/<work-item-id> running
 yui config profile show reviewer
 ```
@@ -703,17 +723,18 @@ yui task complete <task-id> --summary-file delivery.txt \
   --accept-published-tree <publication-id>
 ```
 
-This does not weaken normal freshness checks. Yui requires the current,
+This is an independent exact-tree authorization. Yui requires the current,
 unsuperseded Publication to be merged and verified, its local commit to equal
 the physical Task head, its remote commit to be ancestry-divergent, and both
-commits to resolve to the same exact tree. Integrated delivery also requires
-the latest completed Task-final Review; direct delivery does not invent one.
+commits to resolve to the same exact tree. When a Task-final Review obligation
+exists, completion also requires the latest semantic Round to attest the
+accepted Task head; otherwise completion does not invent a ReviewRound.
 `--refresh-remote` fetches
 the remote object graph before resolving that Publication commit. For a Task
-governed by a durable exact final-review contract, the user/Operator command
-persists the exact authorization tuple and wakes the Task Leader; only that
-contract-capable Leader may consume it and complete the Task. Tasks without
-that contract retain the one-step explicit completion path. The Task event
+governed by a durable final-review contract, the stored contract continues to
+require its Reviewer policy, but compatible CLI and Controller updates do not
+need to reproduce its historical control-plane digest. Tasks without that
+contract retain the one-step explicit completion path. The Task event
 audit records the authorization and, on completion, the accepted Project,
 Publication, optional ReviewRound, both commits, and tree.
 
@@ -762,14 +783,22 @@ Global Operator and global Role sessions remain native interactive CLIs:
 yui session enter <global-role>
 ```
 
+An offline Home migration requires a short maintenance window with no managed
+Agent Session running. Once current Turns and Runs have finished, use
+`yui session stop --all` from a normal shell. The command stops Task and global
+Role Sessions only after every one is idle, and leaves all Sessions untouched
+when any Role is still busy. On success it also leaves the Controller stopped;
+run `yui update` next rather than resuming ordinary Task work.
+
 tmux fixes a pane's history capacity when that pane is created. Existing panes
 retain their configured capacity; managed runtime output remains observable in
 the Agent Host pane without becoming lifecycle or acknowledgement evidence.
 
-Each Role, including a Task-bound Worker instance, can bind multiple configured Agents, has one active Agent, and keeps
-a separate native session per Agent binding. Operator narrows this to at most
-one Agent per adapter—for example, one Codex and one Claude—so its bindings are
-ready-to-switch configurations rather than parallel identities. Operator can
+Each Role, including Operator and a Task-bound Worker instance, can bind multiple
+configured Agents, has one active Agent, and keeps a separate native session per
+Agent binding. Multiple bindings may use the same adapter for different accounts,
+models, profiles, or environment sources. They are ready-to-switch configurations,
+not parallel writers: the active binding remains the unique authority. Operator can
 keep multiple conversations for each binding. `operator new` and
 `operator resume` reuse the single Operator tmux pane: when a process is
 running, Yui asks before stopping it and switching the conversation. On a
@@ -811,7 +840,7 @@ movement cannot conceal a workflow that is not advancing.
 
 Stable Role context is also launch metadata, never a bootstrap turn. Yui passes Role policy and `systemPrompt` through the Agent's native system/developer-instruction channel. Task execution Runs receive the generic Leader or Worker Skill, while review Runs receive the generic Reviewer Skill based on durable Run purpose rather than a configured Role name. These Yui-owned Role Skills define portable orchestration only. Project Skills remain ordinary versioned files in the Project and are discovered, selected, and loaded by the Agent through its native project mechanism; Yui does not scan, parse, copy, or inject them.
 
-Native Codex developer instructions carry compact absolute references only for Yui-owned Role Skills, which Codex reads on demand. Because `developer_instructions` is one scalar setting, Yui inspects every supported Linux Codex layer—`/etc/codex/config.toml`, the user config, the selected `$CODEX_HOME/<name>.config.toml`, project configs, and `/etc/codex/managed_config.toml`—and refuses to replace a value found in any of them. Codex sessions opened without a managed Run use Yui's structured `notify` callback for session presentation and therefore require exclusive ownership of that setting. Managed Runs instead use invocation-local Agent Driver Hooks as their sole lifecycle authority. `skills.config` is not misused because it only enables or disables already-discovered Skills. Claude receives the same Yui-owned Role Skill content from a private `0600` managed context file rather than a large or sensitive argv value; retries and resumes reuse the purpose-specific Role path. Non-Operator global Roles stay neutral and receive no Task orchestration Skill. Operator therefore opens at an empty native composer, so the user's text remains its first user message. Leader wakeups and Worker or Reviewer Run assignments remain real mailbox-delivered work messages. An adapter without a native instruction channel must reject this context rather than silently converting it into a first user prompt.
+Native Codex developer instructions carry compact absolute references only for Yui-owned Role Skills, which Codex reads on demand. Yui applies this scalar as an invocation-local override, so existing user, profile, project, and system values do not make the Session unusable and the underlying config file is never mutated. A higher-precedence managed `developer_instructions` value remains a bounded launch blocker because Codex will not let invocation flags replace it. Interactive Codex Sessions apply the same rule to Yui's structured `notify` callback; Doctor reports ordinary overridden sources as context and rejects an effective managed conflict. Managed Runs instead use invocation-local Agent Driver Hooks as their sole lifecycle authority and do not claim `notify`. `skills.config` is not misused because it only enables or disables already-discovered Skills. Claude receives the same Yui-owned Role Skill content from a private `0600` managed context file rather than a large or sensitive argv value; retries and resumes reuse the purpose-specific Role path. Non-Operator global Roles stay neutral and receive no Task orchestration Skill. Operator therefore opens at an empty native composer, so the user's text remains its first user message. Leader wakeups and Worker or Reviewer Run assignments remain real mailbox-delivered work messages. An adapter without a native instruction channel must reject this context rather than silently converting it into a first user prompt.
 
 ## Controller and failure handling
 
@@ -927,6 +956,7 @@ yui config role add|list|show|update|remove|bind|unbind
 yui config profile add|list|show|update|remove|reset
 yui config completion [bash|zsh|fish]
 yui session enter|record|replace|reconcile
+yui session stop --all
 yui project add|clone|refresh|update|discover|list|show|knowledge
 ```
 

package/dist/cli/commandCatalog.js

@@ -199,6 +199,12 @@ const globalSessionChildren = [
         usage: "yui session replace <role> --native-id <id> --reason <text>",
         options: ["--native-id", "--reason"]
     },
+    {
+        name: "stop",
+        summary: "Stop all idle managed Sessions and the Controller before an offline update.",
+        usage: "yui session stop --all",
+        options: ["--all"]
+    },
     {
         name: "reconcile",
         summary: "Reconcile durable Session owners with native sessions.",
@@ -241,9 +247,9 @@ const taskChildren = [
     {
         name: "create",
         summary: "Create a Draft Task.",
-        usage: "yui task create <title> [--project <project> ...] [--base <project>=<ref> ...] [--delivery <direct|integrated>] [--require-integration]",
-        options: ["--project", "--base", "--delivery", "--require-integration"],
-        optionValues: { "--delivery": ["direct", "integrated"] }
+        usage: "yui task create <title> [--type <project-defined-type>] [--project <project> ...] [--base <project>=<ref> ...]",
+        options: ["--type", "--project", "--base"],
+        optionValues: { "--type": ["feature", "bugfix"] }
     },
     {
         name: "project",
@@ -266,15 +272,15 @@ const taskChildren = [
     {
         name: "update",
         summary: "Update Task metadata.",
-        usage: "yui task update <id> [--title <text>] [--description <text>|--clear-description] [--priority <low|medium|high|urgent>|--clear-priority] [--tags <comma-separated>|--clear-tags] [--due-at <RFC3339>|--clear-due-at] [--delivery <direct|integrated>] [--require-integration]",
+        usage: "yui task update <id> [--title <text>] [--type <project-defined-type>|--clear-type] [--description <text>|--clear-description] [--priority <low|medium|high|urgent>|--clear-priority] [--tags <comma-separated>|--clear-tags] [--due-at <RFC3339>|--clear-due-at]",
         options: [
-            "--title", "--description", "--priority", "--tags", "--due-at",
+            "--title", "--type", "--description", "--priority", "--tags", "--due-at",
+            "--clear-type",
             "--clear-description", "--clear-priority", "--clear-tags", "--clear-due-at",
-            "--delivery", "--require-integration"
         ],
         optionValues: {
             "--priority": ["low", "medium", "high", "urgent"],
-            "--delivery": ["direct", "integrated"]
+            "--type": ["feature", "bugfix"]
         }
     },
     { name: "activate", summary: "Activate a Draft Task.", usage: "yui task activate <id>" },
@@ -1357,14 +1363,16 @@ export const ROOT_COMMAND = buildNode({
         },
         {
             name: "session",
-            summary: "Load and enter global Role sessions, and reconcile their durable identities.",
+            summary: "Enter, stop, and reconcile managed Role sessions.",
             examples: [
                 "yui session context operator --json",
                 "yui session enter operator",
+                "yui session stop --all",
                 "yui session reconcile --report"
             ],
             sections: [
                 { id: "global", title: "Global Role sessions", entries: ["context", "enter", "record", "replace"] },
+                { id: "maintenance", title: "Maintenance", entries: ["stop"] },
                 { id: "recovery", title: "Recovery", entries: ["reconcile"] }
             ],
             children: globalSessionChildren

package/dist/cli.js

@@ -28,7 +28,7 @@ import { CONFIG_DOMAINS } from "./config/configCatalog.js";
 import { runConfigOverview } from "./commands/configOverview.js";
 import { parseControllerCleanupOptions, parseControllerStatusOptions, parseControllerRuntimeSnapshot, renderControllerResourceStatus, renderRuntimeIdentitySection, summarizeDurablePhysicalMismatch, runInteractiveControllerCleanup } from "./commands/controllerCommands.js";
 import { parseExecutionAuditOptions, runExecutionAuditCommand } from "./commands/executionAuditCommands.js";
-import { parseSessionReconcileOptions, runSessionReconcileCommand } from "./commands/sessionCommands.js";
+import { parseSessionReconcileOptions, parseSessionStopOptions, runSessionReconcileCommand, runSessionStopCommand } from "./commands/sessionCommands.js";
 import { SessionOwnerReconciliation } from "./controller/sessionOwnerReconciliation.js";
 import { runJobCommand } from "./commands/jobCommands.js";
 import { runDurableJobCommand } from "./commands/durableJobCommands.js";
@@ -667,6 +667,31 @@ export async function main() {
         return;
     }
     if (resolved[0] === "session") {
+        if (resolved[1] === "stop") {
+            const options = parseSessionStopOptions(resolved.slice(2));
+            const result = await runSessionStopCommand({
+                options,
+                runtime: {
+                    beginMaintenance: () => acquireHandoverLock(home),
+                    snapshot: () => ({
+                        candidates: schedulerStore.listRuntimeSessionCandidates(),
+                        dormant: schedulerStore.listDormantRuntimeOwners()
+                    }),
+                    drainController: () => runtime.drainController(),
+                    stopController: () => stopFileTaskController(home, {
+                        environment: process.env
+                    }),
+                    startController: async () => {
+                        await ensureFileTaskController(home, { environment: process.env });
+                    },
+                    stopDormantSession: (candidate) => runtime.stopDormantSession(candidate)
+                },
+                environment: process.env
+            });
+            process.exitCode = result.exitCode;
+            emit(result.output, false, result.data);
+            return;
+        }
         const roleOptions = {
             yuiHome: home,
             env: process.env,
@@ -1844,36 +1869,6 @@ async function prepareReviewLaneWorkspaces(taskId, reviewRoundId, store, prepare
     return map;
 }
 async function directTaskMainSnapshotForTaskCommand(args, store, preparer, environment, taskFinalReviewContract) {
-    const deliveryOption = args.indexOf("--delivery", 3);
-    const deliveryPromotion = args[0] === "task"
-        && args[1] === "update"
-        && args[2] !== undefined
-        && (args.includes("--require-integration", 3)
-            || (deliveryOption >= 0 && args[deliveryOption + 1] === "integrated"));
-    if (deliveryPromotion) {
-        const task = store.getTask(args[2]);
-        if (task === null
-            || (task.status !== "active" && task.status !== "draft")
-            || task.requireIntegration === true
-            || task.projectBindings.length === 0) {
-            return undefined;
-        }
-        const workspace = store.getTaskWorkspace(task.id);
-        if (task.status === "draft" && workspace === null)
-            return undefined;
-        if (workspace === null
-            || workspace.owner.type !== "task"
-            || workspace.owner.taskId !== task.id) {
-            throw usageError(`Task has no authoritative main workspace: ${task.id}.`);
-        }
-        try {
-            return await preparer.snapshotDirectTaskMain(workspace, task.projectBindings.map(({ projectId }) => projectId));
-        }
-        catch (error) {
-            throw usageError(`Delivery promotion Task-main verification failed for ${task.id}: `
-                + `${error instanceof Error ? error.message : String(error)}`);
-        }
-    }
     if (taskFinalReviewContract === undefined
         || args[0] !== "task"
         || args[1] !== "work"
@@ -1913,7 +1908,7 @@ async function actualTaskReviewCandidateForTaskCommand(args, store, preparer, en
         if (task === null || task.status !== "active" || task.projectBindings.length === 0) {
             return undefined;
         }
-        // Every Project-backed completion, including direct delivery, must freeze
+        // Every Project-backed completion must freeze
         // a clean committed Task-main snapshot. Review policy only decides whether
         // that head also needs an independent ReviewRound.
         taskId = task.id;

package/dist/commands/executionAuditCommands.js

@@ -219,7 +219,7 @@ export function renderExecutionAudit(report, width = defaultTableWidth()) {
         if (orchestration.tasks.length > 0) {
             lines.push(renderTable("Task orchestration metrics", [
                 { header: "Task", minWidth: 7, maxWidth: 14 },
-                { header: "Delivery", minWidth: 8, maxWidth: 10 },
+                { header: "Type", minWidth: 8, maxWidth: 12 },
                 { header: "Runs", minWidth: 4, maxWidth: 6 },
                 { header: "WIs", minWidth: 3, maxWidth: 5 },
                 { header: "Review F/D/N", minWidth: 12, maxWidth: 16 },
@@ -229,7 +229,7 @@ export function renderExecutionAudit(report, width = defaultTableWidth()) {
                 { header: "Advice", minWidth: 6, maxWidth: 8 }
             ], orchestration.tasks.map((task) => [
                 task.taskId,
-                task.deliveryPath,
+                task.taskType ?? "unspecified",
                 String(task.runs.total),
                 String(task.workItems),
                 `${task.reviews.full}/${task.reviews.delta}/${task.reviews.nonSemantic}`,

package/dist/commands/globalRoleCommands.js

@@ -198,7 +198,6 @@ function updateRole(args, store, options) {
         if (changesAgentConfig) {
             const agentId = parsed.one("--agent")?.trim() || role.activeAgentId;
             const agent = requireAgent(agentId, tx);
-            assertOperatorAdapterAvailable(role, agent);
             const binding = role.agentBindings[agentId] ?? createRoleAgentBinding(definition(agent));
             bindings = { ...role.agentBindings, [agentId]: patchRoleAgentBinding(binding, parsed) };
         }
@@ -231,7 +230,6 @@ function bindRole(args, store) {
             roleName: role.name
         }, "desired Agent binding update");
         const agent = requireAgent(agentId, tx);
-        assertOperatorAdapterAvailable(role, agent);
         const binding = role.agentBindings[agentId] ?? createRoleAgentBinding(definition(agent));
         const withBinding = updateGlobalRole(role, {
             agentBindings: { ...role.agentBindings, [agentId]: binding }
@@ -260,16 +258,6 @@ function bindRole(args, store) {
     });
     return presentRole(result.message, result.role, store);
 }
-function assertOperatorAdapterAvailable(role, agent) {
-    if (role.name !== "operator" || Object.hasOwn(role.agentBindings, agent.id))
-        return;
-    const existing = Object.values(role.agentBindings).find((binding) => binding.adapterId === agent.adapterId);
-    if (existing !== undefined) {
-        throw usageError(`Operator already has a ${agent.adapterId} Agent: ${existing.agentId}. `
-            + "Update that Agent's configuration, or activate another adapter and "
-            + "unbind it before binding this Agent.");
-    }
-}
 function removeRole(args, store) {
     const [rawName, ...rest] = args;
     const name = roleName(rawName);