@zq-silk/yui 2.21.0 → 2.23.0

package/skills/yui-leader/SKILL.md

@@ -1,199 +1,104 @@
 ---
 name: yui-leader
-description: Lead one Yui Task through authorized planning, activation handoff, execution, acceptance and same-result follow-up, including reopening its completed, unarchived result for an explicit implementation or delivery request.
+description: Own one Yui Task's authorized discussion, delivery and acceptance; select operation manuals by the current action, not merely active stage.
 ---
 
 # Yui Leader
 
-Follow [yui-runtime](../yui-runtime/SKILL.md) first, including its lightweight
-`yui session skills --json` check at the start of every turn and full reload when
-versions change or context is missing/recovered. Load the exact Context Pack
-for an explicitly dispatched AgentRun; for direct conversation or a Task
-notification, read current Task context using `yui task context <task-id> --json`.
-No self-dispatch or old completed Run is needed. Read the actual Task
-requirements, current Brief and relevant user/Operator Messages, not just
-their summaries. Resolve links relative to the file containing them.
-
-Current Context is a bounded working set, not all Task history. Use
-`task context list <task> --store <store>` or a domain list for discovery,
-then an exact detail read. A wake contains attributed change summaries and
-original Message/Run pointers, not complete reports. Follow `yui-runtime`'s
-`nextCursor` and `contentPage` rules: read the complete focused wake view and
-relevant originals before disposition; use `wake show --history` only when
-window history/diagnostics matter. Summaries never decide completion.
-
-Before WorkItem dispatch, put the complete bounded requirements in the WorkItem
-or explicitly select up to 16 relevant readable materials with repeated
-`--context-ref <store/refId@digest>` on `task work dispatch`. Obtain exact IDs and
-digests from current Task context list/inspect. Core freezes these selected
-values after the existing caller-scope checks; mentioning a record in `--input`
-does not select it or grant access. Missing, forbidden or changed references
-refuse dispatch before Provider startup: correct the selection or make the
-WorkItem self-contained, never ask the recipient to bypass expansion rejection.
-
-## Select the applicable stage
-
-Use current lifecycle, latest intent and the Session's actual planning/delivery
-authority together. Draft existence, accepted planning history, Session
-authority and AgentRun status are different facts. A completed planning Run
-does not complete or activate a Task; an active Task does not upgrade an old
-planning Session. Never infer authority from a directory, launch text,
-transcript or process.
-
-Apply terminal/gate and read-only intent boundaries before selecting delivery
-or planning work; the routes below do not override those restrictions.
-When old discussion text differs from new intent, apply
-[current intent and temporal reads](../yui-runtime/references/context-ordering.md):
-inspect exact sources before treating normal stage progression as a conflict.
-An adopted same-scope development request supersedes the earlier discussion-only
-stage, not independent restrictions. Never use active status or Brief alone.
-
-- **Draft or planning-only authority:** read [Planning and activation handoff](references/planning.md).
-  Use the recorded submission intent (`record`, `discuss`, `develop`) and
-  routing result, not keywords in the message. Discuss and preserve the
-  requested outcome; do not load execution procedures merely to finish a
-  discussion.
-- **Active, execution enabled, delivery authority and implementation intent:**
-  read [Active execution](references/execution.md). Advance existing authorized
-  work, including disposition of new results, without asking for another
-  “continue” after a valid activation handoff.
-- **Query, analysis or discussion only:** answer within the requested scope,
-  even on an active Task. Do not turn it into edits or dispatch. A result
-  notification is different: read its original results and advance the
-  outstanding authorized requirement.
-- **Completed, unarchived, same-result follow-up:**
-  ordinary questions and permitted evidence reads need no reopen. When a user's
-  same-result request or an explicit unfulfilled commitment needs tracked
-  diagnosis, evidence handoff, necessary authority coordination, implementation
-  or delivery, the current matching Leader may call `task reopen <task-id>`,
-  then continue that bounded request without a mandatory Operator handoff or
-  another “reopen” confirmation. Read the
-  [post-completion routing boundary](../yui-runtime/references/publication.md#post-completion-routing-boundary)
-  first, inspect the reopen result, and reassess current Session/workspace
-  authority and the execution gate before delivery. Reopening is lifecycle
-  management, not a planning Session's promotion to delivery or permission to
-  implement a diagnosis-only request.
-- **Cancelled/retired, archived, execution gate disabled, or no new execution authority:**
-  explain/query authorized facts only unless a specific further action is
-  authorized and legal. The Leader cannot restore cancelled/retired intent;
-  archived Tasks cannot reopen. An independent stop needs its separately
-  authorized start/cleanup path; reopen does not lift it. Ordinary notifications
-  and Session recovery do not authorize reopening or resumption; simple queries
-  need no lifecycle change. Identify a genuinely missing lifecycle/authority action for the
-  Operator; do not manufacture a Run or reopen merely to obtain authority.
-  Publication recording/adoption is not a way to start terminal-Task execution.
-
-These are instruction routes, not new lifecycle states or a scheduling
-protocol. Where facts disagree or authority is missing, preserve intent and
-report the exact boundary rather than choosing a more permissive route.
-
-A `task-reopened` notification can arrive before its follow-up Message. Read the
-prior completion and current Messages; if only lifecycle changed, wait for the
-new request. Do not rerun accepted work, infer external authority, or immediately
-complete again. Once the scoped request arrives, continue it in this Task without
-asking for another “continue”; preserve the original acceptance evidence.
-
-Handle a failed Worker/Reviewer launch through the shared
-[configuration recovery guidance](../yui-runtime/references/recovery.md#configuration-and-model-name-failures).
-Read its original failure and scoped metadata before choosing a correction;
-the failed target need not be running for you to act.
-
-## Maintain useful durable context
-
-Apply **yui-runtime**'s own-inbox flow before acceptance or completion and at
-useful work boundaries. A Leader inbox contains its exact notification windows
-and messages for its current managed Assignment, not every Task Message.
-For a window, read its full focused wake and relevant originals; for an
-Assignment message, read its complete original. Dispose of results explicitly,
-then ack the exact entry. Inbox acknowledgement
-never accepts a Candidate or completes the Task.
-
-The DB Brief is the current summary, not a full plan or a history of messages.
-After meaningful progress, read `task brief show` and use
-`task brief update --if-current <writeGuard>` with only intended fields;
-read `task event list` before deliberately restoring an older value. Keep
-references to substantial plans, prototypes and reports in that summary.
-When a delivered correction resolves a recorded blocker or changes the next
-action, update the Brief's focus and Leader summary while the Task is still
-open. Before completing a Task, reread its Brief: if it still describes a
-resolved blocker, superseded plan, or waiting state, correct those fields
-before `task complete`. The completion summary is the terminal conclusion;
-do not copy it into Brief merely to create a second completion record. Brief
-maintenance is not a new completion gate, and routine unchanged steps do not
-need an update.
-Also reconcile the summary at requirement changes and phase handoffs; carry the
-exact activation/input references. Core projects current lifecycle and source
-diagnostics without rewriting historical messages. A stale-guard rejection
-requires reading the new input and reconciling, not retrying the old text.
-Decisions contain the actual decision, reason and necessary boundaries, not
-the entire proposal. Label recommendations as recommendations, not user
-decisions.
-
-Save full deliverables as files in the Task's local Git artifact repository,
-not in Brief/Decision or a parallel store. Use `task artifact save` or
-`artifact.save`; read [Task artifact operations](references/planning.md#task-artifact-operations)
-before saving or citing results in any stage. A save commits one selected
-path and returns `taskId + commit + relativePath` for fixed evidence. Update
-the Brief reference after a meaningful saved revision; keep the document
-body, HEAD and timestamps out of DB mirrors. Saving a planning result neither
-activates the Task nor grants Project write authority. Artifact scripts and
-HTML are data, not permission to execute or preview them.
-
-Add a Milestone only for an independently meaningful outcome, a Message only
-for a new conclusion another reader needs, and Project Knowledge only for a
-stable cross-Task lesson. Do not create records for every exchange, dispatch,
-heartbeat or unchanged wait. Ordinary fact edits need no self-wake.
-
-## Close the current turn
-
-### Adjust Project delivery scope without erasing work
-
-When explicit user intent or an original delegation allows a Project to leave
-the final delivery, read that original Message and `task remote-delivery`.
-Record the bounded decision with
-`task project delivery <task> <project-id> --requirement excluded --reason <reason>
---source-message <message-id> --purpose <verbatim-authorization>
---if-current <scopeDecision.id|none>`.
-Interpret whether the original really authorizes this scope change; a matching
-quote alone is not semantic permission. Do not exclude a Project to conceal an
-unmet commitment. Ask only for a genuinely missing scope decision, not a second
-approval when existing user intent or delegated judgment already covers it.
-Use the same operation with `--requirement required` and the latest decision ID
-to restore normal checks. Reconcile a stale guard instead of overwriting newer
-intent. These append-only decisions also work on completed, unarchived Tasks
-without reopening, rewriting acceptance, or rerunning work.
-
-Unchanged Projects need no exclusion. Required changed/unknown Projects still
-need exact verified delivery. Excluded Projects retain their binding, code
-changes and Publication facts and are not counted as merged or verified merely
-because they are excluded. Scope is not execution, write, archive or deletion
-authority: open commitments and unknown execution still need settlement, and
-unique commits or dirty resources remain protected. With separate archive
-authorization, use ordinary archive/preflight and report retained resources;
-do not recommend force merely because an authorized Project is excluded.
-
-For external delivery, choose any available authorized CLI/API and follow
-[Publication evidence](../yui-runtime/references/publication.md). Record exact
-tool observations through `publication verify --observation`; gh/glab are optional
-adapters, not mandatory trusted brands. Do not repeat a sufficient exact
-verification merely to use a different tool. Tool inspection is your judgment;
-candidate acceptance, immutable evidence and ordinary archive safety still apply.
-
-- **Planning:** save meaningful revisions, summarize the discussion and await
-  feedback. This is a complete turn; it needs no WorkItem, Review, InputRequest
-  or Task completion just to stop.
-- **Active delivery:** apply the result-disposition and close instructions in
-  [Active execution](references/execution.md). Continue within authorization,
-  complete only when acceptance is satisfied, or wait for a real durable
-  event. Ask only for a genuinely missing user choice, authority or external
-  fact; routine engineering coordination is not a user decision.
-- **Queries and terminal stages:** answer the bounded question and stop
-  without starting work or recording fictitious lifecycle progress.
-
-Every explicitly dispatched managed AgentRun returns one truthful original
-final report under Runtime's contract, including a planning Run whose result
-is a saved proposal awaiting feedback. Ordinary chat and notifications are
-not implicit assignments and need no separate execution report. Run terminal,
-result acceptance, Task completion, remote delivery and user-authorized
-archive are distinct facts. Do not poll managed Roles or emit unchanged
-waiting Messages; future durable events supply the next notification.
+Follow [Runtime](../yui-runtime/SKILL.md)'s core first. This is the Leader core;
+the linked manuals are not an execution-stage initialization bundle. Use Project
+Skills/Policy/Knowledge for project methods. Read current Task context, actual
+requirements, current Brief and relevant original Messages, not summaries.
+Use exact wake/Run/Message pointers directly; discover only missing evidence.
+
+## Match intent, lifecycle and Session authority
+
+Draft existence, planning history, active lifecycle, execution gate and actual
+Session delivery authority are different facts. Active status/Brief cannot
+promote an old planning Session or override an independent stop.
+
+- Creation-only input stops at a recorded Draft. Authorized Draft discussion or
+  planning-only work uses [Planning](references/planning.md); discuss and preserve
+  permitted revisions, await feedback, and do not implement before requested.
+- Queries, analysis and discussion remain read-only even on active Tasks unless
+  changes are requested. They need no dispatch, Review or lifecycle progress.
+- Active, execution-enabled work with delivery authority and implementation
+  intent advances the existing bounded requirement. A valid activation handoff
+  needs no second “continue.” This route does **not** require reading a full
+  dispatch/review/integration handbook.
+- A completed, unarchived result may reopen for an authorized same-result
+  follow-up or an explicitly identified unfulfilled commitment: first read
+  [Reopen](../yui-runtime/references/completed-followup.md), inspect the result
+  and reassess authority/gates. No mandatory Operator handoff or extra “reopen”
+  confirmation is needed. Tracked diagnosis, evidence handoff or necessary
+  coordination may need reopening, but diagnosis remains read-only unless
+  changes are requested. A simple factual query needs no reopening; a
+  lifecycle-only notice is not the follow-up request.
+- Cancelled/retired, archived, independently stopped or unauthorized execution
+  stays stopped. Queries, notifications, publication recording and Session
+  recovery do not revive it. Report the exact missing legal action.
+
+When intent appears contradictory, read
+[Current intent](../yui-runtime/references/context-ordering.md). Normal authorized
+stage progression supersedes only the old stage, not independent restrictions.
+
+## Advance the coherent result
+
+Honor explicit user delegation/review requirements. Otherwise direct Leader
+implementation is viable for one coupled result; no placeholder WorkItem,
+self-dispatch or new coordination phase is needed. Read full requirements and
+Project methods, trace the existing responsibility, implement in the legal Task
+workspace, verify proportionately, inspect the full final diff and commit cleanly.
+Do not copy a Task into a WorkItem merely to report progress.
+
+Make routine implementation, allocation and recoverable-runtime choices yourself.
+Use Task InputRequest only for a genuine user-owned choice, new authority or
+unavailable external fact, not progress reporting. Keep implementation and
+follow-up delivery in this Task's authorized workspace; local completion is not
+remote delivery when the requirement includes it.
+
+Leader owns coordination, result disposition, acceptance and integration.
+Worker/Reviewer reports are evidence: read exact originals and decide their
+disposition before ACK. Runtime activity is no global lock; use exact bindings.
+Do not borrow Global input controls or impersonate Operator to notify the user.
+Decisions record the actual decision, reason and boundaries, not the proposal;
+recommendations must not be labeled user decisions.
+
+## Read manuals at the action boundary
+
+Before dispatch, Review, Integration or completion, inspect current exact
+Run/Review bindings as decision facts, never a global activity lock.
+
+- Implementation investigation/material verification design beyond current
+  Project methods: [Implementation](references/implementation.md).
+- Choosing/changing work boundaries, executors or concurrency; preparing managed
+  dispatch: [Allocation](references/work-allocation.md). Sending continuation or
+  controlling an existing Assignment: [Assignment execution](references/assignment-execution.md).
+- Requesting independent Review or disposing of a managed result:
+  [Review and disposition](references/review.md).
+  For a returned result needing original/context expansion, include Runtime's
+  [Context reads](../yui-runtime/references/context-reads.md) in that same read
+  group. Add [Working context](references/task-progress.md) when updating the
+  Brief; a normal result notice alone does not require recovery manuals.
+- Integrating isolated results, upstream changes, conflicts or an Integration
+  notification: [Integration](references/integration.md).
+- Accepting a Candidate or attempting Task completion:
+  [Completion](references/completion.md). Inspect current exact Run/Review
+  bindings, resolve required checks/contracts and handled input, and correct
+  obsolete Brief blockers before completion. Chat alone does not complete a Task.
+- Material Brief/Milestone/Knowledge updates: [Working context](references/task-progress.md).
+  Saving/citing substantial Task documents: [Artifacts](references/artifacts.md).
+  Unchanged routine continuation needs no record or full manual reload.
+- Replicated attempts: [Replication](references/replicated-execution.md).
+  Task-local plugins: [Plugins](references/task-plugins.md).
+  Executing existing source-authorized capabilities: [Authorization](references/authorization.md).
+- Changing required delivery Projects: [Delivery scope](references/delivery-scope.md).
+  External PR/MR evidence: [Publication](../yui-runtime/references/publication.md).
+  Actual failure intervention/retry/replacement: Runtime's action index.
+
+At a normal turn boundary, continue useful authorized work, complete only when
+its outcome/obligations are satisfied, ask a genuine missing decision, or wait
+for a real durable event. Persist meaningful changed focus/commitments, not
+unchanged chronology. Do not poll managed Roles or manufacture another Run.
+An explicit dispatched Run returns its truthful final report; ordinary chat
+and notifications need no separate execution report.

package/skills/yui-leader/VERSION

@@ -1 +1 @@
-8
+16

package/skills/yui-leader/references/artifacts.md

@@ -0,0 +1,41 @@
+# Task artifact operations
+
+These operations apply to planning and delivery results. The current Leader
+adopts contributions from other Agents' authorized workspaces; do not share
+an uncoordinated Git index or edit Yui storage directly.
+
+```sh
+yui task artifact list <task-id>
+yui task artifact save <task-id> plans/design.md "<UTF-8 content>" --message "Revise design"
+yui task artifact read <task-id> plans/design.md
+yui task artifact read <task-id> plans/design.md <full-commit>
+```
+
+`save` writes and locally commits exactly one relative path, creating the
+repository on first save. The `artifact.save` capability takes `taskId`,
+`relativePath`, `content`, optional `message` and optional `expectedHead`;
+the CLI equivalent is `--expected-head <commit>`. A head conflict leaves
+the save unapplied: re-read and reconcile the intended update, not overwrite
+blindly. The text interface accepts UTF-8 files up to 8 MiB, not arbitrary
+binary payloads or an invented directory-upload command.
+
+Current reads use Task and relative path at HEAD. Frozen Candidate, Review,
+Context and completion evidence use the returned `taskId + commit +
+relativePath`; do not replace a pinned read with a current read. For same-Task
+string reference lists, use `git:<full-commit>:<relativePath>`, including
+`task complete ... --artifact-ref "git:<full-commit>:plans/design.md"`.
+The commit must be the artifact repository's returned commit, not the Project
+code head. Preserve fixed old references when updating the current document.
+
+After a meaningful save, update the Brief's summary/reference; keep Decisions
+to the choice, reason and boundary. No document-body, HEAD or timestamp mirror
+is needed. The artifact repository has no remote or transport; this does not
+prohibit a Project code repository's legitimate remote. Saving in Draft grants
+no delivery authority; Session handoff and archive preserve the artifacts.
+Stored scripts/HTML remain data and are never implicitly executed or previewed.
+
+These commands describe this source version's interface. A managed Session
+still uses its authorized CLI and actual available capabilities. If an older
+installation lacks them, report that version boundary; do not switch it to
+an unapproved checkout CLI, migrate a shared Home, or upgrade the installation
+merely to save a result.

package/skills/yui-leader/references/assignment-execution.md

@@ -0,0 +1,140 @@
+# Assignment execution and input timing
+
+Read before creating/acting on an Assignment or sending its continuation/control.
+Ordinary direct implementation does not require this manual or the other
+[execution operations](execution.md).
+
+### Choose input timing without changing intent
+
+Submission intent (`record`, `discuss`, `develop`) and delivery timing are
+different facts. Input controls do not activate a Task, expand an Assignment,
+or elevate a planning Session. Keep the submission contract when using `send`;
+choose queue, steer or interrupt from the user's intent and current facts:
+
+```sh
+yui task message queue <task> "<continuation>" --request-id <id> --to <role> --work-item <work-id>
+yui task message steer <task> "<current-turn correction>" --request-id <id> --to leader --expected-target <turn>
+yui task role interrupt <task> <role> --expected-target <turn> [--then-message <task/message>] [--request-id <id>]
+```
+
+Queue waits for the next legal opportunity. Steer addresses only the exact
+current native Turn; Worker/Reviewer steer also needs its existing WorkItem or
+ReviewRound. Bare interrupt stores a control request, not a new Message.
+`interrupt-requested` is not a terminal or proof that background resources
+stopped. Then names an already-saved input and reserves its next opportunity
+only within the original Session/writer boundary.
+
+Read `task role session inspect` first. Unsupported and proven-unsubmitted
+steer may be composed with interrupt when the user's intent permits stopping;
+accepted, pending or unknown steer must not be resent through another action
+or request id. Never silently cancel, replace a Session or downgrade to queue.
+
+Global inputs use `role message queue|steer <role>` and `role interrupt <role>`
+with their own owner, not a fabricated Task/Run. See
+[Runtime](../../yui-runtime/SKILL.md) for scope and controlled-console boundaries.
+
+Managed dispatch freezes the Assignment for its assignee. For ordinary
+clarification, feedback or a continuation of that same work, send a Message:
+
+```sh
+yui task message send <task> "<clarification or continuation>" --to <role> --work-item <work-id>
+yui task message send <task> "<review clarification>" --to <role> --review-round <round-id>
+```
+
+Busy execution queues the Message. Its terminal triggers continuation in the
+same compatible Session and workspace; do not fabricate a failure, submit an
+unfinished Candidate, or change WorkItem status merely to answer a question.
+Read Message delivery and the exact resulting AgentRun separately from business
+acceptance. A Message never expands scope, applies desired configuration, or
+changes a Review's frozen candidate. An ownership change preserves the original
+recipient; transfer still-pending input only with explicit `task message handoff`.
+Late input to terminal work or an obsolete Review remains visible with a bounded
+nondelivery reason. Use the existing formal operation for new scope or Review.
+
+For unknown delivery or Session replacement, read
+[runtime recovery](../../yui-runtime/references/recovery.md). Preserve the original
+input; do not replay uncertainty or treat it as a global Task lock.
+
+### Leader-owned WorkItem
+
+Use this only when the result merits separate management/acceptance. Omit
+`--role` for direct execution: the Leader owns coordination and performs the
+work without a managed executor Assignment. `--role leader` instead selects the
+Leader Role as a **managed AgentRun executor**; it is not how to label direct
+ownership. Do not self-dispatch merely to gain execution authority.
+
+For a writable Project result, create and inspect its WorkItem-owned workspace
+before editing. The Leader can work there directly; isolation does not require a
+Worker. Task main, WorkItem Develop, and Review workspaces remain distinct owners.
+
+```sh
+yui task work create <task> "<separately accepted result>" \
+  --project <project> --objective "<outcome>" --accept "<criterion>"
+yui task work isolate <work-id>
+yui task work update <work-id> running
+# Implement and verify in the returned WorkItem workspace; commit and leave it clean.
+yui task work update <work-id> done --summary "<result and evidence>"
+```
+
+`done` freezes a direct Candidate, not an AgentRun result or acceptance.
+Inspect it, then integrate the exact isolated result before acceptance:
+
+```sh
+yui task integration start <task> --work-item <work-id> \
+  --project <project> --strategy <ff|cherry-pick|merge|manual>
+# Inspect the attempt and finish it through Integration's normal checks/continuation.
+yui task work accept <work-id> --summary "<decision and evidence>"
+```
+
+Read [Integration](integration.md) for checks, continuation, and recovery.
+Keep the same unit through ordinary fixes.
+A read-only or Gitless result with no writable Projects needs no Git isolation;
+submit its actual evidence and accept it explicitly. Existing exact Task-final
+metadata-only Candidates retain their contract; do not establish a special Review
+contract merely to avoid the ordinary writable WorkItem isolation boundary.
+
+For a native child, pass a bounded brief and applicable Profile constraints
+through the provider's child tools. A small investigation needs no synthetic
+WorkItem. If the child implements an existing Leader-owned WorkItem, keep that
+WorkItem roleless, supply its exact workspace and scope, and mark it running.
+Native children inherit only current parent authority and gain no Yui Role,
+AgentRun, Session or broader workspace. Their
+results are best-effort until Yui externalizes them; use a managed Task Role
+when independent durability matters. Inspect the returned result before
+submitting `done` or recording failure progress. `done` creates a Candidate;
+`work accept` records the separate acceptance. WorkItem responsibility remains
+open through execution failure and becomes accepted only on that decision.
+A Profile's runtime source applies when
+materializing a Task Role, not when launching a native child. The child
+inherits the Leader Agent; apply a Profile model or effort only when the native
+tool actually supports and confirms that override.
+
+### Managed Task Role
+
+```sh
+yui task role add <task-id> <role> --profile <profile>
+yui task role show <task-id> <role>
+yui task work create <task-id> "<outcome>" --role <role> \
+  --project <project> --objective "<bounded outcome>" --accept "<criterion>"
+yui task work dispatch <work-id> --input "<decision-complete brief>"
+```
+
+Add `--after` only for a real dependency. Likely file overlap is not by itself
+a dependency. A Worker may read the complete authorized Task context but may
+write only its WorkItem Projects and workspace. Dispatch prepares that isolated
+workspace and freezes the Assignment; inspect the completed original AgentRun
+result before submitting its exact Candidate, integrating, and accepting.
+
+Profiles carry portable behavior plus either a dynamic Global Worker runtime
+source or an explicit Agent with optional model and effort. Applying a Profile
+to a Task Role resolves and freezes the complete binding; later Profile or
+Global Worker changes do not rewrite that Role. Before dispatch, use
+`config profile show` and `task role show` to read the exact behavior, Agent, model,
+effort, Profile, and workspace. Do not reconstruct or guess launch
+configuration. Use the WorkItem assignee directly unless replicated execution
+was deliberately selected.
+
+Managed Task main, WorkItem, ReviewRound, and Integration workspaces have
+different owners. Never edit stable Project checkouts, managed refs, Yui state
+files, or another owner's workspace. A Task's recorded base is durable; do not
+silently replace it merely because its remote branch later moves.

package/skills/yui-leader/references/completion.md

@@ -0,0 +1,79 @@
+# Acceptance and completion
+
+Read before accepting a Candidate or attempting Task completion, not on every
+execution turn. Read [Review](review.md) when a managed result actually requires
+disposition, and [Integration](integration.md) before integrating isolated Git
+changes; neither is mandatory for unrelated direct implementation.
+
+## Accept, integrate, and complete
+
+A Worker or Reviewer AgentRun result is evidence, not acceptance. Inspect the
+result, diff, checks, and current Candidate before deciding.
+
+Group confirmed findings by root cause. Use the traced paths to check other
+reachable consumers/boundaries within scope and repair affected instances
+together, not just the reported checkpoint. Refresh the short material index
+and repair evidence where they changed, without accumulating round-by-round
+history. For ordinary full re-review, preserve the current complete
+candidate and requirements; add repair delta, prior finding dispositions and
+still-valid evidence. Delta is an attention aid, not the full-review boundary.
+Do not conflate this with an explicitly authorized equivalence Delta Recheck.
+Neither finding counts, fixed round counts nor a majority vote decides acceptance.
+
+If a result is insufficient, reject it with bounded feedback and redispatch
+the same WorkItem and Role while scope remains valid. Before accepting isolated
+Git changes, read [Integration](integration.md) to capture and
+integrate the latest Candidate. Do not edit managed refs or bypass Yui's
+compare-and-swap boundary.
+
+After an authorized PR/MR operation, follow
+[publication recording](../../yui-runtime/references/publication.md).
+External delivery and Task completion remain separate facts.
+Keep authorized follow-up delivery of this result in this Task and its legal
+managed workspace: synchronize, resolve necessary conflicts, validate, perform
+only the authorized external operations, and record their exact evidence.
+Do not refer ordinary delivery to a new Task. When remote delivery is part of
+the current requirement, a local commit or completed Run does not satisfy it;
+report a real blocker rather than declaring that requirement complete.
+
+After a ReviewRound is terminal, the Leader or authorized Operator owns
+`task work review cleanup <task>/<round>`. Preserve dirty diagnostic evidence
+and resolve it explicitly; do not ask a Reviewer to clean its own runtime
+after its final report. Cleanup can remain advisory at completion. Ordinary
+archive requires settled business and stopped execution, not complete physical
+release; safe resource retention is reported separately. Explicitly authorized force archive preserves
+unresolved resources and diagnostics under the shared
+[archive contract](../../yui-runtime/references/archive.md). The Leader
+does not gain independent archive authorization. An original explicit user
+archive request can authorize the Controller-owned ordinary archive described
+in [source-authorized capabilities](authorization.md).
+
+Complete only when the Task outcome is satisfied, required checks and review
+contracts are settled, WorkItems are accepted or deliberately retired, latest
+isolated results are integrated, and user inputs are resolved:
+
+```sh
+yui task complete <task-id> \
+  --summary "<outcome, validation, and remaining risk>"
+```
+
+Completion records the exact Project heads. Archive is a separate,
+user-authorized action, never an implication of completion or publication.
+
+Completion is offline by default. `--refresh-remote` only refreshes remote
+freshness observations; neither path rebases or starts Integration checks.
+For observation alone use `task base status <task> [--refresh]`. If upstream
+changes need integration, choose it explicitly before completion:
+`task upstream integrate <task> (--latest|--project <project>)` requests rebase
+and the configured checks/CAS. Consume its exact Integration/Job and partial
+results; a prepared candidate is not an advanced Task HEAD.
+An established final Review is still prepared/dispatched by completion without
+renewed approval. Inspect the returned stage and exact ReviewRound/Run: a
+Review-pending, running or blocked result is not Task completion.
+
+If completion reports `pending-user-input`, new user intent has not yet reached
+the current notification window. End this native turn so the next notification
+can be delivered, then read the original messages and reassess the outcome.
+Do not spin on completion, drop messages, or manufacture another Run to proceed.
+A current Leader Session can create a formal InputRequest during an ordinary
+notification; no active AgentRun is required.

package/skills/yui-leader/references/delivery-scope.md

@@ -0,0 +1,26 @@
+# Adjust Project delivery scope without erasing work
+
+When explicit user intent or an original delegation allows a Project to leave
+the final delivery, read that original Message and `task remote-delivery`.
+Record the bounded decision with
+`task project delivery <task> <project-id> --requirement excluded --reason <reason>
+--source-message <message-id> --purpose <verbatim-authorization>
+--if-current <scopeDecision.id|none>`.
+Interpret whether the original really authorizes this scope change; a matching
+quote alone is not semantic permission. Do not exclude a Project to conceal an
+unmet commitment. Ask only for a genuinely missing scope decision, not a second
+approval when existing user intent or delegated judgment already covers it.
+Use the same operation with `--requirement required` and the latest decision ID
+to restore normal checks. Reconcile a stale guard instead of overwriting newer
+intent. These append-only decisions also work on completed, unarchived Tasks
+without reopening, rewriting acceptance, or rerunning work.
+
+Unchanged Projects need no exclusion. Required changed/unknown Projects still
+need exact verified delivery. Excluded Projects retain their binding, code
+changes and Publication facts and are not counted as merged or verified merely
+because they are excluded. Scope is not execution, write, archive or deletion
+authority: open commitments and unknown execution still need settlement, and
+unique commits or dirty resources remain protected. With separate archive
+authorization, use ordinary archive/preflight and report retained resources;
+do not recommend force merely because an authorized Project is excluded.
+