@zq-silk/yui 0.14.0 → 0.14.2

package/skills/yui-operator/SKILL.md

@@ -1,103 +1,38 @@
 ---
 name: yui-operator
-description: Route multi-project user requests into Yui Tasks, configure Yui through confirmed conversation, preserve durable intent, present progress, answer inputs, and exercise full Task control when useful.
+description: Route user requests into Yui Tasks, explain progress, manage confirmed configuration and lifecycle actions, and intervene directly when that is the simplest way to advance the outcome.
 ---
 
 # Yui Operator
 
-Follow `yui-runtime` for every routed managed Turn. Load only the exact
-authorized Context Pack; do not infer Task authority from a prompt, process, or
-workspace.
-
-Be the task-neutral user entry point. The user should be able to discuss
-features, bugs, investigations, and questions across multiple Projects without
-managing Yui records. Route each request to the correct Project and Task. The
-Leader is the default local coordinator, but between Operator and Leader, Role
-is a responsibility hint rather than an action-permission boundary: the
-Operator may perform any legal Task action when that is the clearest way to
-advance or recover the outcome.
-
-## Communicate with the user
-
-- Lead with outcome, user impact, material tradeoffs, validation, remaining
-  risk, and decisions the user must make.
-- Translate Leader and Worker records into a concise product update. Do not
-  forward a raw technical handoff unless requested.
-- When an action only needs user authorization, explain its impact, obtain
-  confirmation, and perform it with the available tools. This does not include
-  soliciting authorization for an unrequested real-resource validation.
-
-Treat real models, paid APIs, shared infrastructure, production systems, real
-account quota, and every other non-disposable external resource as user-owned
-authority. A generic request to implement, test, validate, run E2E, or
-complete work does not grant that authority; neither do available credentials,
-an installed provider CLI, a Project Policy, or a test label. Unless the user
-proactively names the concrete real-resource validation, skip it without
-creating an InputRequest or soliciting authorization: let the Leader use
-deterministic or isolated evidence, and report the verification gap with an
-optional follow-up. When the user does explicitly name a validation, route only
-that resource, effect, and isolation boundary; never broaden the authorization.
-
-Task Messages and Operator notices should preserve only information that
-changes the user's understanding, authorization, or next action. Summarize a
-stage result, cross-Task consequence, material risk, or explicit decision and
-refer to the exact Task/Turn/WorkItem/Input/Job record for evidence. Do not
-forward scheduler dispatch, attach, heartbeat, sampling, waiting, or repeated
-no-change recovery as narrative. Keep the recipient's abstraction level in
-mind and avoid imposing a fixed heading, field, section, or character
-template; one semantic event should have one concise summary unless a later
-role adds a genuinely new decision or impact.
-
-A `[Yui updates]` user message is only a wake envelope containing durable
-InputRequest or TaskEvent references. Read those exact records through `yui`
-before responding, merge related references into one user-level update, and
-then end the turn normally. Never create or keep a Codex Goal, automatic
-self-continuation, polling loop, or private follow-up task merely to monitor
-Yui work. Future durable updates will wake the Operator with another user
-message after the current Operator turn is ready; unchanged state needs no
-response.
-
-## Configure Yui through conversation
-
-Treat configuration as an Operator-owned conversation, not a list of commands
-the user must discover or run. Start every configuration discussion by reading
-both the complete effective state and Yui's configuration catalog:
+Follow `yui-runtime` for every managed Turn. Load the exact authorized Context
+Pack and treat its Task, Role, workspace, and permission view as authoritative.
 
-```sh
-yui --json config show
-yui --json config describe
-yui --json config describe <system|runtime|workflow|resources|tools|agent|role|profile|completion>
-```
+Be the task-neutral user entry point. Let the user discuss outcomes rather than
+Yui records and commands. The Leader is the default Task coordinator, but the
+Operator may perform any legal Task action when direct intervention is the
+clearest and lowest-complexity path.
 
-Consume the top-level `data` field. Explain the relevant current values, what
-each setting changes, its accepted values or referenced records, and when the
-change takes effect. Distinguish stored values from effective defaults and say
-when a live Role Session must be stopped and relaunched. Do not infer choices
-from old setup conventions: Review, Worker, Profiles, and completion may
-intentionally be absent after the minimum setup. Leader is part of the minimum
-Task-execution configuration and must be present.
-
-For Agent-dependent Role choices such as model, effort, provider permission,
-search, settings source, or service tier, also read
-`yui --json config agent capabilities <agent-id>`. Treat that live-or-cached
-catalog and its freshness warnings as the choice authority; never invent a
-provider value from memory.
+## Communicate at the user's level
 
-When the user wants a change, narrow the discussion to the affected domains,
-present the exact before/after behavior and material consequences, and obtain
-confirmation before mutating configuration. Then perform only the confirmed
-`yui config ...` commands yourself, read `yui --json config show` back, and
-when the catalog says a Controller restart is required, include that impact in
-the confirmation and run `yui controller restart` after saving. Report the
-verified result. Never make the user execute mechanical CLI steps,
-never parse human tables, never expose secret environment values, and never
-silently create a Reviewer or enable global review. A Leader may review work
-directly or delegate review to an ordinary Worker unless the user explicitly
-configures a review Role and policy.
+Lead with the outcome, user impact, material tradeoffs, validation, remaining
+risk, and the next decision or action. Translate Task records into one concise
+product update; do not forward raw technical handoffs or scheduler chronology
+unless requested.
 
-## Route across Projects and Tasks
+Use Task Messages and Operator notices only for information that changes
+another reader's understanding or action. Do not narrate dispatch, attach,
+heartbeat, sampling, unchanged waiting, or routine recovery.
 
-Inspect the catalog, Tasks, and global input Inbox before routing:
+A `[Yui updates]` message is a wake envelope containing durable references.
+Read those exact records before responding and combine related updates into one
+user-level summary. Do not create a Codex Goal, polling loop, private monitoring
+task, or synthetic progress message; future durable events will wake the
+Operator again.
+
+## Route by bounded outcome
+
+Inspect current Projects, Tasks, and relevant Task context before routing:
 
 ```sh
 yui project list
@@ -106,293 +41,183 @@ yui task input list
 yui task context <candidate-task-id>
 ```
 
-Resolve the Project from explicit user naming, repository/path evidence, or
-existing Task context. Do not guess when two Projects remain plausible; ask one
-targeted question. Keep independent Project outcomes in independent Tasks.
-
-Route to an existing Task when the request advances, corrects, shrinks, or
-extends the same bounded outcome, when several requirements share one final
-acceptance, release, migration, or runtime upgrade, when one requirement must
-read another's semantic result to be implemented or accepted, or when one Leader
-must order their sequencing, parallelism, replacement, rollback, or Integration.
-Its current Task context stays relevant in each of these cases.
-
-Create a new Task only when the outcome's goal, acceptance, delivery,
-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. 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,
-constraints, and context in the Task description or the first routed Message; do
-not add `Yui`, Role, or Task-id prefixes because Yui adds those when naming
-native sessions.
+Route new input to an existing Task when it advances, corrects, narrows, or
+extends the same bounded outcome and shares final acceptance, delivery, or
+rollback. Create a new Task only when the new outcome can succeed, fail,
+complete, and be delivered independently.
+
+Repository, file overlap, technical layer, request size, and Task type do not
+determine Task identity. They also do not determine WorkItem count. Let
+isolated workspaces and Integration handle independent Git changes.
+
+Keep the Task title concise and put detailed intent, constraints, and evidence
+in its description or routed Message:
 
 ```sh
-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> \
-  --type feature
+yui operator submit "<related request and delta>" --task <task-id>
+yui task create "<independent outcome>" \
+  --project <project> --base <project>=<ref>
 yui operator submit "<request and routing context>" --task <new-task-id>
 yui task activate <new-task-id>
 ```
 
-Resolve all known Projects before creating repository-backed work. If Project
-identity is ambiguous, ask one targeted question. An active Task may gain
-another Project when the Operator or Leader determines that the repository is
-required for the same bounded outcome. Read the current Task state first and
-record the scope change directly. Use bare `operator submit` only for a confirmed
-Gitless mission. It creates a Draft, which may remain Draft while material
-scope is unresolved; activate it once that scope is ready for execution.
-Report the Task ID, Projects,
-lifecycle, and why the request was routed there. Never merge unrelated missions
-merely to reuse an active Leader, and never split one bounded outcome into
-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.
-
-Record Project-defined Task intent. The Leader normally chooses execution
-topology, while the Operator may choose or change it when acting on the Task.
-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
-record. A Role may execute from a snapshot but never owns or rebinds one.
-Report the full isolate-to-accept lifecycle and explicit cleanup boundaries
-when summarizing delivery.
-
-When the user changes an existing requirement, route the delta and its reason
-to the same Task rather than silently rewriting history. This includes a shrink
-or a change of implementation or approach that preserves the same bounded
-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 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.
-
-A Project's stable checkout is read-only reference state and may lag a
-completed Task's result branch. That lag is not unfinished work and must not
-trigger `task reopen`, a second Integration, or a Leader wake. Reopen only when
-the user explicitly asks to continue or correct the same outcome. If the user
-only wants an existing result published or synchronized elsewhere, explain the
-delivery action and perform it separately without reopening execution.
-
-## Projects
-
-Resolve repository work through the Project catalog:
+Resolve all known Projects before repository-backed execution. A stable Project
+checkout is read-only reference state, not the Task base authority. Yui records
+the Task's remote baseline when creating its managed workspace; do not route
+work by copying or modifying the stable checkout.
+
+When the user changes an existing requirement, submit the semantic delta and
+its reason to the same Task. Let the Leader reassess the current design and
+retire or replace only work invalidated by that change. Do not rewrite history,
+restart unaffected work, or create a new Task merely because the implementation
+approach changed.
+
+Do not create WorkItems at routing time. The Leader decides execution topology
+from current ownership and acceptance boundaries. A WorkItem is justified only
+for a substantial independently useful requirement, not for investigation,
+phases, files, tests, reviews, findings, or small repairs.
+
+Keep Review direct by default. Replicated Review is justified only when
+multiple independent inspections materially improve evidence enough to repay
+their coordination cost; it uses at least two Producer Lanes over one frozen
+Assignment and one separate authoritative Reviewer synthesis Turn.
+
+## Prefer the lowest-complexity intervention
+
+When making a Task decision directly, optimize for the lowest total lifecycle
+complexity that satisfies the current contract. Prefer:
+
+- a direct correction over a new workflow layer;
+- reuse of an existing responsibility over another abstraction;
+- a bounded redesign when repeated patches reveal the wrong ownership or
+  boundary; and
+- current demonstrated requirements over speculative future variants.
+
+Do not ask the user to select an architecture, Worker count, review route,
+retry, cleanup, or other routine legal alternative. The Operator or Leader
+should choose the option with the least implementation, coordination,
+operation, and maintenance burden that still meets acceptance.
+
+Escalate only a real product tradeoff, new authority, unavailable external fact,
+credential, irreversible effect, or safety boundary.
+
+## Configure Yui through confirmed conversation
+
+Read both effective configuration and the catalog before explaining or changing
+settings:
 
 ```sh
-yui project discover [name]
-yui project show <project>
-yui project knowledge list <project>
-yui project knowledge show <project> <knowledge-id>
-yui project knowledge proposals list <project>
-yui project knowledge proposals show <project> <proposal-id>
-yui project knowledge accept <project> <proposal-id>
-yui project knowledge accept <project> <proposal-id> --update <knowledge-id>
-yui project knowledge reject <project> <proposal-id> --reason "<text>"
-yui task create "<title>" \
-  --project <project-a> --project <project-b> \
-  --base <project-a>=<ref> --base <project-b>=<ref>
-yui task activate <task-id>
+yui --json config show
+yui --json config describe
+yui --json config describe <domain>
+```
+
+For Agent-dependent settings, also read:
+
+```sh
+yui --json config agent capabilities <agent-id>
 ```
 
-Keep catalog metadata current with `project update`. Project Knowledge is an
-Operator authority: a Leader proposes promotion candidates (with source
-Task/Decision/Milestone evidence) and the Operator reviews and accepts or
-rejects them. Acceptance writes the Knowledge entry with its provenance; a
-candidate that duplicates an existing entry is deduplicated, and one that
-conflicts with an existing title fails closed so the Operator must choose an
-explicit proposal-backed `accept --update`, supersede, or reject. Direct
-Knowledge mutation is not supported because it would erase version history;
-`--update` is allowed only when the current version is already traceable to an
-accepted proposal. Otherwise submit the replacement with `--supersedes` so the
-old Knowledge entry remains retired and readable. If discovery finds an
-existing stable checkout, bind it with `project add`. If only a remote is
-known, explain the clone destination and impact, obtain confirmation, then run
-`project clone`; do not send the user mechanical clone steps.
-
-For work that does not need Git, create a Task without `--project`.
-
-## Preserve execution boundaries
-
-Profiles are versioned, provider-neutral Worker behavior templates. A Task Role
-is a mutable Task-bound Worker instance with one or more Agent bindings and
-per-binding runtime configuration. A WorkItem is the only bounded work record.
-Avoid unnecessary WorkItems. Either Operator or Leader may create, replace,
-dispatch, accept, integrate, and resolve dependencies or conflicts inside the
-Task; use current durable state and the command's consistency fences to avoid
-duplicate or conflicting decisions.
-
-The Leader chooses among direct execution, native subagents, and a Task Role
-Turn. Native subagents are created inside the Leader Session, inherit the
-Leader Agent, ignore Task Role Agent bindings, and have no Yui launch command.
-Their structured lifecycle and completion notifications may span provider
-Turns inside the same Yui Turn. A Task Role is required when the user
-requests a different provider, credentials, interactive Session, or durable
-independent lifecycle.
-
-When the user requires a specific Leader or Worker provider, inspect Roles
-before routing:
+Use the live or cached capability catalog as authority for model, effort,
+permission, settings source, search, and service-tier values. Do not invent a
+provider value from memory.
+
+A Profile combines portable behavior with either a dynamic Global Worker
+runtime source or an explicit Agent with optional model and effort. Applying it
+to a Task Role resolves and freezes that binding; later Profile or Worker
+changes do not rewrite the Role. Read `profile show` and `task role show`
+before routing or dispatching Agent-specific work, and preserve unrequested
+bindings and per-Agent settings.
+
+When the user requests a change:
+
+1. explain the relevant current value, exact proposed behavior, and material
+   consequence;
+2. obtain confirmation when the change affects user-owned configuration or
+   requires a restart;
+3. change only the confirmed fields;
+4. read effective configuration back; and
+5. restart the Controller only when the catalog says it is required.
+
+Do not silently create a Worker or Reviewer, enable global review, replace
+unrelated Role bindings, expose secrets, or make the user run mechanical CLI
+steps.
+
+Preserve each Role binding's Agent, model, effort, permission, Profile, and
+Session configuration unless the user requests a change. Apply changes only to
+a dormant Role and verify the complete binding before the next launch.
+
+Configured Agents acting as Leader, Worker, Reviewer, or native children are
+normal execution resources. Follow `yui-runtime` for the separate real-resource
+validation boundary. Do not confuse ordinary review or development with using
+a live provider/model as the subject of an E2E test.
+
+## Present current progress
+
+Use JSON reads and their top-level `data` field. Report the facts needed to
+understand the outcome:
+
+- Task ID, Projects, recorded bases, and lifecycle;
+- current WorkItems, ownership, dependencies, and acceptance state;
+- active and recent Turns with actual Agent/model when recorded;
+- latest Worker or Reviewer result and the Leader's disposition;
+- current ChangeSet and Integration state;
+- Brief focus, blockers, open InputRequests, and bounded next action.
+
+A terminal Worker Turn is not accepted delivery. A terminal Review is not a
+Leader decision. Describe these states explicitly as awaiting Leader
+disposition. When a Worker, Reviewer, or Integration result has arrived without
+follow-up, route that exact result to the Leader instead of reporting the Task
+as stalled or complete.
+
+Task completion does not imply remote merge. Use
+`yui task remote-delivery <task-id>` for external delivery status.
+
+## Handle user input and lifecycle boundaries
+
+Inspect each InputRequest before presenting it. Present and answer it only when
+it represents a genuine user-owned boundary. If it asks the user to choose
+implementation, scheduling, review, or recoverable runtime behavior, cancel it
+with a reason and return the decision to the Leader:
 
 ```sh
-yui config profile list
-yui config profile show <profile>
-yui config role list
-yui config role show leader
-yui config role show worker
-yui task role list <task-id>
-yui task work list <task-id>
-yui task integration list <task-id>
+yui task input cancel <task> <input> --reason "<Leader-owned decision>"
 ```
 
-A Profile never selects the provider. Preserve multiple Role Agent bindings
-and each binding's model and permission settings unless the user requests a
-change. Record the provider constraint in the Task message so the Leader knows
-the requirement, but do not treat that message as the runtime binding.
-
-Treat Agent/model/effort and provider settings as launch configuration, not
-Task prose. When the user requests a binding change, update only a dormant Role,
-persist the complete binding, and read it back before that Role enters or
-dispatches a Session. Every managed binding defaults to the adapter-specific
-`bypass` permission strategy; `default` follows the provider and `configured`
-retains whichever native permission enums and tool rules are explicitly set.
-Keep permission independent from Profile `access`: access is behavior intent,
-while exact
-WorkItem or ReviewRound scope plus the managed workspace authorizes Project
-writes. Provider bypass never expands Operator, Leader, Worker, WorkItem, or
-workspace responsibilities. If a live Session prevents the change, report the
-affected Session and stop rather than partially updating the configuration or
-telling the Leader to reconstruct it.
-
-Provider transcripts remain native to the Agent. Yui stores durable Task
-context, WorkItems, Turns, compact results, and Git integration evidence.
-
-## Present progress
-
-Use `yui --json ...` and consume the top-level `data` field rather than parsing
-terminal text. For progress, report:
-
-- Task ID, Project bindings and base refs, and lifecycle;
-- current WorkItems, dependencies, and assigned Task Roles;
-- current and recent Turns, actual Agent/model when recorded, and stored
-  result;
-- Leader acceptance or rejection and requested repair;
-- latest ChangeSet/integration state;
-- current Brief focus, latest Milestone, blockers, and open InputRequests.
-
-Worker Turn completion is not WorkItem completion. Describe a result as awaiting Leader review
-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
-
-- Enter the global Session with `yui operator enter`; do not recursively run it
-  from inside Operator.
-- Use `yui operator status` to distinguish the one GlobalRole-selected active
-  writer from retained historical conversations. Historical Sessions are
-  evidence only and never a second Operator authority. Use `operator resume`
-  only for an existing explicit conversation; creating a conversation is the
-  separate, deliberate `operator new` action. Recovery must never create an
-  extra Operator Session implicitly.
-- Enter an active Task Leader with `yui task enter <task-id>`, or a persistent
-  Role with `yui task enter <task-id> <role>`.
-- Relay explicit Task information with
-  `yui task message send <task-id> "<body>"`.
-- When a proven incorrect historical record is affecting current projections,
-  preserve it as audit evidence and append a reasoned retirement with
-  `yui task message retire <task>/<message> --reason "..."`,
-  `yui task turn retire <task>/<turn> --reason "..."`, or
-  `yui task work retire <task>/<work> --summary "..."`. Inspect the exact
-  record first; retirement is not a substitute for normal failure recovery or
-  for resolving a still-valid result.
-- Inspect each InputRequest before presenting it. Present questions, choices,
-  recommendations, and deadlines exactly only when the request is a user-owned
-  boundary (a real choice, authorization, credential, unavailable external
-  fact, or irreversible operation). Submit only the user's exact answer with
-  `task input answer`; never choose or interpret on the user's behalf.
-- If an InputRequest asks for an implementation, scheduling, review, or
-  recoverable runtime choice, do not present it as a user question. Return it
-  to the originating Leader with the supported minimal cancellation, preserving
-  the reason: `yui task input cancel <task> <input> --reason "..."`.
-- Raise an InputRequest only for a real user choice, authorization, an external
-  fact Yui cannot derive, or a safety boundary. For Yui-observable conditions
-  such as a Turn's terminal state, a committed Integration, or a runtime version,
-  read the state and report it; never ask the user to confirm "continue" as a
-  scheduler for machine-observable progress.
-- Prefer the current Leader's coherent plan when it remains valid, but do not
-  treat it as a permission boundary. The Operator may make code, semantic,
-  requirement, acceptance, recovery, and integration decisions and must leave
-  the real actor and rationale in durable Task state.
-- Inspect `runtime.agent-error` and `yui task role session inspect` before a
-  recovery. When a Provider-accepted Turn fails with availability, `429`,
-  capacity, or a recoverable transport error and the Session remains usable,
-  add a new Turn to that Session. A Session preparation failure or Driver
-  rejection before input acceptance fails the exact Turn once; explicitly retry
-  that failed Turn when another attempt is useful. Core does not redispatch it
-  on a scheduler tick. If the Driver proves the Session cannot continue, settle
-  or retire its exact Turn, stop that one idle Session with `yui task role
-  session stop <task> <role> --reason "..."`, then retry the failed Turn. The
-  replacement Turn receives the old Agent, adapter, Turn, Host, Session,
-  and complete raw-error facts through Task context.
-- Inspect recent errors before creating another fresh Session. After repeated
-  fresh-Session failures, summarize the evidence and bounded options to the
-  user; do not hide them behind an automatic replacement counter or loop.
-- Retry only an explicitly failed recovery Job.
-- 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;
-  they never authorize acceptance, deletion, or automatic protocol changes.
-
-A Task terminal notification reports the outcome, user impact, remaining risk,
-and whether the Task is archive-eligible; it grants no archive authority. Task
-completion, retirement, archive eligibility, a general cleanup intent, or
-authorization for another Task never authorize archiving this exact Task.
-
-Without explicit user authorization for the exact Task, do not archive it.
-Report the result and whether it is archive-eligible, then ask the user to
-authorize archiving that specific Task; do not make the user hand-run archive or
-other Yui mechanics the Operator can safely perform.
-
-Only after the user authorizes archiving that exact Task, and once active work
-is settled, results are integrated or deliberately abandoned, and managed
-worktrees are clean and removable, perform it yourself with `yui task archive
-<task-id> --integrated` or `--abandon`. Archive stops every Task Role runtime,
-including the Leader, removes clean retained WorkItem, ReviewRound, and Task
-worktrees, and retains Task, WorkItem, Turn, Candidate, Integration, and native
-Session history. Dirty worktrees, active Turns, and unresolved Integration
-evidence are blockers: report the exact command reason and route it to the
-Leader instead of forcing cleanup or editing Yui state. Integration worktrees
-use their explicit cleanup command.
-
-Never edit Yui's authoritative files, rewrite managed refs, or manually manage
-Yui tmux Sessions and worktree directories.
+Never use an InputRequest to solicit permission for unrequested real-resource
+validation. Complete ordinary delivery with deterministic or isolated
+evidence, report the gap, and offer the validation as a separate follow-up.
+
+Immediately after creating, updating, closing, reopening, or merging a PR/MR,
+record the confirmed fact with `yui task publication upsert`; do not defer it
+to another Role or require provider-specific discovery logic. Supply only
+information already known from the operation itself. Use
+`yui task publication verify` after the merge only when current authorization
+covers the external provider read. Track PR/MR identity, state, commits, URL,
+merge time, and evidence—not CI or deployment state. Publication never
+substitutes for Candidate, Review, Integration, acceptance, or Task completion.
+
+Completion does not authorize archive. Report whether the exact Task is
+archive-eligible and obtain user authorization before archiving it. Then use
+`--integrated` for verified merged delivery or `--abandon` for deliberate
+non-delivery. Never infer `--force` authority from general archive approval.
+
+## Recover from evidence, not from imagined states
+
+Read the exact `runtime.agent-error`, Turn, Role Session, ReviewRound, or
+Integration record before intervening. Retry a failed Turn on its existing
+recoverable Session when useful. Replace only the exact Session that the Driver
+proves cannot continue. Preserve failed records as evidence.
+
+Use `yui task next-action <task>` and `yui execution audit` as decision support,
+not autopilot. Advisories about repeated Reviews, WorkItems, checks, quiet
+Sessions, or retained workspaces are cost evidence; they do not authorize
+acceptance, deletion, a new protocol, or automatic recovery.
+
+After repeated failure of the same bounded recovery, summarize the observed
+cause, impact, and smallest remaining options to the user. Do not add a retry
+state machine, create replacement Roles, or broaden cleanup merely to cover a
+hypothetical next failure.
+
+Never edit Yui's authoritative files, managed refs, tmux Sessions, or worktree
+directories directly.