@chinhae/atw-cli 0.5.0 → 0.7.0

package/dist/templates/claude/settings.json

@@ -57,6 +57,18 @@
         ]
       }
     ],
+    "PostToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "{{PYTHON_CMD}} .claude/hooks/show-notice.py",
+            "timeout": 15
+          }
+        ]
+      }
+    ],
     "UserPromptSubmit": [
       {
         "hooks": [

package/dist/templates/codex/hooks/session-start.py

@@ -237,8 +237,8 @@ def _get_task_status(atw_dir: Path, hook_input: dict, general: bool = False) ->
             )
         return (
             "Status: NO ACTIVE TASK\n"
-            "Next: Classify the current turn and ask for task-creation consent "
-            "before creating any ATW task."
+            "Next: If the request is about a task that already exists — the user names it, or asks to continue or accept and only one open task fits — make it this session's task first, as the no-task breadcrumb says; do not ask whether to create a new one. "
+            "Otherwise classify the current turn and ask for task-creation consent before creating any ATW task."
         )
 
     task_ref = active.task_path

package/dist/templates/common/bundled-skills/atw-askme/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: atw-askme
-description: "一场毫不留情的访谈，旨在打磨计划或设计。"
+description: "一场毫不留情的访谈，旨在打磨计划或设计。用户想把计划或设计拿来逐条拷问时使用。"
 disable-model-invocation: true
 ---
 

package/dist/templates/common/bundled-skills/atw-askme-with-docs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: atw-askme-with-docs
-description: "一场旨在完善计划或设计的深入访谈，同时在过程中逐步生成相关文档（ADR 和术语表）。"
+description: "一场旨在完善计划或设计的深入访谈，同时在过程中逐步生成相关文档（ADR 和术语表）。用户想一边被追问一边留下书面成果时使用。"
 disable-model-invocation: true
 ---
 

package/dist/templates/common/bundled-skills/atw-channel/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: atw-channel
-description: Use ATW channel for live multi-agent collaboration, spawned workers, cross-agent review, progress inspection, forum channels, and channel log debugging.
+description: Use when the user wants live multi-agent collaboration through ATW channel, spawned workers, cross-agent review, progress inspection, forum channels, or channel log debugging.
 ---
 
 # atw-channel
@@ -41,14 +41,17 @@ atw channel context list <board> --scope global --thread <thread>
 
 ## Core Rules
 
+- Workers can be Claude Code, Codex, pi or omp: `spawn` / `run` take `--provider <claude|codex|pi|omp>`. An agent card's `provider:` field only takes `claude` or `codex` — any other value is dropped, as if unset — so pick pi or omp with `--provider`. Flags: `references/workers.md`.
 - New forum channels use `--type forum`. A `thread` is one item inside a forum channel.
 - Use `--context-file` / `--context-raw` and `atw channel context add/delete/list`. `--linked-context-*` is deprecated terminology.
 - Use `--stdin` or `--text-file` for long messages. Do not put long mixed Chinese/English text in the positional shell argument.
 - Pretty `messages` output is an operator dashboard and may truncate progress. Use `--raw` for audit.
+- Reviewer workers: `spawn` / `run` take `--read-only`, `--clean`, `--no-session`, `--effort <level>`, `--standard-speed`; none of them means the worker launches as before. Claude Code with `--read-only` alone is still widened by the user's own allow rules and hooks — add `--clean`. Details: `references/workers.md` "Reviewer Mode".
+- `run --json` prints one result object on stdout in every outcome — `status` (done / timeout / error / not-started), `text` with `partial` (on timeout: what was produced so far), `durationMs`, `costUsd` or token `usage` (`null` = not reported; `costUnreported` also flags the `0` pi or omp gives for an interrupted turn), `model`, codex `instructionSources`, raw `error`, and the tool's own `errorKind` / `errorStatus` / `errorSubkind` (claude, codex; `null` when it gave none); exit code and keep-on-failure unchanged. Fields: `references/command-reference.md` "run".
 - `--as` is the speaker or worker handle, depending on the command. Use explicit, stable names when multiple agents or sessions are involved.
 - `--scope project` (default) operates on the current cwd's project bucket; `--scope global` operates on the shared `__global__` bucket. Pick scope deliberately — a global board is invisible from project listings unless `--scope global` is passed.
 - For brainstorm, do multiple pressure-test rounds. One answer plus one confirmation is review, not brainstorm.
-- **Dispatcher wait pattern**: use `--kind done` / `--kind turn_finished` (atw-emitted system events), NOT a user `--tag` as the completion signal. CLI help lists `phase_done` / `question` as `--tag` examples but only `interrupt` is a reserved tag with hardcoded atw behavior; the others are opaque user labels. Relying on a worker to run `send --tag <my_signal>` is unreliable — LLM workers commonly write the tag string into prose instead of running the actual CLI command. See `references/command-reference.md` "tag vs kind".
+- **Dispatcher wait pattern**: use `--kind done` / `--kind turn_finished` (ATW-emitted system events), NOT a user `--tag` as the completion signal. CLI help lists `phase_done` / `question` as `--tag` examples but only `interrupt` is a reserved tag with hardcoded atw behavior; the others are opaque user labels. Relying on a worker to run `send --tag <my_signal>` is unreliable — LLM workers commonly write the tag string into prose instead of running the actual CLI command. See `references/command-reference.md` "tag vs kind".
 - Forum channels are event-sourced. Do not parse `events.jsonl` first; use `forum`, `thread`, `messages --thread`, and `context list`.
 - `@chinhae/atw-core` owns reusable channel/thread state, event append, seq allocation, context/title projection, reducers, and task helpers. The CLI owns flags, terminal rendering, prompts, worker lifecycle, and process exits.
 

package/dist/templates/common/bundled-skills/atw-channel/references/command-reference.md

@@ -151,7 +151,7 @@ not a legacy alias for any `--tag` flag.
 Concrete model in the current source:
 
 - `--kind` is the only event-type filter, and it is constrained to the
-  atw-emitted whitelist (`CHANNEL_EVENT_KINDS` in
+  ATW-emitted whitelist (`CHANNEL_EVENT_KINDS` in
   `packages/core/src/channel/internal/store/events.ts`):
   - `create`, `join`, `leave`, `message`, `thread`, `context`, `channel`,
     `spawned`, `killed`, `respawned`, `progress`, `done`, `error`,
@@ -214,7 +214,7 @@ Behavior:
 atw channel spawn <name>
   [--scope project|global]
   [--agent <agent-name>]                  # loads .atw/agents/<name>.md
-  [--provider claude|codex]               # overrides agent file
+  [--provider claude|codex|pi|omp]        # overrides agent file
   [--as <worker-name>]                    # default: agent name
   [--cwd <path>]
   [--model <id>]
@@ -232,12 +232,19 @@ atw channel spawn <name>
                                           # default 5m, 0 disables
   [--max-live-workers <n>]                # spawn-time live-worker budget
                                           # default 6, 0 disables
+  [--sandbox read-only|workspace-write|danger-full-access]
+                                          # codex only; default workspace-write
+  [--read-only]                           # reviewer mode, see workers.md
+  [--clean]                               # claude: needs --read-only
+  [--no-session]                          # no session record, not resumable
+  [--effort <level>]                      # tool's own levels, checked first
+  [--standard-speed]                      # skip the user's fast tier
 ```
 
 Behavior:
 - Provider is validated against the adapter registry
   (`packages/cli/src/commands/channel/adapters/`); current: `claude`,
-  `codex`.
+  `codex`, `pi`, `omp`.
 - Worker stays inbox-idle until the first `send --to <worker>`.
 - Records a `spawned` event with `pid`, `provider`, `agent`, `files`,
   `manifests`.
@@ -245,13 +252,22 @@ Behavior:
   (`ATW_CHANNEL_WORKER_IDLE_TIMEOUT`,
   `ATW_CHANNEL_MAX_LIVE_WORKERS`) →
   `.atw/config.yaml#channel.worker_guard` → built-in defaults.
+- Reviewer mode (`--read-only`, `--clean`, `--no-session`, `--effort`,
+  `--standard-speed`): without them the launch is unchanged. Unknown effort
+  levels and combinations a tool cannot do (claude `--clean` without
+  `--read-only`; codex `--read-only` with a writable `--sandbox`; omp
+  `--effort auto`, or `--read-only --clean` without `--model`) exit 1
+  before launch; a pi or omp level the model lacks fails the handshake before
+  any message is sent. Codex workers record the thread's `instructionSources` as a
+  `progress` event (`detail.kind: "instruction_sources"`). Per-tool
+  translation and known limits: `workers.md` "Reviewer Mode".
 
 ### `run [name]`
 
 ```bash
 atw channel run [name?]
   [--agent <name>]
-  [--provider claude|codex]
+  [--provider claude|codex|pi|omp]
   [--as <worker-name>]
   [--cwd <path>]
   [--model <id>]
@@ -259,6 +275,9 @@ atw channel run [name?]
   [--jsonl <path>] ...                    # repeatable
   [--message <text> | --message-file <path> | --stdin]
   [--timeout <Ns|Nm|Nh>]                  # default 5m
+  [--read-only] [--clean] [--no-session]  # reviewer mode, same as spawn
+  [--effort <level>] [--standard-speed]
+  [--json]                                # one result object on stdout
 ```
 
 Behavior:
@@ -267,6 +286,25 @@ Behavior:
   sends the prompt, waits for `done`, prints the final assistant text to
   stdout, then removes the channel on success. On failure the channel is
   kept for inspection and exit code is 1.
+- `--json`: stdout carries exactly one JSON object, printed in every
+  outcome (the create / spawn / send notes move to stderr). Exit code and
+  keep-on-failure are the same as without it. Fields:
+
+  | Field | Value |
+  |---|---|
+  | `status` | `done` · `timeout` · `error` · `not-started` (the tool never said anything: arguments or launch refused, not installed, handshake failed, or exited at once — e.g. not logged in; or it errored before a word of its own, whether or not it reported an error kind — model names, usage and cost do not count. Claude's `<synthetic>` error message is not an answer) |
+  | `text` | `done`: the final answer. Otherwise the text produced so far (claude: finished text blocks; codex, pi, omp: the streamed answer), or `null` |
+  | `partial` | `true` when `text` is not a finished answer (always the case on timeout with text) |
+  | `durationMs` | wall-clock time of the whole run |
+  | `costUsd` | dollars the tool reported (claude `total_cost_usd`; pi and omp the turn's growth of the `get_session_stats` cost total, which also counts tool-reported and compaction cost, falling back to the turn's `usage.cost.total`); `null` = not reported, distinct from `0`. Codex never reports money, and a timed-out claude, pi or omp run has no cost frame. A failed claude turn's `total_cost_usd` is passed on as is (`0` stays `0`) |
+  | `costUnreported` | `true` when the tool did not report this turn's cost: `costUsd` is `null`, or pi / omp reported `0` for an interrupted turn (pi gives `0` there although the turn did cost; `costUsd` keeps that `0`). A failed turn's `0` is passed on unmarked |
+  | `usage` | token counts the tool reported (codex `tokenUsage.total`: `totalTokens`, `inputTokens`, `cachedInputTokens`, `cacheWriteInputTokens`, `outputTokens`, `reasoningOutputTokens`; pi `get_session_stats` `tokens`: `input`, `output`, `cacheRead`, `cacheWrite`, `total`; omp the same plus `reasoning`); `null` = not reported |
+  | `model` | model the tool says it ran (claude `init`, codex `thread/start`, pi and omp `get_state` as `provider/id`); `null` = not reported |
+  | `instructionSources` | codex: instruction files the thread loaded; `null` for claude, pi and omp |
+  | `error` | raw error text when not `done` (a tool that exits at once has its stderr tail appended; on `timeout` the timeout reason); `null` on `done` |
+  | `errorKind` | the tool's own error kind, verbatim (claude: the `error` of its `<synthetic>` error message, e.g. `model_not_found`, `authentication_failed`; codex: `codexErrorInfo`, e.g. `usageLimitExceeded`); `null` when the tool gave none (always for pi and omp) |
+  | `errorStatus` | the HTTP status the tool reported with that kind (claude `api_error_status`, codex `httpStatusCode`); `null` when it gave none |
+  | `errorSubkind` | a finer kind under `errorKind`, verbatim (claude `api_error`: a used-up plan comes as `rate_limit` with `usage_limit_reached` or `model_requires_usage_credits`; Claude documents the field as internal, so it may be renamed); `null` when it gave none |
 
 > `run` has **no** `--tag` flag. Completion is detected via the `done`
 > event the supervisor emits.
@@ -474,7 +512,8 @@ Forum channels are event-sourced; use the CLI reducers
 - **Pretty reads** (`list`, `messages`, `forum`, `thread`, `context list`)
   print colored, padded tables / timelines.
 - **`run`** prints only the final assistant text on stdout (so callers can
-  pipe); diagnostic notes go to stderr.
+  pipe); diagnostic notes go to stderr. `run --json` prints one result
+  object instead (see `run` above).
 - **Errors** go through `chalk.red("Error:")` to stderr and `exit 1`.
 - **`wait` timeout** specifically exits **124**.
 

package/dist/templates/common/bundled-skills/atw-channel/references/progress-debugging.md

@@ -106,6 +106,15 @@ by `action` field, but the load-bearing fields are always under `detail`:
 - `detail.status` — short string used by long-running actions
   (`starting`, `running`, `flushing`, `done`).
 - `detail.action` — semantic label (e.g. `status` for thread heartbeats).
+- `detail.kind: "model"` (`detail.model`) — the model the tool says it runs
+  (claude `init`, codex `thread/start`, pi and omp `get_state` as `provider/id`).
+- `detail.kind: "token_usage"` (`detail.usage`) — codex token counts after
+  each model request (`total`, `last`, `modelContextWindow`); no money. pi
+  and omp: the session's `get_session_stats` tokens as `usage.total`, after each turn.
+- `detail.kind: "turn_cost"` (`detail.cost_usd`) — pi's or omp's dollars for
+  one finished turn (growth of the `get_session_stats` cost total);
+  `detail.unreported: true` marks the `0` reported for an interrupted turn
+  (the tool did not report that turn's cost).
 
 Progress events are **noisy** by design. `wait` ignores them unless you
 pass `--include-progress`. When you do want to see them, prefer:

package/dist/templates/common/bundled-skills/atw-channel/references/workers.md

@@ -1,8 +1,8 @@
 # Workers And Agent Cards
 
 Use workers when a peer agent should execute independently and report back
-through the channel event log. A worker is a registered child process (claude
-or codex) attached to a channel; the supervisor forwards inbox messages to it
+through the channel event log. A worker is a registered child process (claude,
+codex, pi or omp) attached to a channel; the supervisor forwards inbox messages to it
 and translates its output back into channel events.
 
 ## Spawn
@@ -25,11 +25,11 @@ inbox-idle until a `send --to <worker>` (or a broadcast when
 Key `spawn` flags:
 
 - `--agent <name>` — load `.atw/agents/<name>.md` (provider/model/as/system prompt defaults).
-- `--provider <claude|codex>` — overrides the agent card; validated against the adapter registry.
+- `--provider <claude|codex|pi|omp>` — overrides the agent card; validated against the adapter registry.
 - `--as <name>` — channel worker handle; defaults to the agent name.
 - `--cwd <path>` — worker working directory (also the jail root for `--file`/`--jsonl`).
 - `--model <id>` — model override.
-- `--resume <id>` — resume an existing claude session / codex thread.
+- `--resume <id>` — resume an existing claude session / codex thread / pi or omp session (pi: `--session-id`, omp: `--resume`; both ids are read with `get_state` and kept in `<worker>.session-id`).
 - `--timeout <duration>` — auto-kill after `30s` / `2m` / `1h`.
 - `--warn-before <duration>` — supervisor_warning lead time (default `5m`; `0ms` disables).
 - `--file <path>` (repeatable, glob-supported) — inject file content into the system prompt.
@@ -38,10 +38,54 @@ Key `spawn` flags:
 - `--inbox-policy <explicitOnly|broadcastAndExplicit>` — default `explicitOnly`.
 - `--idle-timeout <duration>` — OOM guard idle TTL (default `5m`; `0` disables).
 - `--max-live-workers <n>` — spawn-time live-worker budget (default `6`; `0` disables).
+- Reviewer mode: `--read-only`, `--clean`, `--no-session`, `--effort <level>`, `--standard-speed` (see below; `run` takes them too).
 
 The success event `spawned` records `pid`, `provider`, `agent`, the injected
 `files`, and the resolved `manifests` so later spectators can audit context.
 
+## Reviewer Mode
+
+Five switches on both `spawn` and `run`. With none of them the worker launches
+exactly as before (claude with full permissions; codex in `workspace-write`, or
+whatever `--sandbox` says; pi with its default tools, writable; omp with `--approval-mode yolo` and no UI, so a
+tool that would need approval fails instead of waiting). A cross-model reviewer turns on `--read-only`,
+`--clean`, `--no-session` and `--standard-speed` together.
+
+| Switch | Meaning | claude | codex | pi | omp |
+|---|---|---|---|---|---|
+| `--read-only` | may read, may not write or run commands | `--permission-mode dontAsk --tools Read,Grep,Glob` (no Bash) instead of the bypass pair | thread `sandbox: "read-only"` | `--tools read,grep,find,ls` | `--tools read,grep,glob --approval-mode always-ask`; overlay `tools.xdev: false` |
+| `--clean` | ignore the user's and project's settings, hooks, MCP, plugins, skills, project instruction files | `--safe-mode --restricted --strict-mcp-config`; file reads limited to `--cwd` | thread config: project untrusted + `project_doc_max_bytes: 0`, hooks / plugins / apps off, every MCP server from `config/read` disabled, skills off, `notify: []` | `--no-extensions --no-mcp --no-skills --no-prompt-templates --no-themes --no-context-files --no-approve` | `--no-extensions --no-skills --no-rules --no-lsp --no-title`; overlay `disabledProviders` switches off context files (`AGENTS.md`, `CLAUDE.md`), MCP and other tools' plugins |
+| `--no-session` | leave no session record; the worker cannot be resumed | `--no-session-persistence` | thread `ephemeral: true` | `--no-session` | `--no-session` |
+| `--effort <level>` | thinking effort, in the tool's own levels | `--effort`; `low` `medium` `high` `xhigh` `max` `ultracode` | `model_reasoning_effort`; `none` `minimal` `low` `medium` `high` `xhigh` `max` `ultra` `persistent` | `--thinking`; `off` `minimal` `low` `medium` `high` `xhigh` `max`, and only the ones the model has | `--thinking`; same levels as pi, only the ones the model has; never `auto` |
+| `--standard-speed` | do not use the fast tier the user set for this tool | `--settings '{"fastMode":false}'` | `service_tier: "default"` | nothing to pass (pi has no fast-tier setting) | overlay `tier.openai` / `tier.anthropic` / `tier.google: none`, `providers.fireworksTier: standard` |
+
+omp reads the "overlay" from a settings file the supervisor writes for each
+launch (`<worker>.config-overlay.yml`, passed as `--config`); no switch, no file.
+As a reviewer (`--read-only` with `--clean`) omp must not reach for another
+model: `--model` is passed together with `--smol`, `--slow` and `--plan`, and the
+overlay pins every chat role (`default` `smol` `slow` `plan` `vision` `commit`
+`tiny` `memory` `task` `advisor`, plus `judge`) to that model whatever the
+user's own roles say, and turns off `retry.modelFallback`, TTSR and compaction.
+An ordinary omp helper gets `--model` only when one was given (otherwise omp's
+own default). Messages that start with `/` are sent with a leading space, or omp
+would run them as its built-in commands.
+
+Refused before anything launches (no silent downgrade):
+
+- an effort level the tool does not have — Claude Code and pi would only warn and use their default, Codex would send it unchanged;
+- omp `--effort auto` — omp would ask its judge model to pick a level for every request;
+- a pi or omp level the chosen model lacks (both would silently use the nearest one): the handshake asks the tool `get_available_thinking_levels` and stops before any message is sent;
+- claude `--clean` without `--read-only` — restricted mode refuses the full-permission mode;
+- codex `--read-only` with `--sandbox workspace-write` / `danger-full-access`;
+- pi or omp `--resume` with `--no-session` — an unsaved session cannot be resumed;
+- omp `--read-only` with `--clean` but no `--model` — the helper roles cannot be pinned.
+
+Known limits:
+
+- claude `--read-only` alone still loads the user's own allow rules and hooks from their settings files, which can widen what the worker may do (for example read outside the cwd). Add `--clean` to drop them.
+- pi and omp `--read-only` alone keep MCP and extension tools (`--tools` does not filter them). Add `--clean` to drop them.
+- codex `--clean` cannot switch off the user-level `~/.codex/AGENTS.md`. The thread's `instructionSources` (the instruction files it actually loaded) are recorded as a `progress` event with `detail.kind: "instruction_sources"`.
+
 ## Agent Cards
 
 `--agent <name>` resolves to `.atw/agents/<name>.md`. The card name must

package/dist/templates/common/bundled-skills/atw-code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: atw-code-review
-description: "沿两个维度审查自某个固定点（提交、分支、标签或合并基点）以来的变更——标准（代码是否遵循了该仓库的文档化编码标准？）和规格（代码是否符合原始问题/规格的要求?）。在并行子代理中同时运行这两项审查；变更涉及界面且调用方提供了截图时，再加第三个维度——视觉（渲染出来的画面是否满足界面验收标准和项目设计规范）。各维度结果并排显示。当用户希望审查某个分支、拉取请求、进行中的更改，或要求“审查自 X 以来”的变更时，请使用此功能。"
+description: "沿两个维度审查自某个固定点（提交、分支、标签或合并基点）以来的变更——标准（代码是否遵循了该仓库的文档化编码标准？）和规格（代码是否符合原始问题/规格的要求?）。在并行子代理中同时运行这两项审查；变更涉及界面且调用方提供了截图时，再加第三个维度——视觉（渲染出来的画面是否满足界面验收标准和项目设计规范）。各维度结果并排显示。当用户希望审查或“审一下”某个分支、拉取请求、进行中的更改或改动，或要求“审查自 X 以来”的变更时，请使用此功能。"
 ---
 
 Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
@@ -51,6 +51,29 @@ git ls-files --others --exclude-standard -z |
 
 Check that `$patch` is non-empty — this replaces the old "diff is non-empty" check. Also note the commit list via `git log <fixed-point>..HEAD --oneline`. If the patch is large, check its total size before spawning: both sub-agents receive it, so the token cost is doubled.
 
+#### Run the floor guard
+
+The moment the patch is frozen, run the floor guard on it — before step 2, before any sub-agent is spawned. It reads only the frozen patch and runs no git of its own, so the guard and the sub-agents look at the same change.
+
+```bash
+floor=$(mktemp); floor_err=$(mktemp)
+task_dir=$(python3 .atw/scripts/task.py current 2>/dev/null)
+if [ -n "$task_dir" ] && [ -f "$task_dir/waiting-on-you.md" ] && [ -f "$task_dir/decision-log.md" ]; then
+  python3 .atw/scripts/floor_guard.py "$patch" --waiting-on-you "$task_dir/waiting-on-you.md" --decision-log "$task_dir/decision-log.md" > "$floor" 2> "$floor_err"
+else
+  python3 .atw/scripts/floor_guard.py "$patch" > "$floor" 2> "$floor_err"
+fi
+floor_exit=$?
+```
+
+When the current task's directory holds both `waiting-on-you.md` and `decision-log.md`, the guard gets them too and passes a placeholder that an item in that list names under the three conditions in step 3. A passed placeholder is still printed, with `放行：等你处理第 N 条` (passed: waiting-on-you item N) at the end of its line. The guard reads the two files when it runs, which is why it runs here, before anything else in the review: an item written after the review began cannot pass. Without both files the guard runs exactly as before.
+
+- `0` — clean, or every line it printed is a placeholder it passed against a waiting-on-you item.
+- `1` — at least one finding that was not passed. One line per finding: rule name, `file:line`, the marker or a short snippet. Seven rules: `skip-marker`, `suppress-comment`, `test-file-deleted`, `assertion-removed`, `ignore-entry`, `placeholder`, and `guard-opt-out` — a file whose head declares `floor-guard: opt-out — <reason>` is reported as that one line (file, reason) instead of line by line; a declaration without a reason does not count. The declaration is read from the file in the working tree when it is there (a hunk that never shows the file head still counts), so run the guard from the repo root. Conditional skips (`.skipIf(`, `pytest.mark.skipif`, a `pytest.skip(` under an `if`) are not reported; an assertion that was only edited around (its expression is still in the file) is not reported as removed.
+- `2` — the guard did not run (file missing, not a patch, a waiting-on-you list or decision log it cannot read, the script itself failed). Its error is in `$floor_err`, kept apart from the findings in `$floor` so nothing but findings ever lands in the report verbatim. **`2` is never `0`**: a guard that did not run is a hard violation in the report (step 5), not a clean result.
+
+Keep `$floor` and `$floor_exit`. The output goes into the Standards sub-agent prompt (step 4) and, verbatim, into the final report (step 5).
+
 ### 2. Identify the spec source
 
 Look for the originating spec, in this order:
@@ -85,6 +108,33 @@ Each smell reads *what it is* → *how to fix*; match it against the diff:
 - **Middle Man** — a class or function that mostly just delegates onward. → cut it, call the real target direct.
 - **Refused Bequest** — a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.
 
+#### Floor-guard checks
+
+After the smell baseline, the Standards axis always carries three **floor-guard checks**. Unlike the smells, these are **hard violations, not judgement calls**: each either happened in the diff or it didn't, and no "possible" label applies. The floor guard script (step 1) catches the mechanical part — markers, deleted tests, removed assertions, ignore entries, placeholders; these three cover what needs reading:
+
+- **Thresholds** — a numeric bar in configuration (coverage requirement, budget, severity level) moved: was it lowered or raised? Lowering is the violation; raising is not.
+- **Placeholders** — a stub, `not implemented`, empty catch or TODO left in the change: did the ticket, the PRD, or a waiting-on-you item passed under the three conditions say in advance that this placeholder would be there? If not, it is a violation.
+- **Exceptions** — a skip, suppression or ignore entry: is it written on the offending line itself, with a reason? An exception somewhere else, or without a reason, is a violation.
+
+**Every finding the floor guard reports goes into the report, unless the ticket or the PRD said in advance that it is allowed.** "Said in advance" means a line in the ticket or the PRD that names the placeholder or exception — or, for a placeholder only, an item in the task's waiting-on-you list (`waiting-on-you.md`) that passes all three conditions below. So the sources of "said in advance" are the ticket, the PRD, or a waiting-on-you item passed under the three conditions. Nothing else exempts a finding — not a commit message, not a code comment, not the author's word, not a decision-log row on its own.
+
+A placeholder left because an unattended run lacked an external account, a key or a payment passes against a waiting-on-you item only when all three hold:
+
+1. The item's category is external account · key · payment (外部账号·密钥·付费).
+2. The item is still open (not checked off), names this placeholder's `file:line`, says what is missing and how to hook it up once filled in, the decision log has the item's row and that row has not been superseded, and the item was written before this review began.
+3. The report still lists it, marked `放行：等你处理第 N 条` (passed: waiting-on-you item N).
+
+The guard checks the first two itself when step 1 hands it the two files, and marks the line; take its mark as the verdict and do not pass a placeholder by reading the list yourself. Every other placeholder is as before: if the ticket or the PRD did not say it in advance, it is a hard violation.
+
+#### Security and speed checks
+
+Two more checklists join the Standards axis only when the change calls for them. They are not a new axis: the Standards sub-agent runs them, and a change that calls for neither carries neither. Read the patch and decide:
+
+- **Security check** — when the change touches what atw-security's description lists: external input, login and permissions, stored data or personal information, file upload, external services, or calling AI models. Load atw-security's completion self-check — the "Verification" list in [atw-security](../atw-security/SKILL.md) — and check the change against each item.
+- **Speed check** — only when the change clearly affects speed: a hot loop, a query, bundle size, or page load that the change is about or visibly makes heavier — a new query in ordinary feature code does not by itself qualify. Load the seven questions under "Benchmark checklist" → "The questions" in [atw-performance](../atw-performance/SKILL.md), and check that the change carries measurements — before-and-after numbers in the patch (a benchmark, a raw data file, a decision-log row) or in the commit list — and that the numbers answer the seven questions. A change that clearly affects speed and carries no measurements is a hard violation. Measurements that do not answer all seven questions are a judgement call — name the questions left unanswered.
+
+A self-check item is a hard violation only when the code this change adds or modifies shows it failing. An item the patch simply does not contain — rate limiting or security headers that live elsewhere in the system — is not a finding: a missing item is not a vulnerability. An item the changed code touches but the patch cannot settle is a judgement call — say what would settle it.
+
 ### 4. Spawn the sub-agents in parallel
 
 The Standards and Spec sub-agents read the **frozen patch from step 1** and run **no git commands of their own** — same input, no chance of one axis seeing a file the other missed, and no re-deriving the untracked list from memory.
@@ -93,7 +143,9 @@ The Standards and Spec sub-agents read the **frozen patch from step 1** and run
 
 - The path to the frozen patch, and the commit list. State plainly: this patch is the complete change under review, including uncommitted and untracked files; do not run git.
 - The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full — the sub-agent has no other access to it.
-- The brief: "Report — per file/hunk where relevant — (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls — documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
+- **The floor guard's output** from step 1 — the contents of `$floor` pasted verbatim with `$floor_exit`, **plus the floor-guard checks from step 3** pasted in full. Tell the sub-agent what to do with it: for each line the guard reported, check whether the ticket or the PRD said in advance that it is allowed — a line the guard marked `放行：等你处理第 N 条` is allowed by waiting-on-you item N: list it as passed with its item number, not as a violation — and report every line that isn't allowed as a hard violation; if the exit code is `2`, report "the floor guard did not run" as a hard violation.
+- The security check, the speed check, or both from step 3, pasted in full, when the change calls for them — the section's text plus the "Verification" list or the seven questions it points at, with one line on what in the change triggered each. When neither applies, paste neither.
+- The brief: "Report — per file/hunk where relevant — (a) every place the diff violates a documented standard: cite the standard (file + the rule); (b) any baseline smell you spot: name it and quote the hunk; (c) every floor-guard finding not allowed in advance by the ticket, the PRD or a waiting-on-you item the guard passed, and every floor-guard check that fails — say where the ticket or PRD allows the ones you drop, and list each passed line with its waiting-on-you item number; and (d) when the security or speed check is pasted, every item of it the change fails, and for the speed check whether the change carries measurements that answer the seven questions. Distinguish hard violations from judgement calls — documented-standard breaches can be hard, floor-guard findings and checks are always hard, security and speed findings are hard or judgement calls as the pasted section says, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
 
 **Spec sub-agent prompt** — include:
 
@@ -108,7 +160,8 @@ If the spec is missing, skip the Spec sub-agent and note this in the final repor
 - The screenshot paths, each labelled with screen, state and logical viewport.
 - The spec's UI and Design section and the ticket's UI acceptance criteria.
 - The path to the UI layer's `design-system.md` in `.atw/spec/`, if the project has one.
-- The brief: "Look at every screenshot before judging. Report: (a) UI acceptance criteria not met, citing the screenshot; (b) departures from the project's design rules — colours, type sizes, spacing or components outside them; (c) the one to three biggest visual problems — hierarchy, alignment, crowding, overflow, unreadable text — each with location, observation and a concrete fix. Distinguish observable defects from taste. Do not open source files. If you cannot view images, say so and stop. Under 400 words."
+- The project's accessibility requirements, if it has any (in `design-system.md` or elsewhere in `.atw/spec/`); otherwise the path to atw-ui's [accessibility checklist](../atw-ui/references/accessibility-checklist.md).
+- The brief: "Look at every screenshot before judging. Report: (a) UI acceptance criteria not met, citing the screenshot; (b) departures from the project's design rules — colours, type sizes, spacing or components outside them; (c) the one to three biggest visual problems — hierarchy, alignment, crowding, overflow, unreadable text — each with location, observation and a concrete fix; (d) accessibility problems the screenshots show, checked against the project's accessibility requirements or, when it has none, the accessibility checklist — contrast, visible focus, colour as the only signal, target size — leaving out what a screenshot cannot show. Distinguish observable defects from taste. Do not open source files. If you cannot view images, say so and stop. Under 400 words."
 
 This sub-agent needs a model that can view images. If none is available, skip it and say in the final report that the Visual axis did not run.
 
@@ -118,8 +171,19 @@ Issue every sub-agent call together, in the foreground, and aggregate the report
 
 Present the reports under `## Standards` and `## Spec` headings — plus `## Visual` when that axis ran — verbatim or lightly cleaned. Do **not** merge or rerank findings — the axes are deliberately separate (see _Why two axes_).
 
+Under `## Standards`, add a `### Floor guard` sub-section: the guard's output from step 1 verbatim, its exit code, and the sub-agent's verdict on each line — where the ticket or PRD allows it, passed: waiting-on-you item N (for a line the guard marked `放行：等你处理第 N 条`), or a hard violation. Passed lines stay in the sub-section and do not count as violations in the Standards tally. When the exit code was `2`, the sub-section says **"the floor guard did not run"**, carries the error from `$floor_err`, and counts as a hard violation in the Standards tally — a guard that did not run is not a clean guard. Say on one line which of the security and speed checks the Standards axis carried and what triggered each, or that it carried neither.
+
 End with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes — that's the reranking the separation exists to prevent.
 
+When the user asked for this review themselves, inside an ATW task, and the change is a high-risk change or the task's decision log has rows marked unsure (拿不准), close the report with one sentence suggesting a cross-model review — one sentence even when both hold. Say nothing when `/atw-implement`, `/atw-implement-all` or `/atw-implement-spec` runs this review as a step of its flow, and nothing for a small change with no task. High-risk means you read the whole change and it really changes behaviour in at least one of three areas — security (login and authentication, permission checks, keys and encryption, handling content from outside, network endpoints open to others), data (database schemas, data migrations, deleting or bulk-rewriting user data, data formats saved to disk or sent out), or irreversible or wide blast radius (releases, deployment and upgrades, public interfaces and command-line arguments others depend on, billing and payment); a typo, comments or tests alone do not count, and concurrency and retries are not on the list. Unsure rows are technical judgements made without being sure; when the task has a `decision-log.md`, list them with `python3 .atw/scripts/decision_log.py unsure` — rows already superseded are left out — acknowledged ones still count. The sentence, for a high-risk change, names the files and the area each falls in; for unsure rows, names each row by its time and decision; says what it costs — one run's money or quota, the code is sent to another company's model, and it takes up to about 30 minutes; and gives the input for the user's current tool only, the one line below that names that tool:
+
+- Claude Code: `/atw-cross-model-review`
+- Codex: `$atw-cross-model-review`
+- pi: `/skill:atw-cross-model-review`
+- omp: `/skill:atw-cross-model-review`
+
+The user runs it; you never start it. When the change is not high-risk and there are no unsure rows, say nothing about cross-model review at all — not that it is not needed, not that the change is low-risk. Once per task: say nothing when the task directory already holds a report under `cross-model-review/`, or when it was already suggested in this conversation.
+
 ## Why two axes
 
 A change can pass one axis and fail the other:
@@ -130,3 +194,14 @@ A change can pass one axis and fail the other:
 Reporting them separately stops one axis from masking the other.
 
 The Visual axis exists for the same reason: code can match the spec and every standard and still render as an unreadable, overflowing screen. Neither code-reading axis can see that.
+
+## Rationalizations specific to this skill
+
+Same shape as the general table in `.atw/workflow.md`; these are the excuses that only show up while reviewing.
+
+| Rationalization | Reality |
+|---|---|
+| The patch is too big to read in full, sample it | Say it is too big to read in full; sampling is not reviewing |
+| This is a judgement call, no need to report it | Judgement calls get reported too — labelled as judgement calls |
+| The author says it has been tested | Do not accept conclusions; look only at artefacts |
+| Nobody wrote this standard down | The smell baseline applies even when the repo documents nothing |

package/dist/templates/common/bundled-skills/atw-codebase-design/SKILL.md

@@ -110,5 +110,5 @@ Good interfaces make testing natural:
 
 ## Going deeper
 
-- **Deepening a cluster given its dependencies** — see [DEEPENING.md](DEEPENING.md): dependency categories, seam discipline, and replace-don't-layer testing.
-- **Exploring alternative interfaces** — see [DESIGN-IT-TWICE.md](DESIGN-IT-TWICE.md): spin up parallel sub-agents to design the interface several radically different ways, then compare on depth, locality, and seam placement.
+- **Deepening a cluster given its dependencies** — see [deepening.md](deepening.md): dependency categories, seam discipline, and replace-don't-layer testing.
+- **Exploring alternative interfaces** — see [design-it-twice.md](design-it-twice.md): spin up parallel sub-agents to design the interface several radically different ways, then compare on depth, locality, and seam placement.

package/dist/templates/common/bundled-skills/atw-codebase-design/{DESIGN-IT-TWICE.md → design-it-twice.md}

@@ -11,7 +11,7 @@ Uses the vocabulary in [SKILL.md](SKILL.md) — **module**, **interface**, **sea
 Before spawning sub-agents, write a user-facing explanation of the problem space for the chosen candidate:
 
 - The constraints any new interface would need to satisfy
-- The dependencies it would rely on, and which category they fall into (see [DEEPENING.md](DEEPENING.md))
+- The dependencies it would rely on, and which category they fall into (see [deepening.md](deepening.md))
 - A rough illustrative code sketch to ground the constraints — not a proposal, just a way to make the constraints concrete
 
 Show this to the user, then immediately proceed to Step 2. The user reads and thinks while the sub-agents work in parallel.
@@ -20,7 +20,7 @@ Show this to the user, then immediately proceed to Step 2. The user reads and th
 
 Spawn 3+ sub-agents in parallel. Each must produce a **radically different** interface for the deepened module.
 
-Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
+Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [deepening.md](deepening.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
 
 - Agent 1: "Minimize the interface — aim for 1–3 entry points max. Maximise leverage per entry point."
 - Agent 2: "Maximise flexibility — support many use cases and extension."
@@ -34,7 +34,7 @@ Each sub-agent outputs:
 1. Interface (types, methods, params — plus invariants, ordering, error modes)
 2. Usage example showing how callers use it
 3. What the implementation hides behind the seam
-4. Dependency strategy and adapters (see [DEEPENING.md](DEEPENING.md))
+4. Dependency strategy and adapters (see [deepening.md](deepening.md))
 5. Trade-offs — where leverage is high, where it's thin
 
 ### 3. Present and compare