@zhixuan92/multi-model-agent-core 4.2.1 → 4.3.0

package/dist/tools/delegate/implementer-criteria.js

@@ -1,114 +1,86 @@
 /**
- * Delegate-specific implementer criteria.
+ * Delegate worker criteria — 4.3.0 pipeline-redesign mindset.
  *
- * DELEGATE'S PURPOSE — read this before adding categories.
  * mma-delegate is the generic dispatcher for ad-hoc implementation
- * tasks. The caller hands you a `prompt` (and optionally a `done`
- * acceptance criterion, `filePaths`, `verifyCommand`); your output is
- * a diff a REVIEWER will read alongside the brief. The success
- * criterion is:
+ * tasks. Caller hands you a `prompt` (and optionally a `done` acceptance
+ * criterion, `filePaths`, `verifyCommand`); your output is a diff.
  *
- *   "Could a reviewer who reads only the brief and your diff approve
- *    the merge without flagging gaps the worker should have caught
- *    or extras the brief did not authorize?"
+ * Pipeline mindset (different from earlier versions):
+ * - This is a SINGLE-PASS pipeline. There are NO rework rounds for you.
+ * - After your turn, a SPEC reviewer (complex tier, full editor tools)
+ *   runs ONCE — it doesn't ask you to fix; it fixes inline itself.
+ * - Then a QUALITY reviewer (complex tier, full editor tools) runs ONCE
+ *   for safety/correctness — same thing: fixes inline, doesn't ask you.
+ * - Then an annotator scores overall completion and the commit gate fires
+ *   if the score is high enough.
  *
- * That criterion is what makes a write load-bearing. The reviewer is
- * NOT a rubber stamp — they will ask "did you finish that?" if the
- * fix is partial, and "why did you also touch X?" if the diff has
- * scope creep. Your job is to produce the SMALLEST COMPLETE CHANGE
- * that satisfies the brief — minimal AND complete simultaneously.
- *
- * Delegate is artifact-producing — you write files. Cross-agent
- * spec + quality + diff review applies. The spec the spec-reviewer
- * checks against is the BRIEF (prompt + done), not your interpretation
- * of it. The quality-reviewer checks safety / correctness / style.
+ * What this means for you: do your best ONE pass. You don't need to
+ * second-guess minor things — the reviewer will catch and fix them.
+ * Don't over-think; don't restart-loop; don't bail on uncertainty. The
+ * pipeline has a safety net BUT only one round of it.
  */
 /**
- * The orientation block. Goes at the TOP of every delegate prompt.
- *
- * Without an explicit orientation, workers default to "implement
- * something good" — which produces over-implementation (SCOPE CREEP)
- * and under-implementation (SILENT PARTIAL FIX). With this orientation,
- * the worker calibrates against the reviewer's standard: minimal +
- * complete, the brief is the contract.
+ * Orientation — "smallest complete change" framing.
  */
 export const DELEGATE_PURPOSE_ORIENTATION = [
-    'Why this delegation exists:',
-    'mma-delegate produces a diff a reviewer will read alongside the brief. Success = the diff is the SMALLEST COMPLETE CHANGE that satisfies the brief — minimal AND complete simultaneously. A reviewer should not need to ask "did you finish that?" or "why did you also touch X?".',
+    'Your job: produce the SMALLEST COMPLETE CHANGE that satisfies the brief — minimal AND complete simultaneously.',
+    'A reviewer reads your diff alongside the brief and asks two questions: "did you finish it?" (silent partial fix → blocker) and "why did you also touch X?" (scope creep → blocker). Both must answer cleanly.',
     '',
-    'For your output to clear that bar:',
-    '- Implement EXACTLY what the brief asks for. Not less (SILENT PARTIAL FIX). Not more (SCOPE CREEP).',
-    '- If the brief lists `filePaths`, those are the authorized targets. Existing files in the list = pre-verified to read; non-existent paths in the list = explicit output targets you must create. Files NOT in the list are off-limits to write (touch only when the brief\'s task genuinely requires it, and call out the deviation in your summary).',
-    '- If the brief includes a `done` acceptance criterion, the reviewer will check your diff against that criterion. Match it precisely.',
-    '- If the brief includes a `verifyCommand`, run it after your changes. A green verify is part of "complete"; a red verify is part of "incomplete".',
-    '- Match the surrounding code\'s conventions (naming, import style, error handling, formatting). Inventing patterns instead of matching is convention drift — the reviewer will flag it.',
-    '- If you change a public symbol (exported function signature, exported type, public method), update the callers in the named files. Leaving callers stale is an INCOMPLETE REFACTOR.',
-    '- Do NOT modify tests or fixtures or specs to make a wrong implementation pass. If a test fails, fix the implementation, not the test (unless the brief explicitly says the test is wrong).',
-    '',
-    'The completion test: would a reviewer who reads ONLY the brief and your diff approve the merge — or would they raise a concern (gap, scope creep, drift, broken caller, undocumented assumption) you should have caught?',
+    'Rules:',
+    '- Implement EXACTLY what the brief asks for. Not less. Not more.',
+    '- If the brief lists `filePaths`, those are the authorized targets. Existing entries = read-and-modify; non-existent entries = create. Files outside the list are off-limits to write unless the brief\'s task genuinely requires it (call out any deviation in your summary).',
+    '- If the brief includes a `done` criterion, your diff must satisfy it precisely.',
+    '- If the brief includes a `verifyCommand`, run it after your changes. Green = part of complete; red = part of incomplete.',
+    '- If you change a public symbol (exported function signature, exported type, public method), update callers in the named files. Stale callers are an INCOMPLETE REFACTOR.',
+    '- Do NOT modify tests or fixtures to make a wrong implementation pass. If a test fails, fix the implementation.',
 ].join('\n');
-/**
- * The scope rule for delegate.
- *
- * Replaces the prior one-liner with a concrete contract about what
- * is in scope, what is off-limits, and what to do at the boundary.
- */
 export const DELEGATE_SCOPE_RULE = [
     'Scope:',
     '- Strictly what the brief\'s `prompt` (and `done` if present) requests. The brief is the contract.',
-    '- Reading: the named `filePaths` plus what the task obviously implies (caller files when the diff changes a public symbol; sibling test files when the brief changes behavior; types files when the diff changes a typed interface).',
-    '- Writing: existing files in `filePaths` (modify) and non-existent paths in `filePaths` (create). Files outside `filePaths` are off-limits to write unless the brief\'s task genuinely requires it (e.g. updating a caller because the task changed a signature — call this out in your summary).',
-    '- Out of scope: refactors not in the brief, tangential cleanup ("while I\'m here…"), modifying tests/fixtures/specs to mask a wrong implementation, opportunistic style fixes, dependency upgrades the brief did not request.',
+    '- Reading: the named `filePaths` plus what the task obviously implies (caller files when the diff changes a public symbol; sibling test files when the brief changes behavior; types files when the diff changes an interface).',
+    '- Writing: only files within `filePaths` unless the brief\'s task genuinely requires touching others (e.g. updating a caller because the task changed a signature — note in summary).',
+    '- Out of scope: refactors not in the brief, tangential cleanup, modifying tests to mask wrong code, opportunistic style fixes.',
 ].join('\n');
 /**
- * The failure-mode taxonomy for delegate.
- *
- * Workers calibrated on "implement something good" tend to over-deliver
- * (scope creep) or under-deliver (silent partial fix). The 9 categories
- * below are the specific patterns reviewers raise as merge-blockers.
+ * Top-4 failure modes — calibrated from observed reviewer rejections.
+ * Dropped from the original 9: WRONG FILE TARGET (subsumed by scope
+ * rule), CROSS-CUTTING DAMAGE, CONVENTION DRIFT, SPEC OVERREACH,
+ * UNDOCUMENTED ASSUMPTION (low signal, high noise for cheap models).
  */
 export const DELEGATE_FAILURE_MODES = [
-    'Patterns to consciously check for. Apply on EVERY delegated task:',
-    '',
-    '1. SCOPE CREEP — touched files / added features beyond the brief. The reviewer reads the diff and asks "why did you also change Y?" If you cannot answer with "the brief required it", remove the change.',
-    '2. SILENT PARTIAL FIX — declared done, work demonstrably incomplete. Naming a step in your summary as "done" when the diff does not contain it is the worst delegate failure mode. Either implement it or report explicitly that you did not.',
-    '3. WRONG FILE TARGET — wrote to a path not in `filePaths` (when the caller specified `filePaths`). Existing files outside `filePaths` are off-limits to write. New files outside `filePaths` are scope creep.',
-    '4. PHANTOM TEST PASS — claimed "tests pass" without actually running them, OR ran a non-affected suite (e.g. unit tests pass but the change is in a path covered by integration tests). If the brief includes `verifyCommand`, run that exact command and quote the output.',
-    '5. CROSS-CUTTING DAMAGE — your fix introduced an unrelated regression in the same edit (e.g. fixing a parser bug but breaking the formatter). Re-read the diff before declaring done; check that nothing OTHER than the brief\'s target changed semantically.',
-    '6. CONVENTION DRIFT — invented a naming / import / error-handling / formatting pattern instead of matching the surrounding code. The reviewer will flag this as "matches no neighboring file" — it slows merge.',
-    '7. INCOMPLETE REFACTOR — changed a public symbol (exported function signature, exported type, public method) and did not update its callers. Stale callers either crash at runtime or compile but behave wrong. Update callers in the named files; report in your summary if callers exist outside `filePaths`.',
-    '8. SPEC OVERREACH — modified tests, fixtures, or interface contracts to make a wrong implementation pass, instead of fixing the implementation. If a test is failing, the FIRST hypothesis is that the implementation is wrong, not the test.',
-    '9. UNDOCUMENTED ASSUMPTION — diff relies on the caller doing X (env var set, init function called, dependency installed) without saying so in the brief\'s authoring contract. Either remove the assumption, or document it in your summary so the reviewer can decide if it is acceptable.',
+    'The four ways delegation diverges from intent — check yourself against each before declaring done:',
     '',
-    'Severity calibration for delegate (in your summary, not via SEVERITY_LADDER which is for read-only tools):',
-    '- Issues you notice but do NOT fix: report in summary so the reviewer can decide.',
-    '- Issues you encounter that block the brief: report and stop. Do not pick a workaround unilaterally.',
-    '- Issues clearly implied by the brief but not literally stated (e.g. "fix bug" implies "regression test added"): implement and name them as "implicit per the brief" in summary.',
+    '1. SCOPE CREEP — touched files / added features beyond the brief. For every diff hunk, ask: "is this required by a brief item?" If no, remove it.',
+    '2. SILENT PARTIAL FIX — declared done with the work demonstrably incomplete. Naming a step as "done" when the diff doesn\'t contain it is the worst delegate failure. Either implement it or report explicitly that you did not.',
+    '3. PHANTOM TEST PASS — claimed "tests pass" without actually running them. If `verifyCommand` is set, run that exact command and quote the output. Otherwise run the focused test for the area you changed.',
+    '4. INCOMPLETE REFACTOR — changed a public symbol and did not update callers. Stale callers either crash at runtime or compile-but-misbehave. Update callers in the named files; report any callers outside `filePaths` in your summary.',
 ].join('\n');
 /**
- * Completeness reminder.
- *
- * The shared SEVERITY_LADDER does not apply to write tools. The
- * counter-balance for delegate is opposite to read-only tools: the
- * typical failure is OVER-IMPLEMENTATION (scope creep) and UNDER-
- * IMPLEMENTATION (silent partial fix), often in the same task. This
- * block tells the worker the load-bearing constraint is "minimal AND
- * complete simultaneously".
+ * Completeness reminder — brief-vs-diff walk only. Worked example
+ * dropped (cheap models can apply the rule directly without it).
  */
 export const COMPLETENESS_REMINDER_DELEGATE = [
-    'Completeness reminder:',
-    '- "Smallest complete change" is the bar. Smallest = no extras. Complete = no gaps.',
-    '- Most workers on first pass either bloat (extra refactor / extra cleanup / extra abstraction) or skim (declared done with the regression test missing). Both are merge-blockers; aim for the intersection.',
-    '- Before declaring done, walk the brief literally:',
-    '    1. List every requirement in the prompt (and `done` if present).',
-    '    2. For each, ask: "is this in my diff?" If no, you are not done.',
-    '    3. Walk the diff in reverse: for each changed file/line, ask: "is this required by a brief item?" If no, remove it.',
-    '    4. If `verifyCommand` is set, run it. Quote the relevant output line in your summary.',
+    'Brief-vs-diff walk (REQUIRED before declaring done):',
+    '',
+    'Walk the brief literally:',
+    '  1. List every requirement in `prompt` (and `done` if present).',
+    '  2. For each, locate the diff hunk that satisfies it. If you cannot, you are not done.',
+    '  3. Walk the diff in reverse: for each changed file/line, name the brief item it satisfies. If you cannot, the hunk is SCOPE CREEP — remove it.',
+    '  4. If `verifyCommand` is set, run it. Quote the relevant output line in your summary.',
+    '',
+    '"Smallest" means no extras. "Complete" means no gaps. Both at once.',
+].join('\n');
+/**
+ * Turn budget — calibration block. Same rationale as execute-plan's:
+ * cheap models default to "be thorough" and treat each turn as
+ * "re-verify by re-reading", which becomes a discovery loop. This
+ * block tells them to trust prior reads and edit confidently.
+ */
+export const TURN_BUDGET_DELEGATE = [
+    'Turn budget:',
+    '',
+    'A typical delegate task completes in 5-15 tool calls total: read each file once, edit each file once, run verification once. If you find yourself reading the same file twice, STOP and edit — the content from your first read is in your context window. If you find yourself reading >5 files without writing any, STOP and write — you have enough context to make progress.',
     '',
-    'Brief-vs-diff walk (REQUIRED on every task):',
-    '- For each item in the brief\'s `prompt` and `done`, locate the diff hunk that satisfies it. If you cannot, the item is unsatisfied.',
-    '- For each diff hunk, name the brief item it satisfies. If you cannot, the hunk is scope creep.',
-    '- Worked example. Brief: "fix the off-by-one in `paginate(page, total)` — `total < pageSize` should still produce one page; add a regression test in `tests/pagination.test.ts`." Naive worker rewrites `paginate` as a clean three-liner with new docstrings, skips the test → SILENT PARTIAL FIX (no test) + SCOPE CREEP (rewrote a function that needed a one-line fix). Correct worker: changes one boundary condition in `paginate` (one line of diff in the implementation file), adds one test in `tests/pagination.test.ts` covering the `total < pageSize` case, runs `verifyCommand` if set, quotes the test name and "1 passed" in the summary, stops. Two diff hunks total, both directly tied to the brief.',
-    '- Most workers miss findings of this shape on first pass because the rewrite "feels cleaner". The brief-vs-diff walk forces the question "what did the brief ACTUALLY ask for?".',
+    'Trust your prior reads. Trust your prior edits. The most common cheap-worker failure is restart-looping instead of editing.',
 ].join('\n');
 //# sourceMappingURL=implementer-criteria.js.map

package/dist/tools/delegate/implementer-criteria.js.map

@@ -1 +1 @@
-{"version":3,"file":"implementer-criteria.js","sourceRoot":"","sources":["../../../src/tools/delegate/implementer-criteria.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAEH;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,4BAA4B,GAAG;IAC1C,6BAA6B;IAC7B,oRAAoR;IACpR,EAAE;IACF,oCAAoC;IACpC,qGAAqG;IACrG,uVAAuV;IACvV,sIAAsI;IACtI,mJAAmJ;IACnJ,yLAAyL;IACzL,sLAAsL;IACtL,6LAA6L;IAC7L,EAAE;IACF,0NAA0N;CAC3N,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;GAKG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAG;IACjC,QAAQ;IACR,oGAAoG;IACpG,sOAAsO;IACtO,mSAAmS;IACnS,+NAA+N;CAChO,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,sBAAsB,GAAG;IACpC,mEAAmE;IACnE,EAAE;IACF,2MAA2M;IAC3M,+OAA+O;IAC/O,+MAA+M;IAC/M,6QAA6Q;IAC7Q,+PAA+P;IAC/P,iNAAiN;IACjN,iTAAiT;IACjT,+OAA+O;IAC/O,6RAA6R;IAC7R,EAAE;IACF,4GAA4G;IAC5G,mFAAmF;IACnF,sGAAsG;IACtG,kLAAkL;CACnL,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;;;;;GASG;AACH,MAAM,CAAC,MAAM,8BAA8B,GAAG;IAC5C,wBAAwB;IACxB,oFAAoF;IACpF,6MAA6M;IAC7M,oDAAoD;IACpD,sEAAsE;IACtE,sEAAsE;IACtE,yHAAyH;IACzH,2FAA2F;IAC3F,EAAE;IACF,8CAA8C;IAC9C,sIAAsI;IACtI,iGAAiG;IACjG,0rBAA0rB;IAC1rB,kLAAkL;CACnL,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC"}
+{"version":3,"file":"implementer-criteria.js","sourceRoot":"","sources":["../../../src/tools/delegate/implementer-criteria.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;GAoBG;AAEH;;GAEG;AACH,MAAM,CAAC,MAAM,4BAA4B,GAAG;IAC1C,gHAAgH;IAChH,+MAA+M;IAC/M,EAAE;IACF,QAAQ;IACR,kEAAkE;IAClE,gRAAgR;IAChR,kFAAkF;IAClF,2HAA2H;IAC3H,2KAA2K;IAC3K,iHAAiH;CAClH,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,mBAAmB,GAAG;IACjC,QAAQ;IACR,oGAAoG;IACpG,iOAAiO;IACjO,uLAAuL;IACvL,gIAAgI;CACjI,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;GAKG;AACH,MAAM,CAAC,MAAM,sBAAsB,GAAG;IACpC,oGAAoG;IACpG,EAAE;IACF,mJAAmJ;IACnJ,kOAAkO;IAClO,6MAA6M;IAC7M,yOAAyO;CAC1O,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;GAGG;AACH,MAAM,CAAC,MAAM,8BAA8B,GAAG;IAC5C,sDAAsD;IACtD,EAAE;IACF,2BAA2B;IAC3B,kEAAkE;IAClE,yFAAyF;IACzF,kJAAkJ;IAClJ,yFAAyF;IACzF,EAAE;IACF,qEAAqE;CACtE,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;GAKG;AACH,MAAM,CAAC,MAAM,oBAAoB,GAAG;IAClC,cAAc;IACd,EAAE;IACF,kXAAkX;IAClX,EAAE;IACF,6HAA6H;CAC9H,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC"}

package/dist/tools/delegate/tool-config.js

@@ -2,7 +2,7 @@ import { inputSchema } from './schema.js';
 import { delegateHeadlineTemplate } from '../../reporting/headline-templates/delegate.js';
 import { delegateReportSchema } from '../../reporting/report-parser-slots/delegate-report.js';
 import { compileDelegatePrompt } from '../../intake/brief-compiler-slots/delegate.js';
-import { specTemplate, qualityAPTemplate, diffTemplate } from '../../review/reviewer-engine.js';
+import { specLintTemplate, qualityLintTemplate } from '../../review/reviewer-engine.js';
 import { DEFAULT_TASK_TIMEOUT_MS } from '../../config/schema.js';
 export function registerDelegate(registry) {
     registry.register({
@@ -48,9 +48,9 @@ export const toolConfig = {
     reportSchema: delegateReportSchema,
     headlineTemplate: delegateHeadlineTemplate,
     reviewTemplates: {
-        spec: specTemplate,
-        qualityAP: qualityAPTemplate,
-        diff: diffTemplate,
+        spec: specLintTemplate,
+        qualityAP: qualityLintTemplate,
+        diff: specLintTemplate, // pipeline-redesign: diff path unused; field retained for type compat
     },
 };
 //# sourceMappingURL=tool-config.js.map

package/dist/tools/delegate/tool-config.js.map

@@ -1 +1 @@
-{"version":3,"file":"tool-config.js","sourceRoot":"","sources":["../../../src/tools/delegate/tool-config.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC;AAG1C,OAAO,EAAE,wBAAwB,EAAE,MAAM,gDAAgD,CAAC;AAC1F,OAAO,EAAE,oBAAoB,EAAE,MAAM,wDAAwD,CAAC;AAC9F,OAAO,EAAE,qBAAqB,EAAE,MAAM,+CAA+C,CAAC;AAEtF,OAAO,EAAE,YAAY,EAAE,iBAAiB,EAAE,YAAY,EAAE,MAAM,iCAAiC,CAAC;AAChG,OAAO,EAAE,uBAAuB,EAAE,MAAM,wBAAwB,CAAC;AAEjE,MAAM,UAAU,gBAAgB,CAAC,QAA6B;IAC5D,QAAQ,CAAC,QAAQ,CAAC;QAChB,SAAS,EAAE,UAAU;QACrB,UAAU,EAAE,MAAM;QAClB,QAAQ,EAAE,WAAW;QACrB,OAAO,EAAE,MAAM;QACf,MAAM,EAAE,WAAW;QACnB,YAAY,EAAE,oBAAoB;QAClC,gBAAgB,EAAE,UAAU;QAC5B,oBAAoB,EAAE,IAAI;QAC1B,iBAAiB,EAAE,eAAe;KACnC,CAAC,CAAC;AACL,CAAC;AAaD,MAAM,CAAC,MAAM,UAAU,GAA8C;IACnE,IAAI,EAAE,UAAU;IAChB,QAAQ,EAAE,oBAAoB;IAC9B,SAAS,EAAE,UAAU;IACrB,SAAS,EAAE,CAAC,KAAK,EAAE,EAAE,CACnB,KAAK,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;QACtB,MAAM,EAAE,qBAAqB,CAAC,EAAE,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC;QACnD,IAAI,EAAE,CAAC,CAAC,IAAI;QACZ,SAAS,EAAE,CAAC,CAAC,SAAS;QACtB,SAAS,EAAE,CAAC,CAAC,SAAS,IAAI,UAAU;QACpC,YAAY,EAAE,CAAC,CAAC,YAAY,IAAI,MAAM;QACtC,eAAe,EAAE,CAAC,CAAC,eAAe;QAClC,aAAa,EAAE,CAAC,CAAC,aAAa;QAC9B,UAAU,EAAE,CAAC,CAAC,UAAU;KACzB,CAAC,CAAC;IACL,aAAa,EAAE,CAAC,KAAK,EAAE,GAAG,EAAE,EAAE,CAAC,CAAC;QAC9B,MAAM,EAAE,KAAK,CAAC,MAAM;QACpB,SAAS,EAAE,KAAK,CAAC,SAAS;QAC1B,YAAY,EAAE,KAAK,CAAC,YAAY;QAChC,IAAI,EAAE,KAAK,CAAC,IAAI;QAChB,SAAS,EAAE,KAAK,CAAC,SAAS;QAC1B,eAAe,EAAE,KAAK,CAAC,eAAe;QACtC,aAAa,EAAE,KAAK,CAAC,aAAa;QAClC,UAAU,EAAE,KAAK,CAAC,UAAU;QAC5B,GAAG,EAAE,GAAG,CAAC,cAAc,EAAE,GAAG,IAAI,GAAG,CAAC,GAAG;QACvC,KAAK,EAAE,GAAG,CAAC,MAAM,CAAC,QAAQ,EAAE,KAAK,IAAI,MAAM;QAC3C,SAAS,EAAE,GAAG,CAAC,MAAM,CAAC,QAAQ,EAAE,SAAS,IAAI,uBAAuB;QACpE,aAAa,EAAE,GAAG,CAAC,MAAM,CAAC,QAAQ,EAAE,aAAa,IAAI,UAAU;KAChE,CAAC;IACF,YAAY,EAAE,oBAAoB;IAClC,gBAAgB,EAAE,wBAAwB;IAC1C,eAAe,EAAE;QACf,IAAI,EAAE,YAAY;QAClB,SAAS,EAAE,iBAAiB;QAC5B,IAAI,EAAE,YAAY;KACnB;CACF,CAAC"}
+{"version":3,"file":"tool-config.js","sourceRoot":"","sources":["../../../src/tools/delegate/tool-config.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC;AAG1C,OAAO,EAAE,wBAAwB,EAAE,MAAM,gDAAgD,CAAC;AAC1F,OAAO,EAAE,oBAAoB,EAAE,MAAM,wDAAwD,CAAC;AAC9F,OAAO,EAAE,qBAAqB,EAAE,MAAM,+CAA+C,CAAC;AAEtF,OAAO,EAAE,gBAAgB,EAAE,mBAAmB,EAAE,MAAM,iCAAiC,CAAC;AACxF,OAAO,EAAE,uBAAuB,EAAE,MAAM,wBAAwB,CAAC;AAEjE,MAAM,UAAU,gBAAgB,CAAC,QAA6B;IAC5D,QAAQ,CAAC,QAAQ,CAAC;QAChB,SAAS,EAAE,UAAU;QACrB,UAAU,EAAE,MAAM;QAClB,QAAQ,EAAE,WAAW;QACrB,OAAO,EAAE,MAAM;QACf,MAAM,EAAE,WAAW;QACnB,YAAY,EAAE,oBAAoB;QAClC,gBAAgB,EAAE,UAAU;QAC5B,oBAAoB,EAAE,IAAI;QAC1B,iBAAiB,EAAE,eAAe;KACnC,CAAC,CAAC;AACL,CAAC;AAaD,MAAM,CAAC,MAAM,UAAU,GAA8C;IACnE,IAAI,EAAE,UAAU;IAChB,QAAQ,EAAE,oBAAoB;IAC9B,SAAS,EAAE,UAAU;IACrB,SAAS,EAAE,CAAC,KAAK,EAAE,EAAE,CACnB,KAAK,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;QACtB,MAAM,EAAE,qBAAqB,CAAC,EAAE,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC;QACnD,IAAI,EAAE,CAAC,CAAC,IAAI;QACZ,SAAS,EAAE,CAAC,CAAC,SAAS;QACtB,SAAS,EAAE,CAAC,CAAC,SAAS,IAAI,UAAU;QACpC,YAAY,EAAE,CAAC,CAAC,YAAY,IAAI,MAAM;QACtC,eAAe,EAAE,CAAC,CAAC,eAAe;QAClC,aAAa,EAAE,CAAC,CAAC,aAAa;QAC9B,UAAU,EAAE,CAAC,CAAC,UAAU;KACzB,CAAC,CAAC;IACL,aAAa,EAAE,CAAC,KAAK,EAAE,GAAG,EAAE,EAAE,CAAC,CAAC;QAC9B,MAAM,EAAE,KAAK,CAAC,MAAM;QACpB,SAAS,EAAE,KAAK,CAAC,SAAS;QAC1B,YAAY,EAAE,KAAK,CAAC,YAAY;QAChC,IAAI,EAAE,KAAK,CAAC,IAAI;QAChB,SAAS,EAAE,KAAK,CAAC,SAAS;QAC1B,eAAe,EAAE,KAAK,CAAC,eAAe;QACtC,aAAa,EAAE,KAAK,CAAC,aAAa;QAClC,UAAU,EAAE,KAAK,CAAC,UAAU;QAC5B,GAAG,EAAE,GAAG,CAAC,cAAc,EAAE,GAAG,IAAI,GAAG,CAAC,GAAG;QACvC,KAAK,EAAE,GAAG,CAAC,MAAM,CAAC,QAAQ,EAAE,KAAK,IAAI,MAAM;QAC3C,SAAS,EAAE,GAAG,CAAC,MAAM,CAAC,QAAQ,EAAE,SAAS,IAAI,uBAAuB;QACpE,aAAa,EAAE,GAAG,CAAC,MAAM,CAAC,QAAQ,EAAE,aAAa,IAAI,UAAU;KAChE,CAAC;IACF,YAAY,EAAE,oBAAoB;IAClC,gBAAgB,EAAE,wBAAwB;IAC1C,eAAe,EAAE;QACf,IAAI,EAAE,gBAAgB;QACtB,SAAS,EAAE,mBAAmB;QAC9B,IAAI,EAAE,gBAAgB,EAAG,sEAAsE;KAChG;CACF,CAAC"}

package/dist/tools/execute-plan/implementer-criteria.d.ts

@@ -1,52 +1,57 @@
 /**
- * Execute-plan-specific implementer criteria.
+ * Execute-plan worker criteria — 4.3.0 pipeline-redesign mindset.
  *
- * EXECUTE-PLAN'S PURPOSE — read this before adding categories.
- * mma-execute-plan implements one task from a plan that was written by a
- * higher-capability model. Your output is a diff the PLAN AUTHOR will
- * read. They wrote the plan precisely; your job is execution, not
- * improvement. The success criterion is:
+ * mma-execute-plan implements one named task from a plan written by a
+ * higher-capability model. The plan is the spec; your output is a diff.
  *
- *   "Could the plan author read your diff and say 'yes, that's exactly
- *    what I wrote' — not 'close, but you took liberties' or 'wrong, you
- *    missed step 3'?"
+ * Pipeline mindset (different from earlier versions):
+ * - This is a SINGLE-PASS pipeline. There are NO rework rounds for you.
+ * - After your turn, a SPEC reviewer (complex tier, full editor tools)
+ *   runs ONCE — it doesn't ask you to fix gaps; it fixes them inline
+ *   itself. Plan-fidelity gaps (CODE SUBSTITUTION, STEP SKIP) it can
+ *   detect, it can also fix.
+ * - Then a QUALITY reviewer (complex tier, full editor tools) runs
+ *   ONCE for safety / correctness — same thing.
+ * - Then an annotator scores completion based on the plan's steps.
+ *   Commit fires if completionPercent ≥ 80.
  *
- * That criterion is what makes a write load-bearing. The fidelity bar
- * is sharper than mma-delegate's: even a "better" implementation that
- * deviates from the plan is wrong here. If you think the plan is wrong:
- * REPORT IT and stop. Do NOT silently improve.
- *
- * Plan execution is artifact-producing — you write files. Cross-agent
- * spec + quality review still applies. But the spec the spec-reviewer
- * checks against is the PLAN, not your interpretation of it.
+ * What this means for you: do the mechanical task in ONE pass and
+ * report what you did. You don't need to anticipate every reviewer
+ * concern — they fix things, they don't ping-pong with you. Don't
+ * restart-loop, don't bail on uncertainty, don't over-verify. The
+ * pipeline has a safety net BUT only one round of it.
  */
 /**
- * The orientation block. Goes at the TOP of every execute-plan prompt.
- *
- * Without an explicit fidelity statement, workers default to "implement
- * the goal" — which produces "improvements" that diverge from the plan
- * (CODE SUBSTITUTION, ACCEPTANCE-CRITERIA OVERRUN). With this
- * orientation, the worker treats the plan as authoritative and reports
- * defects rather than silently working around them.
+ * Orientation — fidelity-first framing. Goes at the TOP of every
+ * execute-plan worker prompt.
  */
 export declare const EXECUTE_PLAN_PURPOSE_ORIENTATION: string;
 export declare const EXECUTE_PLAN_SCOPE_RULE: string;
 /**
- * The failure-mode taxonomy for execute-plan.
- *
- * Workers calibrated on "implement the goal" tend to make "small
- * improvements" to plans they think are imperfect. The 9 categories
- * below are the specific ways execution diverges from intent.
+ * Top-4 failure modes — calibrated from observed worker output, not
+ * speculative. The full taxonomy of 9 was dropped to reduce cognitive
+ * load on cheap models.
  */
 export declare const EXECUTE_PLAN_FAILURE_MODES: string;
 /**
- * Plan-fidelity reminder.
- *
- * The shared SEVERITY_LADDER does not apply to write tools. The
- * counter-balance for execute-plan is opposite to read-only tools:
- * the typical failure is OVER-IMPLEMENTATION (improving the plan), not
- * under-finding. This block tells the worker the load-bearing
- * constraint is fidelity, not "good code".
+ * Plan-vs-source reconciliation — handles the case where the plan names
+ * a symbol/path that doesn't exist in source (because the plan was
+ * authored against an older snapshot). Without this rule, workers either
+ * invent the missing symbol (introducing real bugs) or freeze and bail.
+ */
+export declare const PLAN_VS_SOURCE_RECONCILIATION: string;
+/**
+ * Self-verification — workers must run the plan-listed verification
+ * commands themselves before declaring done. Reviewers do not execute
+ * code; the worker has shell access and is the source of truth for
+ * "do these tests pass?".
+ */
+export declare const SELF_VERIFICATION: string;
+/**
+ * Turn budget — calibration block. Cheap models default to "be
+ * thorough" and treat each turn as "let me re-verify state by
+ * re-reading", which becomes a discovery loop. This block tells them
+ * to trust their prior reads and edit confidently.
  */
-export declare const PLAN_FIDELITY_REMINDER: string;
+export declare const TURN_BUDGET: string;
 //# sourceMappingURL=implementer-criteria.d.ts.map

package/dist/tools/execute-plan/implementer-criteria.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"implementer-criteria.d.ts","sourceRoot":"","sources":["../../../src/tools/execute-plan/implementer-criteria.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;GAqBG;AAEH;;;;;;;;GAQG;AACH,eAAO,MAAM,gCAAgC,QAiBjC,CAAC;AAEb,eAAO,MAAM,uBAAuB,QAMxB,CAAC;AAEb;;;;;;GAMG;AACH,eAAO,MAAM,0BAA0B,QAiB3B,CAAC;AAEb;;;;;;;;GAQG;AACH,eAAO,MAAM,sBAAsB,QAYvB,CAAC"}
+{"version":3,"file":"implementer-criteria.d.ts","sourceRoot":"","sources":["../../../src/tools/execute-plan/implementer-criteria.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH;;;GAGG;AACH,eAAO,MAAM,gCAAgC,QAUjC,CAAC;AAEb,eAAO,MAAM,uBAAuB,QAKxB,CAAC;AAEb;;;;GAIG;AACH,eAAO,MAAM,0BAA0B,QAO3B,CAAC;AAEb;;;;;GAKG;AACH,eAAO,MAAM,6BAA6B,QAU9B,CAAC;AAEb;;;;;GAKG;AACH,eAAO,MAAM,iBAAiB,QASlB,CAAC;AAEb;;;;;GAKG;AACH,eAAO,MAAM,WAAW,QAMZ,CAAC"}

package/dist/tools/execute-plan/implementer-criteria.js

@@ -1,104 +1,104 @@
 /**
- * Execute-plan-specific implementer criteria.
+ * Execute-plan worker criteria — 4.3.0 pipeline-redesign mindset.
  *
- * EXECUTE-PLAN'S PURPOSE — read this before adding categories.
- * mma-execute-plan implements one task from a plan that was written by a
- * higher-capability model. Your output is a diff the PLAN AUTHOR will
- * read. They wrote the plan precisely; your job is execution, not
- * improvement. The success criterion is:
+ * mma-execute-plan implements one named task from a plan written by a
+ * higher-capability model. The plan is the spec; your output is a diff.
  *
- *   "Could the plan author read your diff and say 'yes, that's exactly
- *    what I wrote' — not 'close, but you took liberties' or 'wrong, you
- *    missed step 3'?"
+ * Pipeline mindset (different from earlier versions):
+ * - This is a SINGLE-PASS pipeline. There are NO rework rounds for you.
+ * - After your turn, a SPEC reviewer (complex tier, full editor tools)
+ *   runs ONCE — it doesn't ask you to fix gaps; it fixes them inline
+ *   itself. Plan-fidelity gaps (CODE SUBSTITUTION, STEP SKIP) it can
+ *   detect, it can also fix.
+ * - Then a QUALITY reviewer (complex tier, full editor tools) runs
+ *   ONCE for safety / correctness — same thing.
+ * - Then an annotator scores completion based on the plan's steps.
+ *   Commit fires if completionPercent ≥ 80.
  *
- * That criterion is what makes a write load-bearing. The fidelity bar
- * is sharper than mma-delegate's: even a "better" implementation that
- * deviates from the plan is wrong here. If you think the plan is wrong:
- * REPORT IT and stop. Do NOT silently improve.
- *
- * Plan execution is artifact-producing — you write files. Cross-agent
- * spec + quality review still applies. But the spec the spec-reviewer
- * checks against is the PLAN, not your interpretation of it.
+ * What this means for you: do the mechanical task in ONE pass and
+ * report what you did. You don't need to anticipate every reviewer
+ * concern — they fix things, they don't ping-pong with you. Don't
+ * restart-loop, don't bail on uncertainty, don't over-verify. The
+ * pipeline has a safety net BUT only one round of it.
  */
 /**
- * The orientation block. Goes at the TOP of every execute-plan prompt.
- *
- * Without an explicit fidelity statement, workers default to "implement
- * the goal" — which produces "improvements" that diverge from the plan
- * (CODE SUBSTITUTION, ACCEPTANCE-CRITERIA OVERRUN). With this
- * orientation, the worker treats the plan as authoritative and reports
- * defects rather than silently working around them.
+ * Orientation — fidelity-first framing. Goes at the TOP of every
+ * execute-plan worker prompt.
  */
 export const EXECUTE_PLAN_PURPOSE_ORIENTATION = [
-    'Why this execution exists:',
-    'mma-execute-plan executes ONE task from a plan written by a higher-capability model. Your output is a diff the PLAN AUTHOR will read. They wrote the plan precisely. Your job is execution, not improvement.',
-    '',
-    'The completion test: would the plan author, reading your diff, say "yes, that\'s exactly what I wrote" — or would they say "close, but you took liberties" / "wrong, you missed step 3"?',
+    'You are the mechanical executor of one task from a plan written by a higher-capability model.',
+    'Your job: implement the task EXACTLY as the plan specifies. Not improve it. Not redesign it.',
     '',
-    'Fidelity rules — these override your usual instincts:',
-    '- Follow the plan EXACTLY as written. If the plan provides code blocks, use them VERBATIM (same names, same signatures, same comments, same imports).',
-    '- Do NOT redesign. Do NOT substitute your own approach. Do NOT improve names you find unidiomatic.',
-    '- Do NOT add steps the plan does not list. Do NOT skip steps the plan does list.',
-    '- Do NOT widen scope ("while I\'m here…"). Touch only what this task heading authorizes; another task probably owns the rest.',
-    '- If the plan looks wrong (typo, contradiction, undefined symbol, missing dependency): REPORT IT in your summary and stop. Do NOT silently work around it. Do NOT silently fix it.',
-    '- The plan was written by a higher-capability model than you. Your judgment about "what would be cleaner" is not load-bearing here; the plan is.',
+    'Completion test: would the plan author, reading your diff, say "yes, that\'s exactly what I wrote" — or "close, but you took liberties / missed step 3"?',
     '',
-    'Reviewer awareness for plan execution:',
-    '- The spec-reviewer compares your diff against the PLAN section, not against general "good code" heuristics. A diff that improves on the plan will fail spec review.',
-    '- The quality-reviewer checks safety/correctness without overriding the plan. If the plan is genuinely unsafe, that surfaces as a quality concern that the caller resolves — not as your unilateral fix.',
+    'Three rules that override your usual coding instincts:',
+    '- Code blocks the plan provides are VERBATIM contracts. Copy them character-for-character (same names, signatures, comments, control flow). Do not rename, do not reformat, do not "simplify".',
+    '- Steps the plan lists are REQUIRED unless explicitly marked optional. Do not skip, do not reorder, do not add steps the plan does not list.',
+    '- Files outside the task\'s authorized scope are off-limits. Other tasks own other files; touching them creates merge conflicts.',
 ].join('\n');
 export const EXECUTE_PLAN_SCOPE_RULE = [
     'Scope:',
-    '- Strictly the task the descriptor names. Other tasks in the plan have other workers; do not implement them on the side.',
-    '- Touch only the files the named task authorizes (explicit file paths in the plan section, or files clearly implied by the named task).',
-    '- Out of scope: other plan tasks; refactors not in the plan; "while I\'m here" cleanup; renaming code blocks the plan provided verbatim.',
-    '- Genuinely necessary cross-cutting work (e.g. updating a caller because the plan changed a signature): allowed when the plan implies it. When in doubt, REPORT it as part of your summary and let the caller decide.',
+    '- Strictly the task the descriptor names. Other tasks have other workers.',
+    '- Touch only files the named task authorizes (explicit file paths in the plan section, or files clearly implied).',
+    '- No "while I\'m here" cleanup, no refactors not in the plan, no renaming code blocks the plan provided verbatim.',
 ].join('\n');
 /**
- * The failure-mode taxonomy for execute-plan.
- *
- * Workers calibrated on "implement the goal" tend to make "small
- * improvements" to plans they think are imperfect. The 9 categories
- * below are the specific ways execution diverges from intent.
+ * Top-4 failure modes — calibrated from observed worker output, not
+ * speculative. The full taxonomy of 9 was dropped to reduce cognitive
+ * load on cheap models.
  */
 export const EXECUTE_PLAN_FAILURE_MODES = [
-    'Patterns to consciously check for. Apply on EVERY plan execution:',
+    'The four ways execution diverges from intent — check yourself against each before declaring done:',
+    '',
+    '1. CODE SUBSTITUTION — the plan provided a code block; you wrote different code that "does the same thing". The plan\'s code is the contract — copy it verbatim. Even renaming an identifier or removing a comment is substitution.',
+    '2. STEP SKIP — the plan listed multiple steps; you did some and silently omitted others. Every step is a required deliverable unless marked optional.',
+    '3. PLAN REWRITE — you decided the plan was suboptimal and improved it. The plan author treats the plan as the contract; your improvements are a contract violation.',
+    '4. PROBLEM-NOT-FLAGGED — you noticed a defect in the plan (typo, undefined symbol, broken example) and silently worked around it. Defects must be reported in your summary so the caller can correct the plan.',
+].join('\n');
+/**
+ * Plan-vs-source reconciliation — handles the case where the plan names
+ * a symbol/path that doesn't exist in source (because the plan was
+ * authored against an older snapshot). Without this rule, workers either
+ * invent the missing symbol (introducing real bugs) or freeze and bail.
+ */
+export const PLAN_VS_SOURCE_RECONCILIATION = [
+    'Plan-vs-source reconciliation:',
+    '',
+    'When the plan names a symbol/path/import that grep against the named source files returns ZERO matches for, AND source has a single obvious near-match (same kind of symbol, Levenshtein 1-5):',
     '',
-    '1. PLAN REWRITE — you decided the plan was suboptimal and "improved" it. This is the worst execute-plan failure mode. The plan author treats the plan as the contract; your improvements are a contract violation.',
-    '2. STEP SKIP — the plan section lists multiple steps; you implemented some and silently omitted others. Every step listed in the plan is a required deliverable unless the plan explicitly marks it optional.',
-    '3. STEP REORDER — you executed plan steps in a different order than the plan specifies. Order may be load-bearing (later steps may depend on earlier ones); preserve it.',
-    '4. CODE SUBSTITUTION — the plan provided a code block (function body, import line, type definition) and you wrote DIFFERENT code that "does the same thing". The plan\'s code is verbatim; copy it. Renaming, reformatting, or replacing with idiomatic equivalents is substitution.',
-    '5. ACCEPTANCE-CRITERIA OVERRUN — the plan listed criteria A and B; you also delivered C ("seemed natural"). Adding extras the plan did not list is scope creep — even if C is technically good code.',
-    '6. ACCEPTANCE-CRITERIA UNDERRUN — the plan implies sub-criteria (e.g. "add the function" implies "add the export to the index file"; "fix the bug" implies "add a regression test"). Missing implicit sub-criteria is the most common silent-partial-fix in plan execution.',
-    '7. WRONG-TASK MATCH — you matched a different plan section than the descriptor names (e.g. matched "Step 4: foo" when descriptor said "Step 4: bar"). The descriptor must match the plan heading verbatim; if no unique match exists, report that and stop.',
-    '8. CROSS-TASK CONTAMINATION — you touched files the named task does not authorize, on the assumption that another task in the plan will eventually need them. Other tasks have other workers; touching their files creates merge conflicts and ownership ambiguity.',
-    '9. PROBLEM-NOT-FLAGGED — you noticed a defect in the plan (typo, contradiction, undefined symbol, broken example) and silently worked around it. The defect must be reported in your summary so the caller can correct the plan; silent workarounds make the next plan execution harder.',
+    '1. Use the actual source symbol, not the plan\'s.',
+    '2. Add a "Reconciliations" section to your final summary listing each: "Plan said X; source has Y; used Y."',
+    '3. Continue the rest of the task. Do NOT bail on "plan defect detected".',
     '',
-    'Severity calibration for plan execution (in your summary, not via SEVERITY_LADDER which is for read-only tools):',
-    '- Plan defects you notice: ALWAYS report. The caller may have a fix or may want to update the plan first.',
-    '- Sub-criteria you cannot satisfy without deviating from the plan: report and stop. Do not pick a workaround unilaterally.',
-    '- Sub-criteria that are clearly implied but not literally stated: implement them, name them in your summary as "implicit per the task heading".',
+    'Reconciliation is NOT improvement. If the plan\'s symbol DOES exist in source and you chose a different one because it felt cleaner, that\'s CODE SUBSTITUTION (forbidden). Reconciliation is only for the genuine doesn\'t-exist-AND-near-match-exists case. If multiple plausible matches or no near-match: report and stop.',
 ].join('\n');
 /**
- * Plan-fidelity reminder.
- *
- * The shared SEVERITY_LADDER does not apply to write tools. The
- * counter-balance for execute-plan is opposite to read-only tools:
- * the typical failure is OVER-IMPLEMENTATION (improving the plan), not
- * under-finding. This block tells the worker the load-bearing
- * constraint is fidelity, not "good code".
+ * Self-verification — workers must run the plan-listed verification
+ * commands themselves before declaring done. Reviewers do not execute
+ * code; the worker has shell access and is the source of truth for
+ * "do these tests pass?".
+ */
+export const SELF_VERIFICATION = [
+    'Self-verification before declaring done:',
+    '',
+    'Scan the plan section for verification commands ("Run: <cmd>", "Expected: PASS", a code block under "Verify"). Execute each via your shell tool BEFORE writing your final summary. Include in your summary:',
+    '',
+    '  Self-verification:',
+    '  - $ <command>  PASS / FAIL (<N> tests)',
+    '',
+    'If any command FAILS: do NOT declare "done". Investigate, fix, re-run. A failing test is your output, not the reviewer\'s problem. If you cannot run a command (shell unavailable, dependency missing): say so explicitly AND treat the task as incomplete.',
+].join('\n');
+/**
+ * Turn budget — calibration block. Cheap models default to "be
+ * thorough" and treat each turn as "let me re-verify state by
+ * re-reading", which becomes a discovery loop. This block tells them
+ * to trust their prior reads and edit confidently.
  */
-export const PLAN_FIDELITY_REMINDER = [
-    'Plan-fidelity reminder:',
-    '- Your judgment about "what would be cleaner" is NOT load-bearing here. The plan is.',
-    '- Every deviation from the plan needs a reason and a report. Silent deviations are the most common defect.',
-    '- "Smallest faithful change" — touch the minimum the task authorizes, in the order the plan specifies, with the code the plan provides verbatim where provided.',
-    '- If the plan is wrong: report and stop. Do NOT silently fix the plan.',
+export const TURN_BUDGET = [
+    'Turn budget:',
+    '',
+    'A typical plan task completes in 5-15 tool calls total: read each file once, edit each file once, run verification once. If you find yourself reading the same file twice, STOP and edit — the content from your first read is in your context window. If you find yourself reading >5 files without writing any, STOP and write — you have enough context to make progress.',
     '',
-    'Code-block faithfulness walk (REQUIRED on every task that includes plan-provided code):',
-    '- For each code block in the matched plan section, ask: did I copy this verbatim? Same names, same signatures, same comments, same imports?',
-    '- If no — what did I change? Why? Is the change required by the task or am I improving?',
-    '- Worked example. A plan section says: "Step 2: create `src/parser.ts` with content (verbatim): `export function parse(input: string): Token[] { ... }`". Naive worker writes `src/parser.ts` exporting `parseTokens` (renamed for clarity) with JSDoc added. Result: CODE SUBSTITUTION + ACCEPTANCE-CRITERIA OVERRUN. The downstream code that imports `parse` now breaks; the plan author reads the diff and says "I wrote `parse`, why is this `parseTokens`?". Correct worker creates `src/parser.ts` with exactly the named export `parse`, no JSDoc additions, no rename. If JSDoc would be valuable, mention it in the summary as a follow-up rather than adding it here.',
-    '- Most workers miss findings of this shape on first pass because the renamed/reformatted version "feels right" and they trust their instincts. The faithfulness walk forces the verbatim check.',
+    'Trust your prior reads. Trust your prior edits. The most common cheap-worker failure is restart-looping ("let me re-read both files first" repeated 50 times) instead of editing.',
 ].join('\n');
 //# sourceMappingURL=implementer-criteria.js.map

package/dist/tools/execute-plan/implementer-criteria.js.map

@@ -1 +1 @@
-{"version":3,"file":"implementer-criteria.js","sourceRoot":"","sources":["../../../src/tools/execute-plan/implementer-criteria.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;GAqBG;AAEH;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,gCAAgC,GAAG;IAC9C,4BAA4B;IAC5B,8MAA8M;IAC9M,EAAE;IACF,0LAA0L;IAC1L,EAAE;IACF,uDAAuD;IACvD,uJAAuJ;IACvJ,oGAAoG;IACpG,kFAAkF;IAClF,+HAA+H;IAC/H,oLAAoL;IACpL,kJAAkJ;IAClJ,EAAE;IACF,wCAAwC;IACxC,sKAAsK;IACtK,0MAA0M;CAC3M,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACrC,QAAQ;IACR,0HAA0H;IAC1H,yIAAyI;IACzI,0IAA0I;IAC1I,uNAAuN;CACxN,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,0BAA0B,GAAG;IACxC,mEAAmE;IACnE,EAAE;IACF,oNAAoN;IACpN,+MAA+M;IAC/M,0KAA0K;IAC1K,sRAAsR;IACtR,sMAAsM;IACtM,6QAA6Q;IAC7Q,6PAA6P;IAC7P,qQAAqQ;IACrQ,0RAA0R;IAC1R,EAAE;IACF,kHAAkH;IAClH,2GAA2G;IAC3G,4HAA4H;IAC5H,iJAAiJ;CAClJ,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,sBAAsB,GAAG;IACpC,yBAAyB;IACzB,sFAAsF;IACtF,4GAA4G;IAC5G,iKAAiK;IACjK,wEAAwE;IACxE,EAAE;IACF,yFAAyF;IACzF,6IAA6I;IAC7I,yFAAyF;IACzF,kpBAAkpB;IAClpB,iMAAiM;CAClM,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC"}
+{"version":3,"file":"implementer-criteria.js","sourceRoot":"","sources":["../../../src/tools/execute-plan/implementer-criteria.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AAEH;;;GAGG;AACH,MAAM,CAAC,MAAM,gCAAgC,GAAG;IAC9C,+FAA+F;IAC/F,8FAA8F;IAC9F,EAAE;IACF,0JAA0J;IAC1J,EAAE;IACF,wDAAwD;IACxD,gMAAgM;IAChM,8IAA8I;IAC9I,kIAAkI;CACnI,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACrC,QAAQ;IACR,2EAA2E;IAC3E,mHAAmH;IACnH,mHAAmH;CACpH,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;GAIG;AACH,MAAM,CAAC,MAAM,0BAA0B,GAAG;IACxC,mGAAmG;IACnG,EAAE;IACF,qOAAqO;IACrO,uJAAuJ;IACvJ,qKAAqK;IACrK,gNAAgN;CACjN,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;GAKG;AACH,MAAM,CAAC,MAAM,6BAA6B,GAAG;IAC3C,gCAAgC;IAChC,EAAE;IACF,gMAAgM;IAChM,EAAE;IACF,mDAAmD;IACnD,6GAA6G;IAC7G,0EAA0E;IAC1E,EAAE;IACF,gUAAgU;CACjU,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;GAKG;AACH,MAAM,CAAC,MAAM,iBAAiB,GAAG;IAC/B,0CAA0C;IAC1C,EAAE;IACF,6MAA6M;IAC7M,EAAE;IACF,sBAAsB;IACtB,0CAA0C;IAC1C,EAAE;IACF,6PAA6P;CAC9P,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;GAKG;AACH,MAAM,CAAC,MAAM,WAAW,GAAG;IACzB,cAAc;IACd,EAAE;IACF,8WAA8W;IAC9W,EAAE;IACF,mLAAmL;CACpL,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC"}

package/dist/tools/execute-plan/tool-config.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"tool-config.d.ts","sourceRoot":"","sources":["../../../src/tools/execute-plan/tool-config.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,mBAAmB,EAAE,MAAM,6CAA6C,CAAC;AAMlF,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,sCAAsC,CAAC;AACvE,OAAO,EAA4B,KAAK,oBAAoB,EAAE,MAAM,mDAAmD,CAAC;AAYxH,eAAO,MAAM,sBAAsB;;;;;;;;;;;;kBAOxB,CAAC;AAEZ,MAAM,MAAM,oBAAoB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AAE1E,wBAAgB,mBAAmB,CAAC,QAAQ,EAAE,mBAAmB,GAAG,IAAI,CAYvE;AA6DD,eAAO,MAAM,UAAU,EAAE,UAAU,CAAC,oBAAoB,EAAE,oBAAoB,CA4B7E,CAAC"}
+{"version":3,"file":"tool-config.d.ts","sourceRoot":"","sources":["../../../src/tools/execute-plan/tool-config.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,mBAAmB,EAAE,MAAM,6CAA6C,CAAC;AAKlF,OAAO,KAAK,EAAE,UAAU,EAAE,MAAM,sCAAsC,CAAC;AACvE,OAAO,EAA4B,KAAK,oBAAoB,EAAE,MAAM,mDAAmD,CAAC;AAaxH,eAAO,MAAM,sBAAsB;;;;;;;;;;;;kBAOxB,CAAC;AAEZ,MAAM,MAAM,oBAAoB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,sBAAsB,CAAC,CAAC;AAE1E,wBAAgB,mBAAmB,CAAC,QAAQ,EAAE,mBAAmB,GAAG,IAAI,CAYvE;AAgFD,eAAO,MAAM,UAAU,EAAE,UAAU,CAAC,oBAAoB,EAAE,oBAAoB,CA4B7E,CAAC"}