@zq-silk/yui 0.15.9 → 0.15.11

package/docs/testing/verification-levels.md

@@ -53,12 +53,36 @@ regressions, and fast regressions do not establish real-model behavior.
     authentication helpers, rewritten approval records, or secrets forwarded
     to unrelated adapters; native authentication selection stays with Claude. Environment refresh
     removes revoked keys and keeps values out of durable Task/Role records.
+15. ordinary Integration conflicts continue without a decision gate; exact Git
+    receipts and an admitted Job resume interrupted delivery without replay.
+    Validation settlement distinguishes current check conditions from an
+    already-applied CAS. Migration preserves provable old bound FF Jobs and
+    classifies old conflicts without inventing successful checks.
+16. explicit force archive commits before cleanup and preserves uncertain
+    delivery/runtime evidence; partial cleanup and late results remain traceable,
+    while archived runtime resources never become automatically safe to delete.
+17. Host facts reach the existing Inbox even when its compiled store cannot
+    read the Home; Controller-side fencing, ACK-loss replay, and legacy-Host
+    upgrade refusal preserve the original execution. A frozen independent v1
+    protocol producer remains the same process across a real 19→22 migration,
+    authenticates RPCs to both Controllers through refreshed discovery, and
+    retains facts during the disconnected window. Production launch planning
+    also preserves scoped startup evidence before native Session adoption
+    without exporting a Run ID into the Session environment.
+    This fixture is the minimum supported new wire contract, not a claim that
+    pre-fix released Hosts can be hot-patched.
+    Archive racing Host ingress retains the complete source envelope without
+    reopening the Task or settling original uncertain input.
 
 Keep the test phase seconds-scale; measure TypeScript build separately. Record
 incremental runtime when adding a critical regression. The seven recovery boundary
 cases initially add about 0.4 seconds of test bodies (about 0.6 seconds standalone,
 including module startup) on the development host. Avoid sleep-based checks or
 mandatory model/daemon launches in the permanent suite.
+The Integration continuation regressions use disposable Git repositories,
+SQLite and fake Jobs, without a provider or shared Home. Their test bodies
+take about 3 seconds on the development host; validation settlement adds
+about 1.4 seconds to the initial 1.5-second coverage.
 
 ## Skill and instruction changes
 

package/docs/testing/verification-levels.zh-CN.md

@@ -43,6 +43,17 @@ Yui 是一个单用户本地产品。永久验证保护关键的 happy path 和
 14. Claude 收到其原生环境和 settings 路径，而没有被注入的认证 helper、被改写的批准
     记录，也没有把 secret 转发给无关适配器；原生认证选择仍归 Claude。环境刷新移除
     已撤销的 key，并把值挡在持久 Task/Role 记录之外。
+15. 普通 Integration 冲突可直接继续；准确 Git 与 Job 证据恢复中断交付，
+    不重放已执行的步骤，也不把已发生的 CAS 与新的验证条件混为一谈。
+16. 明确授权的 force archive 先提交归档，再独立记录清理；不确定输入与晚到
+    结果仍可追溯，归档不使保留资源自动变得可删除。
+17. 即使 Host 编译版本的存储代码无法读取 Home，事实仍先进入现有 Inbox；
+    Controller 侧归属校验、ACK 丢失重放和 legacy Host 升级拒绝保护原始执行。
+    独立冻结的 v1 协议生产者在真实 19→22 迁移前后保持同一进程，通过新 discovery
+    分别向两个 Controller 发出认证 RPC，并在断线窗口保留事实。生产 launch 路径
+    在不向 Session 环境导出 Run ID 的前提下保留 scoped 启动证据。该 fixture 代表最低
+    支持的新线协议，不声称已发布的修复前 Host 可以原地热更新。
+    归档与 Host 消费交错时保留完整来源 envelope，不重新打开 Task 或结算原不确定输入。
 
 把测试阶段保持在秒级；单独度量 TypeScript 构建。新增一个关键回归时记录其增量运行
 时长。这七个恢复边界用例在开发主机上最初约增加 0.4 秒的测试体（独立运行约 0.6 秒，

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zq-silk/yui",
-  "version": "0.15.9",
+  "version": "0.15.11",
   "description": "Local control plane for long-running native agent CLI sessions backed by tmux.",
   "license": "MIT",
   "private": false,

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

@@ -22,29 +22,56 @@ implementation patterns, scheduling options, review routing, or recoverable
 runtime actions. Create an InputRequest only for a real product choice, new
 authority, irreversible external effect, or unavailable external fact.
 
-## Choose execution topology from ownership
-
-A WorkItem is one substantial requirement with an independent owner and useful
-acceptance boundary. It is not a container for every phase, file, test,
-finding, repair, or progress update. Task type, risk labels, file count, and
-subsystem names do not determine topology.
-
-Choose the smallest useful executor:
-
-1. **Leader directly** when current context, authority, and tools are enough.
-2. **Native subagent** for bounded specialist attention or parallel
-   investigation inside the current Agent Session when a best-effort child
-   result is sufficient.
-3. **Task Role AgentRun** when work needs independent durable ownership, a distinct
-   Agent/provider or credential set, a managed workspace, or a separately
-   recoverable Session and AgentRun lifecycle.
-
-Create multiple WorkItems only when their requirements can make useful
-independent progress, normally in parallel, and the coordination and
-Integration cost is lower than keeping one coherent owner. Keep coupled
-changes together.
-
-An ordinary WorkItem uses its assignee directly; dispatch without `--lane-role`.
+## Separate the work unit, executor, and concurrency
+
+Honor the user's explicit choice of direct work or delegation. Otherwise make
+three independent judgments; Review is a fourth judgment below.
+
+**Does this result need its own management and acceptance boundary?** A WorkItem
+is a substantial result worth managing and accepting separately inside the Task.
+It need not have a different person, an independent release, or parallel execution.
+Use zero WorkItems when the Task already holds one coherent outcome. One WorkItem
+can be Leader-owned or hold a justified whole-result managed Assignment and
+Candidate. Copying the Task unchanged or displaying progress is not a reason
+to create it. Do not split analysis, editing, testing, Review, and ordinary
+repairs into phase-shaped WorkItems.
+
+**Who should execute?** Direct Leader execution is the default viable path for
+one coupled result when current context, delivery authority, and tools suffice.
+A native child can supply bounded specialist attention or parallel investigation
+inside this Session when a best-effort result suffices; it creates no Yui identity,
+authority, or WorkItem by itself.
+
+Choose a managed Worker only for a concrete benefit that repays requirement
+restatement, context reload, startup, waiting, inspection/rework, Integration,
+and lifecycle management. Benefits include safely parallel independent results,
+a needed capability or execution environment, a genuinely necessary separately
+recoverable lifecycle, freeing the Leader for another actual responsibility,
+or explicit user delegation. An available Worker, cheaper/different model,
+many files, high risk, long duration, or generic maintainability alone is not
+enough. Risk can justify independent Review without delegating implementation.
+When delegation involves a material tradeoff, leave one sentence of concrete
+benefit in the existing Brief; no form, approval, or separate decision record
+is needed.
+
+**Should separate units run concurrently?** Multiple WorkItems may run serially
+because of a real dependency, or concurrently when their results can advance
+independently and the net benefit exceeds coordination and Integration cost.
+Neither a single WorkItem nor multiple executors proves parallelism. Keep
+coupled changes together.
+
+For example, fix one coupled behavior directly in Task main, even when it touches
+many files. Delegate an independent import tool while the Leader implements its
+consumer when the two have a stable boundary and useful parallel progress.
+Keep two separately accepted stages serial when the second genuinely needs the
+first result. Do not wrap a whole Task in an `implementer` WorkItem merely because
+that Role exists.
+
+Apply these choices to new work. Do not automatically cancel an existing Worker,
+reassign/retire WorkItems, or move workspaces to conform to a new default; preserve
+their current ownership and evidence until a justified explicit change.
+
+An ordinary managed dispatch uses the WorkItem assignee; omit `--lane-role`.
 Use [replicated execution](replicated-execution.md) only when
 independent attempts over the same frozen Assignment repay their coordination
 cost. Direct managed execution already provides durable ownership.
@@ -79,8 +106,9 @@ messages and Task Brief. Neither `next-action` nor a disabled default review
 policy authorizes dropping them to make completion easier.
 
 An Integration Job's success is not the final target update. For that
-notification, read [Integration](integration.md) and finish the same
-attempt; do not start a duplicate operation.
+notification, read [Integration](integration.md) and continue from its exact
+evidence; do not start a duplicate operation. Read that guidance also for an
+ordinary Git conflict or an attempt that cannot be reliably resumed.
 
 Before dispatch, Review, Integration, or completion, inspect
 `liveTaskState.activeRuns` and `liveTaskState.activeTaskReviews` in the current
@@ -90,7 +118,36 @@ global Task lock.
 
 ## Execute the chosen path
 
-Dispatch establishes the first owner and frozen Assignment. For ordinary
+### 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
@@ -112,37 +169,72 @@ 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.
 
-For direct work, change only Task main, keep it on its managed branch, commit
-the result, and leave it clean. Run the smallest check that can catch the
-changed behavior while implementing.
+### Direct delivery with zero WorkItems
 
-For a substantial delegated requirement:
+The current delivery Leader needs no self-dispatched AgentRun or placeholder
+WorkItem. Read the full Task requirements and relevant Messages, then implement,
+verify, and fix the coherent result in Task main on its managed branch. Commit
+and leave it clean. Run focused checks while changing behavior and the required
+Project delivery checks on the final result.
 
-```sh
-yui task work create <task-id> "<title>" \
-  --project <project-to-modify> \
-  --objective "<bounded outcome>" \
-  --accept "<observable criterion>"
-```
+Keep the Brief as a current summary, not a replacement for Task requirements.
+Preserve changed intent and reasons in Messages/Decisions, substantial documents
+in Task artifacts, and code and verification evidence in the actual delivery.
+Zero WorkItems reduces coordination records, not requirements or evidence.
 
-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.
+Inspect the complete final diff and decide Review separately. If a Task-final
+Review is required or adds useful evidence, request it against the clean Task
+heads using `yui task review request <task> --role <reviewer>`. No WorkItem is
+needed. Consume the original result, fix reachable findings directly in Task
+main, and decide whether the changed result needs another Review. Honor immutable
+Review contracts and explicit user/Project requirements even if a default is
+disabled. Once the outcome and obligations are satisfied, use `task complete`
+with the outcome, checks, and remaining risk; a final chat message is not completion.
+
+### Leader-owned WorkItem
 
-For a Leader-owned WorkItem, mark it running, complete it directly, then record
-its actual result:
+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>"
-yui task work accept <work-id> --summary "<explicit acceptance 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 and mark it running. Native children inherit only current
-parent authority and gain no Yui Role, AgentRun, Session or broader workspace. Their
+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;
@@ -153,20 +245,27 @@ 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.
 
-For a managed Task Role:
+### 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>
+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
-`profile show` and `task role show` to read the exact behavior, Agent, model,
+`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.
@@ -254,8 +353,11 @@ External delivery and Task completion remain separate facts.
 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, but all
-required resources must be settled before user-authorized archive.
+after its final report. Cleanup can remain advisory at completion. Ordinary
+archive requires settled resources; explicitly authorized force archive preserves
+unresolved resources and diagnostics under the shared
+[archive contract](../../yui-runtime/references/publication.md). The Leader
+does not gain independent archive authorization.
 
 Complete only when the Task outcome is satisfied, required checks and review
 contracts are settled, WorkItems are accepted or deliberately retired, latest

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

@@ -11,7 +11,7 @@ before acceptance:
 ```sh
 yui task work capture <work-id>
 yui task integration start <task> --project <project> \
-  --change-set <change-set-id> \
+  --work-item <work-id> --strategy <ff|cherry-pick|merge|manual> \
   --check "<Project Policy command>"
 yui task work accept <work-id> --summary "<decision and evidence>"
 ```
@@ -20,7 +20,23 @@ These are distinct decisions; confirm Integration succeeded before acceptance.
 Preserve each managed workspace's owner and the Task's recorded base. Do not
 silently advance that base because a remote branch moved.
 
-## Finish the same attempt
+## Resolve ordinary Git conflicts yourself
+
+`conflicted` is an engineering step owned by the Leader, not a request for
+user authorization. Read both sides' intent and the current Task contract,
+inspect the exact Integration source, target and workspace, resolve and stage
+the files there, then run `integration continue`. No preceding
+`resolve --option manual-resolution` is required for an ordinary conflict.
+Core completes the matching Git operation, records the candidate, runs or
+recovers its exact checks and advances the original target by CAS.
+
+Do not close the Task execution gate, stop unrelated work, create an
+InputRequest or end in passive waiting merely because Git conflicted.
+Escalate only a real product choice, changed scope, unavailable external fact
+or new authority. The explicit `manual` strategy still requires a recorded
+resolution rationale; it is not the ordinary conflict path.
+
+## Continue from exact evidence
 
 For direct Integration checks running as a DurableJob, Job success is not
 the final target update. Read the terminal result, then use:
@@ -32,8 +48,42 @@ yui task integration continue <task>/<integration>
 This also applies when no manual conflict resolution was needed. Do not start
 a duplicate Integration or wait for an empty queue to finalize it.
 
+Resume interrupted Git/Job work on this attempt when its source/candidate and
+Job identities can be proved. A clean HEAD, leftover REBASE_HEAD or successful
+Job alone does not prove source application or target advancement. Read
+diagnostics when evidence is missing or the source, workspace, candidate,
+target or check conditions changed. Never blindly replay a finished rebase
+or repeat a successful unchanged check.
+
 Resolve failures using the exact conflict or check evidence and the supplied
 Integration workspace. Never bypass compare-and-swap, update managed refs by
 hand, or create a replacement WorkItem for ordinary Integration correction.
 Recheck changed behavior or unresolved failures; do not rerun unchanged
 successful validation without a current reason.
+
+## Abandon an unprovable attempt without discarding delivery
+
+If this attempt cannot safely continue, preserve its candidate, modifications,
+logs and successful evidence, then formally `integration abort --reason ...`
+(or reject a pending resolution). A failed attempt does not require keeping
+the same ID forever or repairing a shared installation before any delivery.
+Choose a new Integration or another already-authorized delivery path.
+
+For `validating`, `abort` checks the exact target and Jobs under the same Git
+fence as `continue`. An unadvanced target can be abandoned despite changed
+check conditions. If CAS already advanced the target, the action records
+`committed` instead of pretending delivery was aborted. Read the returned
+outcome. A concurrent operation, unknown Job, or ambiguous target requires
+inspection, not a forced status change or rollback of current Project policy.
+
+Formal abort preserves history and workspaces. It is not Git abort, branch
+deletion, target advancement, or proof that a Job/process has stopped.
+Inspect all Jobs owned by the exact attempt, including an unbound Job;
+cancel and establish quiescence by exact identity before reusing or cleaning
+resources. Successful Job evidence and Task acceptance remain separate.
+
+Direct Task-main delivery is an alternative only when current delivery
+authority, ownership and the Task contract already permit it, with no other
+writer or active check using that workspace. Do not edit managed refs or the
+control-plane DB, modify another owner's workspace, upgrade shared tools,
+or expand publication authority to work around an Integration failure.

package/skills/yui-operator/SKILL.md

@@ -192,7 +192,12 @@ yui task input cancel <task> <input> --reason "<Leader-owned decision>"
 After an authorized PR/MR operation or before archive, read
 [publication and archive boundaries](../yui-runtime/references/publication.md).
 Record confirmed delivery facts promptly. Completion does not authorize
-archive, and archive approval does not authorize forced cleanup.
+archive, and ordinary archive approval does not authorize `--force`.
+When the user explicitly authorizes force archive for an eligible terminal
+Task, archive even if delivery proof or cleanup is incomplete. Report the
+warnings and retained resources without claiming merge verification or physical
+quiescence. Force archive is not permission to delete dirty/uncertain resources,
+kill unrelated execution, abandon delivery or rewrite historical evidence.
 
 ## Recover from evidence, not from imagined states
 

package/skills/yui-runtime/SKILL.md

@@ -91,6 +91,33 @@ Global context grants no Task implementation workspace. Read a Task only after
 the Operator has routed to its public/task-authorized context command; never
 invent a Task AgentRun identity for a GlobalRole.
 
+A GlobalRole's durable input uses the same three actions as a Task Role,
+addressed by the Role's own name instead of a Task: `yui role message
+queue|steer <global-role>` and `yui role interrupt <global-role>`. Queue and steer
+save an owned Message; bare interrupt records a control request, not a new
+Message. Each uses a stable request id and that Role's own Session; none fabricates a Task or
+runId to reuse Task-scoped delivery. `queue` delivers at the Role's next legal
+opportunity and is idempotent by request id. `steer` and `interrupt` affect only
+the exact current native Turn — a stale `--expected-target`, an incapable plan,
+or an unproven delivery leaves the Message saved and reports the reason, and
+`interrupt` stops only through the Provider's native cancel with an optional
+`--then-message` naming one already-saved GlobalRole Message. When the Role holds
+no live managed Turn, a steer or interrupt is `NO_ACTIVE_TURN` and never falls
+back to another action.
+
+New controlled Global Sessions use the existing Host console, not the native
+TUI, with the configured Agent, permissions and workspace unchanged. A live
+unmanaged Session is not silently replaced or adopted; use an explicit Session
+lifecycle action before enabling controlled delivery.
+
+Context reads never consume queue entries. Read the referenced Message in full
+from Session Context. Native/transport acceptance is not implementation, and
+`interrupt-requested` is not a stopped Turn or stopped background resources.
+Only an exact terminal and the original Session/writer boundary can release a
+then handoff. An accepted or unconfirmed steer must not be submitted again by
+changing its request id or composing then. A conclusive rejection permits an
+explicit new control attempt; uncertainty does not.
+
 ## Preserve intent and authority
 
 An analysis, diagnosis, or review request is read-only unless the user also

package/skills/yui-runtime/references/publication.md

@@ -20,3 +20,23 @@ Completion does not authorize archive. The Operator obtains authorization for
 the exact Task, checks archive eligibility, then uses `--integrated` for verified
 merged delivery or `--abandon` for deliberate non-delivery. General archive
 approval never implies `--force` authority. Preserve the Task record.
+
+With explicit force authorization for a completed or retired Task, use
+`yui task archive <task> (--integrated|--abandon) --force`. Force commits the
+archive and stops new Task scheduling before attempting safe foreground cleanup.
+Missing/stale delivery evidence, unresolved execution and cleanup errors become
+warnings with retained resource references; they do not block that commit.
+Authority, lifecycle, identity and mandatory audit persistence still fail closed.
+
+Force does not verify a merge, accept work, stop unknown execution, discard dirty
+data or imply abandonment. Keep the requested disposition and original
+Publication/completion evidence. Unverified local commits and resources that
+cannot be safely released stay owned and traceable. Late runtime events remain
+source evidence, not authority to resume or settle unknown input.
+
+Read `task show <task> --json` for `archive.warnings`, `retainedResources` and
+cleanup events; `task context` also retains the original records/events. A
+successful archive exit means `archived=true`, not that cleanup fully succeeded.
+If cleanup was interrupted, the Task stays archived. Repeating archive only
+reports current facts; use explicit, exact-owner resource operations after
+inspection instead of re-running broad cleanup. No background retry is implied.