ultra-builder-pro-cli 0.26.2 → 3.0.2

package/docs/WORKFLOW-LIFECYCLE.md

@@ -18,16 +18,41 @@ ultra-status    read-only router at any point
 ultra-delegate  orthogonal bounded execution on another CLI
 ```
 
-Arrows are recommendations, not automatic invocation. The owner explicitly selects
-each public workflow. Delivery archives one stable `change_id`; the next request opens
-a new active id while prior task rows remain in the append-only ledger.
+Arrows are recommendations, not automatic invocation by default. The owner explicitly
+selects each public workflow unless a live owner-activated execution grant
+(session-local activation or a stably verified durable work-package grant)
+authorizes the host model to select only the covered Research,
+Plan, Dev, Test, and reconcile-only Deliver routes. Init, Change, Delegate, Status,
+final archive, and every external effect remain owner-selected. Delivery archives one
+stable `change_id`; the next request opens a new active id while prior task rows remain
+in the append-only ledger.
+
+## Topology and checkpoints
+
+The owner chooses the Agent topology at every stage: one Agent or several, which
+providers, which write scopes, serial or parallel. The unspecified default is the
+current Agent continuing alone — no automatic spawning, delegation, or control-plane
+enablement, and no provider permanently bound to a role. One primary writer owns the
+canonical `.ultra` files in a worktree; parallel source writes use isolated worktrees
+with explicit integration. Moving the primary-writer role itself to another Agent is
+an owner-granted primary transfer — OFFER, verified ACK, sole-writer execution,
+frozen terminal RESULT — and never a widened delegation
+(`skills/ultra-change/references/primary-transfer.md`).
+
+Every owner-facing checkpoint — a WIP at a stop, a closing Resume Note, a delivery
+report — carries the eight fixed semantics defined in
+[artifact authority](ARTIFACT-AUTHORITY.md#owner-checkpoint-semantics): why, outcome,
+accepted boundary, delta, reality, decision needed, next bounded action, and not-done.
+Checkpoints are cognitive interfaces, not stage markers; alignment failure stops work
+until the owner re-accepts an outcome.
 
 ## Common entry contract
 
 Every user-invoked Skill reads, in order:
 
 1. zero or one `.ultra/changes/active/<change_id>/intent.md`; more than one is a conflict;
-2. `.ultra/tasks.json`, selecting only tasks whose `change_id` matches that active id;
+2. `.ultra/tasks.json`, selecting only tasks whose `change_id` matches that active id
+   and treating its v2 row as the sole task-status authority;
 3. the matching frontier task's `context_file` and closing `## Resume Note`;
 4. `.ultra/project-brief.md`, the accepted `.ultra/north-star.md`, `CONTEXT.md`, and
    relevant `.ultra/decisions/`, where those artifacts already exist;
@@ -76,10 +101,11 @@ reconciliation before planning when the accepted contract needs an update.
 
 A micro edit that makes no specification sentence false stays outside the Ultra
 lifecycle and uses ordinary repository TDD/verification. Once an active Change exists,
-even a `quick` profile receives one minimal Plan task so evidence and delivery remain
-bound to its id. A separate request cannot open a second active Change: finish or
-deliver the current one, abandon it with owner authority, or explicitly reconcile the
-new request into the same stable id.
+Plan creates the smallest graph justified by the real seams, evidence, review, and
+recovery needs so delivery remains bound to its id; a profile never fixes task count. A
+separate request cannot open a second active Change: finish or deliver the current one,
+abandon it with owner authority, or explicitly reconcile the new request into the same
+stable id.
 
 ## Planning
 
@@ -88,27 +114,75 @@ current-Change task graph and one context file per task without deleting histori
 rows. The model chooses ordinary technical seams; the owner is asked only when a seam
 changes a public contract, accepted risk, or another material trade-off. Every task
 stores the stable `change_id`; dependencies stay inside that Change and ids remain
-globally unique. Feature tasks are tracer bullets. A contract task precedes cross-process
-or cross-top-level-boundary implementations; integration checkpoints appear after
-several slices. Cycles and broken trace paths are repaired before handoff.
+globally unique. Feature tasks are tracer bullets. A contract task precedes dependent
+implementations when a shared contract must remain valid across independently changed
+boundaries; integration checkpoints appear where slices first compose or observed
+coupling and recovery risk justify a whole-path check. Cycles and broken trace paths are
+repaired before handoff. Complexity, file, task, line, and context counts are
+observations rather than plan-quality gates.
 
 ## Task development
 
 `ultra-dev` writes the implementation plan into the task context before code. It uses
-`ultra-tdd` on confirmed seams, records six evidence dimensions, and keeps ledger and
-context status synchronized. The closing Resume Note is rewritten even when work stops
-early.
-
-Task review uses six independent lenses. Findings move through stable JSON artifacts,
-not intermediate worker chatter. Refactoring happens after the evidence makes real
-duplication or coupling visible.
+`ultra-tdd` on confirmed seams and records `ultra-task-evidence-v2`: typed acceptance,
+six evidence dimensions, subject/context identity, limitations, and task-review
+provenance. `.ultra/tasks.json` is the sole task-status authority; a new context has no
+Status field, while legacy Status/Complexity values are migration diagnostics and the
+ledger wins. The closing Resume Note is rewritten even when work stops early.
+Before publishing that record, Dev hashes bounded stable repository-contained bytes for
+every command or external `raw_evidence_ref` into `raw_evidence_sha256` and reads both
+the raw receipt and written record back. Structural validation checks ref/digest shape
+without dereferencing the receipt.
+
+Task review selects lenses by risk and touched seams while the ledger row remains `in_progress`.
+Its first admission binds the ledger, task context, immutable packet scope, and actual
+pre-review evidence. It does not require a final v2 record or claim a task worktree
+digest that Worker Packet v1 does not carry.
+Findings move through stable JSON artifacts, not intermediate worker chatter. Verdicts
+are terminal for the current subject: `APPROVE` ends the task review even when P2/P3
+findings are retained — they become report entries or owner-selected backlog, never a
+fresh review of the same subject. `REQUEST_CHANGES` routes only the exact current
+P0/P1 findings as one in-scope repair set followed by one affected-lens delta review
+per repair set inside the active review budget — an exact current owner grant
+overrides the versioned product default of one initial review plus at most two
+P0/P1 delta reviews per package; a `REQUEST_CHANGES` that would exceed the active
+budget is an owner checkpoint, not another automatic repair, and the same root
+surviving three failed fixes stops point-patching and reports an architecture
+problem. Lens selection follows the review kind, never a fixed count: an initial task
+review selects `review-spec` plus the lenses justified by risk and touched seams, a
+delta review reruns only the affected lenses, and an aggregate Change review may
+default to all six only when cross-task wiring justifies it. Budget exhaustion keeps the row `in_progress` and returns
+`owner checkpoint` / `budget_exhausted` without any semantic verdict.
+After the final summary validates, Dev independently captures the `subject`
+as a completion-snapshot freshness observation and immediately writes the one canonical
+v2 record; its `task_review` separately binds the retained strict summary, which does not
+prove the subject worktree digest. Only then may the primary model write `completed` to
+the ledger. Refactoring happens
+when evidence makes real duplication, coupling, or a boundary defect visible, never
+because a slice, finding, file, or repair-round count crossed a threshold.
+
+If later work invalidates completed evidence, Dev records the affected criterion IDs and reason in the context Change Log and Resume Note before changing the
+ledger-authoritative row from `completed` to `in_progress`; there is no silent demotion.
+The old frozen review remains historical evidence while the reopened task refreshes the
+affected observations, obtains a new final review, and captures a new completion subject.
 
 ## Whole-system audit
 
-`ultra-test` runs once after tasks for the active Change are complete. It checks anti-patterns, coverage,
+`ultra-test` runs once after tasks for the active Change are completed in the ledger
+with current v2 evidence and retained task-review provenance. Historical v1 evidence is
+a migration diagnostic, not current Test input. It checks anti-patterns, coverage,
 wiring, E2E behavior, performance, and security. It names the exact Git commit and
 binds the report to `change_id`, exact current task ids, intent SHA-256, and the
-product-worktree digest. `passed: true` implies complete current tasks and no required
+product-worktree digest for the current whole Change. Each task evidence subject remains
+its independently captured completion-snapshot freshness observation rather than being
+rebound to this aggregate identity. Test independently rechecks current Acceptance bytes,
+criterion IDs and verification types, retained task-review summary, durable owner record,
+and cited affected artifacts. For command and external evidence it independently takes
+the bounded stable non-symlink raw bytes, recomputes `raw_evidence_sha256`, then recomputes
+the containing record's `evidence_digest`. `.ultra/evidence/**` is excluded from the
+product-worktree digest, so these separate exact bindings prevent a self-referential
+receipt. An invalidated task returns to the explicit Dev reopen
+path. `passed: true` implies complete current tasks and no required
 area left `not_run`; task completion does not force a pass, and dispositioned gaps stay
 visible. It never turns an orphan,
 failed command, stub, or omission into permission to alter scope.
@@ -139,13 +213,21 @@ effects. Readiness grants none automatically.
 - draft or blocking active intent → change;
 - unsatisfied Research Disposition → research;
 - active Change without matching executable tasks → plan;
-- matching pending or in-progress task → dev;
-- completed current-Change tasks without a matching fresh report → test;
+- the unique matching `in_progress` task → dev;
+- only `pending` tasks remaining → report them as frontier candidates and recommend
+  one exact task id for an explicit owner invocation of dev;
+  - a completed ledger row with missing, stale, or invalid v2 evidence/task review → dev
+    to record affected criteria and reason, explicitly reopen, and repair provenance;
+  - completed current-Change tasks with current v2 evidence and no matching fresh report → test;
 - false report → route by finding and owner disposition, not by the boolean alone;
 - fresh, dispositioned report and unarchived Change → deliver.
 
-It also checks installation provenance, stale reports, old in-progress work, and
-unresolved markers. It does not mutate artifacts.
+It also checks installation provenance, unresolved markers, broken resume paths, and
+report freshness by root Change identity, exact ordered v2 task-evidence/review
+identities, and strict aggregate Review packet/admission/subject/summary bindings. It
+replays the existing structural validators; they observe transport and freshness but
+never decide semantic acceptance. Age, complexity, and file/task counts may be reported
+as context but never decide staleness or quality. It does not mutate artifacts.
 
 ## Delegation
 
@@ -170,14 +252,19 @@ Every durable output has a later reader:
   planning, development, audit, review, status, and delivery; an abandoned intent has
   an exact `## Abandonment` closure consumed by future Change reconciliation and Status;
 - the append-only task ledger and contexts are the common resume input after filtering
-  by active `change_id`, while task evidence feeds
-  review, whole-system audit, and delivery;
+  by active `change_id`, while typed v2 task evidence and retained task-review
+  provenance feed review, whole-system audit, and delivery;
 - the current test report is consumed by status and delivery;
 - delivery moves with the Change into archive and remains historical evidence.
 
 `ultra-status` intentionally writes nothing. Review, Hook, compact, and delegation
-files are derived observations with explicit rebuild or rerun paths. No route creates
-an unowned drift log, Change plan, technical-debt report, or second delivery summary.
+files are derived observations rather than semantic authority. A current strict review
+session contains `WORKER-PACKET.json`, `ADMISSION.json`, every selected specialist
+artifact, and `SUMMARY.json`; retain it until aggregate Test and Deliver have both consumed it
+successfully, then it may be garbage-collected. Premature loss requires a fresh Review
+and Test; never reconstruct the old receipt. Other derived observations keep their
+explicit rebuild or rerun paths. No route creates an unowned drift log, Change plan,
+technical-debt report, or second delivery summary.
 
 ## Interruption and cross-host continuation
 
@@ -193,6 +280,17 @@ the common entry contract and compares the working tree with those claims.
 This path remains valid when hooks and `ubp` are disabled. A compact snapshot may be
 used as a hint, then checked against canonical files and Git.
 
+Continuing on a different Agent — not merely a different host — additionally
+requires a primary transfer: an exact owner grant, a derived OFFER binding the
+canonical refs, HEAD, and worktree digest, the receiver's stable-read ACK, and a
+frozen terminal RESULT (`skills/ultra-change/references/primary-transfer.md`).
+Receipts are derived state; when they are lost, the owner confirms and a fresh
+handoff id is issued rather than reconstructing an old ACK. The post-review
+task closeout never refreshes that RESULT or opens a handoff for itself: beside
+a newest completed v2 RESULT it publishes the handoff's CLOSEOUT receipt — the
+one prescribed, uncommitted, review-and-handoff-free closeout transition of the
+same contract.
+
 An authenticated Claude-to-Codex continuation using this path passed on 2026-08-03;
 the exact scope, provenance, results, and limitations are recorded in the
 [runtime compatibility matrix](RUNTIME-COMPAT-MATRIX.md#authenticated-cross-host-continuation-evidence).

package/docs/evals/adversarial-review-2026-08-14.md

@@ -0,0 +1,84 @@
+# 对抗性审查盲测记录 — 2026-08-14
+
+## 结论
+
+本轮证据不支持增加永久第七个 `premise` lens。当前 `review-spec` 在明确要求校验
+North Star 因果贡献后，已经覆盖候选 lens 的五类已知缺陷；候选 lens 没有稳定找到
+当前 roster 漏掉的 consequential defect class。
+
+因此保留六 lens roster，把 premise challenge 固化到 `review-spec`，并把独立
+`premise` 角色保留为 Plan 与 aggregate Test 的 blind cross-family probe。这个 probe
+是隔离采样，不参与投票，也不能用无效结果替代六 lens findings。
+
+## 评估边界
+
+- Fixture revision: `37c07dc8596cda64a93aac260917b3c091ad1b58`
+- Hidden seeds: `tests/evals/adversarial-review-seeds.json`
+- Current prompt: `tests/evals/prompts/current-spec-lens.md`
+- Candidate prompt: `tests/evals/prompts/candidate-premise-lens.md`
+- Six-lens probe: `tests/evals/prompts/current-six-lens-probe.md`
+- Permission: read-only、无 external effects、独立 Git worktree
+- Claude Code: `2.1.232`
+- Kimi Code: `0.31.1`，显式模型 `kimi-code/k3`
+- Grok Build: `1.0.3 (1a29d5bc12d4)`
+- ZCode CLI: `0.16.3`，临时非持久化 provider 配置，GLM-5.3
+
+Seed manifest 从所有 Worker Packet 中隐藏。所有有效结果都通过
+`ultra-delegation-result-v1`、packet digest、只读 diff 和 launcher strict validation；
+模型陈述“未修改文件”本身不算权限证据。
+
+## Seed 映射
+
+| Run | Premise | Correctness | Test coverage | Recovery | Documentation | 可计分 |
+|---|---:|---:|---:|---:|---:|---:|
+| `spec-claude` / current spec | yes | yes | yes | yes | yes | yes |
+| `premise-claude` / candidate | yes | yes | yes | yes | yes | yes |
+| `six-kimi` / current six concerns | yes | yes | yes | yes | yes | yes |
+| `spec-zcode-3` / current spec | yes | yes | yes | yes | yes | yes |
+| `spec-grok-4` / current spec | partial raw text | partial raw text | partial | no stable result | partial | no |
+| `premise-grok-4` / candidate | partial raw text | partial raw text | partial | partial | partial | no |
+
+Claude 的 candidate 产生了比 current spec 更多的表述和风险拆分，但没有新增 seed class。
+Kimi 的完整六关注面与 ZCode 的 current spec 都再次找到五类 seed，说明 premise/causal
+挑战可以被最窄地放进 specification fidelity，而不必增加一个永久 lens。
+
+Grok 四轮尝试均以 exit code 0 结束，但输出被 host wrapper 截断或混入重复、畸形 JSON，
+launcher 正确发布 `failure_type: missing_result`。原始片段里出现若干真实缺陷不能算成功
+findings；这证明的是 Grok 1.0.3 的 structured-result conformance 缺口，不是 lens 语义结论。
+
+## 原始观察
+
+原始 receipt、worker spec、stdout、stderr 与 terminal result 保存在可重建观察区：
+
+`.ultra/.runtime/adversarial-eval/2026-08-14/delegations/`
+
+关键 terminal result SHA-256：
+
+- `spec-claude/result.json`: `14156c2fd86936a725fe5e9e42b90e8cb9e80e2d3045304046bd9791baa5caaf`
+- `premise-claude/result.json`: `bf39a38b5893f53a18f95f55932b28e381edbf2f4a8bae9b1dd1180b61267bbd`
+- `six-kimi/result.json`: `ca523134aa30f2ad39ebf539dd2b31b74b06c966c37d4cee4feae17574bf6aaf`
+- `spec-zcode-3/result.json`: `f9409cdd62a5e41a5b183cbed155e25e097ec9a27d0d0bfae0f9e74d87468956`
+- `spec-grok-4/result.json`: `0d33a9f5f4a80d75b0ebb908d30f6d12d9e26be1f3122b976dfd126fba8a34de`
+- `premise-grok-4/result.json`: `6e33fd9fc6a17313151a640717ad257efbfb780417044f8b9d92cc46acd128b5`
+
+该目录是 disposable evidence，不是项目语义权威；可由 tracked fixture、prompts 和当前
+delegate launcher 重建。
+
+## 产品决定
+
+1. 六 lens roster 不变。
+2. `review-spec` 必须同时验证 accepted behavior、North Star Trace、因果链、contradiction
+   disposition，以及“全部 acceptance 通过但 outcome 仍失败”的路径。
+3. Plan review 与 aggregate Test review 必须产出六 lens session；没有 findings artifact
+   不得声称阶段完成。
+4. 可用不同 model family 时追加一次 blind premise probe；不可用时记录缺失，不伪造独立性。
+5. `execution_mode` 和每个 worker 的 coverage refs 必须落盘。顺序角色扮演只能记录为
+   `sequential_fallback`，不能声称 isolated multi-agent。
+6. 只有 fresh blind fixture 反复证明 current roster 漏掉独立 consequential class 时，
+   才重新讨论第七 lens。
+
+## 最便宜复测
+
+先运行 `node --test tests/adversarial-review-eval.test.cjs`，确认 green-test trap 与五个
+hidden seed 仍存在；然后在新的隔离上下文中用相同 permission 分别运行 current spec 与
+candidate premise prompts。不得向 worker 暴露 seed manifest 或本报告。

package/docs/evals/zcode-automation-2026-08-14.md

@@ -0,0 +1,103 @@
+# ZCode 自动编码与双向委派实测 — 2026-08-14
+
+## 结论
+
+当前实现已经证明两条不同的 live path：ZCode 可以作为第六个目标 Host 被 Ultra
+委派，也可以作为发起 Host 调用另一个 CLI；在 owner 明确激活的 Change-scoped
+Autonomy Envelope 内，它还可以在同一会话连续完成 Plan、Dev/TDD 和 Test，而不需要
+daemon、数据库、MCP 或语义状态机。
+
+这不是无限授权。实测 envelope 只覆盖一个任务、零次委派、零 external effects，并在
+through-test stop condition 后停止；Deliver finalization、archive、commit、push、publish
+和 deploy 都没有获得授权，也没有发生。
+
+## ZCode 原生插件
+
+- ZCode CLI: `0.16.3`
+- Managed plugin: `ultra-builder-pro@inline`
+- Native inventory: 14 Skills、5 Hooks、0 Commands、0 MCP
+- Activation: managed local marketplace 加 owner-configured `plugins.dirs` entry
+- Hook bridge: `hooks/adapters/zcode.py`
+
+安装后 `zcode plugins list` 报告插件 enabled，并能枚举全部十四个 qualified Skills。
+一次真实 no-op Bash tool call 在修复 hook transport 后以 exit 0 完成；无动作 adapter
+现在不再把 `{}` 发送给 ZCode 的 strict hook parser，而是保持 stdout 为空。
+
+## 同会话自动编码
+
+- Fixture: `/tmp/ubp-zcode-autonomy-20260814`
+- Seed HEAD: `7292d7654d228ac3dc7f9b07b2e28d226c6f6104`
+- Change: `C-AUTO`
+- Task: `T-AUTO-1`
+- ZCode session: `sess_49caffcb-1d8e-44be-825d-ec607d21b1e3`
+- Envelope: through-test、max tasks 1、max repairs 2、review budgets 1 each、delegations 0
+
+ZCode 读取 accepted intent 和 exact North Star revision 后完成：
+
+1. 写入一个 tracer-bullet task，并生成 Plan review；
+2. 通过 public seam 写出可发现的 failing test，再做最小实现修复；
+3. 生成 task review 和六维 evidence；
+4. 运行 whole-change Test、真实 consumer E2E 和 aggregate review；
+5. 写入 fresh `.ultra/test-report.json`，然后按 envelope 停止。
+
+独立复核命令 `npm test` exit 0，3 tests、3 pass、0 skipped。三份
+`SUMMARY.json` 都通过当前 `review_wait.py` 校验：Plan 为 APPROVE/0 findings，Task 和
+aggregate Change 均为 APPROVE/1 P3。Test 报告保留两个 P3 residual risk：finite-number
+合同缺少非整数例子，以及作为 library 的 export 没有仓内非测试 consumer。
+
+原会话第一次在所有产品工作完成后，因 no-op hook 把 `{}` 写到 stdout 而在最后一个
+benign Bash 验证上 exit 1。修复 adapter 并重装插件后，先独立复现该 Bash 为 exit 0，
+再 resume 同一个 session 做只读终检；resume exit 0，HEAD 仍是 seed commit，未生成
+commit。这条失败没有被隐藏，它直接产生了当前 hook 修复。
+
+## ZCode 作为目标 Host
+
+对抗性 fixture seed HEAD 为 `37c07dc8596cda64a93aac260917b3c091ad1b58`。一次
+`--to zcode` 的 read-only delegation 通过 instruction、permission、output-schema
+digest、空 diff 和 terminal-result 校验，并找到五类 hidden seed。terminal result
+SHA-256 为：
+
+`f9409cdd62a5e41a5b183cbed155e25e097ec9a27d0d0bfae0f9e74d87468956`
+
+语义评测与 six-lens 决定见 `docs/evals/adversarial-review-2026-08-14.md`。
+
+随后又专门验证了当前 macOS 上 `zcode` 不在 `PATH` 的默认路径。未设置
+`UBP_DELEGATE_ZCODE_BIN`，共享 profile 自动选择
+`/Applications/ZCode.app/Contents/Resources/glm/zcode.cjs`。第一次调用真实完成审查但
+省略 `$schema`；原因是共享 prompt 先要求该字段、随后列举“exact fields”时又漏掉它。
+launcher 按设计发布 `failed/missing_result`，没有把不合约输出算作成功。补上 prompt
+contract 回归并重新安装后，以新 delegation id 再跑：
+
+- Delegation id: `spec-zcode-default-fallback-2`
+- ZCode session: `sess_a985dc31-0eb5-4521-988d-97e92bee2c9a`
+- Selected command: `/Applications/ZCode.app/Contents/Resources/glm/zcode.cjs`
+- Override: absent
+- Result: `finished`、5 findings、empty diff、exit 0、stderr 为空
+- Result SHA-256: `71d973723b9317fe2ad31d3216a4f65e933d8ac18a8275244c94b84623dae852`
+
+这把“ZCode 可以作为 target”从手工 binary override 提升为当前安装形态下的默认真实
+路径，并同时验证了不合约结果的可恢复失败路径。
+
+## ZCode 作为发起 Host
+
+同一 fixture 上，ZCode session `sess_3ba3e9b2-6e3a-492d-876e-5e1a5e817d77`
+执行 `ubp delegate run --to claude`，等待 terminal artifact，再读取并汇报结果。Claude
+worker 只读定位到 `timeout-after-charge` 后无幂等键重试造成重复扣款的缺陷；worktree
+保持空 diff，result status 为 `finished`，exit code 0。
+
+- Delegation id: `zcode-to-claude-2`
+- Result SHA-256: `f2a9d9d88def969a0dc52ce494f0226e4c0f17f48c049c301e01241d449890da`
+- Instruction digest: `0d4a958db8c903eb6f5da6b8a6e6932a67398ad520424b32c8e4f83972618dd4`
+- Permission digest: `96f7f8ed4ddb77e4569519d8d20d2e29595c74a06b119d0dee8f3a7dd2cb`
+- Schema digest: `723230a485136ef52d0ef6f6fcbe804fc9b13544a11b93aefb2a75fe7ce3887d`
+
+这证明的是 ZCode→Ultra launcher→Claude 的真实 source path，不只是“ZCode 能被别的
+Host 调用”。第一次尝试也如实暴露了隔离 `HOME` 隐藏 Claude 登录的问题；第二次仅把
+已授权的真实 `HOME` 交给 nested launcher，未复制或打印任何凭据。
+
+## 六目标 Host 当前边界
+
+Claude、Codex、OpenCode、Kimi 和 ZCode 均完成了 schema-valid read-only target run。
+Grok Build 1.0.3 多轮 exit 0 但 terminal output 截断或畸形，launcher 正确发布
+`failed/missing_result`；其 partial text 不计入 findings。这个残余是当前 Grok 输出
+conformance ceiling，不能通过放松 result contract 来伪造成成功。

package/hooks/README.md

@@ -16,11 +16,34 @@ progress observations live under ignored `.ultra/.runtime/` or `.ultra/progress/
 canonical semantic facts remain the owner-readable files and Git.
 Legacy task rows with no `change_id` remain readable from an active-path `change_ref`
 during migration; a present canonical `change_id` always wins, and archived or
-abandoned paths are never revived as current work. Task
-selection prefers the single `in_progress` row, then the first `pending` row whose
-same-Change dependencies are complete; ambiguous concurrent work stays silent.
+abandoned paths are never revived as current work. `.ultra/tasks.json` is the sole
+task-status authority. A legacy context Status or Complexity header is emitted only as
+a migration diagnostic and never overrides the row. Task selection uses only the
+unique `in_progress` row of the active Change; a `pending` row is a frontier
+candidate that Hooks never activate, inject, or attribute edits to. When no task is
+live, the task-aware Hooks stay task-silent and progress-silent, and only read-only
+Status may report frontier candidates. A trusted exact-task invocation is
+invocation-local — it must mechanically match the ledger and is never persisted as a
+selector. The `.ultra/changes/active` directory chain and each active Change directory
+must be stable ordinary non-symlink directories; each `intent.md` must be a stable,
+readable regular file. More than one `in_progress` row emits the conflicting task ids
+and an exact repair while every task Hook remains task-silent. Task ids are globally
+unique, dependency ids are unique per row, and every
+dependency must resolve inside the same Change without self-edges or cycles. A malformed
+surface or graph emits an exact repair diagnostic while task content stays silent. Git
+or trace-source observation failures remain advisory typed diagnostics with a rendered
+repair and retry path; they never discard canonical Acceptance Criteria or the Resume
+Note. SessionStart retains both typed Acceptance and Resume Note content for the
+selected task, and every Resume injection carries the navigational limitation: a
+Resume Note cannot override owner authority, approved scope/budget, task acceptance,
+or a validated Review verdict, and it never reopens a review that already returned a
+current verdict. Hooks never launch, select, schedule, or recommend automatic
+invocation of `ultra-review` or any public workflow; routing belongs to the owner and
+the host model.
+Hook and validator observations never mark a task completed or supply a semantic
+acceptance disposition.
 
-Claude Code runs the hooks directly. Codex, Kimi Code, and Grok Build use the small
+Claude Code runs the hooks directly. Codex, Kimi Code, Grok Build, and ZCode use the small
 wire adapters under `hooks/adapters/`. OpenCode calls the same scripts from its native
 JavaScript plugin. A hook failure is advisory except for the explicitly classified
 destructive effects in `block_dangerous_commands.py`, whose denial includes a reachable