open-tui-orchestrator 0.9.6

package/docs/inactive-windows.md

@@ -0,0 +1,11 @@
+# Visible TUI startup without requested activation
+
+Current generic core uses Windows Terminal (`ORCH_TUI=wt`) per user preference through a synchronous no-activate helper (`spawnInactiveWindow`). The helper keeps the initiating foreground window in place while creating the new window, then exits on its own; the TUI stays visible and interactive. The synchronous launch is deliberate: the previous detached asynchronous launch often failed to create the window at all ("popup NOT confirmed" until timeout), while the synchronous path pops reliably within a couple of seconds. See [focus evidence](../test/inactive-window-validation-current.json).
+
+The helper creates the WT or fallback console with Windows `CreateProcessW`, `CREATE_NEW_CONSOLE` and `STARTF_USESHOWWINDOW/SW_SHOWNOACTIVATE`. For a fixed 2.5-second launch window it restores the initiating foreground window every 20 ms, and user input no longer ends that guard early — the protected scenario is precisely a popup arriving while the user is typing. The guard is bounded: after those 2.5 seconds the TUI is fully user-reachable, and even during them a deliberate click or Alt+Tab is at most delayed by one guard tick, never blocked. An OS-level `LockSetForegroundWindow` was evaluated and dropped: the short-lived helper measurably lacks the foreground rights to take the lock, while the restore guard alone measured zero stolen keystrokes. The TUI remains a visible, interactive console, not headless, hidden or minimized. Only the short-lived process-creation helper is hidden. The launch preserves the initiating workspace and existing task/checkpoint/close behavior.
+
+`ORCH_TUI=wt` remains the default and keeps Windows Terminal's IME/TSF behavior. If Windows Terminal is unavailable, the same guarded helper uses the visible console fallback. Doctor reports `windowActivation: terminal-managed` for the WT path and `no-activate` for the fallback.
+
+The controlled live probe uses a visible eight-second PowerShell job and monitors foreground notifications, actual foreground samples, visibility, minimized state, execution receipt and automatic closure. The current-core WT observation passed: the window was visible, not minimized and automatically closed; during its live phase it had zero target foreground samples and zero notifications whose actual foreground was the target. One startup notification named the target window while the initiating window remained the actual foreground, which is retained for diagnosis. Windows Terminal ≥ 1.24 programmatically raises its window while tearing down a closed tab; with no recent user input the OS permits a foreground blip of tens of milliseconds on the dying window, so the probe scores only the live phase (events and samples up to 400 ms before the window disappears). That teardown raise cannot eat keystrokes — while the user is typing, the OS denies the background raise; a full-lifecycle typing probe (synthetic keystroke every 80 ms across popup and tab close, through the production helper) delivered 134/134 keystrokes with zero foreground transitions. This is a host-level focus observation, not a universal OS guarantee.
+
+Run `powershell.exe -NoProfile -File test/live-inactive-window.ps1 -Workspace <workspace> -Legacy` for an opt-in visible direct-console probe. Do not click or minimize its window during the observation. Windows or another application may still activate a window; the plugin requests non-activation and cannot promise that all external focus changes are prevented. Runtime argument and helper-failure regressions run with the normal test suite. See [validation evidence](../test/inactive-window-validation-current.json) for recorded results and limitations.

package/docs/kimi-adapter.md

@@ -0,0 +1,27 @@
+# Kimi Code 适配器
+
+open-tui-orchestrator 支持已安装的 Kimi Code CLI（kimi.exe）。发起方为 Kimi 会话时可完全省略 `--agent`：宿主检测会沿 Windows 祖先进程链找到 kimi.exe 并自动绑定。
+
+## 使用
+
+```powershell
+open-tui-orchestrator --agent kimi --doctor
+open-tui-orchestrator --run-id my-run --acceptance-file D:/work/temp/acceptance.json --run-windows '项目91：修改页面，运行测试；项目92：修改接口，检查结果'
+```
+
+## CLI 与运行协议
+
+- 解析 PATH 上的 kimi.exe / kimi.cmd / kimi 启动入口，并补查 `%USERPROFILE%\.kimi-code\bin\kimi.exe` 原生安装位；`--help` 必须提供 `--prompt` / `--output-format` / `--auto`，版本取 `--version` 的语义化输出。显式路径错误时不回退、不安装。
+- 窗口采用 `kimi -p`（print 模式）：按产品契约，非交互模式默认 auto 权限策略处理常规工具调用，静态 deny 规则保持生效；`--prompt` 与 `--auto/--yolo` 互斥，因此不叠加权限旗标。model/thinking 继承发起窗：显式 ORCH_MODEL 优先，否则按 cwd 匹配最新 kimi 会话读其 wire.jsonl 末条 llm.request 的 modelAlias/thinkingEffort（回退 config.toml），model 转 `-m`、effort 经 KIMI_MODEL_THINKING_EFFORT 按进程透传（kimi provider 生效，其它 provider 类型自动回退 config.toml [thinking].effort）；不读取或输出凭据。
+- 提示词从文件读出后作为最后一个 argv 元素传入，且并入数组后再做 Windows PowerShell 5.1 原生命令行修正，嵌入引号、中文与多行内容不丢失。
+- 窗口把输出 tee 到日志，启动器按【本块唯一标识】token 行写结果文件（首行 JSON + `__EXIT__=N` 尾行）；等待方只解析首行 JSON。kimi `-p` 在回合结束后自行退出，无需扩展机制。kimi 诊断（version/thinking/进度）走 stderr，启动器经 ErrorRecord 还原管道把它以普通文本并入日志，窗内不刷红色 NativeCommandError 块（2026-09-09 修复，回归测试锁定）。
+- 规划走 `kimi -p --output-format stream-json`：stdout 每行一个 JSON 对象，取最后一条 `role=assistant` 的 `content`；meta 行与 stderr 进度一律忽略。不支持的沙箱要求明确拒绝（KIMI_SANDBOX_UNSUPPORTED）。
+- argv 顺序硬约束：kimi 解析器对旗标值贪心绑定，提示词必须紧跟 `-p`、其余旗标放最后（`kimi -p --output-format stream-json <提示词>` 会报 `unknown command 'stream-json'`；2026-09-09 真机复现并修复，回归测试锁定）。
+- 已知限制（2026-09-09 实测，当日已缓解）：kimi 规划器冷调用约 295s，远超 codex/pi 的 60-90s 拆块默认超时。kimi 适配器的规划超时默认已放宽到 360s（`KIMI_DECOMPOSE_TIMEOUT_DEFAULT_MS`，`ORCH_DECOMPOSE_TIMEOUT_MS` 显式设置时优先），冷请求可在首轮重试内完成规划；命中拆块缓存仍秒级返回。窗口执行路径不受影响（窗口不走规划器）。
+
+## 验证入口
+
+- `node --test test/kimi-adapter.test.mjs test/kimi-runtime.test.mjs`：真实 CLI 解析、argv 形状、PowerShell 启动器引号/中文/多行回环、结果等待。
+- 本机实测（2026-09-09，kimi 0.41.0）：从 Kimi 会话无 ORCH_AGENT 发起 `--spawn`，进程链自动识别为 kimi，真窗口创建 `hello-kimi.txt` 并以 `__ORCH_DONE__ spawn-<id>` 收尾，done=true。
+
+真实调用消耗本机 Kimi 配额；其余 agent 的兼容性以各自的验收记录为准。

package/docs/kimi-integration.md

@@ -0,0 +1,56 @@
+# Kimi Code 集成：发起窗 todolist 镜像与 spawn 群状态
+
+编排器侧只提供**状态流**，Kimi Code 侧的原生机制（TodoList、后台任务）由**发起 agent** 负责镜像。
+原因：Kimi Code 0.42.0 没有可供外部进程挂载的 hooks 通道，编排器是子进程，无法直接写发起会话的 TodoList；
+"用发起 agent 本身就有的机制" 只能在 agent 侧落地——agent 读流、更新自己的列表。本文给出固化套路。
+
+## 数据源（编排器已内建）
+
+| 通道 | 形态 | 用途 |
+|---|---|---|
+| 引擎 stdout `[board] …` | 每次状态迁移追加一行（`run=… gen=… mode=… N/M verified [B1✓ B2▶] finalized success=true`） | 后台任务输出里天然可见；人类可读 |
+| `--watch <runId> --jsonl` | 每次变更输出一条 JSON（blocks[].status/attempts、tasks[].status/checkpoint、finished/success） | **agent 镜像的首选输入** |
+| `--watch <runId>`（TTY） | 原地重绘的完整看板（块行 + 状态 + 任务标记） | 人类终端的常驻模块 |
+| `--status --readonly` | 活动 run 的看板行 | 快速一瞥 |
+| `runs/<id>/summary.json`、`events.jsonl` | 权威账本与事件流 | 终审与审计 |
+
+## 镜像套路（发起 agent 侧，实测有效）
+
+1. **一次 run = 一个后台任务**：用 Kimi Code 的原生后台任务跑编排入口，天然获得任务面板与完成通知；
+   同时再挂一个观察任务：
+   ```bash
+   node <cli> --agent kimi --run-windows "<请求>"          # 后台任务 A：编排
+   node <cli> --agent kimi --watch <runId> --jsonl          # 后台任务 B：状态流
+   ```
+2. **agent 周期性读 B 的末条 JSON，更新自己的 TodoList**（无需要求 agent 盯着；每次自己回合末端同步一次即可）。
+3. **字段 → TodoList 映射**：
+
+| 看板字段 | TodoList 渲染 |
+|---|---|
+| `blocks[].key/title` | 每个块一个待办项（标题=块名） |
+| `blocks[].status` = `pending/launching/running` | 该项「进行中」 |
+| `verified` | 该项「完成」 |
+| `failed/timeout/needs-reconciliation` | 该项「失败」，追加 `blocks[].reason` |
+| `tasks[].checkpoint`（`started/completed`） | 项内子进度徽标（比 `tasks[].status` 更早、更真：块在跑时任务级状态仍 pending） |
+| `blocks[].attempts` > 1 | 标注「第 N 次尝试」 |
+| `finished/success` | 全部项收官；`success=false` 时按块报告失败原因 |
+
+4. **spawn 群状态**：`blocks[]` 即单元群（headless 与 window 同构；`attempts` 即重试代数）。
+   想单独一项显示，可新增一个「Spawn 群」待办项，内容直接画 `spawned headless/visible …` 行或
+   `B1▶ B2⏳` 摘要；块级状态同时镜像到各自待办项即可，不必双份维护。
+
+## 实测记录（2026-09-11，kimi 0.42.0，core 1.8.0）
+
+- run `kimi-nativesync`：2 块 × 3 任务（真实开发任务：format.js+自测 / check.js+自测），headless 全程；
+- 镜像片段（真实取值）：
+  - 第 1 次同步：`B1 running（T001✓ T002✓ T003▶）/ B2 running（无检查点）`；
+  - 第 2 次同步：`B1 verified（三任务 completed）/ B2 running`；
+  - 终态：`finished=true success=true`，T001-T006 全部 `verified + checkpoint completed`。
+- 结论：task 级进度必须读 `checkpoint` 字段（块在跑时 `tasks[].status` 会滞后到 pending）；
+  流式 JSONL 是 agent 镜像的可靠输入。
+
+## 边界
+
+- TodoList/后台任务是 **Kimi Code agent 运行时**的原生机制（本套路不依赖任何编排器改动）；
+- 编排器不写、也写不了发起会话的会话状态；run 的终审以 `summary.json` + 验收契约为准；
+- 其它 agent（claude/codex 等）同理：各自用其原生 todo/后台机制镜像同一份流。

package/docs/maintenance-lock.md

@@ -0,0 +1,32 @@
+# Maintenance lock
+
+While the orchestrator itself is being upgraded, optimized, maintained or updated, the installation should not serve orchestration calls: the files an agent would load may be mid-edit. The maintenance lock makes that pause explicit and checkable.
+
+Acquire it before touching the installation, release it when done:
+
+```
+node scripts/maintenance-lock.mjs lock --reason "升级 core" [--ttl-minutes N]
+node scripts/maintenance-lock.mjs status
+node scripts/maintenance-lock.mjs unlock
+```
+
+While the lock is held, every action entry point prints exactly one line and exits 0, so the initiating agent skips the orchestrator and executes directly for that round:
+
+```
+open-tui-orchestrator正在维护更新，本轮跳过orchestrator直接开始执行
+```
+
+Gated entries: `--run-windows`, `--spawn`, `--resume-run`, `--run`/`--exec`, `--plan`, `--selftest-close` (in `scripts/core/orchestrate-sdk.mjs`), `scripts/open-tui-orchestrator-preflight.mjs` (any kind), and `scripts/open-tui-orchestrator-force.mjs --assert/--verify`. Read-only entries (`--status`, `--doctor`, `--verify-run`, `--clear-cache`, `--tasks`, `--enable`/`--disable`) keep working; `--status` additionally prints the lock state.
+
+## Properties
+
+- **Global per user, workspace-independent.** Default path `~/.open-tui-orchestrator/maintenance-lock.json`; override with `ORCH_MAINTENANCE_LOCK` (used by tests). Any workspace sees the same lock.
+- **Self-expiring.** Default TTL 180 minutes, capped at 24h (`MAX_TTL_MINUTES`). An expired lock is treated as absent and cleaned up on read, so a crashed or forgotten maintenance session never wedges the tool.
+- **Fail-open.** A missing, unreadable or corrupt lock file means "not locked". The lock is a courtesy gate, not a security boundary; it must never break the orchestrator.
+- **Atomic.** Written via tmp+rename; readers only ever see a complete JSON record or nothing.
+- **Advisory self-lock in repair.mjs.** `repair.mjs --clean` and `repair.mjs --target` acquire the lock for their own duration when no lock is held, and never release a lock held by someone else. (`process.exit()` skips `finally`, so each exit point releases explicitly.)
+- **Test hook.** All readers/writers accept an `env` parameter; `ORCH_MAINTENANCE_LOCK` isolates tests from the real user-level lock. `test/maintenance-lock.test.mjs` covers acquire/read/release, TTL default and cap, expiry cleanup, corrupt-file fail-open, the CLI, and the gated entries (preflight / force / `--run-windows` / `--spawn` / `--status` bypass).
+
+## Maintenance workflow rule
+
+Any session that will modify the orchestrator installation (upgrade, optimization, repair, republish, seal refresh) runs `lock` first and `unlock` last. If in doubt whether a lock is stale, `status` shows the reason and expiry; `unlock` is always safe.

package/docs/openclaw-adapter.md

@@ -0,0 +1,59 @@
+# OpenClaw adapter
+
+The generic CLI implements an OpenClaw-specific adapter for the validated OpenClaw 2026.9.2 release on Windows. It does not pass Codex or pi arguments to OpenClaw. Other OpenClaw versions fail explicitly until their configuration, transcript and TUI interfaces are validated.
+
+From the initiating workspace:
+
+```powershell
+open-tui-orchestrator --agent openclaw --doctor
+open-tui-orchestrator --agent openclaw --plan "Your tasks"
+open-tui-orchestrator --agent openclaw --run-id <id> --acceptance-file <absolute-json> --run-windows "Your tasks"
+```
+
+The ordinary shared planner, global capacity coordinator, task ledger, independent acceptance and recovery controller remain authoritative. OpenClaw's own concurrency setting cannot increase the memory-derived window capacity.
+
+## Isolation and lifecycle
+
+Each window uses the actual `openclaw tui --local` command inside OpenClaw's installed `@lydell/node-pty` terminal implementation. Its state directory is unique under the initiating workspace's `temp/orchestrator/openclaw`. This avoids the native exclusive-state collision without changing or stopping the user's main gateway.
+
+The adapter binds both the configured agent workspace and terminal cwd to the initiating directory. It supports Windows drive roots by treating recursive mkdir of an already-existing drive root as a no-op; other filesystem errors still propagate.
+
+Existing provider configuration is loaded through OpenClaw's runtime API. A temporary configuration uses current `agents.entries` fields and environment references for credential values. The original configuration is unchanged. Channel delivery, scheduled work, hooks and automatic memory search are disabled for these isolated worker sessions. Existing sandbox and execution-policy settings are preserved. Plugin-imposed approvals are not bypassed; configurations requiring interactive approval are not claimed as unattended-compatible.
+
+Configuration validation runs before interactive startup to prevent a schema migration prompt inside the TUI. Planning uses OpenClaw's `agent exec` with all tools denied. Real execution always uses the TUI.
+
+The window controller reads only its own SQLite transcript. It requires the final assistant message, a successful stop reason and the exact completion token, and rejects user or tool messages. It then sends `/exit` and requires a clean process exit. The completion marker remains separate from the parent's independent task acceptance. A bounded watchdog can terminate its own terminal on timeout; it never terminates the shared gateway.
+
+The parent can adopt a surviving window on `--resume-run` through the existing process-identity contract. Preserve the run's acceptance outputs and checkpoints until recovery and verification are finished.
+
+## Verification commands
+
+```powershell
+node <repo>/test/live-openclaw.mjs --smoke
+node <repo>/test/live-openclaw.mjs
+$env:ORCH_LIVE_AGENT = 'openclaw'
+node <repo>/test/live-recovery.mjs
+```
+
+The smoke test verifies an actual command, cwd, result content, task checkpoints and automatic shutdown. The capacity test requires eight simultaneous native TUI descendants and eight simultaneously running probes, with the ninth task serialized inside block eight. Results are recorded per run; static CLI discovery is not sufficient evidence of support.
+
+External plugins, credential stores and custom sandbox combinations require their own acceptance. The current local provider setup has been exercised; this is not a claim that every OpenClaw configuration works unattended.
+
+## Verified results (2026-09-06)
+
+- Generic regression: 129/129 passed. Dedicated installed Codex release: 126/126 passed, with matching physical core integrity manifests in source and cache.
+- Capacity run `acceptance-2814b49b-2998-4ed8-9c89-270e02da2d84`: eight windows, nine tasks, 17.205 seconds of actual probe overlap. Every native exit was zero and every window had an automatic-close receipt. The core was unchanged throughout the test.
+- Recovery run `recovery-2e7bc61d-f094-44db-9647-fd982adb173b`: controller crash followed by adoption of the same window; the first task executed exactly once; the second completed and the window closed automatically.
+- Resuming the already-completed capacity run reverified all results without opening new windows.
+- Deliberate completion-timeout test: failed with `OPENCLAW_WINDOW_TIMEOUT` and closed its own terminal within 13.676 seconds including startup and graceful-exit allowance. The deadline was intentionally shorter than normal initialization.
+- The first capacity run exposed an overly strict whole-message matcher and required four manual test-worker closures. It is recorded as a lifecycle failure, not a successful unattended run. The fix accepts explanatory text only when the last line is the exact token-scoped marker; regression and the subsequent complete live run passed.
+- Source and installed Codex test inventories were reconciled. Native watchdog fixtures now wait for a valid PID rather than file existence, avoiding a race with an empty newly-created PID file.
+
+Compact evidence: [openclaw-live-result.json](../test/openclaw-live-result.json). No cross-machine or cross-version acceptance is claimed. Eight simultaneous OpenClaw startups put significant pressure on this 16 GB machine; startup latency remains a measured limitation.
+
+Cleanup of completed OpenClaw test state directories was rejected by host automatic approval review with `host automatic approval review denied cleanup`. Zero directories were removed by that command, no alternate deletion route was attempted, and the test state remains under the initiating workspace's temp directory. Functional TUI execution required no manual user approval.
+# 2026-09-06 通道隔离补充
+
+每个测试实例除使用独立状态目录、清空 channels 外，还显式设置 plugins.entries.openclaw-weixin.enabled=false，防止微信插件自行发现账户。主配置不修改，模型供应商插件保留。此项属于隔离加固；未发现此前测试抢占微信登录的证据。
+
+微信主通道验收应检查 accounts 的 connected=true、lifecycle=ready 及持续成功轮询，不能只检查 configured。回复发送仍需单独验收。

package/docs/openclaw-assessment-2026-09-06.md

@@ -0,0 +1,59 @@
+> Historical assessment before implementation. Current support and acceptance: [OpenClaw adapter](openclaw-adapter.md).
+
+# OpenClaw compatibility and Codex plugin assessment
+
+This is an assessment, not a declaration of OpenClaw adapter support.
+
+## Fresh verification
+
+- Dedicated Codex plugin: `node --test test/*.test.mjs` completed with 124 passes, zero failures and zero skips (37.55 seconds).
+- Dedicated plugin status: no active windows, pending reservations or pending locks.
+- Installed OpenClaw: 2026.9.2 (3928bad), discovered through the existing npm CLI installation.
+- Generic entry: `--agent openclaw --doctor` exits 1 with `ADAPTER_UNSUPPORTED`. The current adapter table implements Codex and pi only; no alternative agent was substituted.
+- No OpenClaw orchestration or eight-window acceptance is claimed by this report.
+
+## Connection diagnosis and repair
+
+The existing Windows scheduled task `OpenClaw Gateway` was disabled. Both the gateway probe and `openclaw health` reported ECONNREFUSED at 127.0.0.1:18789. The native gateway start command also explicitly failed because the scheduled task was disabled.
+
+Enabled that existing task and started it through `openclaw gateway start --json`. Health subsequently passed. A fresh gateway status reported the gateway running, configuration audit clean and RPC connected. No credentials, model configuration or approval policy were changed.
+
+A no-tools connectivity request returned exactly `OPENCLAW_READY`, with run ID `296ff2e0-4301-4637-8df2-3d06e50a1cdd`. Delivery was not enabled. The response reported the existing configured workspace `C:\Users\<user>\Desktop\openclaw`, although the invoking shell was in `D:\`.
+
+The evidence establishes why the service could not connect; it does not establish who or what disabled the scheduled task. This failure was local service unavailability, not an observed Internet transport timeout. A generic RPC connectivity probe does not prove every operator capability or external messaging channel is usable.
+
+## Integration constraints
+
+OpenClaw's locally installed CLI documentation and official TUI reference agree that local TUI mode holds exclusive ownership of its state directory. Multiple local windows must not share that directory with each other or the gateway. Gateway-backed TUI sessions avoid that particular ownership collision, but their agent workspace is configured on the gateway; setting only the launcher cwd is insufficient.
+
+The `tui` help exposes initial messages and session selection, but no one-turn exit option. An adapter needs verified assistant completion events and owned-window shutdown, independent task acceptance, interrupted-run recovery and workspace-scoped state. Do not assume the pi shutdown extension works in OpenClaw, or force-close a shared gateway when closing one window.
+
+`agent exec --cwd` does bind both the agent workspace and tool directory and supports isolated transient state. It is explicitly headless, so it cannot be presented as successful real-TUI integration. Plugin approval requirements still apply; no tested universal no-prompt TUI configuration is established here.
+
+Recommended design: a dedicated OpenClaw gateway/session adapter with explicit workspace binding and per-run session identity, followed by single-window lifecycle validation, then the existing eight-window/nine-task and crash-recovery acceptance contract. Preserve the global memory-derived cap of eight regardless of OpenClaw's own configured concurrency (currently 16). Do not repoint the user's existing main agent merely to satisfy a test.
+
+Reference: https://docs.openclaw.ai/cli/tui
+
+## Codex maturity judgment
+
+The current implementation is suitable for supervised use in this tested Windows environment, but is not yet demonstrated to be a broadly stable release. The current tests cover task inventory, capacity, dependencies, leases, process identity, independent acceptance and recovery. Prior real eight-window tests remain historical evidence; they were not repeated in this assessment.
+
+Confirmed release risks:
+
+1. The dedicated source plugin's `scripts/core` is a junction to the generic development core. A generic edit therefore changes the specialized plugin immediately. Release snapshots and rollbackable versions should isolate installed execution from development.
+2. The installed skill still contains older Codex-only generic-support wording, contradicted by its newer pi section and the actual adapter table. Documentation needs a consolidated current contract.
+3. The current regression suite includes local installation-dependent tests. Passing on this machine does not establish clean-machine installation or cross-version compatibility.
+
+Further reliability evidence should exercise long network interruptions and controller/window crash timing. A pass count alone does not establish those failure modes.
+
+## Follow-up: native TUI and static plugin evaluation
+
+The repeated user request was checked against the current source again:
+
+- Dedicated plugin regression: 124 passed, zero failed, zero skipped, 37.216 seconds. This is a fresh run, not a reuse of the earlier result.
+- `plugin-eval start` and `plugin-eval analyze` ran using the installed evaluator. Static score: 72/100, grade C. The two error findings are uppercase letters in the plugin and skill names. Those are evaluator naming checks, not observed execution failures or a measured runtime success rate. No coverage artifact was found by that evaluator.
+- The generic `--agent openclaw --run-windows` entry was executed and failed with `ADAPTER_UNSUPPORTED` before opening a window. This verifies the execution entry, in addition to the earlier doctor entry.
+- The real installed OpenClaw `tui` was launched in an interactive PTY from `D:\`, using a dedicated session `agent:main:orch-tui-check-20260906`. The initial no-tools request produced the assistant response `ORCH_OPENCLAW_TUI_READY` and the UI reached `connected | idle` with delivery off.
+- The TUI remained open after the response. The test controller sent `/exit`; the process exited with code 0. This was a native CLI/TUI smoke test, not an orchestrator-launched desktop-window test, and not automatic completion-marker shutdown.
+
+Current conclusion remains: Codex has meaningful local regression evidence but release maturity gaps; OpenClaw's CLI and native TUI work, while its orchestration adapter is absent. Eight-window execution, workspace-bound tools, independent acceptance and interruption recovery have not been validated for OpenClaw.

package/docs/opencode-adapter.md

@@ -0,0 +1,25 @@
+# opencode 适配器
+
+open-tui-orchestrator 支持已安装的 opencode CLI（npm 包 opencode-ai 的原生 opencode.exe）。解析 npm 启动脚本后直指打包的 `node_modules/opencode-ai/bin/opencode.exe`，不经过批处理拼接。
+
+## 使用
+
+```powershell
+open-tui-orchestrator --agent opencode --doctor
+open-tui-orchestrator --run-id my-run --acceptance-file D:/work/temp/acceptance.json --run-windows '项目91：修改页面，运行测试；项目92：修改接口，检查结果'
+```
+
+## CLI 与运行协议
+
+- 探测要求 `--help` 含 "run opencode with a message" 且 `run --help` 同时提供 `--interactive` / `--auto` / `--dir`；版本取 `--version` 首段。显式路径错误时不回退、不安装。
+- 窗口 argv 为 `run -i --auto --dir <工作区>`：`-i` 让 opencode 在本回合结束后自行退出，`--auto` 等价于 pi 的 `--approve`（编排器已完成授权归一）。提示词从文件读出、并入数组后再做 Windows PowerShell 5.1 原生命令行修正，引号、中文与多行内容不丢失。
+- 窗口输出 tee 到日志，启动器按【本块唯一标识】token 行写结果文件（首行 JSON + `__EXIT__=N` 尾行）；等待方只解析首行 JSON。诊断走 stderr，启动器经 ErrorRecord 还原管道以普通文本并入日志，窗内不刷红色 NativeCommandError 块（与 kimi 窗同款修复，2026-09-09）。
+- 规划走 `run --format json` 的 headless 事件流，取最后一条 assistant 文本事件；`type=error` 事件即拒绝该次规划。
+- model 继承发起窗：显式 ORCH_MODEL 优先，否则读 opencode.json(c) 顶层 `model` 转为 `--model`；opencode 无 thinking effort 旗标，不传递；不支持的沙箱要求明确拒绝（OPENCODE_SANDBOX_UNSUPPORTED）。
+
+## 验证入口
+
+- `node --test test/opencode-adapter.test.mjs test/opencode-runtime.test.mjs`：真实 CLI 解析、窗口/规划 argv（含 `--` 后提示词与 `--model` 透传）、PowerShell 启动器回环、stderr 还原、结果等待（含 `__EXIT__=` 尾行兼容与启动器死亡无结果路径）。
+- 本机实测（2026-09-09，opencode 1.18.30）：headless 规划探针返回 OK；`--agent opencode --spawn` 真窗口创建 `hello-opencode.txt` 并以 `__ORCH_DONE__ spawn-<id>` 收尾，done=true。
+
+修复记录（相对 2026-09-08 未提交初版）：Write-Result 的 JSON 行冒号位置导致的 PowerShell 解析错误；提示词引号在 PS 5.1 原生命令行边界被吞；结果等待误把 `__EXIT__=` 尾行一起 JSON.parse 导致永远走超时/误报路径。三处均由新增离线测试先行复现再修复。

package/docs/pi-adapter.md

@@ -0,0 +1,58 @@
+# pi agent 接入与分块修复
+
+open-tui-orchestrator 支持已安装的 Codex CLI 和 pi CLI。专用 codex-TUI-orchestrator 仍只接受 Codex；两套入口共享并发、任务清单、冲突锁、恢复和验收核心。
+
+## 使用
+
+从发起对话的工作目录调用，不要先切到安装目录：
+
+```powershell
+open-tui-orchestrator --agent pi --doctor
+open-tui-orchestrator --agent pi --run-id my-run --acceptance-file D:/work/temp/acceptance.json --run-windows '项目91：修改页面，运行测试；项目92：修改接口，检查结果'
+open-tui-orchestrator --agent pi --resume-run my-run
+```
+
+实际验收 JSON 由主持根据任务准备，规则见 [执行协议](execution-contract.md)。`--plan` 使用 pi 自己的无工具模式规划；`--run-windows` 使用 pi 的真实交互窗口，未用 Codex 代跑。
+
+## CLI 与运行协议
+
+- 支持本地 pi 0.84.4 及以上所需接口。解析 npm 启动入口后，直接用 Node 和实际 cli.js 调用，避免批处理字符串拼接；也检查原生可执行候选。显式路径错误时不回退、不安装。
+- 保留 pi 自己的模型和登录设置。model/thinking 继承发起窗：显式 ORCH_MODEL / ORCH_EFFORT 优先，否则读 `~/.pi/agent/settings.json` 的 defaultModel / defaultThinkingLevel，转为 pi 的 `--model` / `--thinking`；不读取或输出密钥。
+- `--approve` 处理本次项目文件信任，`--offline` 关闭启动时非必要联网，不禁止正常模型请求。没有向 pi 塞入 Codex 的 `--sandbox`、`--cd` 或 `never` 参数；不支持的沙箱要求明确拒绝。
+- 窗口工作目录继承发起目录。pi 会话写入该工作区 `temp/orchestrator/pi/sessions`，启动器和检查点沿用工作区 temp；不修改用户全局配置。
+- 使用 pi 的 agent_settled 事件（自动重试、压缩及排队消息均处理完毕后发出的结束事件），仅在空闲时检查最后一条 assistant 输出，再调用 pi 的正常退出接口。用户提示里的结束标记不能触发成功。
+- 结束标记只表示执行生命周期结束；任务是否成功仍由主持逐项验收。每批记录实际 agent，恢复时不能悄悄切换到另一种 agent。
+
+## 分块根因修复
+
+原始任务清单与确定性分块使用同一个任务边界解析器。逗号后的普通补充说明留在原任务中；只有后面明确开始另一个项目时才拆分。引号和括号内的命令分隔符不会被拆成任务。
+
+模型规划必须返回原始 T001 等任务 ID。主持按 ID 恢复原文后再分块，所以模型改写摘要不会让完整覆盖检查失效。遗漏、重复或未知 ID 会拒绝该规划，不丢任务。
+
+内存上限为“标称内存 GB 的 3/4”：标称内存 GB = round(内存GB × 1024 ÷ 1000)，最大窗口数 = round(标称 GB × 3 ÷ 4)。标称 16 GB 对应上限 12，9 项独立任务分为 9 个单任务块，而不是因逗号自动变成一个大串行块。
+
+## 验证入口
+
+- `node --test test/*.test.mjs`：完整回归，包括实际 PowerShell 启动器与 pi 事件协议。
+- 从目标工作目录按绝对路径运行 `test/live-pi.mjs`：pi 的真实 8 窗 / 9 项验收。
+- 设置 `ORCH_LIVE_AGENT=pi` 后运行 `test/live-recovery.mjs`：真实主持中断与原窗口接管。
+- 使用 `ORCH_LIVE_ENTRY` 指向专用 SDK，再运行 `test/live-codex.mjs`：检查专用入口未回归。
+
+真实测试会使用本地已配置服务的额度。具体结果以本轮独立验收报告为准；接通 pi 不代表其它 CLI 已经兼容。
+
+## 本机验收（2026-09-06）
+
+| 场景 | 结果 |
+|---|---|
+| open 与专用入口完整回归 | 各 124/124 通过 |
+| pi 真实并发 | 8 窗完成 9 项，8 个探针重叠 15.617 秒 |
+| Codex 专用入口真实并发 | 8 窗完成 9 项，8 个探针重叠 17.180 秒 |
+| 原始逗号请求 | 两种 agent 都使用带逗号的请求，分配为 7 个单任务块 + 1 个双任务块 |
+| pi 主持中断 | 原窗被新主持接管，2 项任务完成，第一项只执行一次 |
+| 最终代码恢复已完成 pi 批次 | 成功，未新开窗口、未增加任务执行尝试 |
+
+两次容量测试的严格轮询均返回 0，所有测试窗口已关闭。pi 的实际会话目录和 cwd 均经检查，保留它自己的配置，无需用户手动批准窗口执行。
+
+详见 [pi-live-result.json](../test/pi-live-result.json)。报告分开记录实测时与最终核心的哈希：首次 pi 容量测试后补了版本检查与窗口日志命名，真实窗口测试后补了英文缩写撇号解析；这些收尾修改通过最终完整回归和已完成 pi 批次恢复核验，未冒充重新运行整套 8 窗实测。
+
+本轮 19 个一次性探针脚本的收尾删除被宿主自动审批拒绝（host automatic approval review denied cleanup，未提供具体原因），因此按实际状态保留；未换工具绕过。该拒绝发生在测试后的清理阶段，不是 TUI 执行批准。

package/docs/public-readiness.md

@@ -0,0 +1,63 @@
+# 公开可用性差距清单（2026-09-14）
+
+目标：让**外人**装得上、跑得起来、看得懂。每条都有验证方式；状态只有三种：**已具备** / **待补** / **需你决策**。
+
+## 一、已经具备（都有现场证据）
+
+| 项 | 证据 |
+| --- | --- |
+| MIT 许可 + 作者署名 | `LICENSE` |
+| 离线回归全绿 | 292/292（本轮补 2 条：`scripts/gate.mjs` 自身可红判据；Windows-only 入口拒绝判据——判据本身已用「去守卫 + 重封副本」验证能红；2026-09-15 再补 1 条：封印树「链接拒绝」判据——红例用「摘掉链接检查 + 类型白名单」实测能红） |
+| 发行封印 + 副本流程 | `release.json`（43 核心 + 65 运行时）、`repair.mjs`、`docs/release-policy.md` |
+| 机器可调用失败契约 | 一行 `[orchestrator] FATAL: …`、退出码 0/1/2、未知 run 不挂起（1.13.0 起） |
+| 机判门禁（在仓里，任何人可跑） | `node scripts/gate.mjs --all`：L1 套件 / L2a doctor / L2b 反例能红 / L3 未知 run / L4 版本·封印·文档·套件总数对账 + 锁票巡检 |
+| Windows-only 承诺**已强制** | **2026-09-15 新增** `scripts/platform-guard.mjs`（`cli.mjs`/`orch.mjs`/壳层三入口，早于解析宿主/调模型/落状态）；判据 `test/windows-only.test.mjs` 且红例真做（副本去守卫+重封 → 假平台健康 exit 0） |
+| 发布件真机执行验收 | **2026-09-15 实测** 0.9.4 副本经调用方自助通道双块并行：`2/2 verified finalized success=true`、产物落盘并记 sha256、检查点 completed，~60 秒（零模型调用） |
+| 安全审计（当前核心） | `docs/security-audit-2026-09-09.md`（无 Critical/High；Medium/Low 已修或登记） |
+| 一键补依赖 | **本轮新增** `--install-deps`：幂等、失败干净、stdout 纯数据、从不碰 agent CLI |
+| 安装路径实测 | `npm pack`（403 kB / 162 文件）→ 装进独立前缀 → `--install-deps`（3 s，npm 缓存）→ `--doctor` `hostError=null` `carrierAvailable=true` |
+| 安装文档 | **本轮新增** `INSTALL.md` / `INSTALL-zh.md` + README 安装节 |
+| 调用方接入 | `docs/caller-driven.md`（任何 agent 四行接入、`--plan-file`、`--unit-cmd`、`--tasks`） |
+
+## 二、待补（按我的排序；1–3 是硬门槛）
+
+**结论（2026-09-14，core 1.14.4 / 0.9.4）：清单只剩两件事，且都不可逆、都必须用户亲手点——一、发 npm 包（需要 `npm login`/token）；二、仓转公开。其余全部就绪。**
+
+1. ~~公开前的个人路径清理~~ **完成 2026-09-14**：18 个 tracked 文件、77 处用户名归一化为 `<user>`；根因一并修掉（证据采集器、画像适配器、hermes 画像 provenance）。验证：`git grep -c yecha` 只剩公开的 GitHub 句柄 `yechang1450`。
+2. **npm 发布——只差登录**：`npm publish --dry-run` 全绿（**92 文件 / 298 kB**，本轮加 `scripts/gate.mjs`）；`private` 已去、`files` 白名单已验（不加排除会被 385 MB 的 `scripts/node_modules` 卷进去）、元数据齐备。
+   **需要你**：`npm login`（或给 token）→ `npm publish`。
+3. ~~CI~~ **完成 2026-09-14 / 实测 2026-09-15**：`.github/workflows/ci.yml`（`windows-latest` + Node 24 + 装 codex + `--install-deps` 自检 + `node scripts/gate.mjs --all`）。**实测结论**：在私有仓手动派发该工作流 → 作业零步骤、3 秒失败，GitHub 注解为「recent account payments have failed or your spending limit needs to be increased」——**私有仓的 Actions 作业起不来（与代码无关，是账户计费问题）**；而 GitHub 计费文档明确：**公开仓的标准 hosted runner 免费**。所以正确姿势是**转公开后再武装**（改文件头 2 行 `on:`），提前武装只会收获红叉。
+4. ~~公开文档面~~ **完成 2026-09-14**：`CHANGELOG.md`、`.github/ISSUE_TEMPLATE/bug_report.yml`、`SECURITY.md`（私密漏洞报告渠道 + 披露政策）、`CONTRIBUTING.md`（屋规：判据必须能红、封印纪律、数字对账）。
+5. ~~信任与安全声明~~ **完成 2026-09-14**：`docs/trust-and-safety.md`（隐藏 agent 以你的凭据运行、Codex 的 `--dangerously-bypass-approvals-and-sandbox`、`--unit-cmd` 属调用方自授权、写哪些文件、无遥测无后台服务、如何卸载），README/README-zh 首屏与 INSTALL 均给出一行摘要 + 链接。
+6. ~~平台声明~~ **完成 2026-09-14**：README/README-zh 首屏与 INSTALL「Requirements」均明写 **Windows-only**，其它平台直接给诊断。
+7. **外部首次验收——你的部分**：在一台干净的 Windows 机器/用户上走一遍（装 Node → 装包 → `--install-deps` → doctor → 双块真跑）。`docs/release-policy.md` 已把「不同 Windows 用户安装」列为发行门槛。
+   **注意（2026-09-15 环境事实）**：本机 codex 账号额度耗尽（Sep 19 恢复）——模型驱动的真跑今天做不了；编排器在该条件下退化正确（inline 明说、无假成功），调用方自助通道（零模型调用）的真机双块验收已于 2026-09-15 通过。
+8. ~~验收证据去本地化~~ **完成 2026-09-14**。
+
+### 公开前一毫米（做完这两步就是公开态）
+```powershell
+# 一、发布（产物已验证：93 文件 / 303 kB、三步安装走通；2026-09-15 重测）
+npm login && npm publish
+
+# 二、转公开
+gh repo edit yechang1450/open-tui-orchestrator --visibility public --accept-visibility-change-consequences
+# 然后按 .github/workflows/ci.yml 头部注释武装 CI（2 行）——转公开同时也解锁免费 CI：
+# 私有仓的 Actions 作业被账户计费拦截（2026-09-15 实测），公开仓的标准 runner 免费。
+```
+
+## 三、需要你决策
+
+**当前只剩两个决定，且都是「点不点」的问题（其余我已在 2026-09-14 全部收口）：**
+
+- **仓库是否转公开**（private → public）：不可逆；历史里只有作者信息（已清理机器用户名，只剩公开的 GitHub 句柄）。
+- **npm 发布账号**：用你的账号、还是开组织 scope（如 `@yechang1450/open-tui-orchestrator`）？决定后只差一次 `npm login`。
+
+已由我按「最省事且不烧钱」定完、不需要你操心的：平台路线（Windows-only 明说，不投跨平台）、CI（入仓但不带 push 触发，转公开时改 2 行武装）、信任声明与安全渠道（`docs/trust-and-safety.md` + `SECURITY.md`）。
+
+## 四、推进记录
+
+1. ~~个人路径清理 + `CHANGELOG.md` / issue 模板~~ ✅ 2026-09-14
+2. ~~`npm publish --dry-run` 预演 + 打包瘦身（`files`）~~ ✅ 2026-09-14（89 文件 / 292 kB）
+3. ~~CI 骨架 + 门禁入仓~~ ✅ 2026-09-14（`scripts/gate.mjs` + `.github/workflows/ci.yml`，有意不武装）
+4. ~~信任/安全声明定稿 + `SECURITY.md` + `CONTRIBUTING.md`~~ ✅ 2026-09-14
+5. 干净环境首次验收（第 7 项）——**你的部分**，过了即可对外说「可以用」

package/docs/release-policy.md

@@ -0,0 +1,39 @@
+# Release policy
+
+本项目按独立 Node CLI 发布。`release seal`（发布封印，用 SHA-256 固定可执行文件清单）写入根目录 `release.json`，公共编排入口和轮询入口在加载引擎前都会验证它。封印为 schema 2，覆盖当前通用核心、CLI、运行时脚本和已锁定的 SDK 入口；Git、依赖目录、工作区 `temp`、覆盖率和开发缓存不会进入发行包。
+
+维护和发布按下面顺序进行：
+
+1. 确认没有正在运行或等待回收的编排窗口；运行中的账本属于工作区 `temp/orchestrator`，不能当作发布缓存清理。
+2. 在源码目录执行完整回归：`node --test test/*.test.mjs`。
+3. 核心或运行时变更后重新生成并验证封印：`node scripts/release-integrity.mjs --seal`，随后执行 `node scripts/release-integrity.mjs`。
+4. 用 `node repair.mjs --target <新的绝对父目录>` 生成发行副本。目标目录必须不存在；复制完成后会再次验证封印和必需文件，任何失败都会清理本次 staging 目录。
+5. 从目标副本运行 `node repair.mjs`、`node cli.mjs --version`、`node cli.mjs --agent codex --doctor` 和只读状态检查。本仓库是独立私有 CLI、不含插件管理器：安装、升级和回滚以发行副本的目录级替换落实（外部验收证据见文末）。
+
+当前源码封印记录通用核心 1.14.6、43 个核心文件和 65 个运行时文件。最新离线回归为 292/292 通过；当前已覆盖任务不丢失、多块并行容量调度、依赖波次、单块/纯串行计划不触发普通开窗、同项目任务按资源键精细化拆分并行（资源不明则整组串行兜底）、全局容量租约（排队等待指数退避+抖动：首等 600ms、×1.7、封顶 5s、抖动 ±20%；`ORCH_WAIT_BACKOFF_MS`/`ORCH_WAIT_BACKOFF_MAX_MS` 可调）、无窗 headless 派发默认（`--mode window` 保留可见弹窗；launcher/身份/租约/恢复契约同构，隐藏载具不抢焦点；2026-09-10 在 pi/claude/opencode/kimi 四宿主实跑通过：双块收据齐、零弹窗）、单元载体分级（TUI 类 agent 的 ConPTY 伪终端载体：真实控制台、无窗口、不抢焦点，身份/租约/恢复契约与窗口模式同构；print 类维持无控制台载体；2026-09-12 在 codex（pty）与 pi（stdio）双载体实跑通过）、执行看板（块与任务状态实时 `[board]` 行、run `events.jsonl` 事件流、只读 `--watch <runId>` 流式视图、`--status` 活动 run 摘要）、Windows Terminal 启动（同步拉起，弹窗可靠且不抢发起窗焦点）、进程身份、断点身份、损坏账本拒绝、账本 launcherFiles 工作区包容校验、验收契约创建时哈希锚定（resume/verify 篡改即拒）、注册表锁老化回收、轮询截止时间、SDK 缺失诊断、CLI 只读 `--version` 版本痕迹（不改状态、不解析 agent CLI）、强制编排入口 `orch`（跳过全部 inline 回退——单块/纯串行/只读定性/自改都会派发单元，维护锁仍是唯一门）、调用方自助通道（`--plan-file` 自带计划文件走既有覆盖/依赖/回退硬校验且全程零模型调用，`--unit-cmd`/`--unit-cmd-file` 自带单元命令绕过宿主识别与探测、任意 CLI 走同一启动器/租约/恢复/验收契约，只读 `--tasks` 账本助手，单元命令的 resume 身份一致性，未知 agent 的两条出路诊断）、print-class 数据驱动画像适配管线（`node scripts/adapt.mjs` 与 `ORCH_AUTO_ADAPT=1` 自动模式：表面探测→画像→解析自检→活验守门→重封→自动提交，失败一律回滚；2026-09-11 aider 0.86.2 实弹完成表面/画像/自检并在未登录时正确 fail-closed；画像自动发现 model/effort 探测规格（`modelDetection`，只读 env/配置文件精确键名），发起窗 model/effort 对画像 agent 同样跟随；hermes 画像正式落地：`--agent hermes` 解析为 profile 宿主、hermes 发起即自动挡——适配探活实测 12.5s 取回令牌）、档位去向留痕（summary 的 model/effort 与三态来源 explicit/宿主会话/host-default；机器可读入口 stdout 保持纯数据）、机器可调用失败契约（公开入口失败只回一行 `[orchestrator] FATAL: <原因>`、无栈帧（`ORCH_DEBUG=1` 才打）；未知 run 不甩 `ENOENT` 也不挂起：`--verify-run`/`--resume-run` 立刻 fail-closed，`--watch` 有界宽限 `ORCH_WATCH_GRACE_MS`（默认 60s）后 fail-closed，看板中途丢 `summary.json` 立刻报错）、宿主 CLI 探测超时重试与逐候选拒绝诊断（scripts/core/host-probe.mjs）、OpenClaw 版本门诊断（接口探针先行：版本常量只记「最后验证于」——未验证版本必须以 `tui` 接口探针实测结果 + node-pty 状态 + 最后验证版本 fail-closed；2026-09-14 本机 2026.9.3 实测：探针 OK、node-pty present；扩版仍需逐版 config/transcript/TUI 验收 + 用户侧 gateway 凭据）、恢复账本 launcherFiles 包容校验覆盖盘符根工作区、发起方自动识别（环境标记优先、进程链就近命中：kimi/codex/claude/pi/opencode/openclaw/hermes）、kimi、claude 与 opencode 适配器的启动器回环、控制器异常死亡后的守护进程自动接管恢复（test/guardian-live-result.json）与手动 --resume-run 收编存活窗口恢复（test/recovery-live-result.json）、维护锁（自身维护期间动作入口只回固定话术并放行，docs/maintenance-lock.md）和干净发布副本。2026-09-09 已完成当前核心安全复扫（双路 LLM 源码审计，docs/security-audit-2026-09-09.md）：无 Critical/High，4 个 Medium 与 1 个 Low 已修复并纳入回归，其余 Low 登记为已知问题；该报告、对应修复提交与本次封印共同构成当前核心的新安全基线，替换 2026-09-05 绑定旧哈希的历史基线。长期环境验收仍单独列为发行门槛。覆盖率摘要保存在 `coverage/coverage-summary.json`，它是验证产物，不会随发行副本发布。
+
+Codex、pi 和固定版本 OpenClaw 适配器各自负责宿主参数、会话输出、完成判定和关闭流程。Windows Terminal 是默认可见承载；PowerShell 只作为生命周期脚本和进程枚举辅助，不承担宿主适配。没有经过对应适配器验证的 CLI 会直接失败，不自动安装或回退到其它 Agent。
+
+本机离线和包级检查不能替代外部验收。2026-09-10 已用当前封印在 kimi 路径逐项补证并保留机器可读证据：当前模型额度下八窗口九任务实跑（qA/qB 双夹具，9/9 回执零不符、峰值 8 窗重叠、发起窗 model/thinking 继承一致，test/acceptance-2026-09-10-qA-report.json、qB 同名）、干净 Windows 用户安装（新建 orch-test 用户：副本封印复验 1.7.2/32+50、命令面通过、缺 CLI 时 fail-closed 且带逐候选诊断、指定 ORCH_CLI 后 doctor 成功、代码面无用户路径硬编码，test/acceptance-2026-09-10-clean-user.md）、发行副本目录级安装/升级/回滚（含篡改必拒，test/acceptance-2026-09-10-release-copy.md）、程序级精准断网 4 分钟的断网重连与收尾（8/9 窗由引擎自动重呼恢复、1 个未证明任务按契约 fail-closed、零卡死窗、零假成功，test/acceptance-2026-09-10-netcut-report.json）、TUI/控制器/守护全进程树硬杀后的清理与恢复（零自动复活，手动 `--resume-run` generation=2 重开 8 屏障窗、已完成任务副作用零重复、success=true，test/acceptance-2026-09-10-kill-resume-report.json）——全进程终止+磁盘保留+手动恢复即 Windows 重启的本质（编排器不依赖 OS 易失状态），故该项以杀全树方案作为重启恢复的等价补证。控制器中断后的接管和恢复此前已于 2026-09-09 双路径补证（test/guardian-live-result.json、test/recovery-live-result.json）。2026-09-10 晚间 core 1.8.0（无窗 headless 默认）复证完成：九任务八重叠实跑复现（peak=8、9/9 回执零不符、exit 0，headless 全程约 8.5 分钟；test/acceptance-2026-09-10-headless-qA-report.json）、全灭恢复在 headless 单元上重验（杀 32 进程零存活、60 秒零复活、`--resume-run` generation=2 重开 8 屏障单元、已完成任务副作用零重复、receipts 9/9 零不符；test/acceptance-2026-09-10-headless-kill-resume-report.json）、发行副本封印 35+53 复验与 `--version` 只读版本面通过、pi/claude/opencode/kimi 四宿主 headless 双块实跑全部 success=true（含新增 Claude Code 适配器 headless 与 window 双模式，test/acceptance-2026-09-10-headless-live.json）。合并块串行（块内多任务按序）已于 2026-09-11 用 kimi 双模式实跑补证：两块各 1 次 attempt、块内三任务 checkpoint 依序（前一任务结束→后一任务开始）、6/6 verified、引擎 success=true（test/acceptance-2026-09-11-merged-block-serial.json）；规划期溢出合并由离线容量测试覆盖零丢失。仍未单独补证：真机 Windows 重启（已用全进程树硬杀+磁盘保留+手动恢复的等价方案覆盖）。完成其余项目并保留机器可读证据后，才能把当前候选称为广泛稳定发行版。
+
+2026-09-12 完成 caller-driven 通道（core 1.9.0：`--plan-file` 自带计划 + `--unit-cmd`/`--unit-cmd-file` 自带单元命令 + 只读 `--tasks`）的真机验收，全部走真实 CLI（Kimi Code 0.42.0 / deepseek-flash，headless，无适配器参与）：双块并行实跑 2/2 verified、success=true；同通道 `--resume-run` 对已终结运行零重开（每块 attempts 保持 1）、产物哈希不变；控制器被中途杀死后守护进程自动接管（generation=2，无证据的块按"不重放未证明副作用"重开一次）并最终 success=true；反例（真实 CLI 拒绝未知旗标 exit 1）fail-closed 零假成功。证据 test/acceptance-2026-09-12-caller-driven.json。
+
+2026-09-15 完成公开化准备第五步：模型侧失败**不再被吞**（core 1.14.6 / 0.9.6）。① 真机发现：本机 codex 账号额度耗尽时，分解阶段只报 `no JSON in classify output:  (no valid JSON) -> fallback to single serial block (autosafe detect)`——**读起来像解析 bug，真正原因（额度用尽 / 未登录 / 弱网）被丢掉**：`runThreadPrompt` 返回的 `errored`/`warnings` 从未被检查，代码只去解析空的 `final`。② 修：分解循环在 `final` 为空且存在模型侧故障信息时，抛 `classify model call failed: <原因>`（一行、有界 300 字），失败告警行照旧附带 `-> fallback …` 的兜底说明。③ **前后对照（同一命令、同一账号状态，0.9.5 副本 vs 修复后源码树）**：前 `… no JSON in classify output:  (no valid JSON) …`；后 `… classify model call failed: You've hit your usage limit. Visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at Sep 19th, 2026 4:10 PM. …`——操作者第一次就能看懂并知道何时恢复。④ 同轮记录（**诚实边界**）：额度耗尽下的两次真实模型跑（81/84 双块）均 `success=false`、两任务 `failed`，**无假成功**；但每任务的失败原因是通用的 `No durable task checkpoint` / `Safe recovery attempt budget exhausted`，CLI 原文留在 `runs/<id>/attempts/`，把单元级原因提到摘要属后续项，本轮不冒充已做。离线回归 291/291；门禁 L1–L4 全 PASS。证据 test/acceptance-2026-09-15-windows-guard-live-run.json。
+
+2026-09-15 完成公开化准备第四步：Windows-only 承诺落成判据 + 发布件真机双块验收（core 1.14.5 / 0.9.5）。① **抓到一处「说法无判据」**：README/INSTALL 承诺「其它平台会直接给诊断而不是半可用的安装」，实测（`node --import` 伪造平台）无守卫时 `--doctor` 在"Linux"下**健康返回 exit 0**（还报 `terminal: "wt"`）、`--run-windows` 照常发起分类调用——承诺是假的。② **修法**：`scripts/platform-guard.mjs` 在**三个入口**（`cli.mjs`——npm bin 入口、`orch.mjs`、`scripts/orchestrate-sdk.mjs`）于解析宿主/调模型/落状态**之前**强制，一行 `[orchestrator] FATAL: Windows-only: …` + exit 1；仅保留 `--version`/`--help`/`--install-deps`（平台中立且正是排障所需）。③ **判据与红例**：`test/windows-only.test.mjs` 两条（拒绝必须干净且不得像健康报告；三个中立入口必须照常工作），**红例真做**——副本去掉守卫 + 重封副本 → 假平台下健康 exit 0 ⇒ 判据必红。④ **发布件真机验收**：在 0.9.4 副本上走调用方自助通道（`--plan-file` + `--unit-cmd-file` + `--acceptance-file`，**零模型调用**）双块并行：看板 `0/2 → 1/2 → 2/2 verified → finalized success=true`，产物 `alpha.txt=ALPHA_OK`/`beta.txt=BETA_OK` 落地并记 sha256 证据，两任务 `verified` 且检查点 `completed`，全程 ~60 秒。⑤ **环境事实（记录在案）**：本机 codex 账号额度耗尽（Sep 19 恢复），故「模型驱动的双块实跑」今日无法进行；编排器在该条件下**退化正确**（连续两次分类失败 → `mode:inline` 明说由发起对话执行，无假成功）。离线回归 291/291；门禁 L1–L4 全 PASS；封印 43 核心 + 65 运行时。证据 test/acceptance-2026-09-15-windows-guard-live-run.json。
+
+2026-09-14 完成公开化准备第三步（core 1.14.4 / 0.9.4）：**把门禁搬进仓 + CI 就位 + 公开文档面收口**。① **`scripts/gate.mjs`**——机判门禁从仓外的个人工具变成仓内可跑件：`node scripts/gate.mjs --all` 依次跑 L1 离线套件、L2a 宿主解析、L2b 反例能红（证明判据本身没坏）、L3 未知 run 干净失败、L4 版本/封印/文档/套件总数对账 + 锁票巡检；每条打「命令/期望/实际」，读不到的字段一律算失败。**本轮它自己就抓到了两件事**：新增文件未重封时 CLI 以 `RELEASE_INTEGRITY_FAILED` 拒绝运行（封印在干活），以及改版后三处文档口径过期（`README.md: core 1.14.3 != 1.14.4 ⇒ FAIL`）。② **`.github/workflows/ci.yml`**——在干净 `windows-latest` 上跑同一套门禁（含装 codex、codex vendor bin 入 PATH、`--install-deps` 引导自检）；**有意不武装**（只留手动触发），私有仓推送不吃 Windows runner 分钟数，转公开按文件头 2 行注释武装。③ **公开文档面**：`SECURITY.md`（私密漏洞报告渠道 + 范围 + 披露时限）、`CONTRIBUTING.md`（屋规：判据必须能红、封印纪律、数字单一来源）、`docs/trust-and-safety.md`（信任声明：隐藏窗口以你的凭据跑 agent、Codex 的 `--dangerously-bypass-approvals-and-sandbox`、`--unit-cmd` 属调用方自授权、写哪些文件、无遥测/无守护进程/无自动更新、怎么卸载）；README/README-zh 首屏明写 **Windows-only** 并挂三处链接；INSTALL 补 `gate.mjs` / `release-integrity.mjs` / `ORCH_NPM_BIN`。④ 新增 2 条可红判据（`test/gate.test.mjs`：真仓必绿；口径被篡改的副本必红并指名 README.md）。⑤ **清单收敛为两步**（`docs/public-readiness.md`）：发 npm 包（只差 `npm login`）与仓转公开——都不可逆、都由用户亲手点。离线回归 289/289。证据 test/acceptance-2026-09-14-public-surface.json。
+
+2026-09-14 完成公开化准备第二步：身份清理 + 发行元数据 + 引导入口真机修复（core 1.14.3 / 0.9.3）。① **身份清理**：18 个 tracked 文件、77 处机器用户名归一化为 `<user>`（`git grep -c yecha` 现仅剩公开的 GitHub 句柄 `yechang1450`）；同时修掉三处根因，让**未来**产物也不再泄漏——证据采集器写入前自动折叠用户名段（`test/collect-recovery-evidence.mjs`）、画像适配器改记 basename 而非绝对路径（`scripts/core/adapt-lib.mjs`）、hermes 画像的 provenance 字段去绝对路径。② **发行元数据**：`package.json` 去 `private`、补 `description`/`keywords`/`author`/`license`/`repository`/`homepage`/`bugs`，并加 `files` 白名单——`npm pack` 实测：加白名单前会把 385 MB 的 `scripts/node_modules` 整包卷进去（tar 143 MB），加 `!scripts/node_modules` 后 **89 文件 / 292 kB**、`test/` 不入包、封印件齐全；`npm publish --dry-run` 全绿（仅差 `npm login`）。③ **真机回归抓到两个真 bug 并修复**（`--install-deps` 的成功路径此前没有判据，纸面全绿）：其一，装前算一次的 `present` 常量把「刚装成功」误判为失败（npm exit 0 但报 FATAL）；其二更关键——用户环境里若有 `ORCH_AGENT=codex`，壳层会先跑 SDK 依赖检查、引擎又会顶层 import `@openai/codex-sdk`，缺依赖时**连补依赖的入口都进不去**（鸡生蛋死锁）。现在引导入口先于引擎处理，实现独立成 `scripts/install-deps.mjs`（只依赖 Node 内置模块）；另加 `ORCH_NPM_BIN`（企业镜像/自定义 npm）与 npm-cli.js 直启（免 `shell:true` 的 DEP0190 噪音）。④ 新增判据：成功路径（npm 桩、离线确定）+ 缺工具链（`ORCH_NPM_BIN` 指向不存在的 npm，比「空 PATH」更真实——现代 Node 的 npm 直启在空 PATH 下照样能装）。⑤ 发行件端到端实测：`npm pack` → 装进独立前缀 → `--install-deps`（3 秒）→ 幂等复跑 `already-present` → `--doctor` 全绿 → 副本自验封印。离线回归 287/287。证据 test/acceptance-2026-09-14-release-prep.json。
+
+2026-09-14 完成公开可用性第一步（core 1.14.2 / 0.9.2）：① **`--install-deps`**——npm 发行包不带锁定 SDK 依赖（node-pty + codex-sdk），装完包一条命令补齐：幂等（已装则回 `already-present`、不联网）、stdout 纯数据（进度与失败原因走 stderr）、失败时指名手工兜底命令 `npm ci --prefix "<pkg>\scripts"`，且永不触碰任何 agent CLI。② 公开安装路径**实测走通**：`npm pack`（403 kB / 162 文件）→ 装进独立前缀 → `--install-deps`（3 秒，npm 缓存命中）→ `--doctor` `hostError=null` + `carrierAvailable=true`；缺依赖时本就是一行精确诊断（`RELEASE_DEPENDENCY_MISSING` 并附修复命令）。③ 文档面：`INSTALL.md` / `INSTALL-zh.md`（环境要求、npm/tarball/源码三条路径、验证、首次运行、升级回滚、卸载、排错、「它在你的机器上做什么」）、README 与 README-zh 安装节、`CHANGELOG.md`（0.4.0→0.9.2 用户视角）、`.github/ISSUE_TEMPLATE/bug_report.yml`、`docs/public-readiness.md`（公开差距清单：已具备 8 项 / 待补 8 项 / 需决策 4 项）。④ 事实核查：npm 包名 `open-tui-orchestrator` 未被占用（registry 404）；16 个 tracked 文件仍含机器路径（公开前需清理，列为清单第 1 项）。离线回归 286/286（新增 3 条 install-deps 判据，全可红）。证据 test/acceptance-2026-09-14-public-install.json。
+
+2026-09-14 完成协调器互斥加固与残留治理（core 1.14.1 / 0.9.1）：① 满载假失败**根治**——`lease-lock.ps1` 的互斥等待从写死 20s 改为可调（`ORCH_MUTEX_WAIT_MS`，默认 60000ms），JS 侧等待改为「同口径 + 启动余量」设界并新增重试（`ORCH_MUTEX_RETRIES`，默认 2，指数退避 + 抖动）；旧实现不但等待写死，且**即使子进程早已退出也要熬满 30s 才报错**（本轮 0.8.0 发行副本满套件实跑中 9 进程争 8 槽有 2/9 因此假失败）。② 锁票泄漏**根治**——被强杀/超时的 PS 跑不到自身清理，`lock-*.ready/.release` 在协调器目录无界堆积（本轮实测 **576 个 / 770K**）；现在每次事务前按龄回收（`ORCH_MUTEX_TICKET_TTL_MS`，默认 600000ms），只收老旧票、绝不碰在票。③ 新增 4 条判据（全可红）：调小等待必须秒级失败（红＝回到写死 20s）、瞬时拥塞必须被重试吸收（红＝去掉重试）、按龄回收的收/不收两侧（fresh 必须存活、`leases.json` 绝不触碰）、一次事务跑完不留票。④ 诊断自省：`queue-backoff` 端到端用例失败时现在会带出块级 `reason`（此前真相只落在会被 finally 删掉的 summary.json 里），并提供独立进程放锁夹具（同步阻塞等待期间本进程定时器不触发——测试自己踩过这个坑）。⑤ 残留治理：清掉机器级协调器 576 个泄漏锁票、dev 仓与发行副本的 temp 残留、一个 10:31 起的插件孤儿进程（父进程已死、空挂 6.5 小时）。⑥ 收口两项（同轮跟进）：解析协调器目录时**入口即回收**（空闲时也不积压，而不是等下一次事务才清），PS 侧改为每 100ms 轮询放票、每 ~1s 才做一次进程存活查询——票文件从「释放后 ~1s 才清」降到 **300ms 内清空**。离线回归 283/283。证据 test/acceptance-2026-09-14-mutex-hardening.json。
+
+2026-09-14 完成机器可调用失败契约（core 1.13.0 / 0.8.0）：公开入口的失败一律收敛成**一行诊断**——`[orchestrator] FATAL: <原因>`（完整 Node 栈帧改由 `ORCH_DEBUG=1` 显式开启）；封装入口作为主入口时只打一行、作为模块被 import 时照旧抛出，封印/自适配失败仍是 fail-closed（语义未变，只是不再把栈帧甩到调用者脸上）。② **未知 run 在三条路径上统一 fail-closed**：`--verify-run`/`--resume-run` 立刻回 `Run not found: <id>`（不再甩 `ENOENT` + 4 行裸栈——这正是 2026-09-13 登记在账的 L3 缺口，本轮随车翻转）；`--watch` 引入**有界宽限** `ORCH_WATCH_GRACE_MS`（默认 60000ms，覆盖「`--run-windows` 仍在规划、run 目录尚未建立」的真实竞态），超时即一行诊断退出——修复了此前「未知 run 无限轮询、永不返回」的挂死（本轮在旧 0.7.0 副本上实测复现：watch 静默长挂、无任何输出）；看板读到一半丢 `summary.json` 也立刻报错，不静默停摆。③ 发行副本 0.8.0 验收：`--verify-run` / `--resume-run` / `--watch` 三探针均为 exit=1 + 一行诊断（watch 实测 1565ms 返回，宽限 300ms）、`--doctor` hostError=null、发行副本自带套件实跑 278/278。离线回归 278/278（新增 6 条判据：未知 run 的 verify/resume 两路 clean 失败、watch 的未知 run / 有目录无 summary / 中途丢失 / 宽限内落盘四态；判据可红——退回裸 readFileSync 或裸轮询即失败）。证据 test/acceptance-2026-09-14-failure-contract.json。
+
+2026-09-14 完成 P1 队列退避与 OpenClaw 版本门诊断（core 1.12.0 / 0.7.0）：① 容量/冲突等待者改为**指数退避 + 抖动**（首等 600ms、×1.7、封顶 5s、抖动 ±20%；`ORCH_WAIT_BACKOFF_MS`/`ORCH_WAIT_BACKOFF_MAX_MS` 可调），等待状态仅在理由变化时重写看板——消除多等待者每秒各打一发协调器事务的惊群。真机验收（发行副本 0.7.0 实跑，零 LLM 调用方单元）：`ORCH_MAX_WINDOWS=1` 强制单窗，两块串行通过，看板实录 `0/2 verified 1 waiting [B1▶ B2⏳] → 1/2 verified 1 waiting → 2/2 finalized success=true`；离线回归 272/272（新增退避数学单测 + 单窗排队功能测试）。② OpenClaw 版本门升级为**接口探针先行**：版本常量只记「最后验证于」，不再先于实测拒绝；未验证版本以 `tui` 接口探针实测结果 + node-pty 状态 + 最后验证版本 fail-closed（本机 2026.9.3 实测：探针 OK、node-pty present；首跑冷启动曾致探针超时误报 mismatch，超时已放宽至 30s）。扩版仍需逐版 config/transcript/TUI 验收与用户侧 gateway 凭据。③ 补装 `orch-adapt` 全局 shim（三件套；优先开发仓库、无开发仓库回退安装副本）。证据 test/acceptance-2026-09-14-p1-queue.json。
+
+2026-09-12 完成发起者对位与档位留痕（core 1.11.0 / 0.6.0）的真机验收：无适配器的发起 agent 从「两条出路诊断」升级为「自动挡」——hermes 画像经适配管线正式落地（表面探测→画像→解析自检→活验取回令牌→重封→自动提交），发起身份由环境标记（HERMES_AGENT/HERMES_SESSION_ID）优先、进程链兜底识别，执行者即该 agent 自身 CLI；档位跟随发起者自身配置（画像 modelDetection 自动发现 `$HERMES_HOME/config.yaml` 的 model.default 与 agent.reasoning_effort；引擎支持 `$VAR` 展开与节内键读取），并作为 --model/--reasoning 注入单元；`--no-restore-cwd` 防止 hermes 恢复旧会话 CWD 导致写偏。真机验收（发行副本 0.6.0 实跑）：hermes 发起（不指定 --agent）双块并行 2/2 verified、success=true（257s），日志出现 `inherit host model/effort (hermes/profile:hermes): model=deepseek-flash effort=max`，summary 记录 model/effort/modelSource=profile:hermes；档位去向三态留痕（explicit | 宿主会话来源 | host-default），机器可读入口（--doctor/--tasks/--status/--watch/--verify-run）stdout 保持纯数据。同副本上 codex 默认 headless 双块回归 2/2 verified、success=true（212s，PTY 载体，`inherit (codex/codex-config): gpt-6-astra/ultra`）。离线回归 270/270（新增适配发现、节内键读取、档位留痕断言）。适配管线同时加固：模型短别名（-m）不再被误判为 prompt 旗标（该误判会把提示词喂给 model 参数、将 CLI 拖进交互模式——hermes 实测踩中并修复）、effort 旗标发现覆盖 `--reasoning`/`--thinking`、画像 modelDetection 支持 `<ID>_HOME` 型配置目录与分节键。证据 test/acceptance-2026-09-12-host-align.json。
+
+2026-09-12 完成单元载体分级（core 1.10.0）的真机验收：TUI 类 agent 在默认（headless）模式下改走 ConPTY 伪终端载体（真实控制台、完全不可见，进程树/pidf/身份/租约/恢复契约不变）。根因取证：原无头载体（windowsHide+stdio:ignore）对需要终端的 CLI 无控制台可依，实测秒退 exit 1（338ms；管道 stdin 报 'stdin is not a terminal'）；备选 Start-Process -WindowStyle Hidden 同样秒退、conhost --headless 在本机不可用；ConPTY（@lydell/node-pty 1.2.0-beta.15）实测通过（控制台探针 [Console]::WindowWidth=200）。真机验收（发行副本 0.5.0 实跑）：codex 双块并行 headless 2/2 verified、success=true（1m39s，产物逐字节验收）；print 类（pi）无控制台载体双块回归 2/2 verified、success=true（59s）。离线回归 266/266（含 4 条载体测试）。证据 test/acceptance-2026-09-12-pty-carrier.json。同日附带记录一项可预见情况与预案：pi 宿主 settings 的 defaultModel 被外部改为跨 provider 有歧义的短名，非交互单元秒退——属宿主自身配置问题、编排器忠实继承，显式 ORCH_MODEL=<provider>/<model> 或修正宿主 settings 即恢复（pi-standard-2 实跑为证）。

package/docs/security-audit-2026-09-09.md

@@ -0,0 +1,41 @@
+# 安全审计报告（2026-09-09，当前核心复扫）
+
+审计对象：当前工作树核心（CORE_VERSION 1.7.0，`release.json` 封印 31 核心文件 + 49 运行时文件）。
+方法：双路独立 LLM 源码审计（引擎/注入面 + 适配器/脚本/凭证面），等价于 2026-09-05 的「Codex Security 标准审计」做法（官方 Codex Security MCP 工具在本环境不可用）。
+威胁模型：本机单用户工具，输入来自本地调用方；窗内 agent 以用户全权限运行且工作目录即工作区。
+
+## 基线复验（2026-09-05 结论在当前源码上全部仍成立）
+
+- 无 shell 注入：全部 `spawn/spawnSync` 为数组参数 + `shell:false`，无 `exec/shell:true`。
+- 生成的 ps1 无插值注入：提示词全程走文件（writeFileSync + Get-Content 读回），路径单引号转义、token 限定字符集、PID 数值校验。
+- config.toml 只读 model/effort 两个标量（拒收含空白/引号的值），不打印凭证；全仓库无凭证文件读取。
+- PID 复用防护到位：进程身份四元组（ProcessId+Started+Name+CommandLine）+ launcher 命令行须含预期脚本路径。
+- 完成判定 fail-closed：持久检查点 + 验收双闸；窗内汇报文本不是成功证明；无验收检查时停在 awaiting-verification。
+- 供应链：无远程下载执行路径；唯一依赖由 package-lock 完整性哈希锁定；CLI 解析逐个真实执行能力探针。
+
+## 发现与处置
+
+### 已修复（Medium ×4 + Low ×1）
+
+| 编号 | 问题 | 修复 |
+|---|---|---|
+| A-M1 | 裸名 `powershell.exe`/`where.exe`/`tasklist` 按进程 cwd（=任意工作区）解析，在不受信目录运行构成二进制投毒 | 统一走 `contracts.mjs` 新增 `powershellExe()/systemToolExe()` SystemRoot 锚定（leases/inactive-window/orchestrate-sdk/force 共 11 处调用点），窗内 WT argv 同步锚定 |
+| E-M1 | resume adopt 信任账本 `launcherFiles`，cleanup 可被借手删除任意文件 | `validateRecoverySummary` 增加 launcherFiles 工作区包容校验；cleanup 钩子不信任账本路径，只删工作区内文件（双层） |
+| E-M2 | run 目录可写的 acceptance.json 在 resume/verify 时被回读，`command` 类检查以控制器权限执行 | 创建时把验收契约 sha256 锚定进账本（`acceptanceSha256`），resume/verify 回读先比对，篡改即拒绝 |
+| E-M3 | 注册表文件锁 stale 后永久降级：每次操作 2s 事件循环忙等 + 静默失去互斥 | 锁带 owner+时间戳，超龄（60s）安全回收；争用失败时告警而非静默降级 |
+| E-L1 | 维护锁 expiresAt 缺失/非数字时永久锁死，违背自身 fail-open 契约 | 非数字 expiresAt 一律视为损坏锁：fail-open 并顺手清理 |
+
+### 登记为已知问题（Low，同用户/窗内 agent 前提，不阻断 RC）
+
+- 拆块缓存未带密钥认证，理论可投毒为未来请求注入附加指令（需精确预测请求全文；攻击者本就同权限）。
+- `--verify-run` 信任账本 coordinator 字段，可被重定向建目录（同用户前提）。
+- guardian.json 身份字段可被语义伪造以压制自动恢复（DoS 面，重启预算有界）。
+- 账本/检查点/验收文件同目录自洽伪造的理论残余（根因：控制面状态在窗内 agent 可写目录；需「创建签名+消费校验」的统一治理，属架构级后续项）。
+- 发行封印可被本机同用户写者重封——封印按文档定位是完整性绊线而非防篡改控制，不对外宣称防伪造。
+- 窗口日志/结果文件可能沉淀 agent 输出中的敏感内容（temp 目录视同机密；无脱敏）。
+- openclaw 隔离配置的 0o600 在 Windows 无效；不匹配密钥名正则的自定义字段仍明文落 temp。
+
+## 总体结论
+
+本轮审计在当前核心上**无 Critical/High**；4 个 Medium 与 1 个 Low 已修复并随新测试回归（修复：8 个源码文件；测试：orchestrator/recovery-ledger/recovery-runtime/maintenance-lock/inactive-window 五个测试文件）。
+本报告 + 对应修复提交 + 当次封印哈希三者共同构成**当前核心的新安全基线**，替换 2026-09-05 绑定旧哈希的历史基线。