@zhixuan92/multi-model-agent-core 5.1.0 → 5.2.0

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

@@ -1,121 +0,0 @@
-/**
- * Audit-specific implementer criteria.
- *
- * AUDIT'S PURPOSE — read this before adding categories.
- * Most audit targets are spec / plan / design / recommendation files that
- * will subsequently be EXECUTED BY A LOW-JUDGMENT WORKER (a sub-agent that
- * follows the spec literally, with little ability to disambiguate or
- * choose between alternatives). The audit's success criterion is:
- *
- *   "After audit + fixes, can a literal-following worker execute this
- *    artifact without failing, picking wrong, or getting stuck?"
- *
- * That criterion is what makes a finding load-bearing. Stylistic nits
- * don't block execution; ambiguity, contradictions, missing verification,
- * unspecified branches, out-of-order steps, and overloaded terms do.
- *
- * EVIDENCE & SCOPE for prose artifacts.
- * Audit examines a prose artifact (spec, design doc, plan, recommendation
- * doc, API contract, config, brief). The "thing being examined" is text —
- * not source code — so evidence and scope rules differ from review/debug:
- *
- *  - Evidence is a doc quote, OR a precise reference to a section/item
- *    that *should* address the issue but doesn't (absence-finding), OR
- *    a doc-claim + contradicting source (wrong-claim finding), OR
- *    two sections of the doc that contradict each other (internal-
- *    coherence finding).
- *  - Scope is the document and what it directly references; cross-section
- *    reasoning IS the value of an audit.
- *
- * The failure-mode rubric below tells the worker WHAT KINDS of issues to
- * look for in a prose artifact. Without it, workers calibrated on code
- * audits collapse to surface-level proofreading on documents.
- */
-/**
- * The orientation block. Goes at the TOP of every audit prompt.
- *
- * This is the load-bearing addition. Without an explicit purpose statement,
- * workers default to "find issues in this doc" — which produces stylistic
- * proofreading. With this orientation, they look for issues that would
- * BLOCK EXECUTION by a literal-following worker, which is what the caller
- * actually needs.
- */
-export const AUDIT_PURPOSE_ORIENTATION = [
-    'Why this audit exists:',
-    'The artifact you are auditing is most likely a spec, plan, design doc, or recommendation doc that will subsequently be EXECUTED BY A LOW-JUDGMENT WORKER — a sub-agent that follows instructions literally, has limited ability to disambiguate, and cannot recover from contradictions.',
-    '',
-    'Your job is to find anywhere a literal-following worker would:',
-    '- get stuck on ambiguity (e.g. "implement the function" with no signature, location, or contract)',
-    '- pick wrong on an unspecified branch (e.g. "if X then Y" with no "otherwise")',
-    '- implement contradictions (section A says use X, section B says use Y, both apparently authoritative)',
-    '- skip a requirement that is implicit or buried (the worker only does what is explicitly stated)',
-    '- be unable to verify completion (no acceptance criteria, no done condition, no test command)',
-    '- misinterpret an overloaded term (the same word means two different things in two sections)',
-    '- execute steps out of order (step 3 needs the output of step 5)',
-    '- act on an unbounded scope ("fix the bug" with no scope boundary)',
-    '- need context that is referenced but not provided (a helper, a flag, a file the spec assumes the worker knows)',
-    '- produce data of an unspecified shape (return value, file format, error envelope)',
-    '',
-    'A finding that points at any of these failure-mode triggers is high-value EVEN IF the prose reads cleanly. Conversely, a stylistic nit that does not block execution is low-priority no matter how clean the wording.',
-    '',
-    'When you have completed this audit and its fixes have been applied, the test is: would a worker that reads only this artifact, follows it literally, and asks no clarifying questions, produce the right outcome? If yes, the audit succeeded.',
-].join('\n');
-export const EVIDENCE_RULE_AUDIT = [
-    'Evidence grounding (REQUIRED for every finding):',
-    '- For issues IN the doc: quote the exact passage that demonstrates the issue.',
-    '- For ABSENCES (the doc is silent on something it should specify): name the section that should address it. Example: "Section 3.2 enumerates failure modes but does not specify queue-overflow behavior." This is an absence-finding and is fully valid evidence.',
-    '- For WRONG-CLAIM findings: quote the doc\'s claim AND the source that contradicts it (the actual code, the referenced spec, etc.).',
-    '- For INTERNAL-COHERENCE findings (two parts of the doc conflict, a recommendation contradicts a stated constraint, a fix relies on something the doc forbids): quote both passages OR quote one and name the section ID of the other.',
-    '- A finding without one of these four forms of evidence is speculation. Note "investigation needed" in your summary instead.',
-].join('\n');
-export const SCOPE_RULE_AUDIT = [
-    'Scope:',
-    '- The document itself plus any artifact the document directly references (cited code, linked spec, embedded config).',
-    '- Cross-section reasoning within the document IS in scope and is often the highest-value kind of finding.',
-    '- Do NOT enumerate the repository or glob across all source files. If verifying a referenced file or symbol, read or grep for that specific name only — the goal is to evaluate the document, not catalog the codebase.',
-    '- Out of scope: speculation about content the document does not reference; coding-style nits on inline code examples (those belong in a code review, not an audit).',
-].join('\n');
-/**
- * The failure-mode rubric for prose-document audits.
- *
- * This is the load-bearing addition. Without an explicit taxonomy, workers
- * calibrated on source-code rubrics (off-by-one, type mismatches, dead code)
- * have nothing to look for in a spec/plan/recommendation doc and emit only
- * surface nits. The 11 categories below cover what actually goes wrong in
- * non-trivial prose artifacts and are independent of the audit-type label.
- */
-export const DOC_AUDIT_FAILURE_MODES = [
-    'Look for these kinds of issues — applicable to ALL prose-document audits regardless of auditType. The auditType (default / security / performance) tells you which lens to weight, but every doc audit should sweep the full taxonomy:',
-    '',
-    '1. RECOMMENDATION-COHERENCE — does the proposed fix actually solve the stated problem given the doc\'s own stated constraints? A fix that requires X when the doc forbids X is logically incomplete. **Always check fixes against any explicit principles, constraints, invariants, or "what we won\'t do" sections in the doc itself.** Example: a doc that lists "no persistence" as a principle cannot have a fix that disambiguates "id existed before" from "id never existed" without persistence — that fix is unimplementable.',
-    '2. INTERNAL CONTRADICTION — does section A say something incompatible with section B? Does a methodology disclaimer ("these numbers are approximations") undercut a load-bearing claim built on those same numbers? Does a "do not auto-X" rule sit next to an "auto-X above threshold" recommendation?',
-    '3. CROSS-ITEM DUPLICATION — are two items addressing the same root cause without acknowledging each other? Should they be merged or cross-referenced? Look across the WHOLE doc for items that target the same underlying problem from different angles.',
-    '4. INDEPENDENCE-CLAIMED-WITHOUT-EVIDENCE — is X asserted as independent of Y when the evidence shows correlation, co-occurrence, or shared mechanism?',
-    '5. ARGUMENT SOUNDNESS — does the evidence chain support the conclusion? Does a headline ("95% wasted") rest on data the doc itself flags as unreliable? Does a severity rating match the evidence depth?',
-    '6. COMPLETENESS AGAINST CONSTRAINTS — does any constraint stated elsewhere render a recommendation infeasible? Is a fix step that depends on persistence proposed in a doc that forbids persistence? **If the doc has a principles, invariants, or constraints section, walk every recommendation through every constraint and flag mismatches.**',
-    '7. FIX ACTIONABILITY — is the proposed fix complete enough to implement, or does it stop at "fix it" / vague verbs? Does it leave open which subsystem owns the change? Are step-by-step actions or only goals?',
-    '8. DRIFT / STALENESS — does any claim in one section contradict more recently revised material in the same doc? **Specifically: count items the doc claims to discuss (e.g. "across all three sessions", "the four highest-impact items", "we have N tools") and verify the count against the actual list elsewhere.** If the count is wrong, that\'s drift. Other drift signals: version labels, renamed sections, references to removed items.',
-    '9. SCOPE-CREEP / FRAMING — do recommendations exceed what the evidence supports? Does the framing (table title, bucket label, headline) misrepresent what the row contents actually say?',
-    '10. STRUCTURAL CONSISTENCY — do similar items in a list/table follow the same shape? If one row has a Verification subsection and the others don\'t, that\'s structural inconsistency. If items are numbered "1, 1b, 2, 3" the duplicate "1" is a structural break. If a column is labeled "Fix direction" but one row\'s cell holds verification criteria, that\'s a column-content mismatch.',
-    '11. METADATA COMPLETENESS — for living/revised documents: is there a "last updated" / "as of" / version stamp? When findings claim "still unfixed in version X", is there a date timeline that supports the claim?',
-    '',
-    'Severity calibration for doc audits:',
-    '- critical: a recommendation that, if implemented, would fail or cause harm because the doc is internally incoherent (e.g. a fix that depends on something the doc forbids). Or: a contradiction that would silently lead to wrong implementation if a reader followed both passages.',
-    '- high: a substantive missing recommendation, an incorrect claim of independence between two issues, an evidence chain that does not support a load-bearing conclusion, OR a fix that violates a stated principle/constraint of the doc itself.',
-    '- medium: argument soundness gap, fix actionability gap, drift between sections (item-count mismatch), structural inconsistency between similar items, scope-creep risk that needs a guardrail.',
-    '- low: stylistic, labeling, or formatting issues; missing metadata; minor cross-reference fixes.',
-].join('\n');
-export const ANNOTATOR_AWARENESS_AUDIT = [
-    'After your output, an annotator validates each finding against this audit-specific rubric:',
-    '- Is the finding about the document (contradiction / absence / ambiguity / wrong claim / scope gap / recommendation-coherence / argument-soundness)?',
-    '- Is the evidence one of the four valid shapes: doc quote, absence-reference, claim+contradiction, OR internal-coherence cross-section reference?',
-    '- Is the severity calibrated to actual downstream-execution impact (does following the recommendation as written produce a wrong outcome)?',
-    '- Is the finding within the document\'s scope, or is it speculation about untouched material?',
-    'Self-check before emitting. Findings that fail any check are downgraded or dropped — but logical-coherence and argument-soundness findings backed by section references are FULLY VALID, do NOT downgrade them as "speculation."',
-].join('\n');
-import { parseCriteria } from '../criteria-types.js';
-/** Structured per-criterion array for parallel-criteria fan-out. Derived
- *  from DOC_AUDIT_FAILURE_MODES so the prose in the cached prefix and the
- *  per-sub-worker assignment stay in lockstep. */
-export const AUDIT_CRITERIA = parseCriteria(DOC_AUDIT_FAILURE_MODES);
-//# sourceMappingURL=implementer-criteria.js.map

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

@@ -1 +0,0 @@
-{"version":3,"file":"implementer-criteria.js","sourceRoot":"","sources":["../../../src/tools/audit/implementer-criteria.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AAEH;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,yBAAyB,GAAG;IACvC,wBAAwB;IACxB,0RAA0R;IAC1R,EAAE;IACF,gEAAgE;IAChE,mGAAmG;IACnG,gFAAgF;IAChF,wGAAwG;IACxG,kGAAkG;IAClG,+FAA+F;IAC/F,8FAA8F;IAC9F,kEAAkE;IAClE,oEAAoE;IACpE,iHAAiH;IACjH,oFAAoF;IACpF,EAAE;IACF,uNAAuN;IACvN,EAAE;IACF,gPAAgP;CACjP,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,mBAAmB,GAAG;IACjC,kDAAkD;IAClD,+EAA+E;IAC/E,mQAAmQ;IACnQ,qIAAqI;IACrI,wOAAwO;IACxO,8HAA8H;CAC/H,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,gBAAgB,GAAG;IAC9B,QAAQ;IACR,sHAAsH;IACtH,2GAA2G;IAC3G,yNAAyN;IACzN,qKAAqK;CACtK,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;;;;;;;GAQG;AACH,MAAM,CAAC,MAAM,uBAAuB,GAAG;IACrC,wOAAwO;IACxO,EAAE;IACF,wgBAAwgB;IACxgB,ySAAyS;IACzS,0PAA0P;IAC1P,uJAAuJ;IACvJ,0MAA0M;IAC1M,mVAAmV;IACnV,iNAAiN;IACjN,kbAAkb;IAClb,0LAA0L;IAC1L,gYAAgY;IAChY,oNAAoN;IACpN,EAAE;IACF,sCAAsC;IACtC,uRAAuR;IACvR,iPAAiP;IACjP,iMAAiM;IACjM,kGAAkG;CACnG,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,yBAAyB,GAAG;IACvC,4FAA4F;IAC5F,sJAAsJ;IACtJ,mJAAmJ;IACnJ,4IAA4I;IAC5I,+FAA+F;IAC/F,kOAAkO;CACnO,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,OAAO,EAAE,aAAa,EAAuB,MAAM,sBAAsB,CAAC;AAE1E;;kDAEkD;AAClD,MAAM,CAAC,MAAM,cAAc,GAA8B,aAAa,CAAC,uBAAuB,CAAC,CAAC"}

package/dist/tools/audit/plan-audit-criteria.d.ts

@@ -1,35 +0,0 @@
-/**
- * Plan-audit failure-mode taxonomy (4.2.3+).
- *
- * Drives the parallel-criteria fan-out for `auditType: 'plan'` audits.
- * Each numbered entry below becomes one sub-worker assigned to a single
- * verification dimension. Sub-workers run on the existing complex tier
- * with read-only tools (read_file / grep / glob / list_files); they
- * derive source files to verify from the plan itself, then ground each
- * finding in actual file-and-line evidence.
- *
- * A perspective emitting zero findings means "this dimension passes for
- * this plan." That is the EXPECTED outcome for several perspectives on
- * a clean plan; the merge annotator does NOT inflate severity to fill
- * a quota.
- *
- * Contrast with DOC_AUDIT_FAILURE_MODES (in implementer-criteria.ts):
- * those 11 categories are prose-INTERNAL coherence (ambiguity,
- * contradiction, drift between sections). The 8 perspectives below are
- * EXTERNAL coherence — does the plan match the codebase?
- */
-import { type CriterionEntry } from '../criteria-types.js';
-/** Orientation block — goes at the top of every plan-audit sub-worker
- *  prompt. Contrast with AUDIT_PURPOSE_ORIENTATION (prose-coherence
- *  audit): plan-audit sub-workers verify EXTERNAL coherence (plan vs
- *  codebase), not internal-coherence. */
-export declare const PLAN_AUDIT_PURPOSE_ORIENTATION: string;
-export declare const EVIDENCE_RULE_PLAN_AUDIT: string;
-export declare const SCOPE_RULE_PLAN_AUDIT: string;
-export declare const ANNOTATOR_AWARENESS_PLAN_AUDIT: string;
-export declare const PLAN_AUDIT_FAILURE_MODES: string;
-/** Parsed criterion array for the parallel-criteria fan-out. Eight
- *  sub-workers, one per verification perspective. Derived from
- *  PLAN_AUDIT_FAILURE_MODES so prose and dispatcher stay in lockstep. */
-export declare const PLAN_AUDIT_CRITERIA: readonly CriterionEntry[];
-//# sourceMappingURL=plan-audit-criteria.d.ts.map

package/dist/tools/audit/plan-audit-criteria.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"plan-audit-criteria.d.ts","sourceRoot":"","sources":["../../../src/tools/audit/plan-audit-criteria.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG;AAEH,OAAO,EAAiB,KAAK,cAAc,EAAE,MAAM,sBAAsB,CAAC;AAE1E;;;yCAGyC;AACzC,eAAO,MAAM,8BAA8B,QAyC/B,CAAC;AAEb,eAAO,MAAM,wBAAwB,QAmBzB,CAAC;AAEb,eAAO,MAAM,qBAAqB,QAMtB,CAAC;AAEb,eAAO,MAAM,8BAA8B,QAO/B,CAAC;AAGb,eAAO,MAAM,wBAAwB,QAmDzB,CAAC;AAEb;;yEAEyE;AACzE,eAAO,MAAM,mBAAmB,EAAE,SAAS,cAAc,EAA4C,CAAC"}

package/dist/tools/audit/plan-audit-criteria.js

@@ -1,159 +0,0 @@
-/**
- * Plan-audit failure-mode taxonomy (4.2.3+).
- *
- * Drives the parallel-criteria fan-out for `auditType: 'plan'` audits.
- * Each numbered entry below becomes one sub-worker assigned to a single
- * verification dimension. Sub-workers run on the existing complex tier
- * with read-only tools (read_file / grep / glob / list_files); they
- * derive source files to verify from the plan itself, then ground each
- * finding in actual file-and-line evidence.
- *
- * A perspective emitting zero findings means "this dimension passes for
- * this plan." That is the EXPECTED outcome for several perspectives on
- * a clean plan; the merge annotator does NOT inflate severity to fill
- * a quota.
- *
- * Contrast with DOC_AUDIT_FAILURE_MODES (in implementer-criteria.ts):
- * those 11 categories are prose-INTERNAL coherence (ambiguity,
- * contradiction, drift between sections). The 8 perspectives below are
- * EXTERNAL coherence — does the plan match the codebase?
- */
-import { parseCriteria } from '../criteria-types.js';
-/** Orientation block — goes at the top of every plan-audit sub-worker
- *  prompt. Contrast with AUDIT_PURPOSE_ORIENTATION (prose-coherence
- *  audit): plan-audit sub-workers verify EXTERNAL coherence (plan vs
- *  codebase), not internal-coherence. */
-export const PLAN_AUDIT_PURPOSE_ORIENTATION = [
-    'Why this audit exists:',
-    'You are auditing a CODE-EXECUTION PLAN against a real codebase AND (when provided) against the upstream requirement spec. The plan will subsequently be dispatched to literal-following workers via mma-execute-plan; if the plan names a method, file, type, or signature that does not match the codebase as it exists today, the worker will freeze on the contradiction or produce broken code. If the plan silently skips a spec requirement, the implementation will ship incomplete. Your job: verify every plan claim against the actual codebase, and (when the spec is available) verify every spec requirement is covered by at least one task.',
-    '',
-    'Your job is NOT prose-quality on the plan itself (that is the default audit\'s job). Your job splits into three groups of perspectives:',
-    '  • EXTERNAL CODEBASE COHERENCE (perspectives 1–8) — for every named symbol, file path, signature, or import in the plan, the codebase must contain it as described UNLESS the plan task is the one creating it. (See "How to classify a plan\'s mention of X" below.) These perspectives REQUIRE source-side evidence (file:line).',
-    '  • INTRA-PLAN STRUCTURE (perspectives 9, 11, 12) — task granularity, placeholder language, and required plan skeleton. These perspectives look ONLY at the plan markdown itself; no codebase grounding is needed.',
-    '  • SPEC ALIGNMENT (perspective 10) — every load-bearing spec requirement maps to ≥1 task in the plan, and no task implements something the spec did not ask for. This perspective requires the reference SPEC to be available in your context (registered as a context block by the caller). If no spec is in context, emit "No findings for this criterion." for perspective 10 ONLY — do NOT skip the other perspectives.',
-    '',
-    'Tool surface: read_file / grep / glob / list_files. The plan itself is in your filePaths input (one file). Source files are NOT pre-listed — you derive them from the plan\'s "Files: Modify:" / "Test:" / "Create:" blocks and from import statements in code blocks, then grep / read them yourself under cwd. The reference SPEC, when provided, lives in the cached prefix above as a registered context block — read it directly from there for perspective 10.',
-    '',
-    'A finding without an actual file-and-line reference for the source side is speculation FOR PERSPECTIVES 1–8 ONLY. Drop those. Perspectives 9, 11, 12 are intra-plan and need only a plan-side quote. Perspective 10 needs a spec-side quote (the requirement) plus a plan-side reference (the task that does or does not cover it). If a perspective has no findings to flag for this plan, that is the correct outcome — say so via the standard "No findings for this criterion." string and move on.',
-    '',
-    '— BEFORE FLAGGING — How to classify a plan\'s mention of X (REQUIRED triage step):',
-    '',
-    'Plans contain TWO different kinds of symbol mention. Confusing them is the #1 way plan-audits over-flag and produce false positives. Before any SYMBOL EXISTENCE / SIGNATURE MATCH / IMPORT GRAPH finding, classify the mention:',
-    '',
-    '**USE intent** — the plan TREATS X as already existing in the codebase. The task ASSUMES the symbol is there. Examples:',
-    '  • method calls: `store.register(...)`, `obj.helper(...)`, `await provider.run(...)`',
-    '  • property/field access: `config.someField`, `result.cost`, `this._ttlMs`',
-    '  • import statements: `import { X } from "./bar.js"`',
-    '  • type references: `function f(arg: X)`, `: Promise<X>`, `: ExistingInterface`',
-    '  • test code calling production code: `expect(store.register(...))`',
-    '',
-    '**DEFINE intent** — the plan CREATES X in this task. X is the deliverable. Examples:',
-    '  • function/method declarations: `function foo()`, `private foo()`, `static foo()`, `async foo()`',
-    '  • class/interface/type declarations: `class Foo {}`, `interface Bar {}`, `type Q = ...`, `enum E {}`',
-    '  • exported constants: `export const baz = ...`, `export function ...`',
-    '  • new fields added to existing types: `interface ExistingType { newField: X }`',
-    '  • new option keys on existing methods: `register(content: string, opts: { newOpt: X })`',
-    '  • new test files via "Test: <path> (new)"',
-    '  • new modules via "New: <path>" or "Create: <path>"',
-    '',
-    '**Verification rule by intent:**',
-    '  • USE intent → the symbol MUST exist in the named source file. If grep returns no match → flag (CRITICAL, "did you mean: <nearest match>").',
-    '  • DEFINE intent → the symbol MAY NOT exist yet. The task is the one adding it; that is the deliverable. **DO NOT FLAG.** This is the most common false-positive trap in plan audits.',
-    '  • DEFINE intent + symbol DOES already exist in source → flag MEDIUM "task is obsolete; this deliverable already shipped — plan needs trimming."',
-    '',
-    '**Task scope = a unit.** Each `### Task X.Y:` heading + its `Files:` block + its numbered steps + their code blocks form ONE UNIT. Read the unit as a whole before flagging. Do not extract a symbol from a code block in isolation. Specifically: a `private findByContentSha(...) { … }` definition appearing inside Task A1.4\'s code block, where the task\'s `Files:` block names the implementation file as `Modify:`, is the task INTRODUCING that helper — not the task ASSUMING it already exists. Look at the task\'s intent before flagging the symbol.',
-    '',
-    'Heuristic for fast classification: if the plan\'s code block has a function/method declaration syntax ON THE SAME LINE as the symbol name, it\'s DEFINE intent. If the symbol appears as a callee, an imported name, a type annotation, or a property access, it\'s USE intent.',
-].join('\n');
-export const EVIDENCE_RULE_PLAN_AUDIT = [
-    'Evidence grounding (REQUIRED for every finding — evidence shape varies by perspective group):',
-    '',
-    'Perspectives 1–8 (EXTERNAL CODEBASE COHERENCE) — both sides REQUIRED:',
-    '- Plan side: quote the exact line from the plan, with task ID + section reference (e.g. "Plan A1.4 step 3 line: `store.registerBlock(content, opts)`").',
-    '- Source side: file path + line number + actual content (e.g. "`packages/core/src/stores/file-backed-context-block-store.ts:113` defines `register(content, opts)` — no method named `registerBlock`").',
-    '- For SYMBOL-EXISTENCE findings: include the nearest match (Levenshtein) the worker found in the source. Example: "did you mean `register`? (Levenshtein distance 5)".',
-    '- For SIGNATURE-MATCH findings: quote BOTH the plan\'s call (with parameter names/types) AND the source\'s actual signature.',
-    '- A finding without both sides on perspectives 1–8 is speculation. Drop it.',
-    '',
-    'Perspective 10 (SPEC-COVERAGE) — both sides REQUIRED:',
-    '- Spec side: quote the exact `shall` / `must` / `should` clause (or the acceptance-criterion line) from the registered spec context block.',
-    '- Plan side: name the task that does (or does NOT) cover it. For absence findings: "no task in this plan implements <spec clause>". For scope-creep findings: "task X.Y implements <plan-side claim>, which has no corresponding spec requirement".',
-    '',
-    'Perspectives 9, 11, 12 (INTRA-PLAN STRUCTURE) — plan-side quote sufficient:',
-    '- Quote the exact plan line that demonstrates the issue, with task ID + section reference. No codebase or spec evidence is needed; these are intra-document checks.',
-    '- For absence findings (e.g. missing Goal/Architecture header, missing Files: block, missing commit step): name the section that SHOULD contain it and confirm it does not.',
-    '',
-    'Severity binding for all perspectives: critical = task BLOCKED at dispatch; high = ambiguous artifact; medium = recoverable with reordering or one-sentence edit; low = cosmetic.',
-].join('\n');
-export const SCOPE_RULE_PLAN_AUDIT = [
-    'Scope:',
-    '- The plan markdown (your one filePath input), plus the source files the plan directly references (in "Files: Modify:" / "Test:" / "Create:" lines, or via `import` statements in code blocks), plus the reference SPEC if it was registered as a context block in your cached prefix.',
-    '- Use grep / read_file targeted at the symbols and paths the plan names. DO NOT do an enumeration of the entire codebase.',
-    '- For perspective 10 (SPEC-COVERAGE): the spec lives in the registered context block above. Walk its requirement clauses against the plan\'s tasks; do NOT grep the codebase for spec content — that is not the perspective\'s job.',
-    '- Out of scope: prose-quality issues in the plan beyond placeholder-language scanning (use auditType=default for general prose quality), suggestions for refactoring the plan\'s recommendations, and any source files the plan does not reference.',
-].join('\n');
-export const ANNOTATOR_AWARENESS_PLAN_AUDIT = [
-    'After your output, an annotator validates each finding against this plan-audit-specific rubric:',
-    '- Does the finding cite the right evidence shape for its perspective group? (1–8: plan-side quote + source-side file:line; 10: spec-side clause quote + plan-side task reference; 9/11/12: plan-side quote alone, no codebase grounding needed.)',
-    '- Is the finding categorized correctly by perspective (1 PATH / 2 SYMBOL / 3 SIGNATURE / 4 IMPORT / 5 TEST HARNESS / 6 STEP SEQUENCE / 7 CROSS-TASK / 8 VERIFY CMD / 9 TASK GRANULARITY / 10 SPEC COVERAGE / 11 PLACEHOLDER LANGUAGE / 12 PLAN SKELETON)?',
-    '- Is the severity calibrated to actual dispatch impact (CRITICAL only when the task would BLOCK; HIGH for ambiguity that produces wrong artifact; MEDIUM for recoverable; LOW for cosmetic)?',
-    '- Does the finding name a specific task ID (e.g. "A1.4") so the merge annotator can group findings by task to compute per-task verdicts? For plan-level findings that do not attach to a single task (e.g. missing top-level header, spec requirement with no covering task), use the task ID "META".',
-    'Self-check before emitting. Findings on perspectives 1–8 missing source-side evidence are downgraded to LOW or dropped — but findings backed by file:line citations from a real file are FULLY VALID, do NOT downgrade them as "speculation." Findings on perspectives 9, 11, 12 with only a plan-side quote are FULLY VALID — they are intra-plan checks by design.',
-].join('\n');
-export const PLAN_AUDIT_FAILURE_MODES = [
-    'Plan-audit perspectives — applicable to code-execution plans being audited against a real codebase. Each perspective is one verification dimension; emitting zero findings for a perspective means "this dimension passes for this plan." Do not invent findings to hit a quota — if a perspective has nothing to flag, stay silent for that dimension. Apply each perspective end-to-end across every task in the plan. Use read_file / grep / glob / list_files to ground every finding in actual file-and-line evidence; findings without a real source-side reference are not load-bearing and must be dropped.',
-    '',
-    '1. PATH EXISTENCE — every line under a task\'s "Files:" block must resolve correctly per its label. Sub-rules: (a) "Modify: <path>" → file MUST exist on disk; missing = CRITICAL (the task cannot start). (b) "Test: <path>" or "Test: <path> (new)" → parent directory MUST exist; the test file itself may or may not exist. (c) "New: <path>" or "Create: <path>" → parent directory MUST exist AND the file MUST NOT exist (if it does, the task is obsolete — plan needs trimming, MEDIUM). Use list_files / read_file to verify. CRITICAL on missing modify-targets or missing parent dirs. MEDIUM on already-existing create-targets.',
-    '',
-    '2. SYMBOL EXISTENCE — for every method / type / class / function / imported identifier appearing inside ```ts``` or ```typescript``` code blocks under a task: FIRST classify the mention as USE or DEFINE intent (see the orientation block above). ONLY flag USE-intent mentions where grep against the named source file returns no match. DEFINE-intent mentions are the task\'s deliverable — DO NOT FLAG. Plan says `store.registerBlock(...)` (USE — method call on existing object) against `file-backed-context-block-store.ts`? grep the file; if not found, CRITICAL with nearest match. Plan defines `private findByContentSha(...) { … }` (DEFINE — declaration syntax) inside a Modify-target code block? skip — the task is creating the helper. Always include the actual nearest match (Levenshtein) on USE-intent findings so the plan can be fixed in one edit.',
-    '',
-    '3. SIGNATURE MATCH — when the plan\'s code uses a method with specific parameters or expects a specific return shape, the actual signature in the source must match. Same intent rule applies: ONLY flag for USE-intent mentions (calls or imports). When the plan DEFINES a method or extends an interface signature, that\'s the deliverable — don\'t flag. Plan calls `register(content, { ttlMs: 60_000 })` (USE) but actual signature is `register(content, opts: { id?: string })` with no `ttlMs`? CRITICAL — call would fail at build. Plan ALSO has a step adding `ttlMs?: number` to the interface (DEFINE)? skip the DEFINE; flag only the call site if the call appears BEFORE the interface-extension step within the task\'s numbered sequence (out-of-order — see perspective 6).',
-    '',
-    '4. IMPORT GRAPH — every `import { X } from \'…\'` line in code blocks must resolve under the same intent rule. Imports inside test code are USE intent (the imported symbol must exist somewhere). Imports of NEW modules the task creates (e.g. `import { sweepProjectCap } from \'./context-block-project-cap.js\'` when the same task\'s "Files: New:" block lists `context-block-project-cap.ts`) are DEFINE-adjacent — don\'t flag the import itself, but DO flag if the task forgets to also add the corresponding `exports` entry in the workspace package.json (HIGH — the build will fail).',
-    '',
-    '5. TEST HARNESS AVAILABILITY — when the plan introduces test code, every helper / factory / fixture the test USES (calls / imports) must exist at the named path. `mockProvider`, `startTestServerWithAgents`, `mkdtempSync`, `mockAdapter`, etc. — verify via grep. **However**: if the task explicitly says it adds a new option to an existing helper (e.g. "extend `startTestServerWithAgents` to accept `configOverrides`"), that\'s DEFINE intent — don\'t flag the new option, but DO flag if the test code uses the new option BEFORE the task\'s numbered step that adds it (out-of-order, perspective 6). Helper truly missing (no path, no related task) = HIGH.',
-    '',
-    '6. STEP SEQUENCE WITHIN TASK — within a single task, the numbered steps must be executable in order. Step 4 says "verify the test passes" — was step 3 the implementation that the test exercises? Step 7 references `helper()` — was it defined by an earlier step or in source? No step depends on output from a later step. Severity MEDIUM unless the dependency would actually halt execution (then HIGH).',
-    '',
-    '7. CROSS-TASK DEPENDENCIES — when task B\'s code uses something task A introduces (a method, a type, a config field), the plan\'s task ordering must reflect the dependency. Plan A1.5 calls `findByContentSha()` defined by A1.4 but A1.5 appears earlier? CRITICAL — execution would fail. Less severe: dependency exists but is undeclared in the task description (no "depends on A1.4" note). MEDIUM.',
-    '',
-    '8. VERIFICATION COMMAND VALIDITY — every "Run: <command>" / "verify" instruction in the plan must work with the project\'s actual tooling. Plan says `npm run validate-things` — does package.json have that script? Plan says `npx vitest run tests/foo.test.ts` — does that path exist (after the task\'s implementation lands)? Plan says `cargo test` in a TypeScript project? CRITICAL. Vague verification ("run the test") with no concrete command? MEDIUM — workable but the worker has to guess.',
-    '',
-    '9. TASK GRANULARITY — each task should be implementable in one focused sub-agent run. Flag tasks that are oversized for single-run execution. Concrete signals (any one or in combination): the task touches more than 3 distinct source files; the task\'s code blocks contain more than ~40 net lines of diff; the task mixes unrelated concerns (e.g. extending a config schema AND adding a new module AND wiring a CLI flag in one task heading); the task lists more than ~6 numbered steps. Severity HIGH when the task clearly exceeds standard-tier capacity (would force escalation to complex tier or thrash through review/rework rounds); MEDIUM when borderline. Suggested fix: split into atomic sub-tasks, one per file or one per concept, each with its own "Files:" block and numbered steps. The audit-fix loop iterates: author re-runs plan-audit, sees tasks downsized, re-audits until clean. This perspective is the upstream complement to perspective 6 (STEP SEQUENCE WITHIN TASK) — perspective 6 catches ordering bugs WITHIN a task; this one catches "task is too big to be one task at all."',
-    '',
-    '10. SPEC COVERAGE — every load-bearing requirement in the reference SPEC maps to at least one task in this plan, and no task implements a deliverable the spec did not ask for. Requires the spec to be available in your context (registered by the caller as a context block; read it from the cached prefix above). If no spec is in context, emit "No findings for this criterion." — that is the correct outcome when the caller did not provide one. When the spec IS in context, walk each `shall` / `must` / `should` clause (and each named acceptance criterion or architecture component) against the plan\'s task list. For each unmapped requirement: severity CRITICAL when load-bearing (the feature does not work without it), HIGH when supporting (test coverage, observability hook, non-functional requirement that the spec marked as required). For scope-creep (task implements something the spec did not request): severity HIGH if the work is substantive (>1 task or new deliverable), MEDIUM if minor (extra polish that does not affect cost / risk). Implicit mapping (task plausibly covers the requirement but does not say so explicitly) is MEDIUM with the suggested fix: add an explicit "Covers spec requirement: <quote>" line to the task description. Use task ID "META" for findings that point at an uncovered requirement (the task does not exist).',
-    '',
-    '11. PLACEHOLDER LANGUAGE — scan every task\'s steps and code blocks for prose patterns that the writing-plans skill classifies as "plan failures" because they leave a literal-following worker unable to act. Concrete signals: bare phrases `TBD`, `TODO`, `implement later`, `fill in details`, `Add appropriate error handling`, `add validation`, `handle edge cases`, `Similar to Task N` (without repeating the code), `Write tests for the above` (without showing the test code); steps that describe what to do without showing how when the step changes code (missing code block); verification instructions like `make sure it works` or `run the test` with no concrete command. Severity HIGH on load-bearing steps that cannot be executed without invention (e.g. an implementation step with no code block, a "TBD" in the middle of a task\'s numbered list); MEDIUM on vague verification instructions (worker has to guess but can recover); LOW on cosmetic placeholders in non-load-bearing prose (e.g. a "TODO: link to design doc" in the plan\'s preamble). Evidence is the exact placeholder quote with task ID + step number; no codebase grounding needed.',
-    '',
-    '12. PLAN SKELETON — the plan must carry the required structural scaffolding so a worker knows what the plan is for and where each task fits. Concrete signals to flag: missing or empty top-level header (`Goal:` / `Architecture:` / `Tech Stack:` lines); missing top-level File Structure section that maps the files-to-touch with their responsibilities before the task list begins; a task that has no `Files:` block (so the worker cannot tell which files to Create / Modify / Test); a task that has no commit step at the end (frequent-commits discipline is a writing-plans hard rule). Severity MEDIUM for missing required-header fields and missing per-task `Files:` blocks (worker can still execute but loses framing or has to derive file scope from code blocks); HIGH when the missing structure forces ambiguous file-scope decisions (e.g. a task whose code blocks reference multiple files but has no `Files:` block to say which is the modify target); LOW for missing commit steps and other discipline gaps. Evidence is plan-side: name the section that should contain the structure and confirm it is absent. Use task ID "META" for plan-level skeleton findings; use the specific task ID for per-task skeleton findings.',
-    '',
-    'Severity calibration for plan audits:',
-    '- critical: plan claim contradicts codebase ground truth in a way that BLOCKS dispatch, OR a load-bearing spec requirement has zero covering tasks. Examples: missing modify-target file (perspective 1), wrong method name (perspective 2), wrong signature/return type (perspective 3), missing module export (perspective 4), out-of-order task dependency (perspective 7), wrong tooling (perspective 8), uncovered load-bearing spec requirement (perspective 10).',
-    '- high: load-bearing ambiguity that risks wrong implementation. Plan signature is consistent with itself but multiple matching symbols exist in the source and the plan doesn\'t disambiguate. Test harness missing in the form claimed but the worker could synthesize. Step depends on later step in a recoverable but ambiguous way. Oversized task that must be split (perspective 9). Substantive scope-creep with no spec backing (perspective 10). Placeholder language on a load-bearing step (perspective 11). Missing `Files:` block that forces ambiguous file-scope (perspective 12). The task may execute, but produces an ambiguous artifact.',
-    '- medium: step ordering issue, cross-task dependency unstated but inferable, verify command vague but recoverable, missing parent dirs for create-targets, implicit spec mapping (perspective 10 — task plausibly covers a requirement but does not say so), vague verification instructions (perspective 11), missing required header / Files block on a single task (perspective 12). Fixable by reordering or adding a sentence; doesn\'t block dispatch.',
-    '- low: stylistic, missing metadata, naming preference, cosmetic placeholder in non-load-bearing prose, missing commit step. Cosmetic.',
-    '',
-    'Per-task verdict (the merge-annotator computes this from all sub-worker findings):',
-    '- EXECUTABLE: zero CRITICAL or HIGH findings against this task across all 8 perspectives.',
-    '- PARTIAL: one or more HIGH findings, no CRITICAL. Task may execute but produces an ambiguous result.',
-    '- BLOCKED: one or more CRITICAL findings. Task cannot be dispatched as written; a literal worker would freeze.',
-    '',
-    'Output format for each finding:',
-    '- Task ID (e.g., "A1.4") that the finding affects.',
-    '- Perspective number (1-8) and name.',
-    '- Plan claim: quote the line + section reference.',
-    '- Source reality: file path + line number + actual content.',
-    '- Severity (critical / high / medium / low).',
-    '- Suggested fix: concrete edit (e.g. "rename `registerBlock` → `register` in plan A1.4 step 3", or "rename source method to match plan").',
-    '',
-    'Anti-patterns to avoid:',
-    '- Speculation without source-file evidence ON PERSPECTIVES 1–8. If you can\'t open the file and find the line, drop the finding for those perspectives. Perspectives 9, 11, 12 are intra-plan and do not need source evidence — quoting the plan IS the evidence.',
-    '- Flagging general prose-quality on the plan. That\'s the default audit\'s job. You flag external coherence (perspectives 1–8), plan-vs-spec coverage (perspective 10), task granularity (perspective 9), the specific placeholder-language patterns in perspective 11, and the specific structural skeleton requirements in perspective 12. Other prose nits (sentence flow, paragraph organization, tone) are out of scope.',
-    '- Flagging perspective 10 (SPEC COVERAGE) without a spec in context. If no spec was registered, emit "No findings for this criterion." for perspective 10 — do not invent the spec or grep for it elsewhere.',
-    '- Inventing findings to fill quota. Zero findings on a perspective is the correct outcome when the dimension passes.',
-].join('\n');
-/** Parsed criterion array for the parallel-criteria fan-out. Eight
- *  sub-workers, one per verification perspective. Derived from
- *  PLAN_AUDIT_FAILURE_MODES so prose and dispatcher stay in lockstep. */
-export const PLAN_AUDIT_CRITERIA = parseCriteria(PLAN_AUDIT_FAILURE_MODES);
-//# sourceMappingURL=plan-audit-criteria.js.map

package/dist/tools/audit/plan-audit-criteria.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"plan-audit-criteria.js","sourceRoot":"","sources":["../../../src/tools/audit/plan-audit-criteria.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;GAmBG;AAEH,OAAO,EAAE,aAAa,EAAuB,MAAM,sBAAsB,CAAC;AAE1E;;;yCAGyC;AACzC,MAAM,CAAC,MAAM,8BAA8B,GAAG;IAC5C,wBAAwB;IACxB,4nBAA4nB;IAC5nB,EAAE;IACF,yIAAyI;IACzI,qUAAqU;IACrU,oNAAoN;IACpN,8ZAA8Z;IAC9Z,EAAE;IACF,scAAsc;IACtc,EAAE;IACF,yeAAye;IACze,EAAE;IACF,oFAAoF;IACpF,EAAE;IACF,kOAAkO;IAClO,EAAE;IACF,yHAAyH;IACzH,uFAAuF;IACvF,6EAA6E;IAC7E,uDAAuD;IACvD,kFAAkF;IAClF,sEAAsE;IACtE,EAAE;IACF,sFAAsF;IACtF,oGAAoG;IACpG,wGAAwG;IACxG,yEAAyE;IACzE,kFAAkF;IAClF,2FAA2F;IAC3F,6CAA6C;IAC7C,uDAAuD;IACvD,EAAE;IACF,kCAAkC;IAClC,+IAA+I;IAC/I,wLAAwL;IACxL,mJAAmJ;IACnJ,EAAE;IACF,oiBAAoiB;IACpiB,EAAE;IACF,iRAAiR;CAClR,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,wBAAwB,GAAG;IACtC,+FAA+F;IAC/F,EAAE;IACF,uEAAuE;IACvE,yJAAyJ;IACzJ,yMAAyM;IACzM,wKAAwK;IACxK,8HAA8H;IAC9H,6EAA6E;IAC7E,EAAE;IACF,uDAAuD;IACvD,4IAA4I;IAC5I,qPAAqP;IACrP,EAAE;IACF,6EAA6E;IAC7E,qKAAqK;IACrK,6KAA6K;IAC7K,EAAE;IACF,mLAAmL;CACpL,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,qBAAqB,GAAG;IACnC,QAAQ;IACR,wRAAwR;IACxR,2HAA2H;IAC3H,qOAAqO;IACrO,qPAAqP;CACtP,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,8BAA8B,GAAG;IAC5C,iGAAiG;IACjG,kPAAkP;IAClP,2PAA2P;IAC3P,8LAA8L;IAC9L,uSAAuS;IACvS,sWAAsW;CACvW,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAGb,MAAM,CAAC,MAAM,wBAAwB,GAAG;IACtC,qlBAAqlB;IACrlB,EAAE;IACF,+mBAA+mB;IAC/mB,EAAE;IACF,o1BAAo1B;IACp1B,EAAE;IACF,kwBAAkwB;IAClwB,EAAE;IACF,skBAAskB;IACtkB,EAAE;IACF,6oBAA6oB;IAC7oB,EAAE;IACF,iZAAiZ;IACjZ,EAAE;IACF,4YAA4Y;IAC5Y,EAAE;IACF,2eAA2e;IAC3e,EAAE;IACF,+jCAA+jC;IAC/jC,EAAE;IACF,k0CAAk0C;IACl0C,EAAE;IACF,ynCAAynC;IACznC,EAAE;IACF,gsCAAgsC;IAChsC,EAAE;IACF,uCAAuC;IACvC,ycAAyc;IACzc,6nBAA6nB;IAC7nB,8bAA8b;IAC9b,uIAAuI;IACvI,EAAE;IACF,oFAAoF;IACpF,2FAA2F;IAC3F,uGAAuG;IACvG,gHAAgH;IAChH,EAAE;IACF,iCAAiC;IACjC,oDAAoD;IACpD,sCAAsC;IACtC,mDAAmD;IACnD,6DAA6D;IAC7D,8CAA8C;IAC9C,2IAA2I;IAC3I,EAAE;IACF,yBAAyB;IACzB,mQAAmQ;IACnQ,+ZAA+Z;IAC/Z,8MAA8M;IAC9M,sHAAsH;CACvH,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb;;yEAEyE;AACzE,MAAM,CAAC,MAAM,mBAAmB,GAA8B,aAAa,CAAC,wBAAwB,CAAC,CAAC"}

package/dist/tools/audit/schema.d.ts

@@ -1,61 +0,0 @@
-import { z } from 'zod';
-export declare const inputSchema: z.ZodObject<{
-    document: z.ZodOptional<z.ZodString>;
-    subtype: z.ZodDefault<z.ZodEnum<{
-        default: "default";
-        spec: "spec";
-        plan: "plan";
-        skill: "skill";
-    }>>;
-    filePaths: z.ZodOptional<z.ZodArray<z.ZodString>>;
-    contextBlockIds: z.ZodOptional<z.ZodArray<z.ZodString>>;
-}, z.core.$strict>;
-export type Input = z.infer<typeof inputSchema>;
-export declare const outputSchema: z.ZodObject<{
-    headline: z.ZodString;
-    results: z.ZodUnion<readonly [z.ZodArray<z.ZodType<unknown, unknown, z.core.$ZodTypeInternals<unknown, unknown>>>, z.ZodObject<{
-        kind: z.ZodLiteral<"not_applicable">;
-        reason: z.ZodString;
-    }, z.core.$strip>]>;
-    batchTimings: z.ZodUnion<readonly [z.ZodObject<{}, z.core.$loose>, z.ZodObject<{
-        kind: z.ZodLiteral<"not_applicable">;
-        reason: z.ZodString;
-    }, z.core.$strip>]>;
-    costSummary: z.ZodUnion<readonly [z.ZodObject<{}, z.core.$loose>, z.ZodObject<{
-        kind: z.ZodLiteral<"not_applicable">;
-        reason: z.ZodString;
-    }, z.core.$strip>]>;
-    structuredReport: z.ZodUnion<readonly [z.ZodObject<{}, z.core.$loose>, z.ZodObject<{
-        kind: z.ZodLiteral<"not_applicable">;
-        reason: z.ZodString;
-    }, z.core.$strip>]>;
-    error: z.ZodUnion<readonly [z.ZodObject<{
-        code: z.ZodString;
-        message: z.ZodString;
-        details: z.ZodOptional<z.ZodUnknown>;
-    }, z.core.$strip>, z.ZodObject<{
-        kind: z.ZodLiteral<"not_applicable">;
-        reason: z.ZodString;
-    }, z.core.$strip>]>;
-    specReviewVerdict: z.ZodOptional<z.ZodEnum<{
-        error: "error";
-        approved: "approved";
-        concerns: "concerns";
-        changes_required: "changes_required";
-        annotated: "annotated";
-        skipped: "skipped";
-        not_applicable: "not_applicable";
-    }>>;
-    qualityReviewVerdict: z.ZodOptional<z.ZodEnum<{
-        error: "error";
-        approved: "approved";
-        concerns: "concerns";
-        changes_required: "changes_required";
-        annotated: "annotated";
-        skipped: "skipped";
-        not_applicable: "not_applicable";
-    }>>;
-    roundsUsed: z.ZodOptional<z.ZodNumber>;
-}, z.core.$loose>;
-export type Output = z.infer<typeof outputSchema>;
-//# sourceMappingURL=schema.d.ts.map

package/dist/tools/audit/schema.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"schema.d.ts","sourceRoot":"","sources":["../../../src/tools/audit/schema.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAMxB,eAAO,MAAM,WAAW;;;;;;;;;;kBAevB,CAAC;AAEF,MAAM,MAAM,KAAK,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,WAAW,CAAC,CAAC;AAEhD,eAAO,MAAM,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;iBAA8B,CAAC;AAExD,MAAM,MAAM,MAAM,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,YAAY,CAAC,CAAC"}

package/dist/tools/audit/schema.js

@@ -1,21 +0,0 @@
-// packages/core/src/tool-schemas/audit.ts
-import { z } from 'zod';
-import { buildOutputEnvelopeSchema } from '../shared-output.js';
-// Ported verbatim from packages/mcp/src/tools/audit-document.ts (auditDocumentSchema).
-// commonToolFields (filePaths + contextBlockIds) are inlined here to avoid
-// cross-package coupling.
-export const inputSchema = z.object({
-    document: z.string().optional().describe('Inline document content to audit'),
-    subtype: z.enum(['default', 'plan', 'spec', 'skill'])
-        .default('default')
-        .describe('Audit subtype — which artifact kind is being audited. `default` is the comprehensive prose-coherence sweep for design docs, recommendation docs, post-mortems, READMEs, briefs. `plan` is for code-execution plans audited against the actual codebase (pass the plan as the single filePaths entry; workers grep the codebase to verify every named symbol / path / signature / import). `spec` is for requirement-style prose (testability, scope explicitness, acceptance-criteria coverage). `skill` is for an mma-* skill markdown file (when_to_use specificity, input-shape completeness, anti-pattern coverage). For security or performance focus, include that emphasis in the free-text prompt — it is not a subtype.'),
-    filePaths: z.array(z.string()).optional()
-        .describe('Files the sub-agent should focus on. Multiple files are processed in parallel. For subtype=plan, MUST contain exactly one entry — the plan markdown.'),
-    contextBlockIds: z.array(z.string()).optional()
-        .describe('IDs from register_context_block to prepend to prompt. Use for delta audits, diff-scoped reviews, or shared specs.'),
-}).strict().refine((input) => input.subtype !== 'plan' || (Array.isArray(input.filePaths) && input.filePaths.length === 1), {
-    message: "Plan audit takes exactly one filePath (the plan markdown). The worker discovers and verifies source files itself via its tool surface — do not pre-list source files.",
-    path: ['filePaths'],
-});
-export const outputSchema = buildOutputEnvelopeSchema();
-//# sourceMappingURL=schema.js.map

package/dist/tools/audit/schema.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"schema.js","sourceRoot":"","sources":["../../../src/tools/audit/schema.ts"],"names":[],"mappings":"AAAA,0CAA0C;AAC1C,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAAE,yBAAyB,EAAE,MAAM,qBAAqB,CAAC;AAEhE,uFAAuF;AACvF,2EAA2E;AAC3E,0BAA0B;AAC1B,MAAM,CAAC,MAAM,WAAW,GAAG,CAAC,CAAC,MAAM,CAAC;IAClC,QAAQ,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE,CAAC,QAAQ,CAAC,kCAAkC,CAAC;IAC5E,OAAO,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,SAAS,EAAE,MAAM,EAAE,MAAM,EAAE,OAAO,CAAC,CAAC;SAClD,OAAO,CAAC,SAAS,CAAC;SAClB,QAAQ,CAAC,ksBAAksB,CAAC;IAC/sB,SAAS,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE;SACtC,QAAQ,CAAC,sJAAsJ,CAAC;IACnK,eAAe,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE;SAC5C,QAAQ,CAAC,mHAAmH,CAAC;CACjI,CAAC,CAAC,MAAM,EAAE,CAAC,MAAM,CAChB,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,OAAO,KAAK,MAAM,IAAI,CAAC,KAAK,CAAC,OAAO,CAAC,KAAK,CAAC,SAAS,CAAC,IAAI,KAAK,CAAC,SAAS,CAAC,MAAM,KAAK,CAAC,CAAC,EACvG;IACE,OAAO,EAAE,uKAAuK;IAChL,IAAI,EAAE,CAAC,WAAW,CAAC;CACpB,CACF,CAAC;AAIF,MAAM,CAAC,MAAM,YAAY,GAAG,yBAAyB,EAAE,CAAC"}

package/dist/tools/audit/skill-audit-criteria.d.ts

@@ -1,9 +0,0 @@
-import type { CriterionEntry } from '../criteria-types.js';
-import type { RouteSemantics } from '../read-route-prompt.js';
-export declare const SKILL_AUDIT_PURPOSE_ORIENTATION: string;
-export declare const EVIDENCE_RULE_SKILL_AUDIT: string;
-export declare const SCOPE_RULE_SKILL_AUDIT: string;
-export declare const ANNOTATOR_AWARENESS_SKILL_AUDIT: string;
-export declare const SKILL_AUDIT_CRITERIA: readonly CriterionEntry[];
-export declare const SKILL_AUDIT_SEMANTICS: RouteSemantics;
-//# sourceMappingURL=skill-audit-criteria.d.ts.map

package/dist/tools/audit/skill-audit-criteria.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"skill-audit-criteria.d.ts","sourceRoot":"","sources":["../../../src/tools/audit/skill-audit-criteria.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,sBAAsB,CAAC;AAE3D,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,yBAAyB,CAAC;AAE9D,eAAO,MAAM,+BAA+B,QAShC,CAAC;AAEb,eAAO,MAAM,yBAAyB,QAO1B,CAAC;AAEb,eAAO,MAAM,sBAAsB,QAKvB,CAAC;AAEb,eAAO,MAAM,+BAA+B,QAEhC,CAAC;AAYb,eAAO,MAAM,oBAAoB,EAAE,SAAS,cAAc,EAA6C,CAAC;AAExG,eAAO,MAAM,qBAAqB,EAAE,cAYnC,CAAC"}

package/dist/tools/audit/skill-audit-criteria.js

@@ -1,52 +0,0 @@
-import { parseCriteria } from '../criteria-types.js';
-export const SKILL_AUDIT_PURPOSE_ORIENTATION = [
-    'Why this audit exists:',
-    'A skill is the markdown a caller reads to decide whether to route a request to a tool and how to construct that request. A finding here is a place where the skill, as written, would cause a competent reader to dispatch the wrong call, miss a path of use, or fall for a foreseeable anti-pattern.',
-    '',
-    'For your output to clear that bar, every Finding must answer:',
-    '- Issue: the gap or ambiguity, quoting the exact skill section (heading + line).',
-    '- Suggestion: the missing or replacement text the skill needs.',
-    '',
-    'The completion test: would a competent reader given ONLY this skill be able to construct a correct request and avoid the named anti-patterns? If a Finding does not change that answer from "no" to "yes" when applied, it is below the bar — omit it.',
-].join('\n');
-export const EVIDENCE_RULE_SKILL_AUDIT = [
-    'Evidence grounding (REQUIRED for every finding):',
-    '- Quote the exact section heading + offending line (or the absence — name what is missing AND where it should appear).',
-    '- For when_to_use overlap findings: name the sibling skill that overlaps + quote both `when_to_use` lines.',
-    '- For input-shape findings: name the field that lacks documentation + quote the schema or surface where the field is exposed.',
-    '- For link-integrity findings: name the broken link + the file that should exist at that path.',
-    '- Severity binding: critical = wrong-tool routing; high = wrong-field dispatch; medium = reader hesitation; low = stylistic / metadata fix.',
-].join('\n');
-export const SCOPE_RULE_SKILL_AUDIT = [
-    'Scope:',
-    '- In scope: when_to_use specificity, input-shape completeness, output-shape contract, anti-pattern coverage, recipe-vs-skill scope discipline, version frontmatter, link integrity.',
-    '- Out of scope: implementation details of the tool itself (those belong in source code, not the skill), opinions on the underlying tool design, prose stylistic preferences that do not affect reader effectiveness.',
-    '- Multi-tool flows (recipes that span 2+ skills) are out of scope for individual skill files and belong in `multi-model-agent` SKILL.md\'s recipes section — flag in-skill recipes as RECIPE-VS-SKILL-SCOPE findings.',
-].join('\n');
-export const ANNOTATOR_AWARENESS_SKILL_AUDIT = [
-    '(N/A — your output is consumed verbatim by the user; there is no downstream annotator dedup step on this subtype.)',
-].join('\n');
-const SKILL_AUDIT_FAILURE_MODES = [
-    '1. WHEN-TO-USE-SPECIFICITY — The `when_to_use` frontmatter cleanly distinguishes this skill from sibling skills. Overlap with another `mma-*` skill without a tiebreaker is a finding.',
-    '2. INPUT-SHAPE-COMPLETENESS — Required JSON fields are documented with name + type + constraint + example. A reader can write a valid request from the skill text alone. Missing fields, types, or constraints flag.',
-    '3. OUTPUT-SHAPE-CONTRACT — The terminal envelope shape the caller will consume is described, including the structured-report shape and which fields are guaranteed vs optional.',
-    '4. ANTI-PATTERN-COVERAGE — Foreseeable misuses are called out with a corrective ("use X instead"). Anti-patterns mentioned without a corrective flag.',
-    '5. RECIPE-VS-SKILL-SCOPE — The skill documents a single tool, not a multi-step recipe spanning multiple tools. Multi-tool flows belong in `multi-model-agent` SKILL.md\'s recipes section.',
-    '6. VERSION-FRONTMATTER — `name` / `description` / `when_to_use` / `version` frontmatter is present and well-formed. `version` is the literal string `"0.0.0-unreleased"` before npm publish injection.',
-    '7. LINK-INTEGRITY — Internal cross-references (`./_shared/...`, `mma-other-skill`) point at files that exist; external links are not load-bearing for the skill\'s correctness.',
-].join('\n');
-export const SKILL_AUDIT_CRITERIA = parseCriteria(SKILL_AUDIT_FAILURE_MODES);
-export const SKILL_AUDIT_SEMANTICS = {
-    goalLine: 'Find ALL ways this skill, as written, would cause a competent reader to dispatch the wrong call, miss a path of use, or fall for a foreseeable anti-pattern — viewed through this criterion.',
-    emptyOutcomeLine: 'If THIS criterion does not surface a real gap in the skill, respond with the literal text "No findings for this criterion." — that is a valid outcome on a clean skill file.',
-    findingMeaningParagraph: 'A finding is a PLACE WHERE THE SKILL TEXT FAILS THE READER-EFFECTIVENESS TEST viewed through this criterion. Title = the failing section (or its anchor). Severity reflects whether a reader would route to the wrong tool, dispatch with wrong fields, hesitate / re-read, or just notice a stylistic nit.',
-    severityMeanings: {
-        critical: 'would route the reader to the wrong tool entirely — e.g. when_to_use overlaps a sibling skill with no tiebreaker, or the description names the wrong tool category.',
-        high: 'would dispatch with wrong fields — input shape incomplete, required field undocumented, JSON example wrong/missing.',
-        medium: 'would make a reader hesitate or re-read — anti-pattern mentioned without correction, recipe-vs-skill scope unclear, version frontmatter malformed.',
-        low: 'stylistic / link / metadata fix; does not affect dispatch correctness.',
-    },
-    mustEmitAtLeastOne: false,
-    legalOutcomes: ['found', 'clean'],
-};
-//# sourceMappingURL=skill-audit-criteria.js.map

package/dist/tools/audit/skill-audit-criteria.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"skill-audit-criteria.js","sourceRoot":"","sources":["../../../src/tools/audit/skill-audit-criteria.ts"],"names":[],"mappings":"AAKA,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AAGrD,MAAM,CAAC,MAAM,+BAA+B,GAAG;IAC7C,wBAAwB;IACxB,wSAAwS;IACxS,EAAE;IACF,+DAA+D;IAC/D,kFAAkF;IAClF,gEAAgE;IAChE,EAAE;IACF,wPAAwP;CACzP,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,yBAAyB,GAAG;IACvC,kDAAkD;IAClD,wHAAwH;IACxH,4GAA4G;IAC5G,+HAA+H;IAC/H,gGAAgG;IAChG,6IAA6I;CAC9I,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,sBAAsB,GAAG;IACpC,QAAQ;IACR,qLAAqL;IACrL,sNAAsN;IACtN,uNAAuN;CACxN,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,+BAA+B,GAAG;IAC7C,oHAAoH;CACrH,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,yBAAyB,GAAG;IAChC,wLAAwL;IACxL,sNAAsN;IACtN,iLAAiL;IACjL,uJAAuJ;IACvJ,4LAA4L;IAC5L,wMAAwM;IACxM,iLAAiL;CAClL,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAEb,MAAM,CAAC,MAAM,oBAAoB,GAA8B,aAAa,CAAC,yBAAyB,CAAC,CAAC;AAExG,MAAM,CAAC,MAAM,qBAAqB,GAAmB;IACnD,QAAQ,EAAE,8LAA8L;IACxM,gBAAgB,EAAE,8KAA8K;IAChM,uBAAuB,EAAE,6SAA6S;IACtU,gBAAgB,EAAE;QAChB,QAAQ,EAAE,qKAAqK;QAC/K,IAAI,EAAE,qHAAqH;QAC3H,MAAM,EAAE,oJAAoJ;QAC5J,GAAG,EAAE,wEAAwE;KAC9E;IACD,kBAAkB,EAAE,KAAK;IACzB,aAAa,EAAE,CAAC,OAAO,EAAE,OAAO,CAAU;CAC3C,CAAC"}

package/dist/tools/audit/spec-audit-criteria.d.ts

@@ -1,9 +0,0 @@
-import type { CriterionEntry } from '../criteria-types.js';
-import type { RouteSemantics } from '../read-route-prompt.js';
-export declare const SPEC_AUDIT_PURPOSE_ORIENTATION: string;
-export declare const EVIDENCE_RULE_SPEC_AUDIT: string;
-export declare const SCOPE_RULE_SPEC_AUDIT: string;
-export declare const ANNOTATOR_AWARENESS_SPEC_AUDIT: string;
-export declare const SPEC_AUDIT_CRITERIA: readonly CriterionEntry[];
-export declare const SPEC_AUDIT_SEMANTICS: RouteSemantics;
-//# sourceMappingURL=spec-audit-criteria.d.ts.map

package/dist/tools/audit/spec-audit-criteria.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"spec-audit-criteria.d.ts","sourceRoot":"","sources":["../../../src/tools/audit/spec-audit-criteria.ts"],"names":[],"mappings":"AAGA,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,sBAAsB,CAAC;AAE3D,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,yBAAyB,CAAC;AAE9D,eAAO,MAAM,8BAA8B,QAS/B,CAAC;AAEb,eAAO,MAAM,wBAAwB,QAQzB,CAAC;AAEb,eAAO,MAAM,qBAAqB,QAKtB,CAAC;AAEb,eAAO,MAAM,8BAA8B,QAE/B,CAAC;AAcb,eAAO,MAAM,mBAAmB,EAAE,SAAS,cAAc,EAA4C,CAAC;AAEtG,eAAO,MAAM,oBAAoB,EAAE,cAYlC,CAAC"}