@sanity/ailf 0.1.18 → 0.1.20

package/dist/_vendor/ailf-core/examples/index.d.ts

@@ -151,30 +151,30 @@ export declare const exampleGroqBlogListingYaml = "# \u2500\u2500\u2500\u2500\u2
 /** Parsed task data for example-id-based-ref (JSON-safe) */
 export declare const exampleIdBasedRefData: readonly [{
     readonly id: "example-id-based-ref";
-    readonly description: "Example — GROQ cheat sheet (ID-based doc references)";
+    readonly description: "Example — GROQ feature support (ID-based doc references)";
     readonly featureArea: "groq";
     readonly canonicalDocs: readonly [{
-        readonly id: "81b839a4-2fc1-4769-941a-ec4de9276492";
-        readonly slug: "query-cheat-sheet";
-        readonly reason: "GROQ query patterns and cheat sheet reference";
+        readonly id: "0ba88f1b-d1a7-418a-9267-2e343d01886a";
+        readonly slug: "groq-feature-support-by-context";
+        readonly reason: "GROQ feature support across different Sanity contexts";
     }, {
-        readonly id: "44e5fc43-4628-4a4c-8e00-6ae12b83b8d2";
-        readonly slug: "groq-introduction";
-        readonly reason: "Core GROQ syntax and language overview";
+        readonly id: "5b9c2863-ef01-4565-af8e-ee54e081ee74";
+        readonly slug: "custom-groq-functions";
+        readonly reason: "Custom GROQ functions and pipelines";
     }];
     readonly docCoverage: true;
     readonly vars: {
-        readonly task: "Using the GROQ query language, write queries for the following\ncommon content operations:\n1. Fetch all documents of type \"post\" with title and slug\n2. Filter posts published after a specific date\n3. Sort results by publishedAt descending with a limit of 10\n4. Join author data from a reference field\nExplain each query pattern and when to use it.\n";
+        readonly task: "Explain how GROQ is used across different Sanity contexts.\nCover the following:\n1. Which GROQ features are available in each context (API queries,\n   webhooks, custom functions, access control)\n2. How to create and use custom GROQ functions\n3. Any differences in GROQ support between contexts\nProvide examples demonstrating context-specific GROQ patterns.\n";
         readonly docs: "";
     };
     readonly assert: readonly [{
         readonly type: "llm-rubric";
         readonly template: "task-completion";
-        readonly criteria: readonly ["Provides a GROQ query that filters by _type", "Demonstrates date-based filtering", "Shows ordering with order() and slicing for limits", "Demonstrates reference expansion (dereferencing with ->)"];
+        readonly criteria: readonly ["Explains GROQ availability across different Sanity contexts", "Describes custom GROQ function creation and usage", "Notes differences in GROQ support between contexts"];
     }, {
         readonly type: "llm-rubric";
         readonly template: "code-correctness";
-        readonly criteria: readonly ["All GROQ queries use valid syntax", "Projections correctly select and alias fields"];
+        readonly criteria: readonly ["GROQ examples use valid syntax", "Custom function examples follow the correct API pattern"];
     }];
     readonly baseline: {
         readonly enabled: true;
@@ -185,75 +185,32 @@ export declare const exampleIdBasedRefData: readonly [{
     };
 }];
 /** Raw YAML string for example-id-based-ref (preserves comments) */
-export declare const exampleIdBasedRefYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n# Example Task: Document ID-based canonical doc references\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n#\n# Demonstrates using `id` to reference canonical documentation by\n# Sanity document `_id`. This is useful for:\n#   - Draft documents that don't have a stable slug yet\n#   - Programmatic references from imports or migrations\n#   - Documents where you know the _id but not the slug\n#\n# The `id` ref type can also carry optional `slug` and `path` fields\n# as human-readable annotations \u2014 these are NOT used for resolution,\n# only for display in logs and reports.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\n- id: example-id-based-ref\n  description: \"Example \u2014 GROQ cheat sheet (ID-based doc references)\"\n\n  featureArea: groq\n\n  # ID-based canonical doc references.\n  #\n  # Use the Sanity document _id to reference articles directly.\n  # Optional slug/path annotations help humans reading the YAML\n  # but are NOT used for resolution \u2014 only the `id` field matters.\n  #\n  # These IDs reference real articles in the Sanity docs (next dataset):\n  #   81b839a4... = \"Query Cheat Sheet - GROQ\"\n  #   44e5fc43... = \"GROQ introduction\"\n  canonicalDocs:\n    - id: \"81b839a4-2fc1-4769-941a-ec4de9276492\"\n      slug: query-cheat-sheet # annotation only \u2014 not used for resolution\n      reason: \"GROQ query patterns and cheat sheet reference\"\n    - id: \"44e5fc43-4628-4a4c-8e00-6ae12b83b8d2\"\n      slug: groq-introduction # annotation only \u2014 not used for resolution\n      reason: \"Core GROQ syntax and language overview\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Using the GROQ query language, write queries for the following\n      common content operations:\n      1. Fetch all documents of type \"post\" with title and slug\n      2. Filter posts published after a specific date\n      3. Sort results by publishedAt descending with a limit of 10\n      4. Join author data from a reference field\n      Explain each query pattern and when to use it.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Provides a GROQ query that filters by _type\"\n        - \"Demonstrates date-based filtering\"\n        - \"Shows ordering with order() and slicing for limits\"\n        - \"Demonstrates reference expansion (dereferencing with ->)\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"All GROQ queries use valid syntax\"\n        - \"Projections correctly select and alias fields\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
-/** Parsed task data for example-mixed-ref-types (JSON-safe) */
-export declare const exampleMixedRefTypesData: readonly [{
-    readonly id: "example-mixed-ref-types";
-    readonly description: "Example — Mixed canonical doc reference types (slug + path + id + perspective)";
-    readonly featureArea: "groq";
-    readonly canonicalDocs: readonly [{
-        readonly slug: "groq-introduction";
-        readonly reason: "Core GROQ language overview";
-    }, {
-        readonly path: "content-lake/how-queries-work";
-        readonly reason: "Query execution model (disambiguated by section)";
-    }, {
-        readonly id: "81b839a4-2fc1-4769-941a-ec4de9276492";
-        readonly slug: "query-cheat-sheet";
-        readonly reason: "GROQ query patterns cheat sheet (referenced by document ID)";
-    }, {
-        readonly perspective: "rE9TSJvR4";
-        readonly reason: "Additional GROQ docs from the test content release";
-    }];
-    readonly docCoverage: true;
-    readonly vars: {
-        readonly task: "Create a comprehensive GROQ query guide that covers:\n1. Basic query structure and filtering by document type\n2. Projections and field selection\n3. Ordering, slicing, and pagination\n4. Reference joins and nested data\n5. Webhook GROQ filter configuration\nInclude working examples for each concept and explain the\nquery execution model.\n";
-        readonly docs: "";
-    };
-    readonly assert: readonly [{
-        readonly type: "llm-rubric";
-        readonly template: "task-completion";
-        readonly criteria: readonly ["Covers basic GROQ query structure with _type filtering", "Demonstrates projections with field aliasing", "Shows ordering with order() and slice syntax", "Includes reference joins with the dereference operator", "Explains webhook GROQ filter patterns"];
-    }, {
-        readonly type: "llm-rubric";
-        readonly template: "code-correctness";
-        readonly criteria: readonly ["All GROQ queries use valid syntax", "Examples are practical and self-contained"];
-    }];
-    readonly baseline: {
-        readonly enabled: true;
-        readonly rubric: "abbreviated";
-    };
-    readonly execution: {
-        readonly enabled: false;
-    };
-}];
-/** Raw YAML string for example-mixed-ref-types (preserves comments) */
-export declare const exampleMixedRefTypesYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n# Example Task: All canonical doc reference types in one task\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n#\n# Demonstrates combining all four canonical doc reference strategies\n# in a single task's canonicalDocs array:\n#\n#   slug        \u2014 by article slug (simplest, may not be unique)\n#   path        \u2014 by section/slug path (unique, preferred)\n#   id          \u2014 by Sanity document _id (for drafts, imports)\n#   perspective \u2014 by content release (one-to-many expansion)\n#\n# Each reference type resolves through a different strategy, but the\n# pipeline merges them into a single flat documentation context. The\n# LLM sees the same combined markdown regardless of how docs were found.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\n- id: example-mixed-ref-types\n  description:\n    \"Example \u2014 Mixed canonical doc reference types (slug + path + id +\n    perspective)\"\n\n  featureArea: groq\n\n  # All four canonical doc reference types demonstrated together.\n  #\n  # The pipeline resolves each ref independently:\n  #   1. slug refs \u2192 GROQ query by slug.current\n  #   2. path refs \u2192 GROQ query by section + slug (or slug fallback)\n  #   3. id refs   \u2192 GROQ query by _id\n  #   4. perspective refs \u2192 expand to all articles in the release\n  #\n  # After resolution, all entries become a flat list of document slugs.\n  # The fetched markdown is concatenated into a single context string.\n  canonicalDocs:\n    # Slug reference \u2014 simplest form, resolves by article slug\n    - slug: groq-introduction\n      reason: \"Core GROQ language overview\"\n\n    # Path reference \u2014 section-qualified, uniquely identifies the article\n    - path: content-lake/how-queries-work\n      reason: \"Query execution model (disambiguated by section)\"\n\n    # ID reference \u2014 resolves by Sanity document _id\n    # Optional slug annotation helps humans reading the YAML\n    - id: \"81b839a4-2fc1-4769-941a-ec4de9276492\"\n      slug: query-cheat-sheet\n      reason: \"GROQ query patterns cheat sheet (referenced by document ID)\"\n\n    # Perspective reference \u2014 expands to all articles in the release\n    # This adds webhooks, query-cheat-sheet, and groq-joins from release rE9TSJvR4\n    # Note: query-cheat-sheet appears via both the id ref and the perspective ref,\n    # but the pipeline deduplicates slugs automatically.\n    - perspective: rE9TSJvR4\n      reason: \"Additional GROQ docs from the test content release\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Create a comprehensive GROQ query guide that covers:\n      1. Basic query structure and filtering by document type\n      2. Projections and field selection\n      3. Ordering, slicing, and pagination\n      4. Reference joins and nested data\n      5. Webhook GROQ filter configuration\n      Include working examples for each concept and explain the\n      query execution model.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Covers basic GROQ query structure with _type filtering\"\n        - \"Demonstrates projections with field aliasing\"\n        - \"Shows ordering with order() and slice syntax\"\n        - \"Includes reference joins with the dereference operator\"\n        - \"Explains webhook GROQ filter patterns\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"All GROQ queries use valid syntax\"\n        - \"Examples are practical and self-contained\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
+export declare const exampleIdBasedRefYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n# Example Task: Document ID-based canonical doc references\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n#\n# Demonstrates using `id` to reference canonical documentation by\n# Sanity document `_id`. This is useful for:\n#   - Draft documents that don't have a stable slug yet\n#   - Programmatic references from imports or migrations\n#   - Documents where you know the _id but not the slug\n#\n# The `id` ref type can also carry optional `slug` and `path` fields\n# as human-readable annotations \u2014 these are NOT used for resolution,\n# only for display in logs and reports.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\n- id: example-id-based-ref\n  description: \"Example \u2014 GROQ feature support (ID-based doc references)\"\n\n  featureArea: groq\n\n  # ID-based canonical doc references.\n  #\n  # Use the Sanity document _id to reference articles directly.\n  # Optional slug/path annotations help humans reading the YAML\n  # but are NOT used for resolution \u2014 only the `id` field matters.\n  #\n  # These IDs reference real articles in the Sanity docs (next dataset):\n  #   0ba88f1b... = \"GROQ feature support across Sanity\"\n  #   5b9c2863... = \"Custom GROQ functions\"\n  canonicalDocs:\n    - id: \"0ba88f1b-d1a7-418a-9267-2e343d01886a\"\n      slug: groq-feature-support-by-context # annotation only \u2014 not used for resolution\n      reason: \"GROQ feature support across different Sanity contexts\"\n    - id: \"5b9c2863-ef01-4565-af8e-ee54e081ee74\"\n      slug: custom-groq-functions # annotation only \u2014 not used for resolution\n      reason: \"Custom GROQ functions and pipelines\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Explain how GROQ is used across different Sanity contexts.\n      Cover the following:\n      1. Which GROQ features are available in each context (API queries,\n         webhooks, custom functions, access control)\n      2. How to create and use custom GROQ functions\n      3. Any differences in GROQ support between contexts\n      Provide examples demonstrating context-specific GROQ patterns.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Explains GROQ availability across different Sanity contexts\"\n        - \"Describes custom GROQ function creation and usage\"\n        - \"Notes differences in GROQ support between contexts\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"GROQ examples use valid syntax\"\n        - \"Custom function examples follow the correct API pattern\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
 /** Parsed task data for example-path-based-ref (JSON-safe) */
 export declare const examplePathBasedRefData: readonly [{
     readonly id: "example-path-based-ref";
-    readonly description: "Example — GROQ webhooks (path-based doc references)";
+    readonly description: "Example — GROQ mutations (path-based doc references)";
     readonly featureArea: "groq";
     readonly canonicalDocs: readonly [{
-        readonly path: "content-lake/webhooks";
-        readonly reason: "GROQ-powered webhooks configuration and GROQ filter patterns";
+        readonly path: "content-lake/mutations-introduction";
+        readonly reason: "Introduction to document mutations in the Content Lake";
     }, {
-        readonly path: "content-lake/how-queries-work";
-        readonly reason: "How GROQ queries execute — projection, filtering, ordering";
+        readonly path: "content-lake/documents";
+        readonly reason: "Document structure and types (Content Lake, not CLI reference)";
     }];
     readonly docCoverage: true;
     readonly vars: {
-        readonly task: "Create a webhook configuration for a Sanity project that triggers\nwhen blog post documents are published. The webhook should use a\nGROQ filter to match only documents of type \"post\" and a GROQ\nprojection to include the title, slug, and publishedAt fields in\nthe webhook payload. Explain the GROQ filter syntax used.\n";
+        readonly task: "Explain how to create, update, and delete documents in Sanity's\nContent Lake using mutations. Cover:\n1. The different mutation types (create, createOrReplace, patch, delete)\n2. Document structure and required fields (_id, _type)\n3. How to use patch operations to update specific fields\n4. Best practices for mutation patterns\nProvide working code examples using @sanity/client.\n";
         readonly docs: "";
     };
     readonly assert: readonly [{
         readonly type: "llm-rubric";
         readonly template: "task-completion";
-        readonly criteria: readonly ["Configures a webhook with a GROQ filter for _type == 'post'", "Uses a GROQ projection to shape the payload", "Includes title, slug, and publishedAt in the projection", "Explains when the webhook fires (on publish events)"];
+        readonly criteria: readonly ["Explains create, createOrReplace, patch, and delete mutations", "Describes required document fields (_id, _type)", "Shows patch operations for field-level updates", "Includes practical code examples"];
     }, {
         readonly type: "llm-rubric";
         readonly template: "code-correctness";
-        readonly criteria: readonly ["GROQ filter syntax is valid", "Projection syntax correctly selects nested fields"];
+        readonly criteria: readonly ["Uses correct @sanity/client mutation API", "Patch operations use valid set/unset/inc syntax"];
     }];
     readonly baseline: {
         readonly enabled: true;
@@ -264,7 +221,7 @@ export declare const examplePathBasedRefData: readonly [{
     };
 }];
 /** Raw YAML string for example-path-based-ref (preserves comments) */
-export declare const examplePathBasedRefYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n# Example Task: Path-based canonical doc references\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n#\n# Demonstrates using `path` to reference canonical documentation.\n# Paths are the preferred reference type because they uniquely identify\n# an article across sections (unlike slugs, which can collide).\n#\n# Path format:\n#   - Simple:   \"webhooks\"              \u2192 resolves by slug lookup\n#   - Sectioned: \"content-lake/webhooks\" \u2192 disambiguates by section + slug\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\n- id: example-path-based-ref\n  description: \"Example \u2014 GROQ webhooks (path-based doc references)\"\n\n  featureArea: groq\n\n  # Path-based canonical doc references.\n  #\n  # Use \"section/slug\" format to uniquely identify articles:\n  #   - \"content-lake/webhooks\" \u2192 the webhooks article in the Content Lake section\n  #   - \"content-lake/how-queries-work\" \u2192 disambiguated from any other section\n  #\n  # Simple paths (just the slug) also work but don't disambiguate sections.\n  canonicalDocs:\n    - path: content-lake/webhooks\n      reason: \"GROQ-powered webhooks configuration and GROQ filter patterns\"\n    - path: content-lake/how-queries-work\n      reason: \"How GROQ queries execute \u2014 projection, filtering, ordering\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Create a webhook configuration for a Sanity project that triggers\n      when blog post documents are published. The webhook should use a\n      GROQ filter to match only documents of type \"post\" and a GROQ\n      projection to include the title, slug, and publishedAt fields in\n      the webhook payload. Explain the GROQ filter syntax used.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Configures a webhook with a GROQ filter for _type == 'post'\"\n        - \"Uses a GROQ projection to shape the payload\"\n        - \"Includes title, slug, and publishedAt in the projection\"\n        - \"Explains when the webhook fires (on publish events)\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"GROQ filter syntax is valid\"\n        - \"Projection syntax correctly selects nested fields\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
+export declare const examplePathBasedRefYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n# Example Task: Path-based canonical doc references\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n#\n# Demonstrates using `path` to reference canonical documentation.\n# Paths are the preferred reference type because they uniquely identify\n# an article across sections (unlike slugs, which can collide).\n#\n# Path format:\n#   - Simple:   \"webhooks\"              \u2192 resolves by slug lookup\n#   - Sectioned: \"content-lake/webhooks\" \u2192 disambiguates by section + slug\n#\n# This example demonstrates why paths matter: the slug \"documents\"\n# exists in both the \"content-lake\" and \"cli-reference\" sections.\n# Using \"content-lake/documents\" ensures we get the right one.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\n- id: example-path-based-ref\n  description: \"Example \u2014 GROQ mutations (path-based doc references)\"\n\n  featureArea: groq\n\n  # Path-based canonical doc references.\n  #\n  # Use \"section/slug\" format to uniquely identify articles:\n  #   - \"content-lake/mutations-introduction\" \u2192 the mutations article\n  #   - \"content-lake/documents\" \u2192 the documents article in Content Lake\n  #     (not the CLI \"documents\" article in cli-reference section)\n  #\n  # The \"documents\" slug exists in two sections \u2014 this is exactly why\n  # path-based references are preferred over slug-based references.\n  canonicalDocs:\n    - path: content-lake/mutations-introduction\n      reason: \"Introduction to document mutations in the Content Lake\"\n    - path: content-lake/documents\n      reason: \"Document structure and types (Content Lake, not CLI reference)\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Explain how to create, update, and delete documents in Sanity's\n      Content Lake using mutations. Cover:\n      1. The different mutation types (create, createOrReplace, patch, delete)\n      2. Document structure and required fields (_id, _type)\n      3. How to use patch operations to update specific fields\n      4. Best practices for mutation patterns\n      Provide working code examples using @sanity/client.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Explains create, createOrReplace, patch, and delete mutations\"\n        - \"Describes required document fields (_id, _type)\"\n        - \"Shows patch operations for field-level updates\"\n        - \"Includes practical code examples\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"Uses correct @sanity/client mutation API\"\n        - \"Patch operations use valid set/unset/inc syntax\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
 /** Parsed task data for example-perspective-ref (JSON-safe) */
 export declare const examplePerspectiveRefData: readonly [{
     readonly id: "example-perspective-ref";
@@ -274,12 +231,12 @@ export declare const examplePerspectiveRefData: readonly [{
         readonly perspective: "rE9TSJvR4";
         readonly reason: "All GROQ documentation updates in the test content release";
     }, {
-        readonly slug: "groq-introduction";
-        readonly reason: "Foundational GROQ syntax reference (published, stable)";
+        readonly slug: "groq-data-types";
+        readonly reason: "GROQ data type reference (published, stable)";
     }];
     readonly docCoverage: true;
     readonly vars: {
-        readonly task: "Using GROQ, demonstrate advanced query patterns including:\n1. Joining data across document types using references\n2. Filtering webhook payloads with GROQ projections\n3. Using the query cheat sheet patterns for common operations\nProvide working GROQ query examples for each pattern.\n";
+        readonly task: "Using GROQ, demonstrate advanced query patterns including:\n1. Joining data across document types using references\n2. Filtering webhook payloads with GROQ projections\n3. Using the query cheat sheet patterns for common operations\n4. Working with different GROQ data types in filters\nProvide working GROQ query examples for each pattern.\n";
         readonly docs: "";
     };
     readonly assert: readonly [{
@@ -300,7 +257,7 @@ export declare const examplePerspectiveRefData: readonly [{
     };
 }];
 /** Raw YAML string for example-perspective-ref (preserves comments) */
-export declare const examplePerspectiveRefYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n# Example Task: Perspective / content release doc references\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n#\n# Demonstrates using `perspective` to reference all documentation\n# articles within a content release. This is the key capability for\n# evaluating NEW feature documentation before it's published.\n#\n# How it works:\n#   - A perspective ref is one-to-many: the doc fetcher queries the\n#     named release and expands it to ALL articles versioned within it.\n#   - Downstream consumers see the same flat DocContext[] regardless\n#     of how docs were resolved.\n#   - When the release is published, the perspective entry becomes a\n#     no-op (articles are now in published). Migrate to explicit path\n#     or slug refs at your convenience.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\n- id: example-perspective-ref\n  description:\n    \"Example \u2014 GROQ features from content release (perspective-based doc\n    references)\"\n\n  featureArea: groq\n\n  # Perspective-based canonical doc reference.\n  #\n  # The perspective ID references a content release in the Sanity\n  # Content Lake. At evaluation time, the doc fetcher auto-discovers\n  # all articles versioned in this release and includes them as\n  # canonical documentation context.\n  #\n  # Release rE9TSJvR4 contains:\n  #   - \"GROQ-powered webhooks\" (webhooks)\n  #   - \"Query Cheat Sheet - GROQ\" (query-cheat-sheet)\n  #   - \"GROQ joins\" (groq-joins)\n  #\n  # You can combine perspective refs with explicit slug/path/id refs\n  # to include foundational published docs alongside release content.\n  canonicalDocs:\n    - perspective: rE9TSJvR4\n      reason: \"All GROQ documentation updates in the test content release\"\n    - slug: groq-introduction\n      reason: \"Foundational GROQ syntax reference (published, stable)\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Using GROQ, demonstrate advanced query patterns including:\n      1. Joining data across document types using references\n      2. Filtering webhook payloads with GROQ projections\n      3. Using the query cheat sheet patterns for common operations\n      Provide working GROQ query examples for each pattern.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Demonstrates GROQ join syntax for cross-document queries\"\n        - \"Shows GROQ filter patterns for webhook configuration\"\n        - \"Includes practical query examples from cheat sheet patterns\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"All GROQ queries use valid syntax\"\n        - \"Reference joins use correct dereference operator (->)\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
+export declare const examplePerspectiveRefYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n# Example Task: Perspective / content release doc references\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n#\n# Demonstrates using `perspective` to reference all documentation\n# articles within a content release. This is the key capability for\n# evaluating NEW feature documentation before it's published.\n#\n# How it works:\n#   - A perspective ref is one-to-many: the doc fetcher queries the\n#     named release and expands it to ALL articles versioned within it.\n#   - Downstream consumers see the same flat DocContext[] regardless\n#     of how docs were resolved.\n#   - When the release is published, the perspective entry becomes a\n#     no-op (articles are now in published). Migrate to explicit path\n#     or slug refs at your convenience.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\n- id: example-perspective-ref\n  description:\n    \"Example \u2014 GROQ features from content release (perspective-based doc\n    references)\"\n\n  featureArea: groq\n\n  # Perspective-based canonical doc reference.\n  #\n  # The perspective ID references a content release in the Sanity\n  # Content Lake. At evaluation time, the doc fetcher auto-discovers\n  # all articles versioned in this release and includes them as\n  # canonical documentation context.\n  #\n  # Release rE9TSJvR4 contains:\n  #   - \"GROQ-powered webhooks\" (webhooks)\n  #   - \"Query Cheat Sheet - GROQ\" (query-cheat-sheet)\n  #   - \"GROQ joins\" (groq-joins)\n  #\n  # You can combine perspective refs with explicit slug/path/id refs\n  # to include foundational published docs alongside release content.\n  # Here we add groq-data-types as a complementary published reference.\n  canonicalDocs:\n    - perspective: rE9TSJvR4\n      reason: \"All GROQ documentation updates in the test content release\"\n    - slug: groq-data-types\n      reason: \"GROQ data type reference (published, stable)\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Using GROQ, demonstrate advanced query patterns including:\n      1. Joining data across document types using references\n      2. Filtering webhook payloads with GROQ projections\n      3. Using the query cheat sheet patterns for common operations\n      4. Working with different GROQ data types in filters\n      Provide working GROQ query examples for each pattern.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Demonstrates GROQ join syntax for cross-document queries\"\n        - \"Shows GROQ filter patterns for webhook configuration\"\n        - \"Includes practical query examples from cheat sheet patterns\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"All GROQ queries use valid syntax\"\n        - \"Reference joins use correct dereference operator (->)\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
 /** Parsed task data for example-studio-custom-input (JSON-safe) */
 export declare const exampleStudioCustomInputData: readonly [{
     readonly id: "example-studio-custom-input";
@@ -309,6 +266,9 @@ export declare const exampleStudioCustomInputData: readonly [{
     readonly canonicalDocs: readonly [{
         readonly slug: "custom-input-widgets";
         readonly reason: "Guide for building custom form inputs in Sanity Studio";
+    }, {
+        readonly slug: "form-components";
+        readonly reason: "Form component API and customization patterns";
     }];
     readonly docCoverage: true;
     readonly referenceSolution: "canonical/example-studio-custom-input.ts";
@@ -334,13 +294,13 @@ export declare const exampleStudioCustomInputData: readonly [{
     };
 }];
 /** Raw YAML string for example-studio-custom-input (preserves comments) */
-export declare const exampleStudioCustomInputYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n# Example Task: Custom input component in Sanity Studio\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n#\n# This is a starter template \u2014 edit it for your own documentation.\n# Delete this file or replace it with your own tasks.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\n- id: example-studio-custom-input\n  description: \"Example \u2014 Custom input component in Sanity Studio\"\n\n  featureArea: studio\n\n  # Slug-based canonical doc reference.\n  # Note: the correct slug is \"custom-input-widgets\" (not \"custom-input-components\").\n  canonicalDocs:\n    - slug: custom-input-widgets\n      reason: \"Guide for building custom form inputs in Sanity Studio\"\n\n  docCoverage: true\n  referenceSolution: canonical/example-studio-custom-input.ts\n\n  vars:\n    task: |\n      Build a custom string input component for Sanity Studio that shows\n      a character count below the input field. The component should accept\n      a maxLength option from the field schema and display a warning when\n      the text exceeds the limit.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Implements a React component that renders a text input\"\n        - \"Displays a live character count\"\n        - \"Reads maxLength from schema options\"\n        - \"Shows a visual warning when limit is exceeded\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"Uses the Sanity UI library for styling\"\n        - \"Calls onChange with patch operations\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
+export declare const exampleStudioCustomInputYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n# Example Task: Custom input component in Sanity Studio\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n#\n# This is a starter template \u2014 edit it for your own documentation.\n# Delete this file or replace it with your own tasks.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\n- id: example-studio-custom-input\n  description: \"Example \u2014 Custom input component in Sanity Studio\"\n\n  featureArea: studio\n\n  # Slug-based canonical doc references.\n  canonicalDocs:\n    - slug: custom-input-widgets\n      reason: \"Guide for building custom form inputs in Sanity Studio\"\n    - slug: form-components\n      reason: \"Form component API and customization patterns\"\n\n  docCoverage: true\n  referenceSolution: canonical/example-studio-custom-input.ts\n\n  vars:\n    task: |\n      Build a custom string input component for Sanity Studio that shows\n      a character count below the input field. The component should accept\n      a maxLength option from the field schema and display a warning when\n      the text exceeds the limit.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Implements a React component that renders a text input\"\n        - \"Displays a live character count\"\n        - \"Reads maxLength from schema options\"\n        - \"Shows a visual warning when limit is exceeded\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"Uses the Sanity UI library for styling\"\n        - \"Calls onChange with patch operations\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
 /** All task example data as a flat array (JSON-safe) */
 export declare const allTaskData: readonly unknown[];
 /** Map of task ID (filename stem) → raw YAML string (preserves comments) */
 export declare const taskYamlFiles: Record<string, string>;
 /** List of task file stems, in alphabetical order */
-export declare const TASK_FILE_NAMES: readonly ["example-groq-blog-listing", "example-id-based-ref", "example-mixed-ref-types", "example-path-based-ref", "example-perspective-ref", "example-studio-custom-input"];
+export declare const TASK_FILE_NAMES: readonly ["example-groq-blog-listing", "example-id-based-ref", "example-path-based-ref", "example-perspective-ref", "example-studio-custom-input"];
 export type ExampleType = "config" | "source" | "rubric" | "threshold" | "ailf-config" | "task";
 export declare const EXAMPLE_TYPES: readonly ExampleType[];
 export interface ExampleRecord {

package/dist/_vendor/ailf-core/examples/index.js

@@ -198,23 +198,23 @@ export const exampleGroqBlogListingYaml = "# ───────────
 export const exampleIdBasedRefData = [
     {
         "id": "example-id-based-ref",
-        "description": "Example — GROQ cheat sheet (ID-based doc references)",
+        "description": "Example — GROQ feature support (ID-based doc references)",
         "featureArea": "groq",
         "canonicalDocs": [
             {
-                "id": "81b839a4-2fc1-4769-941a-ec4de9276492",
-                "slug": "query-cheat-sheet",
-                "reason": "GROQ query patterns and cheat sheet reference"
+                "id": "0ba88f1b-d1a7-418a-9267-2e343d01886a",
+                "slug": "groq-feature-support-by-context",
+                "reason": "GROQ feature support across different Sanity contexts"
             },
             {
-                "id": "44e5fc43-4628-4a4c-8e00-6ae12b83b8d2",
-                "slug": "groq-introduction",
-                "reason": "Core GROQ syntax and language overview"
+                "id": "5b9c2863-ef01-4565-af8e-ee54e081ee74",
+                "slug": "custom-groq-functions",
+                "reason": "Custom GROQ functions and pipelines"
             }
         ],
         "docCoverage": true,
         "vars": {
-            "task": "Using the GROQ query language, write queries for the following\ncommon content operations:\n1. Fetch all documents of type \"post\" with title and slug\n2. Filter posts published after a specific date\n3. Sort results by publishedAt descending with a limit of 10\n4. Join author data from a reference field\nExplain each query pattern and when to use it.\n",
+            "task": "Explain how GROQ is used across different Sanity contexts.\nCover the following:\n1. Which GROQ features are available in each context (API queries,\n   webhooks, custom functions, access control)\n2. How to create and use custom GROQ functions\n3. Any differences in GROQ support between contexts\nProvide examples demonstrating context-specific GROQ patterns.\n",
             "docs": ""
         },
         "assert": [
@@ -222,18 +222,17 @@ export const exampleIdBasedRefData = [
                 "type": "llm-rubric",
                 "template": "task-completion",
                 "criteria": [
-                    "Provides a GROQ query that filters by _type",
-                    "Demonstrates date-based filtering",
-                    "Shows ordering with order() and slicing for limits",
-                    "Demonstrates reference expansion (dereferencing with ->)"
+                    "Explains GROQ availability across different Sanity contexts",
+                    "Describes custom GROQ function creation and usage",
+                    "Notes differences in GROQ support between contexts"
                 ]
             },
             {
                 "type": "llm-rubric",
                 "template": "code-correctness",
                 "criteria": [
-                    "All GROQ queries use valid syntax",
-                    "Projections correctly select and alias fields"
+                    "GROQ examples use valid syntax",
+                    "Custom function examples follow the correct API pattern"
                 ]
             }
         ],
@@ -247,88 +246,26 @@ export const exampleIdBasedRefData = [
     }
 ];
 /** Raw YAML string for example-id-based-ref (preserves comments) */
-export const exampleIdBasedRefYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: Document ID-based canonical doc references\n# ──────────────────────────────────────────────────────────────────────\n#\n# Demonstrates using `id` to reference canonical documentation by\n# Sanity document `_id`. This is useful for:\n#   - Draft documents that don't have a stable slug yet\n#   - Programmatic references from imports or migrations\n#   - Documents where you know the _id but not the slug\n#\n# The `id` ref type can also carry optional `slug` and `path` fields\n# as human-readable annotations — these are NOT used for resolution,\n# only for display in logs and reports.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# ──────────────────────────────────────────────────────────────────────\n\n- id: example-id-based-ref\n  description: \"Example — GROQ cheat sheet (ID-based doc references)\"\n\n  featureArea: groq\n\n  # ID-based canonical doc references.\n  #\n  # Use the Sanity document _id to reference articles directly.\n  # Optional slug/path annotations help humans reading the YAML\n  # but are NOT used for resolution — only the `id` field matters.\n  #\n  # These IDs reference real articles in the Sanity docs (next dataset):\n  #   81b839a4... = \"Query Cheat Sheet - GROQ\"\n  #   44e5fc43... = \"GROQ introduction\"\n  canonicalDocs:\n    - id: \"81b839a4-2fc1-4769-941a-ec4de9276492\"\n      slug: query-cheat-sheet # annotation only — not used for resolution\n      reason: \"GROQ query patterns and cheat sheet reference\"\n    - id: \"44e5fc43-4628-4a4c-8e00-6ae12b83b8d2\"\n      slug: groq-introduction # annotation only — not used for resolution\n      reason: \"Core GROQ syntax and language overview\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Using the GROQ query language, write queries for the following\n      common content operations:\n      1. Fetch all documents of type \"post\" with title and slug\n      2. Filter posts published after a specific date\n      3. Sort results by publishedAt descending with a limit of 10\n      4. Join author data from a reference field\n      Explain each query pattern and when to use it.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Provides a GROQ query that filters by _type\"\n        - \"Demonstrates date-based filtering\"\n        - \"Shows ordering with order() and slicing for limits\"\n        - \"Demonstrates reference expansion (dereferencing with ->)\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"All GROQ queries use valid syntax\"\n        - \"Projections correctly select and alias fields\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
-/** Parsed task data for example-mixed-ref-types (JSON-safe) */
-export const exampleMixedRefTypesData = [
-    {
-        "id": "example-mixed-ref-types",
-        "description": "Example — Mixed canonical doc reference types (slug + path + id + perspective)",
-        "featureArea": "groq",
-        "canonicalDocs": [
-            {
-                "slug": "groq-introduction",
-                "reason": "Core GROQ language overview"
-            },
-            {
-                "path": "content-lake/how-queries-work",
-                "reason": "Query execution model (disambiguated by section)"
-            },
-            {
-                "id": "81b839a4-2fc1-4769-941a-ec4de9276492",
-                "slug": "query-cheat-sheet",
-                "reason": "GROQ query patterns cheat sheet (referenced by document ID)"
-            },
-            {
-                "perspective": "rE9TSJvR4",
-                "reason": "Additional GROQ docs from the test content release"
-            }
-        ],
-        "docCoverage": true,
-        "vars": {
-            "task": "Create a comprehensive GROQ query guide that covers:\n1. Basic query structure and filtering by document type\n2. Projections and field selection\n3. Ordering, slicing, and pagination\n4. Reference joins and nested data\n5. Webhook GROQ filter configuration\nInclude working examples for each concept and explain the\nquery execution model.\n",
-            "docs": ""
-        },
-        "assert": [
-            {
-                "type": "llm-rubric",
-                "template": "task-completion",
-                "criteria": [
-                    "Covers basic GROQ query structure with _type filtering",
-                    "Demonstrates projections with field aliasing",
-                    "Shows ordering with order() and slice syntax",
-                    "Includes reference joins with the dereference operator",
-                    "Explains webhook GROQ filter patterns"
-                ]
-            },
-            {
-                "type": "llm-rubric",
-                "template": "code-correctness",
-                "criteria": [
-                    "All GROQ queries use valid syntax",
-                    "Examples are practical and self-contained"
-                ]
-            }
-        ],
-        "baseline": {
-            "enabled": true,
-            "rubric": "abbreviated"
-        },
-        "execution": {
-            "enabled": false
-        }
-    }
-];
-/** Raw YAML string for example-mixed-ref-types (preserves comments) */
-export const exampleMixedRefTypesYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: All canonical doc reference types in one task\n# ──────────────────────────────────────────────────────────────────────\n#\n# Demonstrates combining all four canonical doc reference strategies\n# in a single task's canonicalDocs array:\n#\n#   slug        — by article slug (simplest, may not be unique)\n#   path        — by section/slug path (unique, preferred)\n#   id          — by Sanity document _id (for drafts, imports)\n#   perspective — by content release (one-to-many expansion)\n#\n# Each reference type resolves through a different strategy, but the\n# pipeline merges them into a single flat documentation context. The\n# LLM sees the same combined markdown regardless of how docs were found.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# ──────────────────────────────────────────────────────────────────────\n\n- id: example-mixed-ref-types\n  description:\n    \"Example — Mixed canonical doc reference types (slug + path + id +\n    perspective)\"\n\n  featureArea: groq\n\n  # All four canonical doc reference types demonstrated together.\n  #\n  # The pipeline resolves each ref independently:\n  #   1. slug refs → GROQ query by slug.current\n  #   2. path refs → GROQ query by section + slug (or slug fallback)\n  #   3. id refs   → GROQ query by _id\n  #   4. perspective refs → expand to all articles in the release\n  #\n  # After resolution, all entries become a flat list of document slugs.\n  # The fetched markdown is concatenated into a single context string.\n  canonicalDocs:\n    # Slug reference — simplest form, resolves by article slug\n    - slug: groq-introduction\n      reason: \"Core GROQ language overview\"\n\n    # Path reference — section-qualified, uniquely identifies the article\n    - path: content-lake/how-queries-work\n      reason: \"Query execution model (disambiguated by section)\"\n\n    # ID reference — resolves by Sanity document _id\n    # Optional slug annotation helps humans reading the YAML\n    - id: \"81b839a4-2fc1-4769-941a-ec4de9276492\"\n      slug: query-cheat-sheet\n      reason: \"GROQ query patterns cheat sheet (referenced by document ID)\"\n\n    # Perspective reference — expands to all articles in the release\n    # This adds webhooks, query-cheat-sheet, and groq-joins from release rE9TSJvR4\n    # Note: query-cheat-sheet appears via both the id ref and the perspective ref,\n    # but the pipeline deduplicates slugs automatically.\n    - perspective: rE9TSJvR4\n      reason: \"Additional GROQ docs from the test content release\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Create a comprehensive GROQ query guide that covers:\n      1. Basic query structure and filtering by document type\n      2. Projections and field selection\n      3. Ordering, slicing, and pagination\n      4. Reference joins and nested data\n      5. Webhook GROQ filter configuration\n      Include working examples for each concept and explain the\n      query execution model.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Covers basic GROQ query structure with _type filtering\"\n        - \"Demonstrates projections with field aliasing\"\n        - \"Shows ordering with order() and slice syntax\"\n        - \"Includes reference joins with the dereference operator\"\n        - \"Explains webhook GROQ filter patterns\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"All GROQ queries use valid syntax\"\n        - \"Examples are practical and self-contained\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
+export const exampleIdBasedRefYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: Document ID-based canonical doc references\n# ──────────────────────────────────────────────────────────────────────\n#\n# Demonstrates using `id` to reference canonical documentation by\n# Sanity document `_id`. This is useful for:\n#   - Draft documents that don't have a stable slug yet\n#   - Programmatic references from imports or migrations\n#   - Documents where you know the _id but not the slug\n#\n# The `id` ref type can also carry optional `slug` and `path` fields\n# as human-readable annotations — these are NOT used for resolution,\n# only for display in logs and reports.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# ──────────────────────────────────────────────────────────────────────\n\n- id: example-id-based-ref\n  description: \"Example — GROQ feature support (ID-based doc references)\"\n\n  featureArea: groq\n\n  # ID-based canonical doc references.\n  #\n  # Use the Sanity document _id to reference articles directly.\n  # Optional slug/path annotations help humans reading the YAML\n  # but are NOT used for resolution — only the `id` field matters.\n  #\n  # These IDs reference real articles in the Sanity docs (next dataset):\n  #   0ba88f1b... = \"GROQ feature support across Sanity\"\n  #   5b9c2863... = \"Custom GROQ functions\"\n  canonicalDocs:\n    - id: \"0ba88f1b-d1a7-418a-9267-2e343d01886a\"\n      slug: groq-feature-support-by-context # annotation only — not used for resolution\n      reason: \"GROQ feature support across different Sanity contexts\"\n    - id: \"5b9c2863-ef01-4565-af8e-ee54e081ee74\"\n      slug: custom-groq-functions # annotation only — not used for resolution\n      reason: \"Custom GROQ functions and pipelines\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Explain how GROQ is used across different Sanity contexts.\n      Cover the following:\n      1. Which GROQ features are available in each context (API queries,\n         webhooks, custom functions, access control)\n      2. How to create and use custom GROQ functions\n      3. Any differences in GROQ support between contexts\n      Provide examples demonstrating context-specific GROQ patterns.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Explains GROQ availability across different Sanity contexts\"\n        - \"Describes custom GROQ function creation and usage\"\n        - \"Notes differences in GROQ support between contexts\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"GROQ examples use valid syntax\"\n        - \"Custom function examples follow the correct API pattern\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
 /** Parsed task data for example-path-based-ref (JSON-safe) */
 export const examplePathBasedRefData = [
     {
         "id": "example-path-based-ref",
-        "description": "Example — GROQ webhooks (path-based doc references)",
+        "description": "Example — GROQ mutations (path-based doc references)",
         "featureArea": "groq",
         "canonicalDocs": [
             {
-                "path": "content-lake/webhooks",
-                "reason": "GROQ-powered webhooks configuration and GROQ filter patterns"
+                "path": "content-lake/mutations-introduction",
+                "reason": "Introduction to document mutations in the Content Lake"
             },
             {
-                "path": "content-lake/how-queries-work",
-                "reason": "How GROQ queries execute — projection, filtering, ordering"
+                "path": "content-lake/documents",
+                "reason": "Document structure and types (Content Lake, not CLI reference)"
             }
         ],
         "docCoverage": true,
         "vars": {
-            "task": "Create a webhook configuration for a Sanity project that triggers\nwhen blog post documents are published. The webhook should use a\nGROQ filter to match only documents of type \"post\" and a GROQ\nprojection to include the title, slug, and publishedAt fields in\nthe webhook payload. Explain the GROQ filter syntax used.\n",
+            "task": "Explain how to create, update, and delete documents in Sanity's\nContent Lake using mutations. Cover:\n1. The different mutation types (create, createOrReplace, patch, delete)\n2. Document structure and required fields (_id, _type)\n3. How to use patch operations to update specific fields\n4. Best practices for mutation patterns\nProvide working code examples using @sanity/client.\n",
             "docs": ""
         },
         "assert": [
@@ -336,18 +273,18 @@ export const examplePathBasedRefData = [
                 "type": "llm-rubric",
                 "template": "task-completion",
                 "criteria": [
-                    "Configures a webhook with a GROQ filter for _type == 'post'",
-                    "Uses a GROQ projection to shape the payload",
-                    "Includes title, slug, and publishedAt in the projection",
-                    "Explains when the webhook fires (on publish events)"
+                    "Explains create, createOrReplace, patch, and delete mutations",
+                    "Describes required document fields (_id, _type)",
+                    "Shows patch operations for field-level updates",
+                    "Includes practical code examples"
                 ]
             },
             {
                 "type": "llm-rubric",
                 "template": "code-correctness",
                 "criteria": [
-                    "GROQ filter syntax is valid",
-                    "Projection syntax correctly selects nested fields"
+                    "Uses correct @sanity/client mutation API",
+                    "Patch operations use valid set/unset/inc syntax"
                 ]
             }
         ],
@@ -361,7 +298,7 @@ export const examplePathBasedRefData = [
     }
 ];
 /** Raw YAML string for example-path-based-ref (preserves comments) */
-export const examplePathBasedRefYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: Path-based canonical doc references\n# ──────────────────────────────────────────────────────────────────────\n#\n# Demonstrates using `path` to reference canonical documentation.\n# Paths are the preferred reference type because they uniquely identify\n# an article across sections (unlike slugs, which can collide).\n#\n# Path format:\n#   - Simple:   \"webhooks\"              → resolves by slug lookup\n#   - Sectioned: \"content-lake/webhooks\" → disambiguates by section + slug\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# ──────────────────────────────────────────────────────────────────────\n\n- id: example-path-based-ref\n  description: \"Example — GROQ webhooks (path-based doc references)\"\n\n  featureArea: groq\n\n  # Path-based canonical doc references.\n  #\n  # Use \"section/slug\" format to uniquely identify articles:\n  #   - \"content-lake/webhooks\" → the webhooks article in the Content Lake section\n  #   - \"content-lake/how-queries-work\" → disambiguated from any other section\n  #\n  # Simple paths (just the slug) also work but don't disambiguate sections.\n  canonicalDocs:\n    - path: content-lake/webhooks\n      reason: \"GROQ-powered webhooks configuration and GROQ filter patterns\"\n    - path: content-lake/how-queries-work\n      reason: \"How GROQ queries execute — projection, filtering, ordering\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Create a webhook configuration for a Sanity project that triggers\n      when blog post documents are published. The webhook should use a\n      GROQ filter to match only documents of type \"post\" and a GROQ\n      projection to include the title, slug, and publishedAt fields in\n      the webhook payload. Explain the GROQ filter syntax used.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Configures a webhook with a GROQ filter for _type == 'post'\"\n        - \"Uses a GROQ projection to shape the payload\"\n        - \"Includes title, slug, and publishedAt in the projection\"\n        - \"Explains when the webhook fires (on publish events)\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"GROQ filter syntax is valid\"\n        - \"Projection syntax correctly selects nested fields\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
+export const examplePathBasedRefYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: Path-based canonical doc references\n# ──────────────────────────────────────────────────────────────────────\n#\n# Demonstrates using `path` to reference canonical documentation.\n# Paths are the preferred reference type because they uniquely identify\n# an article across sections (unlike slugs, which can collide).\n#\n# Path format:\n#   - Simple:   \"webhooks\"              → resolves by slug lookup\n#   - Sectioned: \"content-lake/webhooks\" → disambiguates by section + slug\n#\n# This example demonstrates why paths matter: the slug \"documents\"\n# exists in both the \"content-lake\" and \"cli-reference\" sections.\n# Using \"content-lake/documents\" ensures we get the right one.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# ──────────────────────────────────────────────────────────────────────\n\n- id: example-path-based-ref\n  description: \"Example — GROQ mutations (path-based doc references)\"\n\n  featureArea: groq\n\n  # Path-based canonical doc references.\n  #\n  # Use \"section/slug\" format to uniquely identify articles:\n  #   - \"content-lake/mutations-introduction\" → the mutations article\n  #   - \"content-lake/documents\" → the documents article in Content Lake\n  #     (not the CLI \"documents\" article in cli-reference section)\n  #\n  # The \"documents\" slug exists in two sections — this is exactly why\n  # path-based references are preferred over slug-based references.\n  canonicalDocs:\n    - path: content-lake/mutations-introduction\n      reason: \"Introduction to document mutations in the Content Lake\"\n    - path: content-lake/documents\n      reason: \"Document structure and types (Content Lake, not CLI reference)\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Explain how to create, update, and delete documents in Sanity's\n      Content Lake using mutations. Cover:\n      1. The different mutation types (create, createOrReplace, patch, delete)\n      2. Document structure and required fields (_id, _type)\n      3. How to use patch operations to update specific fields\n      4. Best practices for mutation patterns\n      Provide working code examples using @sanity/client.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Explains create, createOrReplace, patch, and delete mutations\"\n        - \"Describes required document fields (_id, _type)\"\n        - \"Shows patch operations for field-level updates\"\n        - \"Includes practical code examples\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"Uses correct @sanity/client mutation API\"\n        - \"Patch operations use valid set/unset/inc syntax\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
 /** Parsed task data for example-perspective-ref (JSON-safe) */
 export const examplePerspectiveRefData = [
     {
@@ -374,13 +311,13 @@ export const examplePerspectiveRefData = [
                 "reason": "All GROQ documentation updates in the test content release"
             },
             {
-                "slug": "groq-introduction",
-                "reason": "Foundational GROQ syntax reference (published, stable)"
+                "slug": "groq-data-types",
+                "reason": "GROQ data type reference (published, stable)"
             }
         ],
         "docCoverage": true,
         "vars": {
-            "task": "Using GROQ, demonstrate advanced query patterns including:\n1. Joining data across document types using references\n2. Filtering webhook payloads with GROQ projections\n3. Using the query cheat sheet patterns for common operations\nProvide working GROQ query examples for each pattern.\n",
+            "task": "Using GROQ, demonstrate advanced query patterns including:\n1. Joining data across document types using references\n2. Filtering webhook payloads with GROQ projections\n3. Using the query cheat sheet patterns for common operations\n4. Working with different GROQ data types in filters\nProvide working GROQ query examples for each pattern.\n",
             "docs": ""
         },
         "assert": [
@@ -412,7 +349,7 @@ export const examplePerspectiveRefData = [
     }
 ];
 /** Raw YAML string for example-perspective-ref (preserves comments) */
-export const examplePerspectiveRefYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: Perspective / content release doc references\n# ──────────────────────────────────────────────────────────────────────\n#\n# Demonstrates using `perspective` to reference all documentation\n# articles within a content release. This is the key capability for\n# evaluating NEW feature documentation before it's published.\n#\n# How it works:\n#   - A perspective ref is one-to-many: the doc fetcher queries the\n#     named release and expands it to ALL articles versioned within it.\n#   - Downstream consumers see the same flat DocContext[] regardless\n#     of how docs were resolved.\n#   - When the release is published, the perspective entry becomes a\n#     no-op (articles are now in published). Migrate to explicit path\n#     or slug refs at your convenience.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# ──────────────────────────────────────────────────────────────────────\n\n- id: example-perspective-ref\n  description:\n    \"Example — GROQ features from content release (perspective-based doc\n    references)\"\n\n  featureArea: groq\n\n  # Perspective-based canonical doc reference.\n  #\n  # The perspective ID references a content release in the Sanity\n  # Content Lake. At evaluation time, the doc fetcher auto-discovers\n  # all articles versioned in this release and includes them as\n  # canonical documentation context.\n  #\n  # Release rE9TSJvR4 contains:\n  #   - \"GROQ-powered webhooks\" (webhooks)\n  #   - \"Query Cheat Sheet - GROQ\" (query-cheat-sheet)\n  #   - \"GROQ joins\" (groq-joins)\n  #\n  # You can combine perspective refs with explicit slug/path/id refs\n  # to include foundational published docs alongside release content.\n  canonicalDocs:\n    - perspective: rE9TSJvR4\n      reason: \"All GROQ documentation updates in the test content release\"\n    - slug: groq-introduction\n      reason: \"Foundational GROQ syntax reference (published, stable)\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Using GROQ, demonstrate advanced query patterns including:\n      1. Joining data across document types using references\n      2. Filtering webhook payloads with GROQ projections\n      3. Using the query cheat sheet patterns for common operations\n      Provide working GROQ query examples for each pattern.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Demonstrates GROQ join syntax for cross-document queries\"\n        - \"Shows GROQ filter patterns for webhook configuration\"\n        - \"Includes practical query examples from cheat sheet patterns\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"All GROQ queries use valid syntax\"\n        - \"Reference joins use correct dereference operator (->)\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
+export const examplePerspectiveRefYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: Perspective / content release doc references\n# ──────────────────────────────────────────────────────────────────────\n#\n# Demonstrates using `perspective` to reference all documentation\n# articles within a content release. This is the key capability for\n# evaluating NEW feature documentation before it's published.\n#\n# How it works:\n#   - A perspective ref is one-to-many: the doc fetcher queries the\n#     named release and expands it to ALL articles versioned within it.\n#   - Downstream consumers see the same flat DocContext[] regardless\n#     of how docs were resolved.\n#   - When the release is published, the perspective entry becomes a\n#     no-op (articles are now in published). Migrate to explicit path\n#     or slug refs at your convenience.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n#\n# @see docs/design-docs/canonical-doc-resolution.md\n# ──────────────────────────────────────────────────────────────────────\n\n- id: example-perspective-ref\n  description:\n    \"Example — GROQ features from content release (perspective-based doc\n    references)\"\n\n  featureArea: groq\n\n  # Perspective-based canonical doc reference.\n  #\n  # The perspective ID references a content release in the Sanity\n  # Content Lake. At evaluation time, the doc fetcher auto-discovers\n  # all articles versioned in this release and includes them as\n  # canonical documentation context.\n  #\n  # Release rE9TSJvR4 contains:\n  #   - \"GROQ-powered webhooks\" (webhooks)\n  #   - \"Query Cheat Sheet - GROQ\" (query-cheat-sheet)\n  #   - \"GROQ joins\" (groq-joins)\n  #\n  # You can combine perspective refs with explicit slug/path/id refs\n  # to include foundational published docs alongside release content.\n  # Here we add groq-data-types as a complementary published reference.\n  canonicalDocs:\n    - perspective: rE9TSJvR4\n      reason: \"All GROQ documentation updates in the test content release\"\n    - slug: groq-data-types\n      reason: \"GROQ data type reference (published, stable)\"\n\n  docCoverage: true\n\n  vars:\n    task: |\n      Using GROQ, demonstrate advanced query patterns including:\n      1. Joining data across document types using references\n      2. Filtering webhook payloads with GROQ projections\n      3. Using the query cheat sheet patterns for common operations\n      4. Working with different GROQ data types in filters\n      Provide working GROQ query examples for each pattern.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Demonstrates GROQ join syntax for cross-document queries\"\n        - \"Shows GROQ filter patterns for webhook configuration\"\n        - \"Includes practical query examples from cheat sheet patterns\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"All GROQ queries use valid syntax\"\n        - \"Reference joins use correct dereference operator (->)\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
 /** Parsed task data for example-studio-custom-input (JSON-safe) */
 export const exampleStudioCustomInputData = [
     {
@@ -423,6 +360,10 @@ export const exampleStudioCustomInputData = [
             {
                 "slug": "custom-input-widgets",
                 "reason": "Guide for building custom form inputs in Sanity Studio"
+            },
+            {
+                "slug": "form-components",
+                "reason": "Form component API and customization patterns"
             }
         ],
         "docCoverage": true,
@@ -461,7 +402,7 @@ export const exampleStudioCustomInputData = [
     }
 ];
 /** Raw YAML string for example-studio-custom-input (preserves comments) */
-export const exampleStudioCustomInputYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: Custom input component in Sanity Studio\n# ──────────────────────────────────────────────────────────────────────\n#\n# This is a starter template — edit it for your own documentation.\n# Delete this file or replace it with your own tasks.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n# ──────────────────────────────────────────────────────────────────────\n\n- id: example-studio-custom-input\n  description: \"Example — Custom input component in Sanity Studio\"\n\n  featureArea: studio\n\n  # Slug-based canonical doc reference.\n  # Note: the correct slug is \"custom-input-widgets\" (not \"custom-input-components\").\n  canonicalDocs:\n    - slug: custom-input-widgets\n      reason: \"Guide for building custom form inputs in Sanity Studio\"\n\n  docCoverage: true\n  referenceSolution: canonical/example-studio-custom-input.ts\n\n  vars:\n    task: |\n      Build a custom string input component for Sanity Studio that shows\n      a character count below the input field. The component should accept\n      a maxLength option from the field schema and display a warning when\n      the text exceeds the limit.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Implements a React component that renders a text input\"\n        - \"Displays a live character count\"\n        - \"Reads maxLength from schema options\"\n        - \"Shows a visual warning when limit is exceeded\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"Uses the Sanity UI library for styling\"\n        - \"Calls onChange with patch operations\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
+export const exampleStudioCustomInputYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: Custom input component in Sanity Studio\n# ──────────────────────────────────────────────────────────────────────\n#\n# This is a starter template — edit it for your own documentation.\n# Delete this file or replace it with your own tasks.\n#\n# This example task is DISABLED by default. To enable it, either:\n#   1. Remove the execution.enabled: false line below, or\n#   2. Set execution.enabled: true\n# ──────────────────────────────────────────────────────────────────────\n\n- id: example-studio-custom-input\n  description: \"Example — Custom input component in Sanity Studio\"\n\n  featureArea: studio\n\n  # Slug-based canonical doc references.\n  canonicalDocs:\n    - slug: custom-input-widgets\n      reason: \"Guide for building custom form inputs in Sanity Studio\"\n    - slug: form-components\n      reason: \"Form component API and customization patterns\"\n\n  docCoverage: true\n  referenceSolution: canonical/example-studio-custom-input.ts\n\n  vars:\n    task: |\n      Build a custom string input component for Sanity Studio that shows\n      a character count below the input field. The component should accept\n      a maxLength option from the field schema and display a warning when\n      the text exceeds the limit.\n    docs: \"\"\n\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Implements a React component that renders a text input\"\n        - \"Displays a live character count\"\n        - \"Reads maxLength from schema options\"\n        - \"Shows a visual warning when limit is exceeded\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"Uses the Sanity UI library for styling\"\n        - \"Calls onChange with patch operations\"\n\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship disabled so they don't run automatically.\n  # Set enabled: true (or remove this block) to activate.\n  execution:\n    enabled: false\n";
 // ---------------------------------------------------------------------------
 // Aggregate task exports
 // ---------------------------------------------------------------------------
@@ -469,7 +410,6 @@ export const exampleStudioCustomInputYaml = "# ───────────
 export const allTaskData = [
     ...exampleGroqBlogListingData,
     ...exampleIdBasedRefData,
-    ...exampleMixedRefTypesData,
     ...examplePathBasedRefData,
     ...examplePerspectiveRefData,
     ...exampleStudioCustomInputData,
@@ -478,13 +418,12 @@ export const allTaskData = [
 export const taskYamlFiles = {
     "example-groq-blog-listing": exampleGroqBlogListingYaml,
     "example-id-based-ref": exampleIdBasedRefYaml,
-    "example-mixed-ref-types": exampleMixedRefTypesYaml,
     "example-path-based-ref": examplePathBasedRefYaml,
     "example-perspective-ref": examplePerspectiveRefYaml,
     "example-studio-custom-input": exampleStudioCustomInputYaml,
 };
 /** List of task file stems, in alphabetical order */
-export const TASK_FILE_NAMES = ["example-groq-blog-listing", "example-id-based-ref", "example-mixed-ref-types", "example-path-based-ref", "example-perspective-ref", "example-studio-custom-input"];
+export const TASK_FILE_NAMES = ["example-groq-blog-listing", "example-id-based-ref", "example-path-based-ref", "example-perspective-ref", "example-studio-custom-input"];
 export const EXAMPLE_TYPES = ["config", "source", "rubric", "threshold", "ailf-config", "task"];
 export const EXAMPLES = {
     "config": {

package/dist/_vendor/ailf-core/services/scoring.js

@@ -63,12 +63,12 @@ export function detectFeatureArea(description) {
         desc.includes("live preview")) {
         return "visual-editing";
     }
+    if (desc.includes("groq")) {
+        return "groq";
+    }
     if (desc.includes("function") || desc.includes("webhook")) {
         return "functions";
     }
-    if (desc.startsWith("groq")) {
-        return "groq";
-    }
     if (desc.includes("next") || desc.includes("app router")) {
         return "nextjs-live";
     }

package/dist/agent-observer/agentic-provider.js

@@ -188,7 +188,8 @@ export default class AgenticProvider {
         return this.recorder;
     }
     id() {
-        return `agentic:${this.agentMode}:${this.providerId}`;
+        const model = this.config.model || this.providerId;
+        return `agentic:${this.agentMode}:${model}`;
     }
     // -------------------------------------------------------------------------
     // Tool execution

package/dist/orchestration/steps/gap-analysis-step.d.ts

@@ -5,6 +5,13 @@
  * the PipelineStep interface. This includes document manifest enrichment
  * and low-scoring judgment extraction.
  *
+ * Document resolution uses two sources (layered):
+ *   1. TaskSource (from AppContext) — the canonical source of task definitions
+ *      including Content Lake, repo-based, and YAML tasks. This is the primary
+ *      source for mapping task descriptions to canonical doc slugs.
+ *   2. Local task YAML (via resolveMappings) — legacy fallback for tasks not
+ *      found via the TaskSource adapter.
+ *
  * This is an optional step — failure doesn't stop the pipeline.
  */
 import type { AppContext, PipelineStep, StepResult, ValidationIssue } from "../../_vendor/ailf-core/index.d.ts";

package/dist/orchestration/steps/gap-analysis-step.js

@@ -5,10 +5,18 @@
  * the PipelineStep interface. This includes document manifest enrichment
  * and low-scoring judgment extraction.
  *
+ * Document resolution uses two sources (layered):
+ *   1. TaskSource (from AppContext) — the canonical source of task definitions
+ *      including Content Lake, repo-based, and YAML tasks. This is the primary
+ *      source for mapping task descriptions to canonical doc slugs.
+ *   2. Local task YAML (via resolveMappings) — legacy fallback for tasks not
+ *      found via the TaskSource adapter.
+ *
  * This is an optional step — failure doesn't stop the pipeline.
  */
 import { existsSync, readFileSync, writeFileSync } from "fs";
 import { join, resolve } from "path";
+import { isSlugRef } from "../../_vendor/ailf-core/index.js";
 export class GapAnalysisStep {
     name = "gap-analysis";
     optional = true;
@@ -51,9 +59,6 @@ export class GapAnalysisStep {
             const outDir = resolve(root, "results", "latest");
             writeFileSync(join(outDir, "failure-modes.json"), JSON.stringify(failureModeReport, null, 2));
             writeFileSync(join(outDir, "gap-analysis.json"), JSON.stringify(gapReport, null, 2));
-            // ── Document manifest + enrichment ─────────────────────────
-            const { resolveMappings } = await import("../../pipeline/resolve-mappings.js");
-            const mappings = resolveMappings(root);
             const manifestPath = resolve(root, "contexts", "document-manifest.json");
             const manifestEntries = existsSync(manifestPath)
                 ? JSON.parse(readFileSync(manifestPath, "utf-8"))
@@ -75,17 +80,59 @@ export class GapAnalysisStep {
                     : { documentId: "", slug, title: slug };
             })
                 .filter((r) => r.documentId !== "");
+            // ── Build description→docs mapping from TaskSource ─────────
+            // Primary source: use the TaskSource adapter from AppContext.
+            // This works with Content Lake, repo-based, and YAML tasks.
+            // Judgments use task description as their taskId, so we build
+            // maps keyed by both description and task ID for robust matching.
             const descToDocRefs = new Map();
             const areaToDocRefs = new Map();
+            let tasks = [];
+            try {
+                tasks = await ctx.taskSource.loadTasks();
+            }
+            catch {
+                // TaskSource may not be available in all contexts (e.g., standalone
+                // gap analysis on cached results). Fall through to legacy fallback.
+            }
+            if (tasks.length > 0) {
+                // Group tasks by feature area and build slug maps
+                const byArea = new Map();
+                for (const task of tasks) {
+                    const slugs = extractSlugsFromRefs(task.canonicalDocs);
+                    const refs = resolveRefs(slugs);
+                    // Map by description (what judgments use as taskId)
+                    descToDocRefs.set(task.description, refs);
+                    // Also map by task ID for prefix-based matching
+                    descToDocRefs.set(task.id, refs);
+                    // Group slugs by feature area
+                    if (!byArea.has(task.featureArea))
+                        byArea.set(task.featureArea, new Set());
+                    for (const s of slugs)
+                        byArea.get(task.featureArea).add(s);
+                }
+                for (const [area, slugs] of byArea) {
+                    areaToDocRefs.set(area, resolveRefs([...slugs]));
+                }
+            }
+            // Legacy fallback: merge in any tasks from local YAML that weren't
+            // already covered by the TaskSource adapter.
+            const { resolveMappings } = await import("../../pipeline/resolve-mappings.js");
+            const mappings = resolveMappings(root);
             for (const [area, areaData] of Object.entries(mappings.feature_areas)) {
                 const areaSlugs = new Set();
                 for (const task of areaData.tasks) {
                     const taskSlugs = task.canonical_docs.map((d) => d.slug);
-                    descToDocRefs.set(task.description, resolveRefs(taskSlugs));
+                    // Only add if not already mapped by the primary source
+                    if (!descToDocRefs.has(task.description)) {
+                        descToDocRefs.set(task.description, resolveRefs(taskSlugs));
+                    }
                     for (const s of taskSlugs)
                         areaSlugs.add(s);
                 }
-                areaToDocRefs.set(area, resolveRefs([...areaSlugs]));
+                if (!areaToDocRefs.has(area)) {
+                    areaToDocRefs.set(area, resolveRefs([...areaSlugs]));
+                }
             }
             const documentManifest = resolveRefs([...refBySlug.keys()]);
             const enrichedScores = scoreSummary.scores.map((s) => ({
@@ -104,6 +151,7 @@ export class GapAnalysisStep {
                 .sort((a, b) => a.score - b.score)
                 .slice(0, MAX_STORED_JUDGMENTS)
                 .map((j) => {
+                // Judgment taskId is the description with "(gold)" or "(baseline)" suffix
                 const baseDesc = j.taskId.replace(/\s*\((gold|baseline)\)\s*$/, "");
                 const canonicalDocs = descToDocRefs.get(baseDesc);
                 return canonicalDocs ? { ...j, canonicalDocs } : j;
@@ -134,3 +182,32 @@ export class GapAnalysisStep {
         }
     }
 }
+// ---------------------------------------------------------------------------
+// Helpers
+// ---------------------------------------------------------------------------
+/**
+ * Extract slug strings from polymorphic canonical doc refs.
+ *
+ * Only slug-based refs produce a slug directly. Other ref types
+ * (path, id, perspective) are resolved during doc fetching — their
+ * slugs appear in the document manifest, not in the refs themselves.
+ * For path refs, the final segment is used as the slug approximation.
+ */
+function extractSlugsFromRefs(refs) {
+    const slugs = [];
+    for (const ref of refs) {
+        if (isSlugRef(ref)) {
+            slugs.push(ref.slug);
+        }
+        else if ("path" in ref && typeof ref.path === "string") {
+            // Path refs: use the final segment as the slug
+            const segments = ref.path.split("/").filter(Boolean);
+            if (segments.length > 0) {
+                slugs.push(segments[segments.length - 1]);
+            }
+        }
+        // id and perspective refs: slugs are resolved at fetch time
+        // and appear in the document manifest — handled via refBySlug
+    }
+    return slugs;
+}

package/dist/pipeline/agent-behavior-report.js

@@ -53,6 +53,8 @@ export function detectFeatureArea(description) {
         desc.includes("presentation") ||
         desc.includes("live preview"))
         return "visual-editing";
+    if (desc.includes("groq"))
+        return "groq";
     if (desc.includes("function") || desc.includes("webhook"))
         return "functions";
     if (desc.includes("next") || desc.includes("app router"))

package/dist/pipeline/calculate-scores.js

@@ -163,7 +163,7 @@ function aggregateAgentBehavior(resultsPath) {
     const byFeature = {};
     let hasBehaviorData = false;
     for (const result of results) {
-        const feature = detectFeatureArea(result.description);
+        const feature = result.vars.__featureArea || detectFeatureArea(result.description);
         const behavior = extractAgentBehavior(result);
         if (!behavior) {
             continue;
@@ -241,7 +241,7 @@ function aggregateUrlReferences(resultsPath) {
     const results = readAndNormalizeResults(resultsPath);
     const byFeature = {};
     for (const result of results) {
-        const feature = detectFeatureArea(result.description);
+        const feature = result.vars.__featureArea || detectFeatureArea(result.description);
         if (!byFeature[feature]) {
             byFeature[feature] = {
                 baseline: { testCount: 0, urls: {} },
@@ -481,7 +481,7 @@ function scoreResults(results, weights, modelId) {
     // Group by feature + docs/no-docs
     const byFeature = {};
     for (const result of results) {
-        const feature = detectFeatureArea(result.description);
+        const feature = result.vars.__featureArea || detectFeatureArea(result.description);
         if (!byFeature[feature]) {
             byFeature[feature] = { withDocs: [], withoutDocs: [] };
         }
@@ -580,7 +580,7 @@ export function scoreAgenticResults(resultsPath, weights) {
     // Group by feature area
     const byFeature = {};
     for (const result of results) {
-        const feature = detectFeatureArea(result.description);
+        const feature = result.vars.__featureArea || detectFeatureArea(result.description);
         if (!byFeature[feature]) {
             byFeature[feature] = [];
         }

package/dist/pipeline/expand-tasks.d.ts

@@ -85,6 +85,8 @@ export interface SingleTaskDefinition {
     description: string;
     /** Opt-in: auto-generate a documentation coverage rubric for gold. */
     doc_coverage?: boolean;
+    /** Feature area this task belongs to (flows through to scoring). */
+    featureArea?: string;
     /** Explicit task ID — determines the canonical context filename. */
     id: string;
     /** Template variables: task prompt and docs path. */

package/dist/pipeline/expand-tasks.js

@@ -168,7 +168,7 @@ export function expandTask(task, rubricConfig, mode = "baseline") {
         assert: [...resolvedAsserts],
         description: `${task.description} (gold)`,
         ...(mode === "baseline" ? { prompts: ["with-docs"] } : {}),
-        vars: { ...task.vars },
+        vars: { ...task.vars, __featureArea: task.featureArea ?? "" },
     });
     // Baseline entry — floor measurement (no docs, parametric knowledge only).
     // Skipped entirely in agentic mode: the agentic prompt doesn't reference
@@ -188,6 +188,7 @@ export function expandTask(task, rubricConfig, mode = "baseline") {
             vars: {
                 ...task.vars,
                 docs: "",
+                __featureArea: task.featureArea ?? "",
             },
             ...(baselineAsserts.length > 0 ? { assert: baselineAsserts } : {}),
         });
@@ -204,6 +205,7 @@ function taskDefinitionToSingle(task) {
         baseline: task.baseline,
         description: task.description,
         doc_coverage: task.docCoverage,
+        featureArea: task.featureArea,
         id: task.id,
         vars: {
             docs: `file://contexts/canonical/${task.id}.md`,

package/dist/pipeline/grader-compare-runner.js

@@ -52,10 +52,10 @@ function detectFeatureArea(description) {
         desc.includes("presentation") ||
         desc.includes("live preview"))
         return "visual-editing";
+    if (desc.includes("groq"))
+        return "groq";
     if (desc.includes("function") || desc.includes("webhook"))
         return "functions";
-    if (desc.startsWith("groq"))
-        return "groq";
     if (desc.includes("next") || desc.includes("app router"))
         return "nextjs-live";
     if (desc.includes("remix") ||

package/dist/pipeline/grader-consistency-runner.js

@@ -57,10 +57,10 @@ function detectFeatureArea(description) {
         desc.includes("presentation") ||
         desc.includes("live preview"))
         return "visual-editing";
+    if (desc.includes("groq"))
+        return "groq";
     if (desc.includes("function") || desc.includes("webhook"))
         return "functions";
-    if (desc.startsWith("groq"))
-        return "groq";
     if (desc.includes("next") || desc.includes("app router"))
         return "nextjs-live";
     if (desc.includes("remix") ||

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sanity/ailf",
-  "version": "0.1.18",
+  "version": "0.1.20",
   "private": false,
   "publishConfig": {
     "access": "restricted"