@zq-silk/yui 0.8.9 → 0.10.0

package/skills/yui-leader/SKILL.md

@@ -10,12 +10,9 @@ making Task decisions. Recover authority from its Snapshot and deltas, never
 from launch text or transcript memory.
 
 Own Task direction, decomposition, semantic decisions, acceptance, integration,
-and durable context. Yui has one work model: every bounded outcome is a
-WorkItem. Choose one of three execution paths for each WorkItem:
-
-1. execute it directly as this Leader;
-2. create a native subagent inside this Leader's current Agent conversation;
-3. dispatch it to a Task Role and its independently managed AgentRun.
+and durable context. The Task is the bounded user outcome. A WorkItem is only
+one substantial, independently acceptable requirement with a distinct owner;
+it is not the default container for every edit, check, finding, or repair.
 
 Do not invent another execution entity or a `yui ... subagent` command.
 
@@ -33,16 +30,18 @@ workspace or infer a Lane result from a non-durable checkout.
 
 ## Default to the Leader-first fast path
 
-Start from the Task's recorded delivery path:
+Start from Task intent and make the topology decision yourself:
 
-- **Direct**: for a low-risk Project Task, implement, commit, and verify in the
-  managed Task main. Do not create a WorkItem, ChangeSet, IntegrationAttempt,
-  Worker Role, or managed ReviewRound merely to leave more records.
-- **Integrated**: create one roleless WorkItem for the bounded result. Keep its
-  investigation, implementation, targeted checks, and ordinary review fixes
-  together. Split only for independently acceptable ownership or real parallel
-  value; a phase name is not a reason to create another WorkItem, Role,
-  Session, Run, Message, or Input.
+- **Bugfix**: own it in the Leader Session and managed Task main. Implement,
+  commit, and verify promptly without creating a WorkItem or Worker Role. If
+  investigation proves that independent delivery owners are actually needed,
+  update the Task to `feature` before creating those WorkItems. Request one
+  Task-final Review only when risk warrants independent verification.
+- **Feature**: own a small feature the same way. Create WorkItems only when the
+  feature contains multiple substantial requirements that different Workers
+  can own and advance independently, normally in parallel. One WorkItem per
+  owner/delivery boundary is the goal—not one per phase, file, implementation
+  step, test, finding, or fix.
 
 Choose the executor in this order:
 
@@ -56,23 +55,24 @@ Choose the executor in this order:
    unavailable to the current Agent, or an independently managed Session and
    Run lifecycle.
 
-Do not dispatch a Task Role merely to obtain a fresh context, run a command,
+Do not create or dispatch a WorkItem merely to obtain a fresh context, run a command,
 perform a routine small edit, or add an intermediate review. Direct and native
 execution add no Worker Role, Worker Yui Session, or Worker AgentRun. The exact
 Leader Run remains active until an explicit Yui yield, completion, or exact
 failure; native child lifecycle never decides that Run outcome. Task main is
-the direct path's durable delivery boundary; the WorkItem and its workspace are
-the integrated path's boundary.
+the Leader-owned durable delivery boundary; the WorkItem and its workspace are
+an independently owned requirement's boundary.
 
 Provider-native foreground and background child lifecycle stays owned by the
 current Agent Session. Structured child completion notifications may resume the
 Leader in later provider Turns while the same Yui AgentRun remains active.
 
-A direct Project result uses a clean committed Task main and exact completion
-head proof. An integrated result uses one WorkItem-owned Develop workspace and
-a clean committed Candidate; Candidate, ChangeSet, committed Integration,
+A Leader-owned Project result uses a clean committed Task main and exact
+completion-head proof. A WorkItem result uses its own Develop workspace and a
+clean committed Candidate; Candidate, ChangeSet, committed Integration,
 acceptance, Task-final Review when required, and Task completion remain
-distinct judgments and records.
+distinct judgments and records. Integrate every accepted WorkItem result into
+the single Task main before reviewing or completing the whole Task.
 
 Use this validation and review cadence unless Project Policy requires more:
 
@@ -82,16 +82,15 @@ Use this validation and review cadence unless Project Policy requires more:
 2. Have a native child return one consolidated result for the requested round.
    The Leader inspects that result, the diff, and the acceptance criteria; do
    not create progress handoffs or poll the child.
-3. For direct delivery, run Project Policy's complete local delivery validation
-   once on the final Task-main commit, then complete. Use a bounded native
-   review when useful. If an independently managed final Review is required,
-   promote to integrated before Task main advances. An already established
-   immutable final Review remains binding.
-4. For integrated delivery, capture the Candidate and run the complete delivery
-   validation once on the Integration candidate. Use one independent Task-final
-   Review of the frozen committed heads when policy requires it; do not
-   substitute per-WorkItem ReviewRounds or repeat a successful full check on an
-   unchanged commit.
+3. For Leader-owned delivery, run Project Policy's complete local validation
+   once on the final Task-main commit, then complete or request one Task-final
+   Review when risk warrants it. An established immutable final Review remains
+   binding.
+4. For WorkItem delivery, capture each Candidate and run complete delivery
+   validation once on the Integration candidate. After all results are on Task
+   main, request one independent Task-final Review when risk or contract
+   requires it; do not substitute per-WorkItem ReviewRounds or repeat a
+   successful full check on an unchanged commit.
 
 Yui may reuse a successful Integration check only for the same Task, Project,
 exact candidate commit, ordered check commands, immutable runtime release, and
@@ -116,15 +115,14 @@ children through adapter metadata, and routes a later result reference through
 the durable inbox. Do not poll, send a waiting Message, rewrite a checkpoint,
 or yield merely to preserve that native wait.
 
-Before the first durable Leader action, Yui permits at most one automatic
-same-Session Provider continuation. If two fresh Leader generations still
-produce no WorkItem, Review, Integration, or Leader-attributed durable event,
-the Controller stops before a third generation, marks recovery failed, and
-hands the exact evidence to the unique global Operator. Do not bypass that
-stop-loss by manufacturing another Role, Run, Session, or Task. The Operator
-must inspect the failure and explicitly recover or change the configured
-Leader; after first durable progress, ordinary bounded Provider retry policy
-continues to apply.
+Before the first durable Leader action, Yui observes fresh native generations
+that produce no WorkItem, Review, Integration, or Leader-attributed durable
+event. Two such generations create a non-blocking orchestration advisory for
+Leader and Operator judgment; they do not fail the Role, reduce the configured
+Provider retry policy, or prevent another useful generation. Read the evidence
+before retrying, then choose whether to continue, change the configured Leader,
+or perform direct maintenance without manufacturing protocol records merely to
+silence the advisory.
 
 Native child results have an explicit durability boundary. A native subagent is
 best-effort by default: its result returns through the parent Conversation, and
@@ -532,16 +530,21 @@ authorized expansions.
   terminal. Never bypass an active round.
 - `leader`: decide whether the existing evidence is sufficient. Request Agent
   review with `yui task work review <work-id>` when it adds useful evidence.
-- `final`: for normal software delivery, keep WorkItem acceptance and
-  integration independent, then request one fresh ReviewRound over the frozen,
-  integrated Task candidate before completing the Task. The final Reviewer
-  evaluates the complete result across bound Projects; it is not a second
-  per-WorkItem approval protocol.
+- `final`: keep WorkItem acceptance and integration independent. After all
+  results are integrated into Task main, decide whether risk warrants one
+  Task-final ReviewRound over the frozen Task candidate. A Task contract may
+  require it. The final Reviewer evaluates the complete result across bound
+  Projects; it is not a second per-WorkItem approval protocol.
+- A changed Task head creates a new semantic Task-final Round. Reuse the same
+  compatible Reviewer Role Session and stable workspace when Yui offers it;
+  do not create a new Role or native Session for every Round. Round identity
+  still binds each Run to the exact frozen head.
 - A completed review is advice. Decide whether to accept, reject, review again,
   or ask the user.
 - Route a reachable final-Review finding to the original Worker while that
-  WorkItem is open; otherwise create the smallest Repair WorkItem. Resolve
-  all findings from one final Review in one consolidated Repair WorkItem by
+  WorkItem is open; otherwise fix a small local issue as Leader on Task main.
+  Create a Repair WorkItem only when the repair is itself a substantial,
+  independently owned requirement. Keep related findings in that one unit by
   default. Select `task review finding repair-wave --strategy parallel` only
   when the groups have independently acceptable ownership and the concurrency
   benefit exceeds the added Integration and Review cost. Use Leader/Integration
@@ -726,10 +729,10 @@ results are outstanding: the provider owns their completion notifications, and
 Yui keeps this AgentRun active across intermediate provider Turns. After native
 work drains, continue to Task completion, InputRequest, or final yield.
 
-Complete only after the selected delivery path's evidence is satisfied, Role
-work is terminal, latest isolated results are integrated or deliberately
-abandoned, and user inputs are resolved. Direct delivery has no WorkItem gate;
-integrated delivery retains it. Task completion is a semantic boundary: it
+Complete only after the topology-derived evidence is satisfied, Role work is
+terminal, latest isolated results are integrated or deliberately abandoned,
+and user inputs are resolved. A Leader-owned Task has no WorkItem gate; a Task
+with WorkItems must settle and integrate them. Task completion is a semantic boundary: it
 records exact Project heads, reports terminal-workspace cleanup advisories, and
 notifies the global Operator. It does not stop this Leader. Do not kill tmux
 panes, edit Session records, or add a provider-specific cleanup step. After

package/skills/yui-operator/SKILL.md

@@ -111,9 +111,9 @@ completion, failure, and rollback are all independent and it can run in parallel
 without waiting on or controlling another Task. Same repository, same file, or a
 potential Git conflict is neutral to Task identity; let rebase, merge, and
 review handle independent changes instead of merging the Tasks. One bounded
-outcome may bind multiple Projects and independent base refs. A feature, bug
-fix, and question do not need separate Task types; intent and acceptance
-criteria carry the difference.
+outcome may bind multiple Projects and independent base refs. Task type records
+Project-defined intent such as `feature` or `bugfix`; it does not determine
+Task identity or execution topology.
 
 The Task title is the human-facing label used in Agent session lists. Keep it to
 one concise outcome phrase, ideally within 20 characters. Put request details,
@@ -126,7 +126,7 @@ yui operator submit "<related request>" --task <task-id>
 yui task create "<distinct mission>" \
   --project <project-a> --project <project-b> \
   --base <project-a>=<ref> --base <project-b>=<ref> \
-  --delivery integrated
+  --type feature
 yui operator submit "<request and routing context>" --task <new-task-id>
 yui task activate <new-task-id>
 ```
@@ -145,25 +145,21 @@ separate Tasks merely because it spans several Projects or files. A Task may
 carry many features and rounds of WorkItems toward its shared outcome, but it is
 not a permanent backlog; genuinely independent goals become their own Tasks.
 
-Choose the Project delivery path before activation and report it with the Task:
-
-- `--delivery direct` for one bounded, low-risk outcome that Project Policy
-  allows the Leader to implement and verify on Task main. Direct delivery does
-  not require a WorkItem, ChangeSet, IntegrationAttempt, or policy-created
-  managed ReviewRound; it still requires a clean committed managed Task main.
-- `--delivery integrated` when Project Policy requires independent provenance,
-  Integration CAS, or final Review, and whenever the change crosses Projects,
-  storage/migration, permission or authorization, destructive behavior,
-  concurrency/recovery invariants, or release machinery. It requires the
-  WorkItem, ChangeSet, and committed Integration evidence chain.
-- Omit `--delivery` only for a Task with no Project bindings. The legacy
-  `--require-integration` flag remains an alias for `--delivery integrated`.
-
-Risk is a Leader/Project Policy judgment, not a file-count score. When evidence
-changes the risk, promotion from direct to integrated is explicit and
-irreversible; never silently downgrade an integrated Task to make completion
-easier. Do not pre-create WorkItems merely because integrated delivery might
-become necessary later.
+Record Project-defined Task intent and leave execution topology to the Leader.
+For software Projects, use `--type bugfix` or `--type feature`. A bugfix is
+Leader-owned; if it expands into independently owned delivery requirements,
+the Leader reclassifies it as a feature before creating WorkItems. For a
+feature, the Leader decides whether to own the whole result on Task main or
+create substantial WorkItems for different Workers. Never choose a WorkItem
+count at routing time merely from file count, risk labels, or a desire for more
+progress records.
+
+Do not create WorkItems for investigation notes, implementation steps, tests,
+review rounds, findings, or small fixes. A WorkItem is justified only when it
+has its own meaningful requirement, owner, acceptance boundary, and useful
+independent progress—normally enough work for a different Worker to advance in
+parallel. Integration evidence is derived later from WorkItems that actually
+produce isolated Git results.
 
 Managed workspaces are owner-keyed, not Role-keyed: Task main, WorkItem
 Develop, ReviewRound, and IntegrationAttempt each retain their own durable
@@ -178,16 +174,11 @@ outcome: keep it on the original Task, submit only the delta and its reason, and
 let the Leader retire the affected WorkItem, optionally name its replacement,
 and create the replacement. When a change instead abandons the current outcome for an
 independent one, do not force it onto the original Task; apply the strict
-new-Task rule above. If the delta promotes a Project-backed direct Task into
-guarded delivery, first run
-`yui task update <task-id> --delivery integrated`, read back the delivery path,
-and only then submit the delta. Promotion is allowed only while Task main is
-still at its recorded base and no WorkItem, ChangeSet, Integration, or Review
-evidence exists. If implementation already advanced Task main, keep the branch
-intact and either finish under the direct contract or create an integrated
-replacement Task; never manufacture provenance for earlier commits. Bind a
-Project before selecting a delivery path
-for a previously Gitless Task. When a completed Task
+new-Task rule above. If the delta changes the request kind, update the optional
+Task type and submit the delta; the Leader then re-evaluates topology from the
+current Task state without manufacturing WorkItems or provenance for earlier
+commits. Bind a Project before execution when a previously Gitless Task gains
+repository scope. When a completed Task
 receives genuinely new work, reopen it only if it is still the same outcome;
 otherwise create a follow-up Task and reference the earlier result.
 
@@ -302,8 +293,9 @@ terminal text. For progress, report:
 - current Brief focus, latest Milestone, blockers, and open InputRequests.
 
 Worker yield is not completion. Describe a result as awaiting Leader review
-until it is accepted; do not report isolated code as delivered before its latest
-ChangeSet is integrated.
+until it is accepted. Report code as delivered only when the governing
+Candidate's current ChangeSet is committed; a superseded disposition settles
+the workflow without claiming that version was delivered.
 
 ## Enter and administer
 
@@ -349,11 +341,10 @@ ChangeSet is integrated.
   Run, Agent, receipt, launch, and Session identities; never reconstruct them
   from terminal text or ask the user to paste them.
 - Retry only an explicitly failed recovery Job.
-- When a Leader first-progress stop-loss is reported, inspect its two exact
-  native generations and absence of durable progress. Do not request a third
-  automatic generation or create another Operator. Recover the existing Task
-  only after choosing an explicit valid Leader configuration or a direct
-  maintenance action.
+- When a Leader first-progress advisory is reported, inspect its native
+  generations and absence of durable progress. It is cost evidence rather than
+  a recovery gate: choose whether another generation, a different configured
+  Leader, or direct maintenance is the smallest useful next action.
 - Use `yui task next-action <task>` and `yui execution audit` orchestration
   advisories as read-only cost evidence. They may flag excess WorkItems,
   repeated Reviews/checks, pre-progress generations, or terminal workspaces;

package/skills/yui-reviewer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yui-reviewer
-description: Review the exact frozen WorkItem Candidate or Task-final Integration scope without changing delivery sources.
+description: Review the exact frozen WorkItem Candidate or unified Task-final scope without changing delivery sources.
 ---
 
 # Yui Reviewer
@@ -13,11 +13,16 @@ Review only the exact frozen scope and ReviewRound assigned by the Leader; never
 reinterpret its scope:
 
 - For a WorkItem ReviewRound, inspect that Round's exact frozen Candidate.
-- For a Task-final ReviewRound, inspect the exact frozen committed Integration
-  heads supplied by that Round.
+- For a Task-final ReviewRound, inspect the exact frozen Task-main heads
+  supplied directly by that Round. It has no synthetic WorkItem or Candidate
+  anchor.
 
-A Role is an executor, not a workspace owner: the ReviewRound owns its fresh
-workspace. Review edits are confined to that workspace, never modify the
+A Role is an executor, not a workspace owner: each ReviewRound owns an exact
+workspace record. Consecutive Task-final Rounds for the same Reviewer may
+reassign one clean physical workspace and continue the same compatible native
+Session. Treat the new Run Context Pack and frozen head as the authority even
+when the conversation continues; never reuse an earlier verdict. Review edits
+are confined to that workspace, never modify the
 WorkItem Develop workspace, and never become a ChangeSet source.
 
 ## Separate infrastructure failure from review judgment
@@ -68,17 +73,18 @@ not accept the WorkItem or complete the Task. Preserve the ReviewRound record
 and explicitly clean its workspace after the round is terminal.
 
 For normal software delivery, follow the applicable Project Policy. The
-Leader's default policy schedules one
-independent Task-final Review of the frozen committed Integration result before
-completion instead of scheduling a complete ReviewRound for every WorkItem.
+Leader decides whether risk warrants one independent Task-final Review of the
+frozen Task result instead of scheduling a complete ReviewRound for every WorkItem.
 That scheduling policy does not authorize a Reviewer to decline or reinterpret
 an explicitly or risk-triggered WorkItem ReviewRound already assigned to it.
 Reuse the supplied validation evidence and run only checks needed to close a
 specific gap; do not rerun an unchanged complete suite for ceremony.
 
 Return each reachable finding to the Leader with direct evidence and a bounded
-route to the original execution unit: direct Leader work returns to the Leader,
+route to the original execution unit: Leader-owned work returns to the Leader,
 native work to the same child, and managed work to the same Role and native
-Session. Keep the existing WorkItem when its scope remains open; if the frozen
-final-review boundary requires a repair, recommend only the smallest repair
-WorkItem. Never capture or integrate the ReviewRound's diagnostic workspace.
+Session. Keep the existing WorkItem when its scope remains open. For a small
+Task-main fix, return it to the Leader without recommending another WorkItem;
+recommend a Repair WorkItem only when the repair is itself a substantial,
+independently owned requirement. Never capture or integrate the ReviewRound's
+diagnostic workspace.

package/skills/yui-worker/SKILL.md

@@ -9,7 +9,7 @@ Follow `yui-runtime` first. For a managed Run, load its exact Context Pack and
 use only the returned WorkItem, refs, workspace, writable Project IDs, and
 completion actions. The launch Envelope is a pointer, not an execution brief.
 
-Complete only the assigned bounded WorkItem. The Leader owns Task direction,
+Complete only the assigned substantial, independently owned WorkItem. The Leader owns Task direction,
 decomposition, acceptance, integration, scope expansion, and conflict
 decisions. A Worker must not create or rebind Yui worktrees, Sessions, Roles,
 Runs, WorkItems, ReviewRounds, or integration state.
@@ -31,7 +31,9 @@ pack.
 ## Execute within the exact boundary
 
 - Preserve the Task, WorkItem, Role, Run, native Session, and workspace
-  identities supplied by Yui.
+  identities supplied by Yui. A new Run is another attempt or continuation of
+  the same delivery unit; do not request a fresh Role or Session merely because
+  implementation entered another step or repair round.
 - Follow the configured Profile's responsibilities, constraints, access
   intent, Skills, and expected output. Report unsupported model or effort
   hints instead of claiming they were applied.
@@ -56,7 +58,7 @@ authority.
 ## Validate proportionately
 
 Keep investigation, implementation, the smallest targeted check, and ordinary
-finding fixes in one coherent WorkItem round. Run checks that can catch the
+finding fixes in one coherent WorkItem. Run checks that can catch the
 changed behavior; do not repeat an unchanged successful check. Follow Project
 Policy for required validation and state passed, failed, and intentionally
 skipped checks honestly.