@seanmars/tospec 0.12.0 → 0.14.0

package/dist/core/templates/fragments/verify.js

@@ -1,18 +1,21 @@
 /**
- * Verify methodology — apply's automatic final step.
+ * Verify methodology — apply's opt-in review.
  *
- * verify is not a standalone skill/command; it runs at the end of both apply
- * variants. The methodology is long enough that leaving it inline puts ~45
- * lines of end-of-run review in front of an agent that is still on task 1 of N,
- * so the skill form discloses it to a sibling `VERIFY.md` and keeps only a
- * pointer. The command form has no sibling file, so it inlines the same text.
- * Either way this module is the single source of truth.
+ * verify is not a standalone skill/command; it lives inside both apply variants
+ * and runs only when the user asks for it. The methodology is long enough that
+ * leaving it inline puts ~45 lines of end-of-run review in front of an agent
+ * that is still on task 1 of N, so the skill form discloses it to a sibling
+ * `VERIFY.md` and keeps only a pointer. The command form has no sibling file,
+ * so it inlines the same text. Either way this module is the single source of
+ * truth.
  */
 /** The review protocol itself — shared by the disclosed file and the command. */
 export const VERIFY_METHODOLOGY = `Two-axis review of the implementation, run as **independent parallel subagents** so neither pollutes or reranks the other's findings — a change can pass one axis and fail the other, and reporting them separately is what keeps that visible.
 
 **Scope — two subagents, one pass each, and that is the whole review.** The subject under review is always the *code diff*, never another review's output. Do not spawn a third agent to grade the two axes' findings, do not re-review a report you have already written, do not audit the audit. Right-sized review beats deep review: enough eyes to catch real problems, no recursion for its own sake.
 
+**What counts as blocking.** Exactly two kinds of finding block: a **hard violation** of a convention this repo documents, and a **spec-correctness** problem — a requirement missing, implemented wrongly, or contradicting a decision \`design.md\` records. Everything else — judgement calls, style preferences, and every code smell named below — is **report-only**: report it, do not fix it, and do not re-review because of it. A report-only finding is the user's call to make later, not this run's work. Leave this unstated and the safe reading is to fix everything, which makes "re-run only the affected axis" fire on every axis, every time.
+
 **Steps**
 
 1. **Gather context**
@@ -43,28 +46,32 @@ export const VERIFY_METHODOLOGY = `Two-axis review of the implementation, run as
 
 **Verify output**
 
-Report the two-axis result plus test suite status. If both axes are clean and tests are green, the change is verified — tell the user it's ready for \`tospec-archive\`. If either axis has a blocking finding or tests are red, do **not** treat apply as done: fix the issue here (this is still apply) and re-run **only the affected axis against the fixed code** until it's clean — you are re-reviewing the changed code, not the previous report, and a passing axis is done, so don't re-run it "to be sure".
+Report the two-axis result plus test suite status. If both axes are clean and tests are green, the change is verified — tell the user it's ready for \`tospec-archive\`. If either axis has a blocking finding or tests are red, do **not** treat apply as done: fix the issue here (this is still apply), then send **only the hunk that fixed it** back to the axis that reported it — never the whole axis, and never the other one. You are reviewing the changed code, not the previous report. A clean axis is not re-run for extra confidence.
 
 **Verify guardrails**
 - Standards and Spec axes are independent — never let one axis's findings influence the other's report
 - Full test suite must be green; a clean review with red tests is not verified
 - Quote the specific spec/task line or hunk for every finding — no unsupported claims
-- **One review pass per axis — never review the review.** No agent audits another agent's findings, no re-reviewing a report you already wrote; a re-run after a fix targets the changed code, and a clean axis is not re-run for extra confidence`;
+- **One review pass per axis — never review the review.** No agent audits another agent's findings, no re-reviewing a report you already wrote; a re-run after a fix sees only the hunk that fixed it, and a clean axis is not re-run for extra confidence`;
 /** Contents of the `VERIFY.md` shipped beside each apply skill's `SKILL.md`. */
-export const VERIFY_DOC = `# Verify — apply's final step
+export const VERIFY_DOC = `# Verify — apply's opt-in review
 
-Run this once every task in the tracks file is checked off and \`tospec validate\` passes. It is the last step of \`tospec-apply\`, not a separate command the user invokes.
+Run this **when the user asks for a review**, once every task in the tracks file is checked off and \`tospec validate\` passes. It is not a step apply reaches on its own.
 
 ${VERIFY_METHODOLOGY}
 `;
 /** The pointer that replaces the methodology inside the apply skills. */
-export const VERIFY_POINTER = `## Verify (automatic — apply's final step)
+export const VERIFY_POINTER = `## Verify (opt-in — only when the user asks)
+
+The two-axis review does **not** run on its own. Apply finishes on the full test suite and \`tospec validate\`; a change with those green is implemented, review or no review.
 
-Once every task is checked off and \`tospec validate\` passes, **read \`VERIFY.md\` in this skill's directory and run it in full.** It is apply's last step, not a separate command the user has to invoke. The change stays unfinished — and must not go to \`tospec-archive\` — until that review comes back clean and the full test suite is green.`;
+When the user asks for a review, **read \`VERIFY.md\` in this skill's directory and run it in full.** Don't offer it unprompted either — no "shall I review this?" at the end of a run. If a review does run, the change stays unfinished — and must not go to \`tospec-archive\` — until it comes back clean.`;
 /** The same block for the command form, which has no sibling file to point at. */
-export const VERIFY_INLINE = `## Verify (automatic — apply's final step)
+export const VERIFY_INLINE = `## Verify (opt-in — only when the user asks)
+
+The two-axis review does **not** run on its own. Apply finishes on the full test suite and \`tospec validate\`; a change with those green is implemented, review or no review.
 
-Once every task is checked off and \`tospec validate\` passes, run the two-axis review **automatically**. This is not a separate command the user has to invoke — verify is folded into apply and runs here as its last step, before the change is handed to \`tospec-archive\`.
+When the user asks for a review, run the methodology below in full. Don't offer it unprompted either — no "shall I review this?" at the end of a run. If a review does run, the change stays unfinished — and must not go to \`tospec-archive\` — until it comes back clean.
 
 ${VERIFY_METHODOLOGY}`;
 //# sourceMappingURL=verify.js.map

package/dist/core/templates/fragments/verify.js.map

@@ -1 +1 @@
-{"version":3,"file":"verify.js","sourceRoot":"","sources":["../../../../src/core/templates/fragments/verify.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,iFAAiF;AACjF,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mPAwCiN,CAAC;AAEpP,gFAAgF;AAChF,MAAM,CAAC,MAAM,UAAU,GAAG;;;;EAIxB,kBAAkB;CACnB,CAAC;AAEF,yEAAyE;AACzE,MAAM,CAAC,MAAM,cAAc,GAAG;;uVAEyT,CAAC;AAExV,kFAAkF;AAClF,MAAM,CAAC,MAAM,aAAa,GAAG;;;;EAI3B,kBAAkB,EAAE,CAAC"}
+{"version":3,"file":"verify.js","sourceRoot":"","sources":["../../../../src/core/templates/fragments/verify.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AAEH,iFAAiF;AACjF,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;2PA0CyN,CAAC;AAE5P,gFAAgF;AAChF,MAAM,CAAC,MAAM,UAAU,GAAG;;;;EAIxB,kBAAkB;CACnB,CAAC;AAEF,yEAAyE;AACzE,MAAM,CAAC,MAAM,cAAc,GAAG;;;;+SAIiR,CAAC;AAEhT,kFAAkF;AAClF,MAAM,CAAC,MAAM,aAAa,GAAG;;;;;;EAM3B,kBAAkB,EAAE,CAAC"}

package/dist/core/templates/workflows/apply.d.ts

@@ -4,8 +4,8 @@
  * This file is generated by splitting the legacy monolithic
  * templates file into workflow-focused modules.
  *
- * Two apply variants share the same gating (`applyRequires`), auto-verify
- * step, and re-validate step; they differ only in how tests relate to the
+ * Two apply variants share the same gating (`applyRequires`), opt-in verify
+ * section, and re-validate step; they differ only in how tests relate to the
  * implementation:
  *   - `tospec-apply`          — default, tests optional (write one when it earns its keep)
  *   - `tospec-apply-with-tdd` — strict TDD, red → green per slice

package/dist/core/templates/workflows/apply.js

@@ -23,7 +23,7 @@ function buildApplyBody(v, verifySection) {
 
    Act on \`state\`:
    - \`blocked\` — required artifacts or the tracks file are missing; show \`instruction\` and STOP, sending the user back to \`tospec-propose\`/\`tospec-issue\`.
-   - \`all_done\` — everything is checked off already; skip to the verify step below.
+   - \`all_done\` — everything is checked off already; say so and stop. A change being complete is not by itself a reason to review it.
    - \`ready\` — proceed.
 
 3. **Read the context files**
@@ -58,7 +58,7 @@ ${verifySection}
 
 **Output**
 
-Report which tasks/checkboxes completed this pass, current progress (\`tospec status --change "<name>"\`), and whether all required artifacts are checked off. When everything is done, the verify review above has already run — if it came back clean, tell the user the change is ready for \`tospec-archive\`; if it surfaced blocking findings, keep working here to resolve them.
+Report which tasks/checkboxes completed this pass, current progress (\`tospec status --change "<name>"\`), and whether all required artifacts are checked off. When everything is done and the test suite is green, tell the user the change is ready for \`tospec-archive\`. If they asked for a review and it surfaced findings it defines as blocking, keep working here to resolve them.
 
 **Guardrails**
 ${v.guardrailsHead}
@@ -68,7 +68,7 @@ ${v.guardrailsHead}
 - Keep code changes minimal and scoped to the item at hand
 - Any test you do write goes at the pre-agreed seam (design.md for sdd; the existing/new seam identified for issue) — never against internals
 - Fix root cause: check every caller of a shared function before declaring a fix complete
-- Don't hand off to archive until the automatic verify step is clean and the full test suite is green`;
+- Don't hand off to archive until the full test suite is green — and, when a review was requested, until it comes back clean`;
 }
 // -----------------------------------------------------------------------------
 // Default apply — implement per slice; tests are optional, not mandated
@@ -80,7 +80,7 @@ const APPLY_VARIANT = {
 For each tracer-bullet slice in \`tasks.md\`:
 1. Implement the minimum that satisfies the behavior the slice's specs describe. Don't anticipate future slices or add speculative flexibility.
 2. Verify the result matches the behavior the slice's specs describe, and that the existing test suite still passes.
-3. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; it belongs to the verify step at the end of this workflow.
+3. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; raise it separately once the slice is green.
 
 Writing a new test is **not required** in this loop — add one when it earns its keep. If you do, put it at the seam \`design.md\` named and don't test internals or add implementation-coupled assertions (mocking internal collaborators, reaching into private state, checking the database instead of the interface).`,
     issueBranch: `### issue branch — fix root cause
@@ -97,8 +97,8 @@ const APPLY_BODY_COMMAND = buildApplyBody(APPLY_VARIANT, VERIFY_INLINE);
 export function getTospecApplySkillTemplate() {
     return {
         name: 'tospec-apply',
-        description: "Implement a tospec change's tasks slice by slice (tests optional), auto-verifying at the end. Use when the user wants to start or continue implementing a change.",
-        instructions: `Implement a change's tasks one slice at a time, branching by schema, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
+        description: "Implement a tospec change's tasks slice by slice (tests optional). Use when the user wants to start or continue implementing a change.",
+        instructions: `Implement a change's tasks one slice at a time, branching by schema — ready for \`tospec-archive\` once the tasks are done and the tests are green. The two-axis review is opt-in: it runs only if the user asks for it.
 
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
@@ -116,7 +116,7 @@ export function getTospecApplyCommandTemplate() {
         description: 'Implement tasks from a change, one slice at a time',
         category: 'Workflow',
         tags: ['workflow', 'implementation'],
-        content: `Implement a change's tasks one slice at a time, branching by schema, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
+        content: `Implement a change's tasks one slice at a time, branching by schema — ready for \`tospec-archive\` once the tasks are done and the tests are green. The two-axis review is opt-in: it runs only if the user asks for it.
 
 **Input**: Optionally specify a change name after \`tospec-apply\` (e.g., \`tospec-apply add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
@@ -134,7 +134,7 @@ For each tracer-bullet slice in \`tasks.md\`:
 1. Write the failing test first (red) — **only at the seam \`design.md\` named**. Don't test internals, don't add implementation-coupled assertions (mocking internal collaborators, reaching into private state, checking the database instead of the interface).
 2. Implement the minimum to pass (green). Don't anticipate future slices or add speculative flexibility.
 3. Verify the result matches the behavior the slice's specs describe.
-4. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; it belongs to the verify step at the end of this workflow.`,
+4. Check off the slice, then move to the next one — one slice per cycle. Refactoring is not part of this loop; raise it separately once the slice is green.`,
     issueBranch: `### issue branch — three-way test split
 
 Read \`task.md\`'s feedback loop. Then:
@@ -152,7 +152,7 @@ export function getTospecApplyWithTDDSkillTemplate() {
     return {
         name: 'tospec-apply-with-tdd',
         description: 'Implement tasks from a tospec change test-first (red → green). Use when the user wants to start or continue implementation with a strict TDD loop.',
-        instructions: `Implement a change's tasks test-first (red → green), one slice at a time, branching by schema, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
+        instructions: `Implement a change's tasks test-first (red → green), one slice at a time, branching by schema — ready for \`tospec-archive\` once the tasks are done and the tests are green. The two-axis review is opt-in: it runs only if the user asks for it.
 
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
@@ -170,7 +170,7 @@ export function getTospecApplyWithTDDCommandTemplate() {
         description: 'Implement tasks from a change test-first (red → green)',
         category: 'Workflow',
         tags: ['workflow', 'tdd', 'implementation'],
-        content: `Implement a change's tasks test-first (red → green), one slice at a time, branching by schema, then automatically run the two-axis verify review — ready for \`tospec-archive\` when done.
+        content: `Implement a change's tasks test-first (red → green), one slice at a time, branching by schema — ready for \`tospec-archive\` once the tasks are done and the tests are green. The two-axis review is opt-in: it runs only if the user asks for it.
 
 **Input**: Optionally specify a change name after \`tospec-apply-with-tdd\` (e.g., \`tospec-apply-with-tdd add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 

package/dist/core/templates/workflows/apply.js.map

@@ -1 +1 @@
-{"version":3,"file":"apply.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/apply.ts"],"names":[],"mappings":"AAaA,OAAO,EAAE,UAAU,EAAE,cAAc,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAC;AAiBnF;;;GAGG;AACH,uEAAuE;AACvE,SAAS,cAAc,CAAC,CAAe,EAAE,aAAqB;IAC5D,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mEA+B0D,CAAC,CAAC,YAAY;;;;;;;;EAQ/E,CAAC,CAAC,SAAS;;EAEX,CAAC,CAAC,WAAW;;;;;;;;EAQb,aAAa;;;;;;;EAOb,CAAC,CAAC,cAAc;;;;;;;sGAOoF,CAAC;AACvG,CAAC;AAED,gFAAgF;AAChF,wEAAwE;AACxE,gFAAgF;AAEhF,MAAM,aAAa,GAAiB;IAClC,YAAY,EACV,8IAA8I;IAChJ,SAAS,EAAE;;;;;;;yTAO4S;IACvT,WAAW,EAAE;;;;oJAIqI;IAClJ,cAAc,EAAE;;wFAEsE;CACvF,CAAC;AAEF,MAAM,UAAU,GAAG,cAAc,CAAC,aAAa,EAAE,cAAc,CAAC,CAAC;AACjE,MAAM,kBAAkB,GAAG,cAAc,CAAC,aAAa,EAAE,aAAa,CAAC,CAAC;AAExE,MAAM,UAAU,2BAA2B;IACzC,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,mKAAmK;QAChL,YAAY,EAAE;;;;EAIhB,UAAU,EAAE;QACV,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE;QAC9B,YAAY,EAAE,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,iBAAiB,CAAC;QAC3F,UAAU,EAAE,EAAE,WAAW,EAAE,UAAU,EAAE;KACxC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,oDAAoD;QACjE,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,gBAAgB,CAAC;QACpC,OAAO,EAAE;;;;EAIX,kBAAkB,EAAE;KACnB,CAAC;AACJ,CAAC;AAED,gFAAgF;AAChF,2CAA2C;AAC3C,gFAAgF;AAEhF,MAAM,iBAAiB,GAAiB;IACtC,YAAY,EACV,sIAAsI;IACxI,SAAS,EAAE;;;;;;0KAM6J;IACxK,WAAW,EAAE;;;;;;;wMAOyL;IACtM,cAAc,EAAE;yCACuB;CACxC,CAAC;AAEF,MAAM,cAAc,GAAG,cAAc,CAAC,iBAAiB,EAAE,cAAc,CAAC,CAAC;AACzE,MAAM,sBAAsB,GAAG,cAAc,CAAC,iBAAiB,EAAE,aAAa,CAAC,CAAC;AAEhF,MAAM,UAAU,kCAAkC;IAChD,OAAO;QACL,IAAI,EAAE,uBAAuB;QAC7B,WAAW,EAAE,oJAAoJ;QACjK,YAAY,EAAE;;;;EAIhB,cAAc,EAAE;QACd,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE;QAC9B,YAAY,EAAE,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,iBAAiB,CAAC;QAC3F,UAAU,EAAE,EAAE,WAAW,EAAE,UAAU,EAAE;KACxC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,oCAAoC;IAClD,OAAO;QACL,IAAI,EAAE,qBAAqB;QAC3B,WAAW,EAAE,wDAAwD;QACrE,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,KAAK,EAAE,gBAAgB,CAAC;QAC3C,OAAO,EAAE;;;;EAIX,sBAAsB,EAAE;KACvB,CAAC;AACJ,CAAC"}
+{"version":3,"file":"apply.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/apply.ts"],"names":[],"mappings":"AAaA,OAAO,EAAE,UAAU,EAAE,cAAc,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAC;AAiBnF;;;GAGG;AACH,uEAAuE;AACvE,SAAS,cAAc,CAAC,CAAe,EAAE,aAAqB;IAC5D,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mEA+B0D,CAAC,CAAC,YAAY;;;;;;;;EAQ/E,CAAC,CAAC,SAAS;;EAEX,CAAC,CAAC,WAAW;;;;;;;;EAQb,aAAa;;;;;;;EAOb,CAAC,CAAC,cAAc;;;;;;;6HAO2G,CAAC;AAC9H,CAAC;AAED,gFAAgF;AAChF,wEAAwE;AACxE,gFAAgF;AAEhF,MAAM,aAAa,GAAiB;IAClC,YAAY,EACV,8IAA8I;IAChJ,SAAS,EAAE;;;;;;;yTAO4S;IACvT,WAAW,EAAE;;;;oJAIqI;IAClJ,cAAc,EAAE;;wFAEsE;CACvF,CAAC;AAEF,MAAM,UAAU,GAAG,cAAc,CAAC,aAAa,EAAE,cAAc,CAAC,CAAC;AACjE,MAAM,kBAAkB,GAAG,cAAc,CAAC,aAAa,EAAE,aAAa,CAAC,CAAC;AAExE,MAAM,UAAU,2BAA2B;IACzC,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,wIAAwI;QACrJ,YAAY,EAAE;;;;EAIhB,UAAU,EAAE;QACV,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE;QAC9B,YAAY,EAAE,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,iBAAiB,CAAC;QAC3F,UAAU,EAAE,EAAE,WAAW,EAAE,UAAU,EAAE;KACxC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,oDAAoD;QACjE,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,gBAAgB,CAAC;QACpC,OAAO,EAAE;;;;EAIX,kBAAkB,EAAE;KACnB,CAAC;AACJ,CAAC;AAED,gFAAgF;AAChF,2CAA2C;AAC3C,gFAAgF;AAEhF,MAAM,iBAAiB,GAAiB;IACtC,YAAY,EACV,sIAAsI;IACxI,SAAS,EAAE;;;;;;4JAM+I;IAC1J,WAAW,EAAE;;;;;;;wMAOyL;IACtM,cAAc,EAAE;yCACuB;CACxC,CAAC;AAEF,MAAM,cAAc,GAAG,cAAc,CAAC,iBAAiB,EAAE,cAAc,CAAC,CAAC;AACzE,MAAM,sBAAsB,GAAG,cAAc,CAAC,iBAAiB,EAAE,aAAa,CAAC,CAAC;AAEhF,MAAM,UAAU,kCAAkC;IAChD,OAAO;QACL,IAAI,EAAE,uBAAuB;QAC7B,WAAW,EAAE,oJAAoJ;QACjK,YAAY,EAAE;;;;EAIhB,cAAc,EAAE;QACd,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE;QAC9B,YAAY,EAAE,CAAC,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,EAAE,iBAAiB,CAAC;QAC3F,UAAU,EAAE,EAAE,WAAW,EAAE,UAAU,EAAE;KACxC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,oCAAoC;IAClD,OAAO;QACL,IAAI,EAAE,qBAAqB;QAC3B,WAAW,EAAE,wDAAwD;QACrE,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,KAAK,EAAE,gBAAgB,CAAC;QAC3C,OAAO,EAAE;;;;EAIX,sBAAsB,EAAE;KACvB,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/archive.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"archive.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AAiDlE,wBAAgB,6BAA6B,IAAI,aAAa,CAc7D;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}
+{"version":3,"file":"archive.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA2DlE,wBAAgB,6BAA6B,IAAI,aAAa,CAc7D;AAED,wBAAgB,+BAA+B,IAAI,eAAe,CAYjE"}

package/dist/core/templates/workflows/archive.js

@@ -1,54 +1,64 @@
-const ARCHIVE_BODY = `**Finishing a change: confirm verify, decide about sync, then archive — in that order.** Do not run \`tospec archive\` speculatively "to see what happens"; each step below must actually hold first.
+const ARCHIVE_BODY = `**Finishing a change: sync, then archive — in that order.** Do not run \`tospec archive\` speculatively "to see what happens"; each step below must actually hold first.
 
-**Step 0 — verify already happened in apply**
+**Step 1 — run the sync, don't ask about it**
 
-verify is not a separate command anymore — it runs automatically at the end of \`tospec-apply\`. Before archiving, confirm apply's verify step came back clean (both Standards and Spec axes clear of blocking findings, full test suite green). If apply's verify surfaced blocking issues, **stop** and go back to \`tospec-apply\` to fix them — do not archive over them.
+Archive merges the change's delta specs into \`tospec/specs/\` permanently, so if those specs have drifted from what the code actually does, archiving locks in a description that no longer matches reality. Decide **proactively** whether that risk applies here:
 
-**Step 1 — judge whether a sync is needed, and only ask if it is**
+Take these in order; the first that matches wins.
 
-Archive merges the change's delta specs into \`tospec/specs/\`, so if those specs have drifted from what the code actually does, archiving would lock in a spec that no longer matches reality. Decide **proactively** whether that risk applies here:
+1. **The user explicitly asked to skip it** ("archive without syncing", "just archive") — honor that. Skip the sync and archive **without** \`--require-sync\` (Step 2, not-synced branch). This is checked first on purpose: an explicit instruction outranks the default, and what was removed is the unsolicited question, not the user's authority.
+2. **No delta specs at all** (e.g. a purely cosmetic issue fix with no behavior change) — there is no spec-vs-code drift to find. Skip straight to Step 2 and archive directly. Under a schema that requires deltas (sdd), such a change also needs \`skip_specs: true\` in its \`.tospec.yaml\` or validation will refuse it — set that once, and only when the change truly has no externally observable effect. Never write a delta spec just to get past the gate.
+3. **Otherwise the change produced delta specs** (a non-empty \`specs/<capability>/spec.md\` under the change dir), so behavior was added or changed and drift is possible. Run the \`tospec-sync\` workflow now, without asking. There is no question to put: declining would mean knowingly publishing a spec that may not describe the code, so a prompt here spends the user's attention without buying a decision.
 
-- **Sync is warranted** when the change produced delta specs (a non-empty \`specs/<capability>/spec.md\` under the change dir) — i.e. behavior was added or changed, so spec-vs-code drift is possible.
-- **Sync is not needed** when there are no delta specs at all (e.g. a purely cosmetic issue fix with no behavior change). In that case skip straight to Step 2 and archive directly — don't ask a pointless question.
+Running it unannounced is safe because of how \`tospec-sync\` is ordered: it judges every Requirement before writing anything, so a defect surfaces while the working tree is still untouched.
 
-If a sync is warranted, **ask the user one question** (make clear both answers are fine):
+**Step 1a — read the sync's verdict and branch**
 
-> "This change has spec deltas. Run \`tospec-sync\` to reconcile the specs against the code before archiving? (recommended, but you can archive without it.)"
+- **Every Requirement MATCH, or SPEC-UPDATED** (the spec was stale, sync corrected it to match the code and re-validated) → continue to Step 2, synced branch. **Ask nothing** — a corrected spec is the workflow working as intended, not a decision point.
+- **Any CODE-BUG** (the implementation doesn't do what a Requirement describes, or was never built) → \`sync-report.md\` says \`Conclusion: FAIL\` and **no spec file was written**. This is the one place archive stops. **Ask the user exactly once:**
 
-- **User says yes** → run the \`tospec-sync\` workflow now. It reconciles each Requirement against the code (code wins) and writes \`sync-report.md\` with \`Conclusion: PASS\`. If it ends in \`Conclusion: FAIL\` (a real CODE-BUG), **stop** and return to \`tospec-apply\` to fix the code — do not archive. On PASS, archive **with** \`--require-sync\` (Step 2, synced branch).
-- **User says no** → that's allowed. Skip the sync and archive **without** \`--require-sync\` (Step 2, not-synced branch). Declining does not block archiving.
+  > "Sync found <N> Requirement(s) the code doesn't satisfy: <names>. Fix them now, or leave it for later?"
+
+  - **Fix now** → hand off to \`tospec-apply\` for the fix. Archive does not edit source itself. On return, resume \`tospec-sync\` **at step 4** with the verdicts it already produced — do not re-run steps 1-3. Concretely: re-judge **only the Requirements that were reported as defects** (not the whole set, and not the ones already judged MATCH), and once none of them is still a CODE-BUG, run step 4's write phase over **every** SPEC-UPDATED verdict, including the ones sync held back when it stopped. Sync then rewrites \`sync-report.md\` with \`Conclusion: PASS\`. Only then continue to Step 2 — the gate reads that report, so an un-rewritten FAIL will (correctly) refuse.
+  - **Later** → stop. Do not archive; the change stays active with its spec files unmodified.
+
+  If the re-judge finds a Requirement is *still* a CODE-BUG, do **not** put the question again — it was already answered. Report which Requirement did not come clean and stop, as for "Later". The one-question rule is per archive run, not per attempt.
+
+- **\`Conclusion: FAIL\` with no CODE-BUG** — validation failed somewhere sync could not resolve: either on a spec update it had just written (the report names that Requirement) or on the final artifact check, which can fail on an artifact no Requirement touched. Either way this is an artifact problem, not a code defect: fix whatever \`tospec validate --json\` points at — the report names it when a spec update caused it — then re-run validation and have sync complete any remaining writes and rewrite the report to PASS. Do not archive on a FAIL report, and do not reach for \`--require-sync\`'s absence to route around it.
 
 **Step 2 — archive**
 
-Synced branch (user chose to sync and \`sync-report.md\` says \`Conclusion: PASS\`):
+Synced branch (a sync ran and \`sync-report.md\` says \`Conclusion: PASS\`):
 \`\`\`bash
 tospec archive "<name>" --json --require-sync
 \`\`\`
-\`--require-sync\` is the CLI's own machine-checkable half of the sync gate: it refuses unless \`sync-report.md\` exists with a \`Conclusion: PASS\` line (\`SYNC_REPORT_MISSING\` / \`SYNC_REPORT_FAILED\`). If \`tospec-sync\` actually ran and passed, this succeeds for free — a CLI-enforced backstop behind the instruction-level order above. Only pass \`--require-sync\` when a sync actually ran; otherwise the CLI will (correctly) refuse.
+\`--require-sync\` is the CLI's own machine-checkable half of the sync gate: it refuses unless \`sync-report.md\` exists with a \`Conclusion: PASS\` line (\`SYNC_REPORT_MISSING\` / \`SYNC_REPORT_FAILED\`). Since the sync just ran and passed, this succeeds for free — a CLI-enforced backstop behind the instruction-level order above.
 
-Not-synced branch (sync wasn't needed, or the user declined):
+Not-synced branch (no delta specs, or the user asked to skip):
 \`\`\`bash
 tospec archive "<name>" --json
 \`\`\`
+Only omit \`--require-sync\` on this branch; passing it without a sync having run will (correctly) refuse.
 
 Either way, the CLI then: re-validates the delta specs (blocking), checks tasks/task completion (with \`--json\`, incomplete tasks block unless you pass \`--yes\` after the user confirms), does a two-phase atomic merge into \`tospec/specs/\` (dry-run + re-validate every target first, writes only if all pass), and moves the change directory — including \`sync-report.md\` when present — into \`tospec/changes/archive/\` under a \`yyyyMMdd_HHmmss-<name>\` timestamp the CLI generates itself.
 
 **Reading the result**: the \`--json\` output is \`{archive, status}\`. Success → \`archive\` holds \`{change, archivedAs, path, specsUpdated}\`. Failure → \`archive\` is \`null\` and \`status[0].code\` tells you which ending you got: \`archive_validation_failed\` (fix artifacts, re-validate), \`archive_tasks_incomplete\` / \`archive_tasks_missing\` (ask the user, then rerun with \`--yes\` to override), \`SYNC_REPORT_MISSING\` / \`SYNC_REPORT_FAILED\` (the sync gate refused). Each status entry carries \`{code, message, fix}\` — follow \`fix\`.
 
 **Guardrails — explicit and non-negotiable**
-- Judge whether a sync is warranted before archiving; only ask the user when the change has spec deltas — and honor a "no" (archive still proceeds, just without \`--require-sync\`)
+- Run the sync when the change has spec deltas; do not ask permission for it. Honor an explicit request to skip, and skip it outright when there are no delta specs
+- A CODE-BUG is the only outcome that may interrupt — MATCH and SPEC-UPDATED continue silently. Never edit source from here; a fix goes through \`tospec-apply\`
 - Only pass \`--require-sync\` when \`tospec-sync\` actually produced a passing \`sync-report.md\` this run
 - **\`tospec archive\` owns the archive directory** — it generates the \`yyyyMMdd_HHmmss-<name>\` name and moves the change there. Let the command do it: the timestamp comes from internals you cannot reproduce, so a hand-built name risks a collision or a wrong sort order
 - If \`tospec archive\` reports a validation failure or asks for confirmation on incomplete tasks, resolve the underlying issue (or explicitly confirm with the user) — do not route around it with manual file operations
 
 **Output**
 
-Report the archived name and path from \`tospec archive\`'s output, whether a sync ran, and confirm \`tospec/specs/\` now reflects the merged change.`;
+Report the archived name and path from \`tospec archive\`'s output, whether a sync ran and what it concluded, and **anything the sync found that no Requirement asked for** — that is reported here, never written into a spec, and never a reason to block. Confirm \`tospec/specs/\` now reflects the merged change.`;
 export function getTospecArchiveSkillTemplate() {
     return {
         name: 'tospec-archive',
-        description: 'Finish and archive a completed tospec change via `tospec archive`, deciding first whether a spec/code sync is needed. Use when the user wants to finalize an implemented change.',
-        instructions: `Finish a completed change: confirm verify (done in apply), decide about sync (run \`tospec-sync\` if warranted and the user agrees), then \`tospec archive\` — the only path to a merged, archived change.
+        description: 'Finish and archive a completed tospec change via `tospec archive`, running a spec/code sync first when the change has spec deltas. Use when the user wants to finalize an implemented change.',
+        instructions: `Finish a completed change: run \`tospec-sync\` when the change has spec deltas, then \`tospec archive\` — the only path to a merged, archived change.
 
 **Input**: The user's request should name the change to archive.
 
@@ -62,10 +72,10 @@ ${ARCHIVE_BODY}`,
 export function getTospecArchiveCommandTemplate() {
     return {
         name: 'TOSPEC: Archive',
-        description: 'Judge whether a spec/code sync is needed (ask if so), then finalize and archive a completed change',
+        description: 'Run a spec/code sync when warranted, then finalize and archive a completed change',
         category: 'Workflow',
         tags: ['workflow', 'archive'],
-        content: `Finish a completed change: confirm verify (done in apply), decide about sync (run \`tospec-sync\` if warranted and the user agrees), then \`tospec archive\` — the only path to a merged, archived change.
+        content: `Finish a completed change: run \`tospec-sync\` when the change has spec deltas, then \`tospec archive\` — the only path to a merged, archived change.
 
 **Input**: The argument after \`tospec-archive\` is the change name to archive.
 

package/dist/core/templates/workflows/archive.js.map

@@ -1 +1 @@
-{"version":3,"file":"archive.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sJA6CiI,CAAC;AAEvJ,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,kLAAkL;QAC/L,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE;QAC9B,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,oGAAoG;QACjH,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;QAC7B,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}
+{"version":3,"file":"archive.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/archive.ts"],"names":[],"mappings":"AAQA,MAAM,YAAY,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;uTAuDkS,CAAC;AAExT,MAAM,UAAU,6BAA6B;IAC3C,OAAO;QACL,IAAI,EAAE,gBAAgB;QACtB,WAAW,EAAE,+LAA+L;QAC5M,YAAY,EAAE;;;;EAIhB,YAAY,EAAE;QACZ,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE;QAC9B,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,EAAE,iBAAiB,CAAC;KAC7F,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,+BAA+B;IAC7C,OAAO;QACL,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,mFAAmF;QAChG,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,SAAS,CAAC;QAC7B,OAAO,EAAE;;;;EAIX,YAAY,EAAE;KACb,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/propose.js

@@ -22,7 +22,7 @@ const PROPOSE_BODY = `Do NOT re-interview the user — synthesize what's already
    \`\`\`bash
    tospec instructions <artifact-id> --change "<name>" --json
    \`\`\`
-   Read \`template\` and \`instruction\` from the response, write \`resolvedOutputPath\`, then re-run \`status --json\` and continue until every \`applyRequires\` artifact is \`done\`.
+   Read \`template\` and \`instruction\` from the response, re-read every file listed under \`dependencies\` from disk (even ones you already saw — the user may have edited them since), write \`resolvedOutputPath\`, then re-run \`status --json\` and continue until every \`applyRequires\` artifact is \`done\`.
 
    Artifact-specific rules on top of what \`instructions\` returns:
    - **ticket** (already created): keep it thin — just refine the one-line \`## Summary\` so it names what this change does. All the detail (why, what, scope, decisions) lives in \`proposal.md\`, not here. Don't duplicate proposal content into the ticket, and don't add a timestamp or filename yourself.
@@ -44,7 +44,7 @@ Summarize the change name and location, the artifacts created, and prompt: "Run
 - Create every artifact \`apply.requires\` needs — don't stop at \`proposal\`
 - The ticket file and its timestamp are CLI-generated — never create, rename, or move ticket files; only edit the Summary in the existing stub
 - Detailed why/what goes in \`proposal.md\`; the ticket stays a thin index
-- Read dependency artifacts before writing the next one
+- Read dependency artifacts from disk before writing the next one — don't rely on memory from earlier in the conversation, they may have been edited since
 - \`context\`/\`rules\` from \`instructions\` are constraints for you, never content to copy into the file
 - If a change with that name already exists, ask whether to continue it or pick a new name
 - If context is critically unclear even after checking the conversation, ask — but prefer a reasonable default to keep momentum`;

package/dist/core/templates/workflows/sync.d.ts

@@ -4,9 +4,10 @@
  * This file is generated by splitting the legacy monolithic
  * templates file into workflow-focused modules.
  *
- * sync is a standalone skill again. The archive workflow proactively decides
- * whether a sync is warranted and asks the user before archiving; when the
- * user agrees, this is the procedure that runs.
+ * sync is a standalone skill, and also archive's automatic first step: archive
+ * decides whether a sync is warranted and, when it is, runs this procedure
+ * without asking. Step 4's judge-before-write gate is what makes running it
+ * unannounced safe.
  */
 import type { SkillTemplate, CommandTemplate } from '../types.js';
 export declare function getTospecSyncSkillTemplate(): SkillTemplate;

package/dist/core/templates/workflows/sync.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"sync.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/sync.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA6DlE,wBAAgB,0BAA0B,IAAI,aAAa,CAc1D;AAED,wBAAgB,4BAA4B,IAAI,eAAe,CAY9D"}
+{"version":3,"file":"sync.d.ts","sourceRoot":"","sources":["../../../../src/core/templates/workflows/sync.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AACH,OAAO,KAAK,EAAE,aAAa,EAAE,eAAe,EAAE,MAAM,aAAa,CAAC;AA8ElE,wBAAgB,0BAA0B,IAAI,aAAa,CAc1D;AAED,wBAAgB,4BAA4B,IAAI,eAAe,CAY9D"}

package/dist/core/templates/workflows/sync.js

@@ -8,22 +8,36 @@ const SYNC_BODY = `Whether a spec still matches the source code is a semantic ju
 
    **No-delta case**: an issue fix with no behavior change has no delta specs at all. Don't invent Requirements to check — instead confirm \`task.md\`'s described fix matches what the code actually does, and note this as the no-delta case in the report (see format below).
 
-2. **Compare each Requirement against the actual implementation**
+2. **Judge each Requirement against the actual implementation — writing nothing**
+
+   Steps 2 and 3 are the judge phase: they produce verdicts only. **Do not edit a spec file yet, however obviously stale it looks.** Record each verdict and move on; step 4 does all the writing, once every Requirement has a verdict.
 
    For each Requirement, locate the corresponding code (the files apply touched are a good starting point) and judge: does the implemented behavior match what the Requirement's scenarios describe?
 
    **Can't find any corresponding implementation at all**: that's a CODE-BUG, same severity as a behavioral mismatch — the Requirement was agreed to and never built. Don't wave it through as MATCH.
 
-3. **Resolve every mismatch — code wins**
+3. **Sweep the other direction — behavior nobody asked for**
+
+   Step 2 walks Requirements to code, so it can only find what is *missing*. It cannot see the opposite: behavior in the diff that **maps to no Requirement** at all. Walk the change's diff once and flag anything the specs never asked for.
+
+   **Report it, never spec it.** "Code wins" settles how a Requirement is *worded*, not whether behavior *belongs* — it is not a licence to make unrequested work look agreed after the fact. Never add a Requirement to cover scope creep: tell the user what you found and let them decide to keep it, drop it, or plan it properly.
+
+4. **Write the resolutions — code wins**
 
-   - If the spec is stale relative to the code (the code is correct, the spec described the old behavior): update the delta spec's Requirement with **MODIFIED**, pasting the complete, corrected Requirement block. Then:
+   Start this phase **only once steps 2 and 3 are complete and no Requirement is a CODE-BUG.** That gate is what makes it safe for \`tospec-archive\` to run this workflow without announcing it: because every defect surfaces while the judge phase is still writing nothing, walking away at this point leaves every spec file unmodified.
+
+   - **Any CODE-BUG** (the code doesn't do what was agreed in ticket/design, or was never built): **stop before writing anything.** Do not touch the spec to paper over a bug, and do not write the SPEC-UPDATED entries you already judged — they keep until the defect is resolved. Report the mismatch and go to step 5 with \`Conclusion: FAIL\`.
+
+     **Resuming after the defect is fixed** (this is how \`tospec-archive\` re-enters on its "fix now" branch): come back to *this step*, not to step 1. Re-judge only the Requirements that were CODE-BUG; every other verdict still stands. Once none of them is a defect any more, fall through to the bullet below and write **every** SPEC-UPDATED verdict — the ones held back here included, or their staleness ships into \`tospec/specs/\` on archive. Then rewrite \`sync-report.md\` (step 5) with the new conclusion; a report left at FAIL blocks the archive gate.
+   - **No CODE-BUG**: work the SPEC-UPDATED verdicts one at a time. For each, update the delta spec's Requirement with **MODIFIED**, pasting the complete, corrected Requirement block. Then:
      \`\`\`bash
      tospec validate "<name>" --json
      \`\`\`
-     Must pass before moving to the next Requirement — record the validate result in that Requirement's report entry.
-   - If the code itself is wrong (it doesn't do what was actually agreed in ticket/design, or is missing entirely): **stop**. Do not touch the spec to paper over a bug. Report the mismatch to the user and suggest returning to \`tospec-apply\` to fix the code before archiving.
+     Must pass before writing the next one — one write, one validate, so a failure names the Requirement that caused it instead of leaving you to bisect a bulk edit. Record the validate result in that Requirement's report entry.
 
-4. **Write the sync report**
+     **If that validate fails**, the MODIFIED block you just wrote is malformed — an artifact problem, not a code defect. Fix that block and re-run \`tospec validate\` until it passes, then carry on with the remaining verdicts. Only if you cannot make it pass do you stop and report \`Conclusion: FAIL\`, naming the Requirement; that FAIL is not a CODE-BUG and archive handles it as an artifact fix, not a return to \`tospec-apply\`.
+
+5. **Write the sync report**
 
    Create \`sync-report.md\` in the change directory in exactly this format — \`tospec archive --require-sync\` parses the first \`Conclusion:\` line, so the heading and label text must match:
 
@@ -40,7 +54,7 @@ const SYNC_BODY = `Whether a spec still matches the source code is a semantic ju
 
    Fill the \`Conclusion:\` line with exactly one literal — \`Conclusion: PASS\` or \`Conclusion: FAIL\` (FAIL may append a \`(reason)\` note); never leave both options in one line, or \`tospec archive --require-sync\` can't parse it. \`Conclusion:\` is **FAIL** if even one Requirement is CODE-BUG — a single unresolved defect blocks the whole change, not just that Requirement. It's **PASS** only when every Requirement resolved to MATCH or SPEC-UPDATED (with validate passing). For the no-delta case, still emit the Summary and a single Requirements entry describing the task.md-vs-code comparison (module described, not a Requirement name).
 
-5. **Final artifact validation**
+6. **Final artifact validation**
    \`\`\`bash
    tospec validate "<name>" --json
    \`\`\`
@@ -48,19 +62,22 @@ const SYNC_BODY = `Whether a spec still matches the source code is a semantic ju
 
 **Output**
 
-Summarize how many Requirements were in sync, how many specs were updated, and whether anything was flagged as a code defect. If \`Conclusion: PASS\`, prompt: "Run \`tospec-archive\` to finish up — it passes \`--require-sync\` for free now that \`sync-report.md\` reports PASS." If \`Conclusion: FAIL\`, prompt to return to \`tospec-apply\` first — do not proceed to archive.
+Summarize how many Requirements matched, how many specs were updated, whether anything was flagged as a code defect, and anything found that no Requirement asked for.
+
+Where that summary goes depends on who called you. **Run from \`tospec-archive\`** (the usual case): hand the summary straight back — archive continues on \`Conclusion: PASS\`, passing \`--require-sync\` for free, and on \`Conclusion: FAIL\` archive owns the single question about fixing the defect. Do not prompt for archiving yourself; you are already inside it. **Run standalone**: on \`Conclusion: PASS\` prompt "Run \`tospec-archive\` to finish up", and on \`Conclusion: FAIL\` prompt to return to \`tospec-apply\` first.
 
 **Guardrails**
 - Code is the source of truth for behavior — spec updates always follow code, never the other way around
+- Scope creep is reported, never specced — "code wins" settles a Requirement's wording, never whether unrequested behavior belongs
 - Never edit source code from this workflow — a code-side mismatch is diagnosis, not a license to patch here
-- Every MODIFIED delta must re-pass \`tospec validate\` before moving to the next Requirement
+- Judge every Requirement before writing any spec update; inside the write phase, every MODIFIED delta must re-pass \`tospec validate\` before writing the next one
 - \`sync-report.md\` is required output, in the exact format above — \`tospec archive --require-sync\` depends on both its existence and its \`Conclusion:\` line
 - One comparison pass per Requirement — check it against the code once and record the verdict. \`sync-report.md\` is the deliverable, not another review target: don't re-audit the report after writing it, and don't re-check a Requirement already judged MATCH`;
 export function getTospecSyncSkillTemplate() {
     return {
         name: 'tospec-sync',
-        description: 'Reconcile a change\'s Requirements against the actual implementation — code wins on any mismatch — and write sync-report.md. Use before archiving a change whose specs may have drifted from the code.',
-        instructions: `Reconcile \`specs/\` against the implementation for every Requirement this change touched — code wins on any mismatch. Run this before \`tospec-archive\` when the change's specs may have drifted from the code.
+        description: 'Sync a change\'s Requirements against the actual implementation — code wins on any mismatch — and write sync-report.md. Use before archiving a change whose specs may have drifted from the code.',
+        instructions: `Sync \`specs/\` against the implementation for every Requirement this change touched — code wins on any mismatch. Run this before \`tospec-archive\` when the change's specs may have drifted from the code.
 
 **Input**: The user's request should name the change to sync.
 
@@ -74,10 +91,10 @@ ${SYNC_BODY}`,
 export function getTospecSyncCommandTemplate() {
     return {
         name: 'TOSPEC: Sync',
-        description: 'Reconcile specs against the implementation, code as source of truth',
+        description: 'Sync specs against the implementation, code as source of truth',
         category: 'Workflow',
         tags: ['workflow', 'sync', 'archive-gate'],
-        content: `Reconcile \`specs/\` against the implementation for every Requirement this change touched — code wins on any mismatch. Run this before \`tospec-archive\` when the change's specs may have drifted from the code.
+        content: `Sync \`specs/\` against the implementation for every Requirement this change touched — code wins on any mismatch. Run this before \`tospec-archive\` when the change's specs may have drifted from the code.
 
 **Input**: The argument after \`tospec-sync\` is the change name to sync.
 

package/dist/core/templates/workflows/sync.js.map

@@ -1 +1 @@
-{"version":3,"file":"sync.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/sync.ts"],"names":[],"mappings":"AAYA,MAAM,SAAS,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mQAyDiP,CAAC;AAEpQ,MAAM,UAAU,0BAA0B;IACxC,OAAO;QACL,IAAI,EAAE,aAAa;QACnB,WAAW,EAAE,wMAAwM;QACrN,YAAY,EAAE;;;;EAIhB,SAAS,EAAE;QACT,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE;QAC9B,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,CAAC;KAC1E,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,4BAA4B;IAC1C,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,qEAAqE;QAClF,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,MAAM,EAAE,cAAc,CAAC;QAC1C,OAAO,EAAE;;;;EAIX,SAAS,EAAE;KACV,CAAC;AACJ,CAAC"}
+{"version":3,"file":"sync.js","sourceRoot":"","sources":["../../../../src/core/templates/workflows/sync.ts"],"names":[],"mappings":"AAaA,MAAM,SAAS,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mQA0EiP,CAAC;AAEpQ,MAAM,UAAU,0BAA0B;IACxC,OAAO;QACL,IAAI,EAAE,aAAa;QACnB,WAAW,EAAE,mMAAmM;QAChN,YAAY,EAAE;;;;EAIhB,SAAS,EAAE;QACT,OAAO,EAAE,KAAK;QACd,aAAa,EAAE,sBAAsB;QACrC,QAAQ,EAAE,EAAE,MAAM,EAAE,QAAQ,EAAE;QAC9B,YAAY,EAAE,CAAC,gBAAgB,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,CAAC;KAC1E,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,4BAA4B;IAC1C,OAAO;QACL,IAAI,EAAE,cAAc;QACpB,WAAW,EAAE,gEAAgE;QAC7E,QAAQ,EAAE,UAAU;QACpB,IAAI,EAAE,CAAC,UAAU,EAAE,MAAM,EAAE,cAAc,CAAC;QAC1C,OAAO,EAAE;;;;EAIX,SAAS,EAAE;KACV,CAAC;AACJ,CAAC"}

package/dist/core/templates/workflows/update.js

@@ -17,7 +17,7 @@ const UPDATE_BODY = `**Steps**
 
    The artifact ids and paths come from the active schema — never assume them, and never branch on hardcoded artifact names. Custom schemas must work unchanged.
 
-   The files to edit are \`artifactPaths.<id>.existingOutputPaths\` — the concrete files that exist on disk, already glob-expanded for glob artifacts (e.g. \`specs/**/*.md\`). Do NOT write to \`resolvedOutputPath\`: for a glob artifact it is still the glob pattern, not a real file.
+   The files to edit are \`artifactPaths.<id>.existingOutputPaths\` — the concrete files that exist on disk, already glob-expanded for glob artifacts (e.g. \`specs/*/spec.md\`). Do NOT write to \`resolvedOutputPath\`: for a glob artifact it is still the glob pattern, not a real file.
 
 3. **Understand the request**
    - If the user asked for a specific revision ("the design now uses X"), that is the starting edit.

package/dist/core/update.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"update.d.ts","sourceRoot":"","sources":["../../src/core/update.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAmCH;;GAEG;AACH,MAAM,WAAW,oBAAoB;IACnC,kDAAkD;IAClD,KAAK,CAAC,EAAE,OAAO,CAAC;CACjB;AAED,qBAAa,aAAa;IACxB,OAAO,CAAC,QAAQ,CAAC,KAAK,CAAU;gBAEpB,OAAO,GAAE,oBAAyB;IAIxC,OAAO,CAAC,WAAW,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IAoKjD;;OAEG;IACH,OAAO,CAAC,iBAAiB;IAsBzB;;OAEG;IACH,OAAO,CAAC,cAAc;IAkBtB;;;OAGG;IACH,OAAO,CAAC,+BAA+B;IAkBvC;;;;OAIG;YACW,yBAAyB;CA0BxC"}
+{"version":3,"file":"update.d.ts","sourceRoot":"","sources":["../../src/core/update.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AA8BH;;GAEG;AACH,MAAM,WAAW,oBAAoB;IACnC,kDAAkD;IAClD,KAAK,CAAC,EAAE,OAAO,CAAC;CACjB;AAED,qBAAa,aAAa;IACxB,OAAO,CAAC,QAAQ,CAAC,KAAK,CAAU;gBAEpB,OAAO,GAAE,oBAAyB;IAIxC,OAAO,CAAC,WAAW,EAAE,MAAM,GAAG,OAAO,CAAC,IAAI,CAAC;IAoKjD;;OAEG;IACH,OAAO,CAAC,iBAAiB;IAoBzB;;OAEG;IACH,OAAO,CAAC,cAAc;IAkBtB;;;OAGG;IACH,OAAO,CAAC,+BAA+B;IAkBvC;;;;OAIG;YACW,yBAAyB;CA0BxC"}

package/dist/core/update.js

@@ -10,6 +10,7 @@ import { FileSystemUtils } from '../utils/file-system.js';
 import { AI_TOOLS, TOSPEC_DIR_NAME } from './config.js';
 import { getToolVersionStatus, getSkillTemplates, writeSkillDir, getConfiguredTools, removeLegacySkillDirs, removeLegacyToolSkillLayout, writeToolCommands, } from './shared/index.js';
 import { getGlobalConfig } from './global-config.js';
+import { runLegacyUserStateMigration } from './user-state-migration.js';
 import { getProfileWorkflows, ALL_WORKFLOWS } from './profiles.js';
 import { getAvailableTools } from './available-tools.js';
 import { copyDir } from '../utils/link.js';
@@ -17,15 +18,15 @@ const require = createRequire(import.meta.url);
 const { version: TOSPEC_VERSION } = require('../../package.json');
 const OLD_CORE_WORKFLOWS = ['propose', 'explore', 'apply', 'archive'];
 const WORKFLOW_TO_SKILL_DIR = Object.fromEntries(getSkillTemplates().map(({ workflowId, dirName }) => [workflowId, dirName]));
-function getConfiguredProjectTools(projectPath) {
-    return getConfiguredTools(projectPath);
-}
 export class UpdateCommand {
     force;
     constructor(options = {}) {
         this.force = options.force ?? false;
     }
     async execute(projectPath) {
+        // Above every getGlobalConfig() below, so this run reads the migrated file
+        // rather than the legacy fallback.
+        await runLegacyUserStateMigration();
         const resolvedProjectPath = path.resolve(projectPath);
         const tospecPath = path.join(resolvedProjectPath, TOSPEC_DIR_NAME);
         // 1. Check tospec directory exists
@@ -38,7 +39,7 @@ export class UpdateCommand {
         const profileWorkflows = getProfileWorkflows(profile, globalConfig.workflows);
         const desiredWorkflows = profileWorkflows.filter((workflow) => ALL_WORKFLOWS.includes(workflow));
         // 5. Find configured tools
-        const configuredTools = getConfiguredProjectTools(resolvedProjectPath);
+        const configuredTools = getConfiguredTools(resolvedProjectPath);
         if (configuredTools.length === 0) {
             console.log('No configured tools found.');
             console.log('Run "tospec init" to set up tools.');
@@ -54,11 +55,7 @@ export class UpdateCommand {
         const toolsNeedingVersionUpdate = toolStatuses
             .filter((s) => s.needsUpdate)
             .map((s) => s.toolId);
-        const toolsNeedingConfigSync = [];
-        const toolsToUpdateSet = new Set([
-            ...toolsNeedingVersionUpdate,
-            ...toolsNeedingConfigSync,
-        ]);
+        const toolsToUpdateSet = new Set(toolsNeedingVersionUpdate);
         const toolsUpToDate = toolStatuses.filter((s) => !toolsToUpdateSet.has(s.toolId));
         if (!this.force && toolsToUpdateSet.size === 0) {
             // The generated version is current, but update is also the repair path
@@ -171,13 +168,11 @@ export class UpdateCommand {
      * Display the update plan showing which tools need updating.
      */
     displayUpdatePlan(toolsToUpdate, statusByTool, upToDate) {
+        // Every id in toolsToUpdate came from a status with needsUpdate === true,
+        // so there is no non-version reason to be in this list.
         const updates = toolsToUpdate.map((toolId) => {
-            const status = statusByTool.get(toolId);
-            if (status?.needsUpdate) {
-                const fromVersion = status.generatedByVersion ?? 'unknown';
-                return `${status.toolId} (${fromVersion} → ${TOSPEC_VERSION})`;
-            }
-            return `${toolId} (config sync)`;
+            const fromVersion = statusByTool.get(toolId)?.generatedByVersion ?? 'unknown';
+            return `${toolId} (${fromVersion} → ${TOSPEC_VERSION})`;
         });
         console.log(`Updating ${toolsToUpdate.length} tool(s): ${updates.join(', ')}`);
         if (upToDate.length > 0) {