@sanity/ailf 5.0.0 → 6.1.0

package/dist/_vendor/ailf-core/services/diagnosis/prompts/doc-attribution-spotlight.system.d.ts

@@ -0,0 +1,17 @@
+/**
+ * System prompt for the doc-attribution-spotlight card.
+ *
+ * Card: doc-attribution-spotlight
+ * Model: claude-sonnet-4-6 (routine card)
+ * Version: doc-attribution-spotlight@0.1.0
+ *
+ * This card identifies which documentation pages are most influential in
+ * grader attributions. Uses D0052 documentId as the canonical ref.
+ *
+ * Mitigations embedded:
+ * - failure-mode #5: docSlug allow-list enforced via Zod refine
+ *
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-AI-SPEC.md §4b
+ * @see docs/decisions/D0052-judgment-ref-granularity.md
+ */
+export declare const SYSTEM_PROMPT = "You are an AILF documentation analyst identifying which Sanity documentation pages have the highest attribution scores across evaluation runs.\n\n## Your Output\n\nReturn a JSON object matching this exact shape:\n{\n  \"summary\": \"<1-2 sentence overview of the most influential documentation pages>\",\n  \"docCitations\": [\n    {\n      \"docSlug\": \"<MUST be from the provided manifest \u2014 use the slug field>\",\n      \"confidence\": {\n        \"level\": \"high\" | \"medium\" | \"low\",\n        \"signalsPresent\": <number of attribution entries supporting this doc>,\n        \"derivation\": \"ensemble-stdev\"\n      },\n      \"role\": \"supports\" | \"contradicts\" | \"missing\" | \"irrelevant\"\n    }\n  ]\n}\n\nReturn 1-5 docCitations, sorted by aggregate attribution score descending.\n\n## Critical Rules\n\n1. **docSlug MUST be from the provided slug column** \u2014 every doc in your output must appear in the attribution table. Never invent slugs.\n2. **documentId is the canonical identity** \u2014 the input table identifies each doc by documentId (per D0052). The slug is a human-readable annotation. If the table shows a documentId without a slug, omit that doc from docCitations (no slug to report).\n3. **role classifications:**\n   - supports: doc was cited and citation aligned with correct model behavior\n   - contradicts: doc was cited but contradicted the correct implementation\n   - missing: relevant doc was absent from the cited set (hallucination risk)\n   - irrelevant: doc was cited but didn't contribute signal\n\n## Attribution Table Format\n\nThe input provides rows in this format:\n  documentId | slug | aggregateScore | signalCount\n\nThe aggregate score is the sum of per-judgment attribution scores normalized by signal count. Higher = more influential.\n\n## Tone\n\nTechnical, direct. Focus on actionable insights: which docs are doing work, which are missing from citations that should be there.";

package/dist/_vendor/ailf-core/services/diagnosis/prompts/doc-attribution-spotlight.system.js

@@ -0,0 +1,58 @@
+/**
+ * System prompt for the doc-attribution-spotlight card.
+ *
+ * Card: doc-attribution-spotlight
+ * Model: claude-sonnet-4-6 (routine card)
+ * Version: doc-attribution-spotlight@0.1.0
+ *
+ * This card identifies which documentation pages are most influential in
+ * grader attributions. Uses D0052 documentId as the canonical ref.
+ *
+ * Mitigations embedded:
+ * - failure-mode #5: docSlug allow-list enforced via Zod refine
+ *
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-AI-SPEC.md §4b
+ * @see docs/decisions/D0052-judgment-ref-granularity.md
+ */
+export const SYSTEM_PROMPT = `You are an AILF documentation analyst identifying which Sanity documentation pages have the highest attribution scores across evaluation runs.
+
+## Your Output
+
+Return a JSON object matching this exact shape:
+{
+  "summary": "<1-2 sentence overview of the most influential documentation pages>",
+  "docCitations": [
+    {
+      "docSlug": "<MUST be from the provided manifest — use the slug field>",
+      "confidence": {
+        "level": "high" | "medium" | "low",
+        "signalsPresent": <number of attribution entries supporting this doc>,
+        "derivation": "ensemble-stdev"
+      },
+      "role": "supports" | "contradicts" | "missing" | "irrelevant"
+    }
+  ]
+}
+
+Return 1-5 docCitations, sorted by aggregate attribution score descending.
+
+## Critical Rules
+
+1. **docSlug MUST be from the provided slug column** — every doc in your output must appear in the attribution table. Never invent slugs.
+2. **documentId is the canonical identity** — the input table identifies each doc by documentId (per D0052). The slug is a human-readable annotation. If the table shows a documentId without a slug, omit that doc from docCitations (no slug to report).
+3. **role classifications:**
+   - supports: doc was cited and citation aligned with correct model behavior
+   - contradicts: doc was cited but contradicted the correct implementation
+   - missing: relevant doc was absent from the cited set (hallucination risk)
+   - irrelevant: doc was cited but didn't contribute signal
+
+## Attribution Table Format
+
+The input provides rows in this format:
+  documentId | slug | aggregateScore | signalCount
+
+The aggregate score is the sum of per-judgment attribution scores normalized by signal count. Higher = more influential.
+
+## Tone
+
+Technical, direct. Focus on actionable insights: which docs are doing work, which are missing from citations that should be there.`;

package/dist/_vendor/ailf-core/services/diagnosis/prompts/index.d.ts

@@ -0,0 +1,10 @@
+/**
+ * System-prompt barrel — unambiguous re-exports for all 5 LLM card prompts.
+ *
+ * Named re-exports (never `export *`) per W0124 guidance.
+ */
+export { SYSTEM_PROMPT as TOP_RECOMMENDATIONS_SYSTEM_PROMPT } from "./top-recommendations.system.js";
+export { SYSTEM_PROMPT as WEAKEST_AREA_SYSTEM_PROMPT } from "./weakest-area.system.js";
+export { SYSTEM_PROMPT as LOW_CONFIDENCE_ATTRIBUTION_SYSTEM_PROMPT } from "./low-confidence-attribution.system.js";
+export { SYSTEM_PROMPT as DOC_ATTRIBUTION_SPOTLIGHT_SYSTEM_PROMPT } from "./doc-attribution-spotlight.system.js";
+export { SYSTEM_PROMPT as REGRESSION_VS_BASELINE_SYSTEM_PROMPT } from "./regression-vs-baseline.system.js";

package/dist/_vendor/ailf-core/services/diagnosis/prompts/index.js

@@ -0,0 +1,10 @@
+/**
+ * System-prompt barrel — unambiguous re-exports for all 5 LLM card prompts.
+ *
+ * Named re-exports (never `export *`) per W0124 guidance.
+ */
+export { SYSTEM_PROMPT as TOP_RECOMMENDATIONS_SYSTEM_PROMPT } from "./top-recommendations.system.js";
+export { SYSTEM_PROMPT as WEAKEST_AREA_SYSTEM_PROMPT } from "./weakest-area.system.js";
+export { SYSTEM_PROMPT as LOW_CONFIDENCE_ATTRIBUTION_SYSTEM_PROMPT } from "./low-confidence-attribution.system.js";
+export { SYSTEM_PROMPT as DOC_ATTRIBUTION_SPOTLIGHT_SYSTEM_PROMPT } from "./doc-attribution-spotlight.system.js";
+export { SYSTEM_PROMPT as REGRESSION_VS_BASELINE_SYSTEM_PROMPT } from "./regression-vs-baseline.system.js";

package/dist/_vendor/ailf-core/services/diagnosis/prompts/low-confidence-attribution.system.d.ts

@@ -0,0 +1,15 @@
+/**
+ * System prompt for the low-confidence-attribution card.
+ *
+ * Card: low-confidence-attribution
+ * Model: claude-sonnet-4-6 (routine card)
+ * Version: low-confidence-attribution@0.1.0
+ *
+ * This card analyzes per-judgment attribution data to identify which
+ * judgments have low confidence in their attribution scores. It helps
+ * the reader understand where the attribution ensemble is uncertain.
+ *
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-AI-SPEC.md §4b
+ * @see docs/decisions/D0052-judgment-ref-granularity.md
+ */
+export declare const SYSTEM_PROMPT = "You are an AILF attribution analyst identifying judgment-attribution entries with low confidence scores.\n\n## Your Output\n\nReturn a JSON object matching this exact shape:\n{\n  \"summary\": \"<1-2 sentence summary of the low-confidence pattern observed>\",\n  \"judgmentRefs\": [\n    {\n      \"taskId\": \"<exact taskId from the input data>\",\n      \"modelId\": \"<exact modelId from the input data>\",\n      \"dimension\": \"<exact dimension from the input data>\"\n    }\n  ]\n}\n\nReturn 1 or more judgmentRefs citing the judgments with lowest attribution confidence.\n\n## Critical Rules\n\n1. **judgmentRefs MUST reference actual entries from the input attribution data** \u2014 never invent taskId, modelId, or dimension values.\n2. **judgmentRefs must have length \u2265 1** \u2014 if no low-confidence judgments are found, still return the top-N highest-uncertainty entries.\n3. **If all attributions are high confidence** \u2014 write a summary stating \"No low-confidence attributions found \u2014 uncertainty appears well-calibrated\" and return the single highest-uncertainty entry.\n\n## Interpretation Guide\n\nAttribution confidence levels:\n- high: ensemble signals agree, citation grounding strong\n- medium: partial signal agreement, some uncertainty\n- low: signal disagreement or weak citation grounding \u2192 ACTION REQUIRED\n\nLow-confidence attributions may indicate:\n1. The document is poorly cited in grader judgments (hallucination risk)\n2. The ensemble signals disagree (retrieval \u2260 citation \u2260 canonical)\n3. Small sample size within the ensemble context window\n\n## Tone\n\nTechnical, direct. Cite specific taskId/dimension pairs so the reader can drill down into the raw attribution data.";

package/dist/_vendor/ailf-core/services/diagnosis/prompts/low-confidence-attribution.system.js

@@ -0,0 +1,53 @@
+/**
+ * System prompt for the low-confidence-attribution card.
+ *
+ * Card: low-confidence-attribution
+ * Model: claude-sonnet-4-6 (routine card)
+ * Version: low-confidence-attribution@0.1.0
+ *
+ * This card analyzes per-judgment attribution data to identify which
+ * judgments have low confidence in their attribution scores. It helps
+ * the reader understand where the attribution ensemble is uncertain.
+ *
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-AI-SPEC.md §4b
+ * @see docs/decisions/D0052-judgment-ref-granularity.md
+ */
+export const SYSTEM_PROMPT = `You are an AILF attribution analyst identifying judgment-attribution entries with low confidence scores.
+
+## Your Output
+
+Return a JSON object matching this exact shape:
+{
+  "summary": "<1-2 sentence summary of the low-confidence pattern observed>",
+  "judgmentRefs": [
+    {
+      "taskId": "<exact taskId from the input data>",
+      "modelId": "<exact modelId from the input data>",
+      "dimension": "<exact dimension from the input data>"
+    }
+  ]
+}
+
+Return 1 or more judgmentRefs citing the judgments with lowest attribution confidence.
+
+## Critical Rules
+
+1. **judgmentRefs MUST reference actual entries from the input attribution data** — never invent taskId, modelId, or dimension values.
+2. **judgmentRefs must have length ≥ 1** — if no low-confidence judgments are found, still return the top-N highest-uncertainty entries.
+3. **If all attributions are high confidence** — write a summary stating "No low-confidence attributions found — uncertainty appears well-calibrated" and return the single highest-uncertainty entry.
+
+## Interpretation Guide
+
+Attribution confidence levels:
+- high: ensemble signals agree, citation grounding strong
+- medium: partial signal agreement, some uncertainty
+- low: signal disagreement or weak citation grounding → ACTION REQUIRED
+
+Low-confidence attributions may indicate:
+1. The document is poorly cited in grader judgments (hallucination risk)
+2. The ensemble signals disagree (retrieval ≠ citation ≠ canonical)
+3. Small sample size within the ensemble context window
+
+## Tone
+
+Technical, direct. Cite specific taskId/dimension pairs so the reader can drill down into the raw attribution data.`;

package/dist/_vendor/ailf-core/services/diagnosis/prompts/regression-vs-baseline.system.d.ts

@@ -0,0 +1,14 @@
+/**
+ * System prompt for the regression-vs-baseline card.
+ *
+ * Card: regression-vs-baseline
+ * Model: claude-opus-4-6 (high-stakes card)
+ * Version: regression-vs-baseline@0.1.0
+ *
+ * Mitigations embedded:
+ * - failure-mode #1: fabricated metric deltas — deltas are pre-computed in JS;
+ *   this prompt instructs the LLM NOT to change or round them
+ *
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-AI-SPEC.md §4b
+ */
+export declare const SYSTEM_PROMPT = "You are an AILF regression analyst interpreting pre-computed score deltas between two evaluation runs.\n\n## Your Output\n\nReturn a JSON object matching this exact shape:\n{\n  \"summary\": \"<1-2 sentence overview of the overall trend>\",\n  \"deltas\": [\n    {\n      \"area\": \"<feature area name \u2014 MUST match the provided delta table>\",\n      \"direction\": \"improved\" | \"regressed\" | \"unchanged\",\n      \"pointsDelta\": <number \u2014 MUST EXACTLY MATCH the pre-computed value in the delta table>,\n      \"drivers\": [\"<prose explanation of what caused this change>\"]\n    }\n  ],\n  \"overallTrend\": \"net-improved\" | \"net-regressed\" | \"mixed\" | \"stable\"\n}\n\n## CRITICAL: Do Not Modify the Numbers\n\nThe `pointsDelta` values are **pre-computed facts** from the evaluation data. Your job is ONLY to:\n1. Echo the provided delta values EXACTLY (do not round, do not \"correct\")\n2. Assign direction labels that MATCH the sign (positive pointsDelta = \"improved\", negative = \"regressed\", zero = \"unchanged\")\n3. Write `drivers` prose explaining what might have caused the change\n4. Summarize the `overallTrend`\n\n**You may not change, round, or \"correct\" any numeric value.** If you disagree with a number, write your interpretation in the `drivers` text, not by changing the number.\n\n## Direction Sign Rules\n\n- pointsDelta > 0 \u2192 direction MUST be \"improved\"\n- pointsDelta < 0 \u2192 direction MUST be \"regressed\"\n- pointsDelta = 0 \u2192 direction MUST be \"unchanged\"\n\nViolating this causes a schema validation error.\n\n## Overall Trend\n\n- \"net-improved\": majority of deltas are positive\n- \"net-regressed\": majority of deltas are negative\n- \"mixed\": roughly equal positive and negative\n- \"stable\": all deltas near zero (< 1 point)\n\n## Comparison Validity\n\nOnly analyze areas where both baseline and current runs have data. Do not speculate about areas that appear only in one run.\n\n## Tone\n\nDirect, factual. Focus on which areas moved and plausible explanations based on the report context. Avoid marketing language.";

package/dist/_vendor/ailf-core/services/diagnosis/prompts/regression-vs-baseline.system.js

@@ -0,0 +1,63 @@
+/**
+ * System prompt for the regression-vs-baseline card.
+ *
+ * Card: regression-vs-baseline
+ * Model: claude-opus-4-6 (high-stakes card)
+ * Version: regression-vs-baseline@0.1.0
+ *
+ * Mitigations embedded:
+ * - failure-mode #1: fabricated metric deltas — deltas are pre-computed in JS;
+ *   this prompt instructs the LLM NOT to change or round them
+ *
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-AI-SPEC.md §4b
+ */
+export const SYSTEM_PROMPT = `You are an AILF regression analyst interpreting pre-computed score deltas between two evaluation runs.
+
+## Your Output
+
+Return a JSON object matching this exact shape:
+{
+  "summary": "<1-2 sentence overview of the overall trend>",
+  "deltas": [
+    {
+      "area": "<feature area name — MUST match the provided delta table>",
+      "direction": "improved" | "regressed" | "unchanged",
+      "pointsDelta": <number — MUST EXACTLY MATCH the pre-computed value in the delta table>,
+      "drivers": ["<prose explanation of what caused this change>"]
+    }
+  ],
+  "overallTrend": "net-improved" | "net-regressed" | "mixed" | "stable"
+}
+
+## CRITICAL: Do Not Modify the Numbers
+
+The \`pointsDelta\` values are **pre-computed facts** from the evaluation data. Your job is ONLY to:
+1. Echo the provided delta values EXACTLY (do not round, do not "correct")
+2. Assign direction labels that MATCH the sign (positive pointsDelta = "improved", negative = "regressed", zero = "unchanged")
+3. Write \`drivers\` prose explaining what might have caused the change
+4. Summarize the \`overallTrend\`
+
+**You may not change, round, or "correct" any numeric value.** If you disagree with a number, write your interpretation in the \`drivers\` text, not by changing the number.
+
+## Direction Sign Rules
+
+- pointsDelta > 0 → direction MUST be "improved"
+- pointsDelta < 0 → direction MUST be "regressed"
+- pointsDelta = 0 → direction MUST be "unchanged"
+
+Violating this causes a schema validation error.
+
+## Overall Trend
+
+- "net-improved": majority of deltas are positive
+- "net-regressed": majority of deltas are negative
+- "mixed": roughly equal positive and negative
+- "stable": all deltas near zero (< 1 point)
+
+## Comparison Validity
+
+Only analyze areas where both baseline and current runs have data. Do not speculate about areas that appear only in one run.
+
+## Tone
+
+Direct, factual. Focus on which areas moved and plausible explanations based on the report context. Avoid marketing language.`;

package/dist/_vendor/ailf-core/services/diagnosis/prompts/top-recommendations.system.d.ts

@@ -0,0 +1,16 @@
+/**
+ * System prompt for the top-recommendations card.
+ *
+ * Card: top-recommendations
+ * Model: claude-opus-4-6 (high-stakes card)
+ * Version: top-recommendations@0.1.0
+ *
+ * Mitigations embedded:
+ * - failure-mode #2: "Improve the introduction" anti-pattern — 2 few-shot
+ *   pairs showing good vs bad recommendations
+ * - failure-mode #5: docSlug allow-list — prompt instructs LLM to pick slugs
+ *   from the provided manifest; Zod refine enforces this at parse time
+ *
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-AI-SPEC.md §4b
+ */
+export declare const SYSTEM_PROMPT = "You are a senior documentation engineer analyzing AILF (AI Literacy Framework) evaluation reports. Your task is to generate concrete, actionable recommendations for improving Sanity documentation.\n\n## Your Output\n\nReturn a JSON object matching this exact shape:\n{\n  \"summary\": \"<1-2 sentence overview of the top issues>\",\n  \"suggestions\": [\n    {\n      \"title\": \"<specific action title>\",\n      \"body\": \"<specific change to make, 40+ chars, must cite `docSlug` and the exact artifact/flag/API involved>\",\n      \"priority\": \"high\" | \"medium\" | \"low\",\n      \"docSlug\": \"<MUST be a slug from the provided allow-list>\",\n      \"sectionHeading\": \"<exact section heading to edit, or null if targeting the whole page>\"\n    }\n  ]\n}\n\nReturn 1-5 suggestions, sorted by priority (high first).\n\n## Critical Rules\n\n1. **docSlug MUST be from the provided allow-list** \u2014 never invent slugs. If you cannot match a recommendation to a slug in the allow-list, omit that recommendation.\n2. **body MUST be \u226540 characters and cite a concrete artifact** \u2014 the body must include at least one backtick-delimited term (e.g., a CLI flag like `--dataset production`, a type like `SanityClient`, a section like `\u00A7Working Examples`).\n3. **Do not recommend \"improve the introduction\" or vague clarifications** \u2014 every recommendation must name a specific doc, specific section, and specific change.\n\n## Few-Shot Examples\n\n### Good recommendation (DO THIS):\n{\n  \"title\": \"Add --dry-run worked example to schema-deploy docs\",\n  \"body\": \"Add a worked example under \u00A7Worked Examples showing `ailf run --dataset production --dry-run` interaction: what the command prints, what it skips, and when to use it before a destructive change.\",\n  \"priority\": \"high\",\n  \"docSlug\": \"/docs/cli/schema-deploy\",\n  \"sectionHeading\": \"Worked Examples\"\n}\n\n### Bad recommendation (DO NOT DO THIS):\n{\n  \"title\": \"Improve the introduction\",\n  \"body\": \"Consider clarifying the introduction to make it more user-friendly.\",\n  \"priority\": \"high\",\n  \"docSlug\": \"/docs/cli/schema-deploy\",\n  \"sectionHeading\": null\n}\n\nThe bad recommendation is rejected because:\n- \"improve the introduction\" is generic \u2014 every doc has an intro\n- \"make it more user-friendly\" names no artifact, flag, or change\n- A content engineer cannot start work from this recommendation\n\n### Good recommendation \u2014 another example (DO THIS):\n{\n  \"title\": \"Document GROQ projection syntax for nested arrays\",\n  \"body\": \"Add \u00A7Nested Array Projections to the GROQ reference showing how `_id` and `slug.current` projections behave differently under array[]`{...}` traversal \u2014 a common source of `null` in queries.\",\n  \"priority\": \"medium\",\n  \"docSlug\": \"/docs/how-it-works/querying\",\n  \"sectionHeading\": \"Nested Array Projections\"\n}\n\n## Tone\n\nWrite for a senior Sanity content engineer reading triage notes at 10pm. Direct, technical, present-tense. No marketing softeners.";

package/dist/_vendor/ailf-core/services/diagnosis/prompts/top-recommendations.system.js

@@ -0,0 +1,78 @@
+/**
+ * System prompt for the top-recommendations card.
+ *
+ * Card: top-recommendations
+ * Model: claude-opus-4-6 (high-stakes card)
+ * Version: top-recommendations@0.1.0
+ *
+ * Mitigations embedded:
+ * - failure-mode #2: "Improve the introduction" anti-pattern — 2 few-shot
+ *   pairs showing good vs bad recommendations
+ * - failure-mode #5: docSlug allow-list — prompt instructs LLM to pick slugs
+ *   from the provided manifest; Zod refine enforces this at parse time
+ *
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-AI-SPEC.md §4b
+ */
+export const SYSTEM_PROMPT = `You are a senior documentation engineer analyzing AILF (AI Literacy Framework) evaluation reports. Your task is to generate concrete, actionable recommendations for improving Sanity documentation.
+
+## Your Output
+
+Return a JSON object matching this exact shape:
+{
+  "summary": "<1-2 sentence overview of the top issues>",
+  "suggestions": [
+    {
+      "title": "<specific action title>",
+      "body": "<specific change to make, 40+ chars, must cite \`docSlug\` and the exact artifact/flag/API involved>",
+      "priority": "high" | "medium" | "low",
+      "docSlug": "<MUST be a slug from the provided allow-list>",
+      "sectionHeading": "<exact section heading to edit, or null if targeting the whole page>"
+    }
+  ]
+}
+
+Return 1-5 suggestions, sorted by priority (high first).
+
+## Critical Rules
+
+1. **docSlug MUST be from the provided allow-list** — never invent slugs. If you cannot match a recommendation to a slug in the allow-list, omit that recommendation.
+2. **body MUST be ≥40 characters and cite a concrete artifact** — the body must include at least one backtick-delimited term (e.g., a CLI flag like \`--dataset production\`, a type like \`SanityClient\`, a section like \`§Working Examples\`).
+3. **Do not recommend "improve the introduction" or vague clarifications** — every recommendation must name a specific doc, specific section, and specific change.
+
+## Few-Shot Examples
+
+### Good recommendation (DO THIS):
+{
+  "title": "Add --dry-run worked example to schema-deploy docs",
+  "body": "Add a worked example under §Worked Examples showing \`ailf run --dataset production --dry-run\` interaction: what the command prints, what it skips, and when to use it before a destructive change.",
+  "priority": "high",
+  "docSlug": "/docs/cli/schema-deploy",
+  "sectionHeading": "Worked Examples"
+}
+
+### Bad recommendation (DO NOT DO THIS):
+{
+  "title": "Improve the introduction",
+  "body": "Consider clarifying the introduction to make it more user-friendly.",
+  "priority": "high",
+  "docSlug": "/docs/cli/schema-deploy",
+  "sectionHeading": null
+}
+
+The bad recommendation is rejected because:
+- "improve the introduction" is generic — every doc has an intro
+- "make it more user-friendly" names no artifact, flag, or change
+- A content engineer cannot start work from this recommendation
+
+### Good recommendation — another example (DO THIS):
+{
+  "title": "Document GROQ projection syntax for nested arrays",
+  "body": "Add §Nested Array Projections to the GROQ reference showing how \`_id\` and \`slug.current\` projections behave differently under array[]\`{...}\` traversal — a common source of \`null\` in queries.",
+  "priority": "medium",
+  "docSlug": "/docs/how-it-works/querying",
+  "sectionHeading": "Nested Array Projections"
+}
+
+## Tone
+
+Write for a senior Sanity content engineer reading triage notes at 10pm. Direct, technical, present-tense. No marketing softeners.`;

package/dist/_vendor/ailf-core/services/diagnosis/prompts/weakest-area.system.d.ts

@@ -0,0 +1,18 @@
+/**
+ * System prompt for the weakest-area card.
+ *
+ * Card: weakest-area
+ * Model: claude-sonnet-4-6 (routine card)
+ * Version: weakest-area@0.1.0
+ *
+ * Mitigations embedded:
+ * - failure-mode #3: confidence inflation on small samples — prompt instructs
+ *   to hedge when sampleSize < 10; Zod W3 refine enforces at parse time
+ * - failure-mode #4: taxonomy drift — failure-mode lists derived at build
+ *   time from the canonical const arrays in
+ *   `packages/core/src/grader/failure-modes/*.ts`, so the prompt and the
+ *   Zod `.refine(buildFailureModeRefinement())` validator always agree.
+ *
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-AI-SPEC.md §4b
+ */
+export declare const SYSTEM_PROMPT: string;

package/dist/_vendor/ailf-core/services/diagnosis/prompts/weakest-area.system.js

@@ -0,0 +1,74 @@
+/**
+ * System prompt for the weakest-area card.
+ *
+ * Card: weakest-area
+ * Model: claude-sonnet-4-6 (routine card)
+ * Version: weakest-area@0.1.0
+ *
+ * Mitigations embedded:
+ * - failure-mode #3: confidence inflation on small samples — prompt instructs
+ *   to hedge when sampleSize < 10; Zod W3 refine enforces at parse time
+ * - failure-mode #4: taxonomy drift — failure-mode lists derived at build
+ *   time from the canonical const arrays in
+ *   `packages/core/src/grader/failure-modes/*.ts`, so the prompt and the
+ *   Zod `.refine(buildFailureModeRefinement())` validator always agree.
+ *
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-AI-SPEC.md §4b
+ */
+import { AGENT_FAILURE_MODES, COMMON_FAILURE_MODES, KP_FAILURE_MODES, LITERACY_FAILURE_MODES, MCP_FAILURE_MODES, } from "../../../grader/failure-modes/index.js";
+const literacyList = LITERACY_FAILURE_MODES.map((m) => `- ${m}`).join("\n");
+const mcpList = MCP_FAILURE_MODES.map((m) => `- ${m}`).join("\n");
+const kpList = KP_FAILURE_MODES.map((m) => `- ${m}`).join("\n");
+const agentList = AGENT_FAILURE_MODES.map((m) => `- ${m}`).join("\n");
+const commonList = COMMON_FAILURE_MODES.join(", ");
+export const SYSTEM_PROMPT = `You are an AILF evaluation analyst identifying the documentation area most in need of improvement.
+
+## Your Output
+
+Return a JSON object matching this exact shape:
+{
+  "summary": "<1-2 sentence description of the weakest area and why>",
+  "area": "<feature area name, e.g. 'schema-deploy'>",
+  "dimension": "<MUST be one of the canonical dimensions listed below>",
+  "failureMode": "<MUST be from the canonical taxonomy for the chosen dimension>",
+  "sampleSize": <number — MUST equal the judgmentCount provided for this area>,
+  "confidence": {
+    "level": "high" | "medium" | "low",
+    "signalsPresent": <number of tasks backing this finding>,
+    "derivation": "card-type-specific"
+  }
+}
+
+## CANONICAL DIMENSIONS AND FAILURE MODES
+
+You MUST pick dimension and failureMode from this exact taxonomy. Cross-dimension combinations are invalid (e.g., "security" dimension with a literacy-only failure mode is rejected). The lists below are derived at build time from \`packages/core/src/grader/failure-modes/*.ts\` — the Zod validator on the card schema enforces the same taxonomy.
+
+### Literacy family (dimensions: task-completion, code-correctness, doc-coverage)
+Failure modes:
+${literacyList}
+Plus cross-cutting: ${commonList}
+
+### MCP family (dimensions: mcp-behavior, input-validation, output-correctness, error-handling, security)
+Failure modes:
+${mcpList}
+Plus cross-cutting: ${commonList}
+
+### Knowledge-probe family (dimensions: knowledge-probe, factual-correctness, completeness, currency)
+Failure modes:
+${kpList}
+Plus cross-cutting: ${commonList}
+
+### Agent-harness family (dimensions: agent-harness, process-quality, agent-output, tool-usage)
+Failure modes:
+${agentList}
+Plus cross-cutting: ${commonList}
+
+## Confidence Calibration Rules
+
+**CRITICAL:** When sampleSize < 10, you MUST set confidence.level = "low".
+
+- sampleSize >= 30 → "high" is appropriate
+- sampleSize >= 10 → "medium" is appropriate
+- sampleSize < 10 → MUST use "low" (small-sample hedge required)
+
+In your summary, reflect the confidence level: if "low", include language like "small sample (N=X) — re-run with broader dataset before acting".`;

package/dist/_vendor/ailf-core/services/diagnosis/registry.d.ts

@@ -12,9 +12,19 @@
  * `,`. Phase 1 lands the empty registry; Phase 5 registers cards via
  * the composition root, not by mutating this binding.
  *
+ * NOTE (Phase 5 / D-06): The runtime `CardRegistry` type used by the
+ * engine lives on `services/diagnosis-runner.ts` as
+ * `Readonly<Record<CardType, CardGenerator>>`. This file's `cardRegistry`
+ * is an intentionally-empty Phase-1 placeholder for Phase-1 contract
+ * tests. DO NOT mutate `cardRegistry` or add cards here — the composition
+ * root (Plan 06) builds and passes the `CardRegistry` literal into
+ * `createDiagnosisRunner(deps)`.
+ *
+ * @see packages/core/src/services/diagnosis-runner.ts (CardRegistry type)
  * @see docs/decisions/D0045-type-architecture-and-contract-enforcement.md
  * @see docs/decisions/D0048-engine-homes-for-cli-api-parity.md
  * @see .planning/phases/01-foundation-contracts-cross-cutting-schemas/01-CONTEXT.md (D-02, D-08)
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-CONTEXT.md (D-06)
  */
 import type { z } from "zod";
 import type { CardType, DiagnosisCard } from "../../types/diagnosis.js";

package/dist/_vendor/ailf-core/services/diagnosis/registry.js

@@ -12,9 +12,19 @@
  * `,`. Phase 1 lands the empty registry; Phase 5 registers cards via
  * the composition root, not by mutating this binding.
  *
+ * NOTE (Phase 5 / D-06): The runtime `CardRegistry` type used by the
+ * engine lives on `services/diagnosis-runner.ts` as
+ * `Readonly<Record<CardType, CardGenerator>>`. This file's `cardRegistry`
+ * is an intentionally-empty Phase-1 placeholder for Phase-1 contract
+ * tests. DO NOT mutate `cardRegistry` or add cards here — the composition
+ * root (Plan 06) builds and passes the `CardRegistry` literal into
+ * `createDiagnosisRunner(deps)`.
+ *
+ * @see packages/core/src/services/diagnosis-runner.ts (CardRegistry type)
  * @see docs/decisions/D0045-type-architecture-and-contract-enforcement.md
  * @see docs/decisions/D0048-engine-homes-for-cli-api-parity.md
  * @see .planning/phases/01-foundation-contracts-cross-cutting-schemas/01-CONTEXT.md (D-02, D-08)
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-CONTEXT.md (D-06)
  */
 /**
  * Phase 1: empty entrypoint. Phase 5 cards register here through the

package/dist/_vendor/ailf-core/services/diagnosis-runner.d.ts

@@ -1,12 +1,23 @@
 /**
  * Diagnosis runner — engine entry point (D0048).
  *
- * Phase 1 lands the version constant only; the runner factory + cache
- * lookup land in Phase 5.
+ * Phase 5 implements the factory body; Phase 1 shipped `diagnosisVersion` only.
+ * `GeneratorContext.judgmentAttributions` is sourced once per `.run({...})` via
+ * `deps.loadAttributions(runId)` reading Phase 4's
+ * `runs/{runId}/attribution/{entryKey}.json` per-entry artifacts (RESEARCH
+ * Landmine 11).
  *
  * @see docs/decisions/D0048-engine-homes-for-cli-api-parity.md
  * @see .planning/phases/01-foundation-contracts-cross-cutting-schemas/01-CONTEXT.md (D-02)
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-RESEARCH.md (Landmine 11)
+ * @see .planning/phases/05-diagnosis-engine-cli-llm-cards/05-CONTEXT.md (D-02, D-06, D-10)
  */
+import type { LLMClient, ModelId } from "../ports/llm-client.js";
+import type { Logger } from "../ports/logger.js";
+import type { ProgressReporter } from "../ports/progress-reporter.js";
+import type { JudgmentAttribution } from "../types/attribution.js";
+import type { CardType, Diagnosis, DiagnosisCard, VersionedInputs } from "../types/diagnosis.js";
+import type { Report } from "../types/index.js";
 /**
  * Bumped when the runner's selection logic, prompt orchestration, or
  * card-set composition changes in a way that should invalidate cached
@@ -17,3 +28,109 @@
  * across vitest workers (cross-cutting hazard #2).
  */
 export declare const diagnosisVersion = "0.1.0";
+/**
+ * Per-invocation context threaded into every card generator.
+ *
+ * `judgmentAttributions` is the Landmine-11 addition — Phase 4 emits
+ * per-judgment attribution as per-entry GCS artifacts at
+ * `runs/{runId}/attribution/{entryKey}.json`. The runner loads them once
+ * per `.run({...})` via `deps.loadAttributions(runId)` and threads the
+ * result here. Cards that need attribution inspect this field and return
+ * `status: "missing"` when it is `undefined` or empty.
+ */
+export interface GeneratorContext {
+    readonly llm: LLMClient | undefined;
+    readonly model: ModelId;
+    readonly logger: Logger;
+    readonly progress: ProgressReporter;
+    readonly versions: VersionedInputs;
+    readonly runId: string;
+    readonly reportId: string;
+    readonly baseline?: Report;
+    /** Phase-4 attribution array, loaded once per run (Landmine 11). */
+    readonly judgmentAttributions?: JudgmentAttribution[];
+}
+/**
+ * Per-card generator function. Pure async function; the runner wraps
+ * each invocation in try/catch so generators MUST NOT suppress their
+ * own errors — throw freely; the runner owns error translation.
+ */
+export type CardGenerator = (report: Report, ctx: GeneratorContext) => Promise<DiagnosisCard>;
+/**
+ * Flat registry of all 8 card types → generator functions. Lives here
+ * (NOT in `services/diagnosis/registry.ts`) per CONTEXT D-06 — the
+ * Phase-1 `cardRegistry` placeholder stays empty to keep the contract
+ * test green; the composition root builds a `CardRegistry` literal and
+ * passes it into `createDiagnosisRunner(deps)`.
+ *
+ * `Readonly<Record<CardType, CardGenerator>>` — TypeScript exhaustiveness
+ * ensures all 8 literal `CardType` strings appear in any registry literal
+ * (no rogue keys, no silently missing keys).
+ */
+export type CardRegistry = Readonly<Record<CardType, CardGenerator>>;
+/**
+ * Dependencies for the diagnosis runner factory.
+ *
+ * D-02 delta vs. AI-SPEC §3: `cache: CacheStore` is replaced by two
+ * narrow callback deps so the engine uses the artifact store directly
+ * without needing a `CacheStore.get/set` API that doesn't exist.
+ *
+ * Landmine-11 addition: `loadAttributions` lets the composition root bind
+ * a reader over `ARTIFACT_REGISTRY.perEntryAttribution` without widening
+ * the `CacheStore` port.
+ */
+export interface DiagnosisRunnerDeps {
+    /**
+     * Cache-lookup hook. Receives the artifact path built from the
+     * 4-version + model cache key. Plan 06's composition root supplies a
+     * reader that parses cached bytes through the Diagnosis Zod schema
+     * (T-05-04-01 mitigation). Tests supply a simple fake.
+     *
+     * Returns `null` on miss; returns the cached `Diagnosis` on hit.
+     */
+    readonly diagnosisReader: (path: string) => Promise<Diagnosis | null>;
+    /**
+     * Cache-write hook. Receives the same path as `diagnosisReader` plus
+     * the freshly-built `Diagnosis`. Called unconditionally after every
+     * successful run (including `refresh: true` — a refreshed call
+     * replaces the cached Diagnosis per AI-SPEC §3).
+     */
+    readonly diagnosisWriter: (path: string, diagnosis: Diagnosis) => Promise<void>;
+    /**
+     * Attribution loader — invoked once per `.run({...})` with
+     * `report.provenance.runId`. Rejection is caught by the runner; the
+     * resolved value (including `[]`) is threaded into every
+     * `GeneratorContext.judgmentAttributions` (Landmine 11).
+     */
+    readonly loadAttributions: (runId: string) => Promise<JudgmentAttribution[]>;
+    readonly llm: LLMClient | undefined;
+    readonly model: ModelId;
+    readonly logger: Logger;
+    readonly progress: ProgressReporter;
+    readonly registry: CardRegistry;
+}
+/**
+ * Arguments for a single diagnosis run.
+ */
+export interface DiagnosisRunnerRunArgs {
+    readonly report: Report;
+    readonly versions: VersionedInputs;
+    readonly baseline?: Report;
+    /** When `true`, bypasses the cache lookup (but still writes on completion). */
+    readonly refresh?: boolean;
+}
+/**
+ * The diagnosis runner interface. A single `.run()` method returns a
+ * fully-assembled `Diagnosis` (or a partial one if some cards degraded).
+ */
+export interface DiagnosisRunner {
+    run(args: DiagnosisRunnerRunArgs): Promise<Diagnosis>;
+}
+/**
+ * Build a `DiagnosisRunner` whose `.run({report, versions, baseline?, refresh?})`
+ * produces a `Diagnosis` with cards in registry-order.
+ *
+ * No module-scope `let` — all state lives in the `deps` closure and per-run
+ * local variables (AI-SPEC §3 Pitfall 1).
+ */
+export declare function createDiagnosisRunner(deps: DiagnosisRunnerDeps): DiagnosisRunner;