ultra-builder-pro-cli 0.26.1 → 3.0.2

package/docs/WORKFLOW-LIFECYCLE.md

@@ -6,9 +6,9 @@ criteria; repository files record facts; the host model chooses the route.
 ## Capability flow
 
 ```text
-ultra-init
-    ├─ unresolved external claims ─► ultra-research
-    └─ bounded requested outcome ──► ultra-change
+ultra-init ──raw Project Brief──► ultra-research ──accepted baseline──► ultra-change
+                                      ▲                                  │
+                                      └──── scoped consequential evidence gap ────┘
 
 ultra-change ─► ultra-plan ─► ultra-dev (per task) ─► ultra-test ─► ultra-deliver
                      ▲                 │                    │
@@ -18,75 +18,187 @@ 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.
+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. `.ultra/tasks.json`;
-2. the unfinished task's `context_file` and closing `## Resume Note`;
-3. `CONTEXT.md` and relevant `.ultra/decisions/`;
-4. the active Change, specifications, evidence, and Git state relevant to its scope.
+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
+   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;
+5. the active Change, specifications, evidence, maintained documentation, and Git state
+   relevant to its scope.
 
 Missing files produce a precise recovery or initialization recommendation. They do not
 cause the Skill to invent a state transition.
 
 ## Initialization
 
-`ultra-init` distinguishes owner authorization from claims requiring evidence. It
-creates the file skeleton, preserves unknowns as `[NEEDS CLARIFICATION]`, initializes
-Git when absent, and records only repository-observable brownfield facts. It does not
-perform research or launch another workflow.
+Init writes the raw Project Brief and stable empty skeleton. `ultra-init` preserves the
+owner's one-line request, broad outline, explicit inputs, and open questions without
+turning them into validated product truth. It initializes Git when absent and may
+preserve repository-observable brownfield facts as Research inputs. It does not define
+success, establish the North Star, create `CONTEXT.md`, populate specifications, or
+launch another workflow.
 
 ## Research
 
-`ultra-research` maps unresolved claims to the smallest useful subset of seventeen
-focused references. Reports are written immediately. Three material checkpoints can
-change later scope; the owner resolves those checkpoints. The final distillate records
-Git blob hashes of the specifications it summarizes.
+Research turns the brief into an accepted North Star and evidence-backed baseline.
+`ultra-research` uses Wayfinding only when a multi-lens path is unclear, then maps the
+question to the smallest useful subset of seventeen focused references. The first six
+are semantic lenses with real dependencies: `00` precedes `01`; conditional `02` and
+`03` may fan out after the boundary is known; `04` consumes their relevant conclusions
+and is the first owner checkpoint; `05` extracts assumptions from `00` through `04`.
+Grilling controls how missing owner inputs are asked, Think tests one consequential
+decision, and Domain Modeling writes settled vocabulary; none owns the Research route.
+The final synthesis promotes accepted conclusions into the North Star, `CONTEXT.md`,
+three specifications, and a source-hash-bound distillate.
 
 ## Change reconciliation
 
-`ultra-change` first compares requested behavior with product truth and current code.
-It classifies changes by the resulting commitments:
+Change updates only the touched baseline rather than rebuilding it. `ultra-change`
+first compares requested behavior with accepted product truth and current code. It
+classifies changes by the resulting commitments:
 
 - expansion and correction may proceed inside accepted intent;
 - a reduction waits for explicit owner authority.
 
 The output is one active Change intent with observable outcome, acceptance, seams,
-non-goals, and trace anchors.
+non-goals, trace anchors, and an explicit Research Disposition. `none` cites sufficient
+existing evidence; `bounded` or `required` names the exact question, lenses, and exit
+evidence. Unsatisfied exit evidence routes to Research, then back through Change
+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,
+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
 
-`ultra-plan` confirms the scope posture and public seams, then writes a task graph and
-one context file per task. 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.
+`ultra-plan` confirms a material scope posture and records public seams, then appends a
+current-Change task graph and one context file per task without deleting historical
+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 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 the ledger is 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
-never turns an orphan, failed command, stub, or omission into permission to alter scope.
+binds the report to `change_id`, exact current task ids, intent SHA-256, and the
+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.
 
 ## Delivery
 
-`ultra-deliver` reconciles actual outcome, specifications, documentation, current test
-report, aggregate review, build, version impact, omissions, and rollback. It archives
-the Change with `git mv` after local reconciliation.
+`ultra-deliver` uses two observable passes. The first reconciles actual outcome,
+specifications, documentation, aggregate review, omissions, and rollback; if semantic
+or product files change, it stops and recommends a fresh Test. The second begins only
+when report Change/task/intent/HEAD/product identities match, applies the changed-export
+gate, runs build and non-publishing package inspection, records version impact, writes
+delivery metadata, and archives the same stable id with `git mv`. Delivery metadata and
+the directory move do not invalidate their own product snapshot. Producing a release
+package remains blocked while a changed export has neither a non-test consumer nor an
+owner disposition. That disposition is recorded against the finding in the current
+test report without changing the finding or `passed`, then carried into `delivery.md`.
 
 Commit, push, tag, publication, release, and deployment are independent external
 effects. Readiness grants none automatically.
@@ -95,37 +207,72 @@ effects. Readiness grants none automatically.
 
 `ultra-status` infers the smallest next route from observable files:
 
-- no healthy skeleton → init;
-- unresolved evidence-bearing claim → research;
+- no healthy skeleton or usable raw brief → init;
+- raw brief without an accepted baseline, or a consequential evidence gap → research;
 - requested outcome without active Change → change;
-- active Change without executable ledger → plan;
-- pending or in-progress task → dev;
-- completed ledger without current report → test;
-- current report and unarchived Change → deliver.
-
-It also checks installation provenance, stale reports, old in-progress work, and
-unresolved markers. It does not mutate artifacts.
+- draft or blocking active intent → change;
+- unsatisfied Research Disposition → research;
+- active Change without matching executable tasks → plan;
+- 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, 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
+
+`ultra-delegate` is orthogonal to the lifecycle and requires explicit owner authority.
+Its immutable instruction selects task execution/continuation, scoped Research evidence,
+or aggregate Change review/verification. Task execution reads one matching task context;
+the latter two may be read-only and do not require a task, so both pre-Plan evidence and
+post-task review remain reachable. Every scope still binds the one active `change_id`, a
+clean isolated worktree, strict permission/result schemas, and primary-host inspection.
+The worker cannot write canonical `.ultra` files or perform external effects.
 
 ## Artifact closure
 
 Every durable output has a later reader:
 
-- init's north star and specification skeletons are read by all later workflows;
-- research reports are traced into specifications, Change reconciliation, planning,
+- init's Project Brief is consumed by Research, Status, and the pre-baseline session
+  Hook fallback; its empty skeleton supplies stable paths rather than product claims;
+- Research's accepted North Star and domain/specification baseline are read by every
+  later workflow, while selected reports trace into Change reconciliation, planning,
   and delivery;
-- Change intent is consumed through planning, development, audit, review, status, and
-  delivery;
-- task ledger and contexts are the common resume input, while task evidence feeds
-  review, whole-system audit, and delivery;
+- active Change intent and its touched specification deltas are consumed through
+  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 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
 
+There is one primary writer for canonical `.ultra` files. Review workers are read-only;
+delegated source edits use isolated worktrees and return results for explicit
+integration. Parallel canonical writes are unsupported because silently merging intent,
+task, evidence, or report authority would lose meaning.
+
 Before stopping, the active task context records current facts, exact verification,
 open questions, Completion, and a closing Resume Note. The next session or host repeats
 the common entry contract and compares the working tree with those claims.
@@ -133,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

@@ -5,8 +5,8 @@ directory and exits silently when the workflow is not active.
 
 | Hook | Lifecycle | Purpose |
 |---|---|---|
-| `session_context.py` | Session start | Inject the one-line north star and current acceptance criteria |
-| `mid_workflow_recall.py` | Before source reads or edits | Restate current acceptance only |
+| `session_context.py` | Session start | Inject the accepted North Star or Project Brief fallback, plus acceptance from the unique active Change's current task |
+| `mid_workflow_recall.py` | Before source reads or edits | Restate acceptance only for a task matching the unique active `change_id` |
 | `compact_context.py` | Before/after compaction | Save and restore a disposable snapshot derived from files and Git |
 | `post_edit_guard.py` | After edits | Record mechanical evidence observations without deciding completion |
 | `block_dangerous_commands.py` | Before shell execution | Advise on additive protected-branch publication; block history rewrites and a narrow destructive set until the exact command is owner-authorized |
@@ -14,8 +14,36 @@ directory and exits silently when the workflow is not active.
 `_common.py` is a shared library, not a lifecycle registration. Compact snapshots and
 progress observations live under ignored `.ultra/.runtime/` or `.ultra/progress/`; the
 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. `.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