@chinhae/atw-cli 0.3.1 → 0.3.2

package/dist/migrations/manifests/0.3.2.json

@@ -0,0 +1,9 @@
+{
+  "version": "0.3.2",
+  "description": "The per-ticket implement chain now fixes review findings once and re-checks only what was fixed, instead of re-running the full review without a bound.",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "atw-implement and workflow.md: after the review, findings that must be fixed (spec-axis findings and standards hard violations) are fixed in one round, then only what was fixed is re-checked, once, then the commit. The earlier wording was 'fix, then re-run the full review, then commit' with no limit: a full review of freshly fixed code keeps finding something new, so a single ticket could go round several times and take very long. Anything still open after the one re-check now goes to the user before the commit, who decides whether it ships, gets another fix, or changes the spec. This is the same rule the whole-spec run (/atw-implement-spec) already had. Judgement calls still ship and get reported, and the test suite is still the hard gate.",
+  "migrations": [],
+  "notes": "No migration required and no files added, deleted or renamed. Two templates changed: .atw/workflow.md (the implement breadcrumb, the findings table and the paragraph under it) and the atw-implement skill. They update as Template updated where the project left them untouched; where a project edited them locally, atw update asks before replacing — keep the edit and the old unbounded re-review wording stays in force for that project."
+}

package/dist/templates/atw/workflow.md

@@ -342,7 +342,7 @@ Stop ③: implementation is the user's to start. You may not invoke either skill
 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.
 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 first, then a full re-review, then the commit. Judgement calls ship and get reported.
+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.
@@ -670,10 +670,12 @@ That single run is a closed chain:
 
 | Finding | Handling |
 |---|---|
-| Spec-axis finding (the change does not match `prd.md` or the ticket) | Fix first, then re-run the full review, then commit |
-| Standards-axis finding marked a hard violation | Same — fix, full re-review, then commit |
+| Spec-axis finding (the change does not match `prd.md` or the ticket) | Fix once, re-check only what was fixed, then commit |
+| Standards-axis finding marked a hard violation | Same — fix once, re-check the fix, then commit |
 | Standards-axis judgement call | Commit as-is and report it to the user |
 
+One fix round and one re-check, each once. Do not start a second full review and do not loop: a full review of freshly fixed code always finds something new, so a ticket that chases a clean report never lands. Whatever is still open after the re-check goes to the user before the commit — they decide whether it ships, gets another fix, or changes the spec.
+
 The hard gate on this work is the test suite, not the review. Reviews report; tests block.
 
 Spec updates belong in the same chain, before the commit — knowledge that lands in a follow-up commit usually does not land at all.

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

@@ -16,7 +16,7 @@ If the work changes what a user sees, build that part by calling the Skill tool
 
 Once done, call the Skill tool with "atw-code-review" to review the work. When screenshots were captured, pass their paths so the review runs its Visual axis.
 
-Work the findings before committing. Fix what the review raised, then re-run the tests it touched.
+Work the findings before committing. Fix what the review raised, then re-run the tests it touched. 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.
 
 **If the review surfaces a hard problem, stop** — the spec is wrong or self-contradictory, the fix needs a decision nobody has made, or it reaches outside this ticket's slice. Don't paper over it and don't silently widen the scope to absorb it. Say what the finding is and what it blocks, and get the decision from the user before writing more code. If the answer changes what the work is supposed to do, that change lands in the spec via the step below, not only in the code.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chinhae/atw-cli",
-  "version": "0.3.1",
+  "version": "0.3.2",
   "description": "A Team Workflow — an AI coding workflow framework that encodes your team's conventions into the process",
   "type": "module",
   "main": "./dist/index.js",
@@ -33,7 +33,7 @@
     "inquirer": "^9.3.7",
     "undici": "^6.21.0",
     "zod": "^4.4.2",
-    "@chinhae/atw-core": "0.3.1"
+    "@chinhae/atw-core": "0.3.2"
   },
   "devDependencies": {
     "@eslint/js": "^9.18.0",