@zq-silk/yui 0.8.9 → 0.9.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. Once a Task-final Round exists, it remains an obligation; a changed
+Task head requires a new Round and the previous report remains evidence. 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

@@ -250,8 +250,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 +259,16 @@ 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. Once WorkItems
+produce Git results, their ChangeSets must be integrated into the Leader's
+Task main before Task-final Review or completion.
 
 `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 +311,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 +328,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 +386,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
 ```
 
@@ -565,15 +566,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
 ```
@@ -706,8 +707,9 @@ yui task complete <task-id> --summary-file delivery.txt \
 This does not weaken normal freshness checks. 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

package/dist/cli/commandCatalog.js

@@ -241,9 +241,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 +266,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>" },

package/dist/cli.js

@@ -1844,36 +1844,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 +1883,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}`,