@chinhae/atw-cli 0.4.0 → 0.6.0

package/dist/templates/atw/workflow.md

@@ -7,7 +7,7 @@
 1. **Plan before code** — figure out what to do before you start
 2. **Specs injected, not remembered** — guidelines are injected via hook/skill, not recalled from memory
 3. **Persist everything** — research, decisions, and lessons all go to files; conversations get compacted, files don't
-4. **One ticket at a time, unless the user asks for the whole spec at once** — serial by default: claim, finish, close, then take the next. `/atw-implement-spec` is the one parallel path, and only the user starts it
+4. **One ticket at a time, unless the user asks for the whole spec at once** — serial by default: claim, finish, close, then take the next. `/atw-implement-spec` is the one parallel path; `/atw-implement-all` is the third way through stop ③ — started once, still serial, still reviewed per ticket. Only the user starts any of them
 5. **Capture learnings** — after each ticket, review and write new knowledge back to spec
 
 ---
@@ -205,7 +205,7 @@ python3 ./.atw/scripts/get_context.py --mode phase --step <X.Y>  # detailed guid
 
 ```
 Phase 1: Plan    → discover, specify, and (when needed) slice into tickets
-Phase 2: Execute → one ticket at a time through the full implement chain, or the whole spec in one parallel run
+Phase 2: Execute → one ticket at a time through the full implement chain, or the whole spec in one run — parallel, or serial with a review per ticket
 Phase 3: Finish  → read-only acceptance check, then archive
 ```
 
@@ -243,7 +243,7 @@ Outside these four, the AI advances stages on its own. It does not stop to ask "
 |---|---|---|
 | ① | Before creating a task | Does this work deserve a record — the user's |
 | ② | After the spec is written | Is the spec right — the user's |
-| ③ | Before implementation starts | The user runs `/atw-implement` per ticket, or `/atw-implement-spec` once for the whole spec; the AI cannot invoke either |
+| ③ | Before implementation starts | The user runs `/atw-implement` per ticket, `/atw-implement-spec` once for the whole spec in parallel, or `/atw-implement-all` once for the whole spec serially; the AI cannot invoke any of the three |
 | ④ | Before archiving | "This is done" — the user's acceptance |
 
 ### Planning Artifacts
@@ -335,19 +335,21 @@ When the tickets are written, run `task.py start <task>` (step 1.5) to enter imp
 - 2.4 Close the ticket `[required · repeatable]`
 - 2.5 Roll back `[on demand]`
 - 2.7 Whole-spec run `[alternative to 2.1–2.4 · once]` (stop ③; the user picks it)
+- 2.8 Serial whole-spec run `[alternative to 2.1–2.4 · once]` (stop ③; the user picks it)
 
 <!-- Per-turn breadcrumb: stage 'implement' — set by task.py start, held for all of Phase 2 -->
 
 [workflow-state:implement]
-Stop ③: implementation is the user's to start. You may not invoke either skill below yourself, and you may not do the implementation inline instead. When the task has tickets, name both ways and let the user pick; a task with no tickets has only the first.
+Stop ③: implementation is the user's to start. You may not invoke any of the three skills below yourself, and you may not do the implementation inline instead. When the task has tickets, name all three ways and let the user pick; a task with no tickets has only the first.
 Per-ticket path (the default): one ticket at a time. Run `tickets.py frontier`, pick one, `tickets.py claim NN` — never hold two tickets at `doing` — then tell the user to run `/atw-implement` for the claimed ticket. One user invocation per ticket.
 Whole-spec path: the user runs `/atw-implement-spec` once. It owns the run from the first claim to the closing commit: it claims with `tickets.py claim NN --parallel`, dispatches implementer sub-agents across the frontier, each in its own worktree, lands everything on one integration branch, marks each ticket `done` as its work merges, reviews that branch once at the end, and writes spec updates back before its closing commit. Do not claim, review or commit around it. It needs a platform that dispatches sub-agents.
+Serial whole-spec path: the user runs `/atw-implement-all` once. The main session is the orchestrator and the loop is the per-ticket chain without the per-ticket "start": claim → dispatch an implementer → review → fix once, re-check once → write spec updates back → `tickets.py done` → commit state → next ticket. Plain `tickets.py claim NN`, one ticket at `doing`, in place on the current branch, a review per ticket. It halts for four things — an implementer's result-changing ambiguity, a finding still open after the one re-check, a ticket that cannot be finished as written, a frontier holding only `ready-for-human` tickets or a next ticket that is plainly human work — and for `--max N`; a ticket left at `doing` is the breakpoint, and running the same command again resumes from it. It needs a platform that dispatches sub-agents.
 On the per-ticket path, that one `/atw-implement` run is a closed chain and must not be broken up from the outside: implement (test-first where it fits) → run tests, full suite on the last pass → review → handle findings → write spec updates back → commit. Never instruct it to skip the review or the commit.
 Findings triage: spec-axis findings and anything the standards axis calls a hard violation get fixed once, then only what was fixed is re-checked, once, then the commit. No second full review and no loop: anything still open after that one re-check goes to the user before the commit. Judgement calls ship and get reported.
 Relay every review report to the user verbatim — Standards and Spec, plus Visual when the ticket changed UI — even when the verdict is "nothing found". No report reaching you is not a passing review.
 Any sub-agent dispatched from here starts its prompt with `Active task: <task path from task.py current>` — the role files read that line to find the task, and it is the context hooks' fallback when session resolution misses.
-Main-session default: run the process; on the per-ticket path the implementation itself is written inside `/atw-implement`, never by a dispatched `atw-implement-agent` — that role file is reserved and is not a step in this flow. The only sub-agent that path raises is `atw-review` (twice, from inside `/atw-implement` — three times when the ticket changes UI and a Visual review runs). Implementer sub-agents exist only inside a `/atw-implement-spec` run, dispatched by that skill and by nothing else. Sub-agent self-exemption: this breadcrumb reaches sub-agent turns on some hosts. If you are already running as `atw-review`, do NOT spawn another `atw-review` — do the review you were dispatched for. If you were dispatched by `/atw-implement-spec` as an implementer or merger, stop ③ is already satisfied — do the work you were dispatched for and dispatch nothing. Dispatch is main session only.
-Per-ticket path: then `tickets.py done NN` and back to the frontier. Either path: when the frontier is empty and every ticket is `done`, run `task.py set-status <task> accept`.
+Main-session default: run the process; on the per-ticket path the implementation itself is written inside `/atw-implement`, never by a dispatched `atw-implement-agent` — that role file is reserved and is not a step in this flow. The only sub-agent that path raises is `atw-review` (twice, from inside `/atw-implement` — three times when the ticket changes UI and a Visual review runs). Implementer sub-agents exist only inside a `/atw-implement-spec` or `/atw-implement-all` run, dispatched by that skill and by nothing else. Sub-agent self-exemption: this breadcrumb reaches sub-agent turns on some hosts. If you are already running as `atw-review`, do NOT spawn another `atw-review` — do the review you were dispatched for. If you were dispatched by `/atw-implement-spec` as an implementer or merger, or by `/atw-implement-all` as an implementer, stop ③ is already satisfied — do the work you were dispatched for and dispatch nothing. Dispatch is main session only.
+Per-ticket path: then `tickets.py done NN` and back to the frontier. Any path: when the frontier is empty and every ticket is `done`, run `task.py set-status <task> accept` and commit the `task.json` change, so the tree is clean when 3.1 starts.
 [/workflow-state:implement]
 
 ### Phase 3: Finish
@@ -360,6 +362,7 @@ Per-ticket path: then `tickets.py done NN` and back to the frontier. Either path
 [workflow-state:accept]
 Read-only from here. Do not open new work, do not fix things you notice — file them as tickets or a follow-up task instead.
 Walk the acceptance criteria in `prd.md` one by one and report which are met, with evidence; for UI criteria the evidence is a screenshot of the named screen, state and viewport (`/atw-ui` can review read-only). Confirm `tickets.py summary` shows every ticket `done` and `git status --porcelain` is clean.
+As each criterion checks out, tick its checkbox in `prd.md` and in the ticket that carried it — the ticks are the acceptance record, nobody earlier ticks them. Commit the ticks once (`chore(task): <task> acceptance check`) before stop ④.
 Stop ④: present that and wait for the user to accept. Acceptance is the user's judgement, not yours.
 Once accepted, run `task.py archive <task>` — status goes to `completed` and the task moves to `archive/`.
 [/workflow-state:accept]
@@ -391,14 +394,15 @@ When a user request matches one of these intents inside an active task, route fi
 - Slicing a confirmed spec into tickets → `/atw-tickets`
 - Starting a claimed ticket → `/atw-implement` (the user runs it; stop ③)
 - Implementing every ticket of a sliced spec in one parallel run → `/atw-implement-spec` (the user runs it; stop ③)
+- Implementing every ticket of a sliced spec in one serial run, reviewed per ticket → `/atw-implement-all` (the user runs it; stop ③)
 - Building or polishing a screen for a claimed ticket → `/atw-ui`, used from inside `/atw-implement`
 - Same bug fixed more than once → `/atw-diagnosing-bugs`
 - Knowledge worth keeping outside a ticket → `/atw-update-spec`
 - The user cannot follow the terms, an approval prompt or an error, or says "开启小白模式" / "关闭小白模式" → `/atw-noob-mode` (in any stage, with or without a task)
 
-Seven of these are user-triggered and the AI cannot invoke them: `/atw-askme`,
+Eight of these are user-triggered and the AI cannot invoke them: `/atw-askme`,
 `/atw-askme-with-docs`, `/atw-map`, `/atw-spec`, `/atw-tickets`, `/atw-implement`,
-`/atw-implement-spec`.
+`/atw-implement-spec`, `/atw-implement-all`.
 Name the one that fits and let the user run it — calling the Skill tool on one
 returns an error and nothing else.
 
@@ -408,6 +412,7 @@ returns an error and nothing else.
 - Stops ①–④ are the user's calls. Never advance through one by inferring the answer.
 - Planning must be persisted to task artifacts; the review chain must run before reporting a ticket complete.
 - Never mark two tickets `**Impl:** doing` at the same time. The only thing that may is a `/atw-implement-spec` run, through `tickets.py claim NN --parallel`.
+- `/atw-implement-all` is a user-started run like `/atw-implement-spec`: it claims serially and dispatches its own implementers. Outside one of those two runs, no implementer sub-agent is dispatched.
 
 ### Loading Step Detail
 
@@ -590,16 +595,17 @@ Ready to leave Phase 1:
 
 Goal: turn the confirmed spec into committed, reviewed code.
 
-There are two ways through this phase, and the user picks at stop ③:
+There are three ways through this phase, and the user picks at stop ③:
 
 | Path | What the user runs | How the tickets move |
 |---|---|---|
 | Per ticket (the default) | `/atw-implement`, once per ticket | Steps 2.1–2.4: one ticket at a time, each reviewed before it is closed |
 | Whole spec | `/atw-implement-spec`, once | Step 2.7: implementer sub-agents work the frontier in parallel on one integration branch, reviewed once at the end |
+| Whole spec, serial | `/atw-implement-all`, once | Step 2.8: the main session orchestrates — one implementer sub-agent per ticket, in place on the current branch, each ticket reviewed before it is closed |
 
-A task with no tickets has only the per-ticket path. The whole-spec path also needs a platform that dispatches sub-agents; on one that does not, name only the per-ticket path.
+A task with no tickets has only the per-ticket path. Both whole-spec paths also need a platform that dispatches sub-agents; on one that does not, name only the per-ticket path.
 
-The main session runs the process. On the per-ticket path it does not write the implementation itself and it does not dispatch an implementation sub-agent — the work happens inside `/atw-implement`, which the user starts. On the whole-spec path the main session is the orchestrator `/atw-implement-spec` describes, and the implementers it dispatches are that skill's, not a step of this file.
+The main session runs the process. On the per-ticket path it does not write the implementation itself and it does not dispatch an implementation sub-agent — the work happens inside `/atw-implement`, which the user starts. On either whole-spec path the main session is the orchestrator that skill describes — `/atw-implement-spec` or `/atw-implement-all` — and each run dispatches its own implementers; they are that skill's, not a step of this file.
 
 **Sub-agent dispatch protocol** — applies to every platform and every sub-agent
 dispatched anywhere in this workflow (the review sub-agents raised inside the
@@ -624,9 +630,9 @@ dispatch, and it dispatches itself.
 Implementation is never dispatched on the per-ticket path. `atw-implement-agent`
 ships as a reserved role file so the injection path stays wired (D23), but no
 step in this workflow spawns it — the code is written inside `/atw-implement`.
-A `/atw-implement-spec` run does dispatch implementers, as general-purpose
-sub-agents carrying that skill's own brief — not `atw-implement-agent`, which
-may not commit.
+A `/atw-implement-spec` or `/atw-implement-all` run does dispatch implementers,
+as general-purpose sub-agents carrying that skill's own brief — not
+`atw-implement-agent`, which may not commit.
 
 On Grok Build, use `spawn_subagent` with `subagent_type` set to the ATW agent
 name (e.g. `atw-review`). On Kimi Code, dispatch the built-in `coder` /
@@ -654,7 +660,7 @@ For a task that was never sliced, skip to 2.2: the whole `prd.md` is the unit of
 
 **Stop ③**: tell the user to run `/atw-implement`.
 
-You cannot invoke it and you must not substitute for it — not by implementing inline, and not by reading its instructions and following them yourself. One user invocation per ticket.
+You cannot invoke it and you must not substitute for it — not by implementing inline, and not by reading its instructions and following them yourself. One user invocation per ticket. A ticket whose `**Status:**` is `ready-for-human` is not skipped on this path, but `/atw-implement` confirms with the user before touching code: they do it themselves, or they explicitly authorize the AI to do it, and that authorization goes into the commit `/atw-implement` makes at the end of its chain.
 
 That single run is a closed chain:
 
@@ -712,7 +718,7 @@ If the same issue has now been fixed more than once, stop patching and tell the
 
 #### 2.7 Whole-spec run `[alternative to 2.1–2.4 · once]`
 
-**Stop ③**, the other way through it: the user runs `/atw-implement-spec` instead of `/atw-implement`. You cannot invoke it, and you do not start it because it looks faster — the user is trading a per-ticket look at the work for one review at the end, and that trade is theirs.
+**Stop ③**, the second way through it: the user runs `/atw-implement-spec` instead of `/atw-implement`. You cannot invoke it, and you do not start it because it looks faster — the user is trading a per-ticket look at the work for one review at the end, and that trade is theirs.
 
 It replaces steps 2.1–2.4 for the whole task. The skill carries the procedure; what this file needs you to know is what changes around it:
 
@@ -730,6 +736,28 @@ When every ticket is `done`:
 python3 ./.atw/scripts/task.py set-status <task-dir> accept
 ```
 
+#### 2.8 Serial whole-spec run `[alternative to 2.1–2.4 · once]`
+
+**Stop ③**, the third way through it: the user runs `/atw-implement-all` instead of `/atw-implement`. You cannot invoke it, and you do not start it because the user seems to want the whole spec done — removing the per-ticket "start" is the user's trade to make, same as in 2.7.
+
+It replaces steps 2.1–2.4 for the whole task. The skill carries the procedure; what this file needs you to know is how it differs from 2.7:
+
+- **Tickets run serially.** The main session is the orchestrator. It claims with the plain `tickets.py claim NN`, so exactly one ticket is at `**Impl:** doing` and it is the current ticket, as on the per-ticket path. Do not claim by hand during the run.
+- **Work lands in place**, on the branch the task started on. One implementer sub-agent per ticket works on the current branch and commits there; no worktree, no integration branch, no merger.
+- **One review per ticket**, run by the orchestrator in the main session against the `implementation_base_sha` the claim recorded, before the ticket is closed. Findings follow the 2.2 triage: fixed once by the same implementer, re-checked once; whatever is still open goes to the user before the spec is written back.
+- **Spec updates land per ticket**, before the state commit that closes it. Every ticket leaves the implementer's code commit and the orchestrator's state commit.
+- **Review reports are relayed as written** (step 2.3 applies unchanged).
+
+The orchestrator takes the lowest-numbered frontier ticket whose `**Status:**` is not `ready-for-human`, and reads it before dispatching: plainly human work stops the run instead of being dispatched.
+
+The run halts and reports when an implementer hits an ambiguity that would change the result (the orchestrator asks the user and continues), when a finding is still open after the one re-check (same), when a ticket cannot be finished as written, or when the frontier holds only `ready-for-human` tickets. `--max N` halts it cleanly after N tickets. Every closed ticket is already written back and committed, so stopping needs no cleanup: a ticket left at `doing` is the breakpoint, and running `/atw-implement-all` again resumes from it — or the user finishes that ticket with `/atw-implement` and runs it again. After the user finishes a `ready-for-human` ticket — by hand, or through `/atw-implement` — the next `/atw-implement-all` starts from whatever state that left: one ticket at `doing` (the per-ticket path may already have claimed the next frontier ticket, as 2.4 says) is resumed, not re-claimed; nothing at `doing` means the run claims from the frontier. A `doing` ticket after a human ticket is an expected state, not a broken one, and both branches close the ticket the same way — review, write-back, `done`, state commit. Every halt reports one table: a row per ticket with its state, commits, review verdicts and what the user was asked.
+
+When every ticket is `done`, the run itself moves the task on, then commits the `task.json` change as the run's last state commit, so it ends on a clean tree:
+
+```bash
+python3 ./.atw/scripts/task.py set-status <task-dir> accept
+```
+
 ---
 
 ## Phase 3: Finish
@@ -747,7 +775,9 @@ python3 ./.atw/scripts/tickets.py summary   # every ticket done
 git status --porcelain                      # clean tree; the chain commits as it goes
 ```
 
-After a whole-spec run the work sits on the integration branch named in `task.json.branch`. Say so in the report: merging it is the user's call, made after acceptance.
+As each criterion checks out, tick its checkbox — in `prd.md` and in the ticket that carried it. Nobody earlier in the chain ticks them (`tickets.py done` flips `**Impl:**` only), so the ticks are the acceptance record, not new work. When every criterion has been walked, commit the ticks once — `chore(task): <task> acceptance check` — so the tree is clean before stop ④.
+
+After a parallel whole-spec run (2.7) the work sits on the integration branch named in `task.json.branch`; a serial run (2.8) lands in place on the task branch. Say so in the report: merging it is the user's call, made after acceptance.
 
 **Stop ④**: present that and wait. Whether the work is done is the user's judgement, not yours — you can report that every criterion is met, but you cannot accept on their behalf.
 
@@ -775,7 +805,7 @@ Edit the corresponding step's walkthrough body in the Phase 1 / 2 / 3 sections a
 
 - No active task must triage first and ask for task-creation consent before creating an ATW task.
 - Each of the four stops must stay reachable and must stay the user's call.
-- Every execution path must keep review and spec update inside the run, never after it: before each ticket's commit on the per-ticket path, before the closing commit on the integration branch on the whole-spec path.
+- Every execution path must keep review and spec update inside the run, never after it: before each ticket's commit on the per-ticket path and the serial whole-spec path, before the closing commit on the integration branch on the parallel whole-spec path.
 
 Structure is guarded by `packages/cli/test/scripts/workflow-structure.test.ts`, which runs with `pnpm test` — there is no separate step to remember.
 

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

@@ -8,6 +8,14 @@ Implement the work described by the user in the spec or tickets.
 
 If the user passes a ticket reference, fetch it from the issue tracker and state its title before starting. If the reference is ambiguous, ask. If the tracker already marks a different ticket as in progress, stop and say so — don't switch tickets on your own.
 
+Then, before touching any code, read the ticket's `**Status:**` line. `ready-for-human` means the slicer decided a person should do this ticket. Stop there: say the ticket is marked for a human, quote the reason the ticket gives, and ask the user to pick one of two things — they do it themselves, or they explicitly authorize you to do it in their place.
+
+- Nothing short of an explicit yes counts. A question back, a vague answer or silence is not authorization: ask once more, or end the run.
+- They do it themselves: tell them to run `python3 .atw/scripts/tickets.py done NN` when finished and commit that ticket-state change, so the tree is clean for the next run. This run ends there and changes no file.
+- They authorize you: continue with the chain below. The commit you make at the end of it carries one extra line — `ready-for-human ticket implemented by AI with the user's authorization` — followed by the gist of what the user said, so the record shows who decided.
+
+A task without tickets, or a run with no ticket reference, has no `Status:` line and this step does not apply.
+
 Call the Skill tool with "atw-tdd" where possible, at pre-agreed seams.
 
 Run typechecking regularly, single test files regularly, and the full test suite once at the end.

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

@@ -0,0 +1,93 @@
+---
+name: atw-implement-all
+description: "把切好工单的规格一次串行做完：主会话当指挥者，按前沿逐张派出实现子代理，每张票在主会话里审查、处理发现、回写 spec、关单、提交状态；可选 --max N 干净停，停下后再跑同一条命令从断点续上。"
+disable-model-invocation: true
+---
+
+You have been provided a spec sliced into tickets on an ATW task. This skill is the third way through stop ③: the user runs it once, and you — the main session — become the **orchestrator**. You work the ticket frontier one ticket at a time, dispatching one **implementer sub-agent** per ticket, and you run every ticket's review, findings, spec write-back, close-out and state commit yourself, in this session. It is the per-ticket `/atw-implement` chain with the "press start" removed — not the parallel `/atw-implement-spec` run: no worktrees, no integration branch, no merger, and a review per ticket instead of one at the end.
+
+Only the user starts this skill. You never invoke it yourself.
+
+This skill needs an ATW task directory (`.atw/scripts/tickets.py` exists). If it does not, tell the user to run `/atw-init-repo`.
+
+## Before the first ticket
+
+Check in this order, and stop with the named pointer when a check fails:
+
+- The current task (`python3 .atw/scripts/task.py current`) is in the `implement` stage.
+- The task has an `issues/` directory with tickets. A task with no tickets has only `/atw-implement`; tell the user to run that instead.
+- When no ticket is at `**Impl:** doing`, the working tree is clean (`git status --porcelain` prints nothing). An uncommitted change belongs to nobody once implementers start committing; ask the user to commit or discard it first. With one ticket at `doing`, uncommitted changes are that ticket's breakpoint and are left for the resumed implementer (see "Resuming").
+- The platform can dispatch sub-agents. On one that cannot, tell the user to run `/atw-implement` once per ticket.
+- Either `tickets.py frontier` is non-empty, or exactly one ticket is at `**Impl:** doing` (see "Resuming"). Two or more at `doing` while the task's `meta.ticket_mode` is not `parallel` is a contradiction: stop and let the user sort it out; do not guess. Two or more at `doing` with `ticket_mode` set to `parallel` belong to a `/atw-implement-spec` run: stop and tell the user to finish or resume that run instead.
+
+## Arguments
+
+The only argument is an optional `--max N`: close N tickets in this run, then stop cleanly and report. Nothing else is accepted — not a ticket number, not `--only`, not `--skip`. If the user passes any of those, say so and stop; the ticket to work next is always chosen by the rule below.
+
+## Your role
+
+You are the only writer of ticket state. No sub-agent edits a ticket file, `check.jsonl`, `task.json`, or anything else the tracker owns.
+
+You write no code, you do not edit ticket content, and you do not do the implementation in the implementer's place. The whole of your job is: pick, claim, dispatch, relay questions, review, triage, write back, close, commit state, report.
+
+The `- [ ]` checkboxes in the tickets and in `prd.md` are not yours either, and not the implementer's: they are ticked during the acceptance check (workflow.md 3.1), one at a time against the evidence. `tickets.py done` flips `**Impl:**` and nothing else; leave the boxes as they are.
+
+Communication to and from the implementer is sparse. Communicate through **context pointers** — to the spec, the one ticket, the research notes — and never paste their contents into the prompt.
+
+## The loop
+
+For each ticket:
+
+1. **Pick.** Run `python3 .atw/scripts/tickets.py frontier`. Take the lowest-numbered ticket whose `**Status:**` line is not `ready-for-human`. If the frontier holds only `ready-for-human` tickets, stop (see "When the run halts"). Read the ticket file before dispatching: if it is plainly human work the ticket forgot to label — an external account, a manual test pass, a design decision — stop the same way rather than dispatching it.
+
+2. **Claim.** `python3 .atw/scripts/tickets.py claim <NN>` — the plain serial claim, never `--parallel`. This writes the current-ticket line into `check.jsonl` and records `implementation_base_sha` on the task; the review step depends on both.
+
+3. **Dispatch** one general-purpose implementer sub-agent in the foreground, with the brief below. Not the `atw-implement-agent` role, which may not commit.
+
+4. **Handle the report.**
+   - It asks a question: ask the user, with your recommendation, then send the answer back to the same sub-agent and let it continue. On a platform that cannot continue a sub-agent, dispatch a fresh implementer with the answer added to the pointers.
+   - It reports the ticket cannot be finished as written: the whole run stops (see "When the run halts").
+   - It reports done with a commit: go on.
+
+5. **Review.** Call the Skill tool with "atw-code-review", with the task's `implementation_base_sha` (`task.json` → `meta`) as the fixed point; when the implementer captured screenshots, pass their paths so the review runs its Visual axis. Relay every review report to the user as written — Standards and Spec, plus Visual when the ticket changed UI — even when the verdict is "nothing found". No report reaching you is not a passing review: re-run it.
+
+6. **Triage** the findings by the table in workflow.md: spec-axis findings and standards-axis hard violations get fixed; judgement calls ship and are reported. Send the findings to fix back to the same implementer for one fix round that ends in a commit. Then re-check **only the findings that were fixed**, once. Do not start a second full review, and do not loop. Anything still open after that one re-check goes to the user — ship it, fix again, or change the spec — before you write the spec back.
+
+7. **Write back and close.** Call the Skill tool with "atw-update-spec", then `python3 .atw/scripts/tickets.py done <NN>`, then commit the spec and ticket-state changes together. Every ticket leaves two kinds of commit on the branch: the implementer's code commit(s) and your state commit.
+
+8. **Next.** If `--max N` was given and N tickets have been closed in this run, stop and report. Otherwise go back to step 1. When the frontier is empty and `tickets.py summary` shows every ticket `done`: `python3 .atw/scripts/task.py set-status <task-dir> accept`, then commit the `task.json` change as the run's last state commit, so the run ends on a clean tree. Then report; the task stage in the report is `accept`.
+
+## Implementer brief
+
+Every dispatch prompt starts with `Active task: <task path from task.py current>`, then states the role, then gives pointers and rules — nothing more:
+
+- "You are an implementer sub-agent dispatched by `/atw-implement-all`. Stop ③ is already satisfied. Do the work yourself: do not dispatch sub-agents, and do not run a code review — the orchestrator reviews this ticket when you report."
+- pointers to `prd.md`, this one ticket, `research/`, and the coding-standards files the review will hold the work to (the `check.jsonl` entries);
+- work in place on the current branch — no worktree, no new branch;
+- call the Skill tool with "atw-tdd" to build the ticket; build any part that changes what a user sees by calling the Skill tool with "atw-ui", and capture a screenshot into the task directory's `screenshots/` for each UI acceptance criterion (screen, state, viewport in the file name);
+- run typechecking and single test files regularly, and the full suite once at the end;
+- commit to the current branch yourself; do not hand a diff back;
+- do not edit any ticket file or tracker state;
+- make routine judgement calls yourself; stop and ask only when the ambiguity would change the result;
+- if the ticket cannot be finished as written — the spec is wrong or self-contradictory, the fix needs a decision nobody has made, or it reaches outside this ticket's slice — stop and report why; do not widen the scope;
+- report in under 200 words: what changed, test results, commit SHAs, screenshot paths if any, open questions.
+
+A fix-round dispatch is the same brief plus the findings to fix, and ends in a commit the same way.
+
+## Resuming
+
+Stopping is always safe: every halt leaves the spec written back and the ticket state committed for every closed ticket, and the user resumes by running the same command again.
+
+When the run starts with exactly one ticket at `**Impl:** doing`, that ticket is the breakpoint. Do not claim it again. Dispatch an implementer with the brief above plus the instruction to finish the ticket from the current git state and commit — untouched, it is implemented from scratch; changed but uncommitted, the work is finished and committed; already committed, there is nothing to do — then continue from step 4: the resumed implementer's report is handled like any other, and the review follows. The review's fixed point is the `implementation_base_sha` recorded at claim time, whichever way the earlier run broke off.
+
+## When the run halts
+
+The run comes back to the user in four situations, plus the `--max` count:
+
+1. An implementer hits an ambiguity that would change the result → ask, with a recommendation, and continue after the answer.
+2. A finding is still open after the one re-check → ask before writing the spec back, and continue after the answer.
+3. An implementer reports its ticket cannot be finished as written → the run stops. Do not paper over it, do not rewrite the ticket to fit, do not widen the scope.
+4. The frontier holds only `ready-for-human` tickets, or the next ticket is plainly human work → the run stops. Name the tickets that need the user, and say that the run continues once they are done with `/atw-implement`. Say also what the next run does: it starts from whatever state `/atw-implement` left — one ticket at `doing` (the per-ticket path may already have claimed the next frontier ticket) is resumed, not re-claimed (see "Resuming"); nothing at `doing` means the run claims from the frontier. Both ways in, the ticket is closed the same way: review, write-back, `done`, state commit.
+5. `--max N` is reached → the run stops.
+
+Every time the run halts — for a question in situations 1 and 2 as much as for a stop — and when it finishes, report one table with a row per ticket: number and title; state (`done`, `doing`, untouched); commit SHAs; review verdict per axis; what the user was asked. End with the task stage after the halt and the command that picks the run back up.

package/dist/templates/common/bundled-skills/atw-implement-all/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "ATW Implement All"
+  short_description: "一次性串行实现整份规格，逐票审查"
+policy:
+  allow_implicit_invocation: false

package/dist/templates/common/bundled-skills/atw-init-repo/references/issue-tracker-atw-local.md

@@ -36,7 +36,7 @@ On top of the standard ticket template, tickets here carry one extra line:
 
 | Field | Vocabulary | Who writes it |
 |---|---|---|
-| `Status:` | triage roles (see `triage-labels.md`) | Fixed at `ready-for-agent`. These tickets are ones you sliced yourself, so they never need triage — the field is a placeholder kept for vocabulary compatibility. |
+| `Status:` | triage roles (see `triage-labels.md`) | The slicer, when it writes the ticket. Default `ready-for-agent`: these tickets are ones you sliced yourself, so they never go through triage. Set `ready-for-human` on a ticket a person must do — it needs an external account, a manual test pass, or a design or legal decision. `/atw-implement-all` never dispatches such a ticket and stops when the frontier holds only those; `/atw-implement` confirms with the user before touching code — they do it themselves, or explicitly authorize the AI. `tickets.py` does not read this field; the frontier ignores it. |
 | `Impl:` | `ready` / `doing` / `done` | `tickets.py`. This is the field the workflow actually routes on, and the only field the parser requires. |
 
 The ticket template `tickets.py` writes also carries an empty `**Issue:**` line. It is meaningless in this variant — nothing fills it in — and `tickets.py` never reads it. Leave it or delete it; neither breaks anything.
@@ -75,6 +75,8 @@ python3 .atw/scripts/tickets.py claim <NN> --parallel  # → Impl: doing, alongs
 
 **The one parallel path is `/atw-implement-spec`.** Its orchestrator claims with `--parallel`, which lets several tickets sit at `Impl: doing`, records `implementation_base_sha` once for the whole run, and writes no current-ticket line into `$TASK/check.jsonl` — there is no single live ticket. Only the orchestrator writes ticket state; each implementer works in its own worktree.
 
+`/atw-implement-all` is not a second parallel path: its orchestrator claims with plain `claim <NN>`, one ticket at `Impl: doing` at a time, so the current-ticket line and `implementation_base_sha` are recorded per ticket exactly as on the per-ticket path. It too is the only writer of ticket state; its implementers work in place on the current branch.
+
 ## Wayfinding operations
 
 Used by `atw-map`. A map is a **discover-phase** artifact and lives in the task directory alongside everything else.

package/dist/templates/common/bundled-skills/atw-init-repo/references/issue-tracker-atw.md

@@ -44,7 +44,7 @@ On top of the standard ticket template, tickets here carry two extra lines:
 
 | Field | Vocabulary | Who writes it |
 |---|---|---|
-| `Status:` | triage roles (see `triage-labels.md`) | Fixed at `ready-for-agent`. These tickets are ones you sliced yourself, so they never need triage — the field is a placeholder kept for vocabulary compatibility. |
+| `Status:` | triage roles (see `triage-labels.md`) | The slicer, when it writes the ticket. Default `ready-for-agent`: these tickets are ones you sliced yourself, so they never go through triage. Set `ready-for-human` on a ticket a person must do — it needs an external account, a manual test pass, or a design or legal decision. `/atw-implement-all` never dispatches such a ticket and stops when the frontier holds only those; `/atw-implement` confirms with the user before touching code — they do it themselves, or explicitly authorize the AI. `tickets.py` does not read this field; the frontier ignores it. |
 | `Impl:` | `ready` / `doing` / `done` | `tickets.py`. This is the field the workflow actually routes on, and the only field the parser requires. |
 | `Issue:` | `#58`, or empty | Filled in by `github_sync.py sync-tickets`; it is also the only ticket ↔ remote-issue mapping, so there is no separate mapping table. |
 
@@ -83,6 +83,8 @@ python3 .atw/scripts/tickets.py claim <NN> --parallel  # → Impl: doing, alongs
 
 **The one parallel path is `/atw-implement-spec`.** Its orchestrator claims with `--parallel`, which lets several tickets sit at `Impl: doing`, records `implementation_base_sha` once for the whole run, and writes no current-ticket line into `$TASK/check.jsonl` — there is no single live ticket. Only the orchestrator writes ticket state; each implementer works in its own worktree.
 
+`/atw-implement-all` is not a second parallel path: its orchestrator claims with plain `claim <NN>`, one ticket at `Impl: doing` at a time, so the current-ticket line and `implementation_base_sha` are recorded per ticket exactly as on the per-ticket path. It too is the only writer of ticket state; its implementers work in place on the current branch.
+
 ## Wayfinding operations
 
 Used by `atw-map`. A map is a **discover-phase** artifact and lives in the task directory alongside everything else.

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

@@ -91,7 +91,7 @@ Noob mode changes how you talk to the user. It changes nothing about what the wo
 
 - **Stages.** The first time a stage comes up, say in a few words what it is for — discover is "getting clear on what you want", specify is "writing it down so we both agree", slice is "cutting the work into small pieces", implement is "building it", accept is "checking it against what we agreed".
 - **Stops ①–④.** These are the user's decisions. Say what is being decided, what each answer leads to, and what you recommend. Never present a stop as a formality.
-- **Skills only the user can run.** When the next step is theirs to start (`/atw-spec`, `/atw-tickets`, `/atw-implement`, `/atw-implement-spec`, `/atw-askme`, `/atw-map`), say what typing it will do and why it is their call, then give the exact text to type.
+- **Skills only the user can run.** When the next step is theirs to start (`/atw-spec`, `/atw-tickets`, `/atw-implement`, `/atw-implement-spec`, `/atw-implement-all`, `/atw-askme`, `/atw-map`), say what typing it will do and why it is their call, then give the exact text to type.
 - **Asking them to confirm a file.** Do not hand over `prd.md` or a ticket list and ask "confirm?". Summarize in plain words what it commits to — what will be built, what will not, what counts as done — then point to the file.
 - **Other skills' output.** A skill with its own format keeps it. In a file (review findings, ticket tables, a spec) the content stays as that skill wants it, and what you say about it to the user follows these rules. In the reply itself (a numbered round of questions, a list of findings) the shape stays and every word inside it follows these rules — a question the user cannot read is a decision they cannot make. No skill's format outranks noob mode.
 

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

@@ -1,6 +1,6 @@
 ---
 name: atw-prototype
-description: "构建一次性原型来解答设计问题。用于验证状态模型或业务逻辑是否合理、探索界面应该长什么样（多个风格方向并排对比后由用户选定），或把选定方向做成能完整点一遍、带业务逻辑的可交互原型。原型只用于做决定，不是正式实现；按选定方向做正式界面、精修和评审交给 atw-ui。"
+description: "构建一次性原型来解答设计问题。用于验证状态模型或业务逻辑是否合理、探索界面应该长什么样（先用文字比较几个风格方向，要看画面时再做成首屏并排对比，由用户选定），或把选定方向做成能完整点一遍、带业务逻辑的可交互原型。原型只用于做决定，不是正式实现；按选定方向做正式界面、精修和评审交给 atw-ui。"
 ---
 
 # Prototype
@@ -12,7 +12,7 @@ description: "构建一次性原型来解答设计问题。用于验证状态模
 先从用户的请求、相关代码判断要回答的是哪个问题；用户在场时可以直接问：
 
 - **“这套逻辑 / 状态模型对不对？”** → [LOGIC.md](LOGIC.md)。做一个可分享的单文件 HTML：自由操作的按钮加按标签页划分的引导演练，把纸面上难以推演的状态组合跑一遍，让不写代码的人也能自己操作。
-- **“这个界面应该长什么样？”** 或 **“这个页面用起来对不对？”** → [UI.md](UI.md)。分两段：先做几个风格明显不同的方向放进对比页，由用户选定；需要时再把选定方向深化成带业务逻辑的可交互原型，业务逻辑按 LOGIC.md 的方式写成独立的纯模块。
+- **“这个界面应该长什么样？”** 或 **“这个页面用起来对不对？”** → [UI.md](UI.md)。分两段：先认品类、拆标杆，用文字写出三个风格明显不同的方向请用户选，用户要看画面时再把三个首屏放进对比页；需要时再把选定方向深化成带业务逻辑的可交互原型，业务逻辑按 LOGIC.md 的方式写成独立的纯模块。
 
 两个分支的产物差别很大，选错等于白做。问题确实模糊且用户不在时，按周边代码选：后端模块走逻辑，页面或组件走界面；并在原型顶部写明这个假设。
 

package/dist/templates/common/bundled-skills/atw-prototype/UI.md

@@ -2,7 +2,7 @@
 
 界面原型分两段：
 
-- **第一段：选方向。** 做几个风格和结构都明显不同的方向，放进同一个对比页，由用户挑选，再说出具体喜欢和不喜欢哪里。
+- **第一段：选方向。** 先认品类、拆标杆，用文字写出三个风格和结构都明显不同的方向请用户选；用户想看实际画面时，再把三个方向各做成一张首屏放进同一个对比页挑，并说出具体喜欢和不喜欢哪里。
 - **第二段：深化成可交互原型。** 只在问题包含“用起来对不对”时才做：把选定方向做成完整页面，接上按 [LOGIC.md](LOGIC.md) 写的纯逻辑模块，让人能把真实业务流程完整点一遍。
 
 两段的产物都是用来做决定的，不是正式代码。选定之后的正式界面由 atw-ui 按设计说明重新实现。
@@ -19,6 +19,8 @@
 
 ## 承载方式：优先挂在已有页面上
 
+要做出画面时才选承载方式：第一段的三个首屏，或第二段的完整页面。用户从文字里就选定了方向、又不做第二段时，不建任何页面。
+
 界面原型**贴着应用的其他部分**才好判断：真实的顶栏、侧栏、数据和密度。一个孤零零的新页面是真空，每个方案单独看都还行。所以只要有合理的宿主页面，就优先方式 A。
 
 ### 方式 A：在已有页面上调整（优先）
@@ -37,49 +39,66 @@
 
 ## 第一段：选方向
 
-### 1. 写下问题，定方案数量
+### 1. 写下问题，定方向数量
 
-默认 **3 个方向**。超过 5 个就不再是“明显不同”而是噪音，上限 5。窄小的任务不强求多方案。
+默认写 **3 个方向**。用户要更多时照做，但超过 5 个就不再是“明显不同”而是噪音，上限 5。窄小的任务不强求多方案；任务明确只要一个方向时只写一个，见第 6 步。
 
-把计划写成一句话，放在原型所在位置或文件顶部注释里：
+把计划写成一句话；做出画面时放在原型所在位置或文件顶部注释里：
 
-> “设置页的三个方向，用 `?variant=` 在现有 `/settings` 路由上切换，并汇总到对比页。”
+> “设置页的三个方向，先用文字问；要看画面时用 `?variant=` 在现有 `/settings` 路由上切换，并汇总到对比页。”
 
 用户在不在场都适用。
 
-### 2. 定调性，写方向卡，做差异检验
+### 2. 认品类，拆标杆，写方向卡
+
+方向未定时按 [设计方向](references/design-direction.md) 的顺序做：先认品类、拆标杆，标杆的真实画面存进 ATW 任务目录的 `references/`（没有任务时放在原型旁边），不写进技能安装目录；再从产品题材、受众和使用场合推出调性；每个方向从一个具体的生成引擎出发，色彩按“定色彩”的四步从产品推出；写文案之前先定首屏骨架，说服型页面按 [说服型页面首屏骨架](references/direction-persuasion.md) 选，内容和工作区页面的首屏就是第一排内容；为每个方向填方向卡，最后逐条做差异检验。
+
+这一轮几个方向共用调性和标杆与取舍，每个方向只填北极星、生成引擎、首屏骨架、字体、色彩、主视觉、图标和控件语法；其余各栏在方向选定后补齐，见第 7 步。
 
-方向未定时按 [设计方向](references/design-direction.md) 的顺序做：先从产品题材、受众和使用场合推出调性；每个方向从一个具体的生成引擎出发；写文案之前先定首屏骨架；为每个方向填方向卡，写下它的记忆点；最后逐条做差异检验。
+方向**必须在结构上不同**：布局、信息层级、主要操作方式都不一样，不只是换颜色。三个微调过的卡片网格不是界面原型，是墙纸。两个方向太像时，回到骨架重选其中一个，不靠换装饰补救。
 
-方向**必须在结构上不同**：布局、信息层级、主要操作方式都不一样，不只是换颜色。三个微调过的卡片网格不是界面原型，是墙纸。两个方向做出来太像时，回到骨架表重选其中一个，不靠换装饰补救。
+方向由用户的品味来定，不直接采用模型自己想出的方向。任务目录里已有 `ui-direction.md`，或用户明确指定了一个完整的方向时，跳过第一段，直接进入第二段或交给 atw-ui。用户只给了参考图、品牌规范或说了想要的风格，不算给定方向：仍写三个方向、走第 3 步，三个方向怎样写见第 6 步。
 
-方向由用户的品味来定，不直接采用模型自己想出的方向。用户已经给定方向时跳过这一步，直接进入第二段或交给 atw-ui。
+### 3. 先用文字问一次
 
-### 3. 做小样
+方向卡写完，不急着做页面。把每个方向用三四行写给用户：它给人什么感觉，首屏长什么样，用什么字体和色彩，主视觉靠什么。附上你推荐哪一个和理由，然后问：按其中一个定下来，还是把三个都做成首屏放在一起比。发给用户后这一轮结束。
 
-每个方向只做首屏和最能体现方向的一两个区块；用户明确要完整页面时照做。挑能暴露方向优缺点的内容：含复杂表单的产品不能只做封面。
+- 用户选了一个，或者从描述里已经说清想要什么：方向就定了，定下的就是这一个方向。第一段不做首屏，也不做对比页：按 [设计方向](references/design-direction.md) 的“差异检验”把它和拆过的标杆并排比一次，确认不撞脸，然后到第 7 步补齐方向卡、写设计说明。完整页面在第二段或 atw-ui 里做。
+- 用户想看实际画面：按第 4 步把三个都做成首屏。
+- 之后凡是要做出几个候选让用户挑，都先这样用文字问一次：用户从文字里定得下来，就定选中的那一个，不把几个候选都做成画面。
 
-每个方向要守住：
+### 4. 用户要看实际画面时，做三个首屏
 
-- 页面的用途和它能拿到的数据；所有方向共享同样的核心内容和主要操作。
-- 方式 A 用项目已有的组件库和样式体系（TailwindCSS、shadcn、MUI、纯 CSS 等）；方式 B 的独立小样不受此限，但图标只内联用到的 SVG，不引用外部资源。
-- 方式 A 中每个方向导出清楚的组件名，例如 `VariantA`、`VariantB`、`VariantC`。
+每个方向都是一张真实的首屏，骨架、字体、色彩和主视觉都拉开。只做看得出风格所需的东西：
 
-示例内容按真实产品的样子写，避免整数指标和“标题”“描述”这类占位字；画面上不出现“示例”“示意图”“按钮未接入”这类制作说明，这些写进交付说明。视觉层级、字体、色彩和留白的判断见 [视觉语言](references/visual-language.md)。
+- 每个方向一个文件（方式 A 是一个方向组件，导出清楚的组件名，例如 `VariantA`、`VariantB`、`VariantC`；方式 B 是一个 HTML）、一个视口、只有主状态；不写交互，不做响应式和动效，不取证，不派评审。
+- 几个方向共用同一份示例文字和数据，只写一次；页面的用途、核心内容和主要操作也相同。结构和样式各写各的：不用同一个模板换几组样式来生成，那样几个方向的骨架天生是同一个。
+- 方式 A 用项目已有的组件库和样式体系（TailwindCSS、shadcn、MUI、纯 CSS 等）；方式 B 的独立首屏不受此限，但图标只内联用到的 SVG，不引用外部资源。
+- 主视觉靠图的方向，生成一张，至多重新生成一次；其余图位先用从页面取色的色块占着。
+- 每个方向用宿主的浏览器工具截一张图自己看过，改掉重叠、裁切和明显的粗糙就交。
 
-### 4. 生成对比页
+首屏选能暴露方向优缺点的那一页：含复杂表单的产品不能只做封面。示例内容按真实产品的样子写，避免整数指标和“标题”“描述”这类占位字；画面上不出现“示例”“示意图”“按钮未接入”这类制作说明，这些写进交付说明。视觉层级、字体、色彩和留白的判断见 [视觉语言](../atw-ui/references/visual-language.md)。
 
 按 [风格对比页](references/style-explorer.md) 准备 `manifest.json`，把方向卡里的北极星、字体、色板和特征写进去，用内置生成器组装成一个离线 HTML。不要每次自己重做对比工具。对比页和 manifest 放在 ATW 任务目录（没有任务时放在原型旁边），不写进技能安装目录。
 
-### 5. 交给用户选
+### 5. 交对比页，版式也先用文字问
+
+把对比页交给用户，这一轮到此结束：附上推荐理由，请用户选一个方向、说出具体喜欢和不喜欢哪里，并说明想比较不同的版式也可以说。用户只说“再高级一点”这类模糊词时，用设计方向里的翻译表追问，或拿两张首屏让用户比较。三个首屏和版式变体不派评审；用户明确要求时，才按 atw-ui 的 [视觉评审派发协议](../atw-ui/references/visual-review.md) 评一轮。协议里说的“本 Skill 目录”是 atw-ui 的目录：给评审者的是 [评审手册](../atw-ui/references/reviewer-manual.md) 的绝对路径。首屏没跑截图工具，没有 `report.json`，不交默认做法提示，交接里写明未跑截图工具。
+
+用户要比版式，先用文字写出两三种骨架的差别；从文字里定得下来就按选中的定，要看实际画面再做成首屏，连同选中的那一版放进对比页再选一次。版式之间保持选定方向的字体、色彩和控件语法，只在骨架、主视觉的摆法和页面结构上拉开。用户只回了选哪个，就把意见并进去，到第 7 步；想把两个方向拼在一起的，先做出拼合后的首屏给用户确认。
+
+### 6. 哪些情况不这样走
 
-给出简短的方向清单和对比页，附推荐理由，请用户选定，并说出具体喜欢和不喜欢哪里。用户只说“再高级一点”这类模糊词时，用设计方向里的翻译表追问，或拿两张小样让用户比较。
+- 只要设计说明时不做页面，用文字写下方向的决定。
+- 用户已经给了参考图、品牌规范或说清了风格，风格就定了：三个方向都留在这个风格里，只在骨架、主视觉和页面结构上拉开。
+- 用户说了“你定”“直接做”，或者无人值守时，不问：三个首屏仍做出来放进对比页留档，把三张截图缩到 480px 宽并排看一次，自己选定并写明理由，接着到第 7 步。
+- 任务明确只要一个方向时不问也不做对比页，直接写方向卡，再按 [设计方向](references/design-direction.md) 的“差异检验”把它和拆过的标杆并排比一次，确认不撞脸。
 
-交付对比页时，把一轮独立评审作为**推荐的下一步**告诉用户：说明它能改善什么（打破几个方向共用的模板骨架）、大约需要多少时间和调用，由用户决定是否执行，不默认派发。用户同意时按 [视觉评审协议](references/visual-review.md) 给每个方向各评审、修改一轮；用户直接选定方向时跳过。
+### 7. 写设计说明
 
-用户明确让你自行决定、或当前无法交互时，仍然先做小样、生成对比页留档，再按任务适配、辨识度和可执行性选定，并说明理由。
+方向选定后先把方向卡补齐：第 2 步没填的页面结构、各区块的形式、动效、结构性突破、记忆点和放弃什么都填上，“标杆与取舍”里写明标杆画面的存放路径。
 
-选定后写一份简短的**设计说明**：用户任务、内容与主动作、选定方向（附方向卡）、用户的喜欢与不喜欢、视觉关系、关键状态、设备约束和验收重点。放在 ATW 任务目录的 `ui-direction.md`；已有说明直接更新。这份说明是第二段和 atw-ui 的依据。
+再写一份简短的**设计说明**：用户任务、内容与主动作、选定方向（附补齐后的方向卡，标杆与取舍、各区块的形式、控件语法和动效四栏都在）、用户的喜欢与不喜欢、视觉关系、关键状态、设备约束和验收重点。放在 ATW 任务目录的 `ui-direction.md`；已有说明直接更新。这份说明是第二段和 atw-ui 的依据。
 
 ## 第二段：深化成可交互原型
 
@@ -91,7 +110,7 @@
 
 ### 2. 选定方向做成完整页面
 
-把选定方向从小样扩展成完整页面，作为逻辑模块外面的一层外壳：页面只调用模块、渲染模块返回的状态。关键状态都要在界面上有样子——空、加载、成功、失败、被拒绝的非法操作——不只做漂亮的默认状态。
+把选定方向做成完整页面（做过首屏的从首屏扩展），作为逻辑模块外面的一层外壳：页面只调用模块、渲染模块返回的状态。关键状态都要在界面上有样子——空、加载、成功、失败、被拒绝的非法操作——不只做漂亮的默认状态。
 
 方向卡里的记忆点（某个动作的反馈、完成的那一刻）在这里做出来；动效遵循方向的调性。修改数据的动作一律经过逻辑模块，接口用桩代替，不接真实后端。
 
@@ -149,7 +168,7 @@ return (
 
 ## 交给用户
 
-给出对比页路径、页面地址和 `?variant=` 的取值；第二段还要说明状态抽屉怎么打开、有哪些演练场景。用户有空时会翻看。最有价值的反馈常常是 **“我要 B 的顶栏配 C 的侧栏”**——那才是他们真正想要的设计。
+做了画面时，给出对比页路径、页面地址和 `?variant=` 的取值；第二段还要说明状态抽屉怎么打开、有哪些演练场景。用户有空时会翻看。最有价值的反馈常常是 **“我要 B 的顶栏配 C 的侧栏”**——那才是他们真正想要的设计。
 
 交付说明里写清：哪些是模拟数据、生成图片、未接入的动作；实际查看过哪些视口；哪一步没做以及原因。
 
@@ -165,6 +184,7 @@ return (
 
 ## 反模式
 
+- **不问就做三个首屏。** 用户在场时先用文字问一次；从文字里定得下来，就不做首屏和对比页。
 - **方向之间只差颜色或文案。** 那是微调，不是原型。真正的方向在结构上互不相同。
 - **按明暗分方向。** “一个亮、一个暗、一个暖”是最常见的失败；每个方向要有自己的色彩身份。
 - **默认左右分栏。** 一轮里最多一个方向用左右分栏，并写出为什么非它不可。