@sanity/ailf 0.4.1 → 1.0.0

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

@@ -185,13 +185,13 @@ export const exampleGroqBlogListingData = [
         ],
         "baseline": {
             "enabled": true,
-            "rubric": "abbreviated"
+            "rubric": "full"
         },
         "status": "draft"
     }
 ];
 /** Raw YAML string for example-groq-blog-listing (preserves comments) */
-export const exampleGroqBlogListingYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: Blog listing with GROQ queries\n# ──────────────────────────────────────────────────────────────────────\n#\n# This is a starter template — edit it for your own documentation.\n# Each task evaluates whether an AI coding agent can implement a feature\n# using your docs as context. Delete this file or replace it entirely.\n#\n# This example task ships as a DRAFT so it does not run in production\n#   evaluations automatically. To activate it, change status to \"active\"\n# or remove the status line entirely (defaults to active).\n#\n# Full field reference:\n#   https://github.com/sanity-labs/ai-literacy-framework/blob/main/docs/CONTRIBUTING_TASKS.md\n# ──────────────────────────────────────────────────────────────────────\n\n# Unique identifier — lowercase alphanumeric with hyphens.\n# Must be unique across all task files in .ailf/tasks/.\n- id: example-groq-blog-listing\n\n  # Short human-readable summary. Shown in score tables and reports.\n  description: \"Example — Blog listing with GROQ queries\"\n\n  # Feature area this task belongs to. Tasks with the same area are\n  # grouped together in score summaries. Use a short kebab-case name.\n  featureArea: groq\n\n  # Gold-standard documentation articles for this task. The pipeline\n  # fetches these from Sanity and injects them into the prompt for\n  # baseline evaluation. Each entry needs:\n  #   slug   — the article's URL slug in your docs site\n  #   reason — why this doc is relevant (helps with auditing)\n  #\n  # This example uses slug-based references — the simplest form.\n  # See the other example tasks for path, id, and perspective references.\n  canonicalDocs:\n    - slug: groq-introduction\n      reason: \"Core GROQ syntax and query language reference\"\n    - slug: how-queries-work\n      reason: \"Query execution model and best practices\"\n\n  # When true, the pipeline auto-generates an additional rubric that\n  # checks whether the LLM's response actually used the provided docs.\n  docCoverage: true\n\n  # Path to a gold-standard implementation, relative to canonical/.\n  # The grader uses this as a reference when scoring code correctness.\n  referenceSolution: canonical/example-groq-blog-listing.ts\n\n  # vars.task — the implementation prompt given to the LLM.\n  # Write this as if you're asking a developer to build the feature.\n  # Be specific about requirements so the grader can evaluate clearly.\n  #\n  # vars.docs — leave empty (\"\"). The pipeline fills this in:\n  #   • Gold variant: injected with canonical doc content\n  #   • Baseline variant: left empty (tests model knowledge alone)\n  vars:\n    task: |\n      Create a Next.js page component that lists blog posts from Sanity\n      using GROQ. The page should display the title, slug, and published\n      date for each post, sorted by most recent first. Use the Sanity\n      client to fetch data.\n    docs: \"\"\n\n  # Grading assertions — how the LLM's response is scored.\n  #\n  # \"llm-rubric\" assertions use a grader LLM to score against criteria.\n  # The \"template\" references a rubric from config/rubrics.yaml.\n  # The \"criteria\" are task-specific bullets injected into the template.\n  #\n  # Available templates:\n  #   task-completion   — did the LLM implement the feature? (weight: 0.50)\n  #   code-correctness  — is the code idiomatic and correct? (weight: 0.25)\n  #\n  # You can also use value-based assertions:\n  #   - type: contains\n  #     value: \"client.fetch\"\n  #   - type: contains-any\n  #     value: [\"createClient\", \"sanityClient\"]\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Uses the groq tagged template literal\"\n        - \"Fetches blog posts with title, slug, and publishedAt fields\"\n        - \"Orders results by publishedAt in descending order\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"Uses createClient from @sanity/client or next-sanity\"\n        - \"Exports a valid Next.js page component\"\n\n  # Baseline variant configuration.\n  #   enabled — set to false to skip this task entirely\n  #   rubric  — \"abbreviated\" (faster, default), \"full\", or \"none\"\n  baseline:\n    enabled: true\n    rubric: abbreviated\n\n  # Example tasks ship as drafts so they don't run in production evals.\n  # Change to \"active\" (or remove this line) to activate.\n  status: draft\n";
+export const exampleGroqBlogListingYaml = "# ──────────────────────────────────────────────────────────────────────\n# Example Task: Blog listing with GROQ queries\n# ──────────────────────────────────────────────────────────────────────\n#\n# This is a starter template — edit it for your own documentation.\n# Each task evaluates whether an AI coding agent can implement a feature\n# using your docs as context. Delete this file or replace it entirely.\n#\n# This example task ships as a DRAFT so it does not run in production\n#   evaluations automatically. To activate it, change status to \"active\"\n# or remove the status line entirely (defaults to active).\n#\n# Full field reference:\n#   https://github.com/sanity-labs/ai-literacy-framework/blob/main/docs/CONTRIBUTING_TASKS.md\n# ──────────────────────────────────────────────────────────────────────\n\n# Unique identifier — lowercase alphanumeric with hyphens.\n# Must be unique across all task files in .ailf/tasks/.\n- id: example-groq-blog-listing\n\n  # Short human-readable summary. Shown in score tables and reports.\n  description: \"Example — Blog listing with GROQ queries\"\n\n  # Feature area this task belongs to. Tasks with the same area are\n  # grouped together in score summaries. Use a short kebab-case name.\n  featureArea: groq\n\n  # Gold-standard documentation articles for this task. The pipeline\n  # fetches these from Sanity and injects them into the prompt for\n  # baseline evaluation. Each entry needs:\n  #   slug   — the article's URL slug in your docs site\n  #   reason — why this doc is relevant (helps with auditing)\n  #\n  # This example uses slug-based references — the simplest form.\n  # See the other example tasks for path, id, and perspective references.\n  canonicalDocs:\n    - slug: groq-introduction\n      reason: \"Core GROQ syntax and query language reference\"\n    - slug: how-queries-work\n      reason: \"Query execution model and best practices\"\n\n  # When true, the pipeline auto-generates an additional rubric that\n  # checks whether the LLM's response actually used the provided docs.\n  docCoverage: true\n\n  # Path to a gold-standard implementation, relative to canonical/.\n  # The grader uses this as a reference when scoring code correctness.\n  referenceSolution: canonical/example-groq-blog-listing.ts\n\n  # vars.task — the implementation prompt given to the LLM.\n  # Write this as if you're asking a developer to build the feature.\n  # Be specific about requirements so the grader can evaluate clearly.\n  #\n  # vars.docs — leave empty (\"\"). The pipeline fills this in:\n  #   • Gold variant: injected with canonical doc content\n  #   • Baseline variant: left empty (tests model knowledge alone)\n  vars:\n    task: |\n      Create a Next.js page component that lists blog posts from Sanity\n      using GROQ. The page should display the title, slug, and published\n      date for each post, sorted by most recent first. Use the Sanity\n      client to fetch data.\n    docs: \"\"\n\n  # Grading assertions — how the LLM's response is scored.\n  #\n  # \"llm-rubric\" assertions use a grader LLM to score against criteria.\n  # The \"template\" references a rubric from config/rubrics.yaml.\n  # The \"criteria\" are task-specific bullets injected into the template.\n  #\n  # Available templates:\n  #   task-completion   — did the LLM implement the feature? (weight: 0.50)\n  #   code-correctness  — is the code idiomatic and correct? (weight: 0.25)\n  #\n  # You can also use value-based assertions:\n  #   - type: contains\n  #     value: \"client.fetch\"\n  #   - type: contains-any\n  #     value: [\"createClient\", \"sanityClient\"]\n  assert:\n    - type: llm-rubric\n      template: task-completion\n      criteria:\n        - \"Uses the groq tagged template literal\"\n        - \"Fetches blog posts with title, slug, and publishedAt fields\"\n        - \"Orders results by publishedAt in descending order\"\n\n    - type: llm-rubric\n      template: code-correctness\n      criteria:\n        - \"Uses createClient from @sanity/client or next-sanity\"\n        - \"Exports a valid Next.js page component\"\n\n  # Baseline variant configuration.\n  #   enabled — set to false to skip this task entirely\n  #   rubric  — \"full\" (default), \"abbreviated\" (faster), or \"none\"\n  baseline:\n    enabled: true\n    rubric: full\n\n  # Example tasks ship as drafts so they don't run in production evals.\n  # Change to \"active\" (or remove this line) to activate.\n  status: draft\n";
 /** Parsed task data for example-id-based-ref (JSON-safe) */
 export const exampleIdBasedRefData = [
     {
@@ -236,13 +236,13 @@ export const exampleIdBasedRefData = [
         ],
         "baseline": {
             "enabled": true,
-            "rubric": "abbreviated"
+            "rubric": "full"
         },
         "status": "draft"
     }
 ];
 /** 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 ships as a DRAFT so it does not run in production\n#   evaluations automatically. To activate it, change status to \"active\"\n# or remove the status line entirely (defaults to active).\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 as drafts so they don't run in production evals.\n  # Change to \"active\" (or remove this line) to activate.\n  status: draft\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 ships as a DRAFT so it does not run in production\n#   evaluations automatically. To activate it, change status to \"active\"\n# or remove the status line entirely (defaults to active).\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: full\n\n  # Example tasks ship as drafts so they don't run in production evals.\n  # Change to \"active\" (or remove this line) to activate.\n  status: draft\n";
 /** Parsed task data for example-path-based-ref (JSON-safe) */
 export const examplePathBasedRefData = [
     {
@@ -286,13 +286,13 @@ export const examplePathBasedRefData = [
         ],
         "baseline": {
             "enabled": true,
-            "rubric": "abbreviated"
+            "rubric": "full"
         },
         "status": "draft"
     }
 ];
 /** 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 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 ships as a DRAFT so it does not run in production\n#   evaluations automatically. To activate it, change status to \"active\"\n# or remove the status line entirely (defaults to active).\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 as drafts so they don't run in production evals.\n  # Change to \"active\" (or remove this line) to activate.\n  status: draft\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 ships as a DRAFT so it does not run in production\n#   evaluations automatically. To activate it, change status to \"active\"\n# or remove the status line entirely (defaults to active).\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: full\n\n  # Example tasks ship as drafts so they don't run in production evals.\n  # Change to \"active\" (or remove this line) to activate.\n  status: draft\n";
 /** Parsed task data for example-perspective-ref (JSON-safe) */
 export const examplePerspectiveRefData = [
     {
@@ -335,13 +335,13 @@ export const examplePerspectiveRefData = [
         ],
         "baseline": {
             "enabled": true,
-            "rubric": "abbreviated"
+            "rubric": "full"
         },
         "status": "draft"
     }
 ];
 /** 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 ships as a DRAFT so it does not run in production\n#   evaluations automatically. To activate it, change status to \"active\"\n# or remove the status line entirely (defaults to active).\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 as drafts so they don't run in production evals.\n  # Change to \"active\" (or remove this line) to activate.\n  status: draft\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 ships as a DRAFT so it does not run in production\n#   evaluations automatically. To activate it, change status to \"active\"\n# or remove the status line entirely (defaults to active).\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: full\n\n  # Example tasks ship as drafts so they don't run in production evals.\n  # Change to \"active\" (or remove this line) to activate.\n  status: draft\n";
 /** Parsed task data for example-studio-custom-input (JSON-safe) */
 export const exampleStudioCustomInputData = [
     {
@@ -386,13 +386,13 @@ export const exampleStudioCustomInputData = [
         ],
         "baseline": {
             "enabled": true,
-            "rubric": "abbreviated"
+            "rubric": "full"
         },
         "status": "draft"
     }
 ];
 /** 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 ships as a DRAFT so it does not run in production\n#   evaluations automatically. To activate it, change status to \"active\"\n# or remove the status line entirely (defaults to active).\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 as drafts so they don't run in production evals.\n  # Change to \"active\" (or remove this line) to activate.\n  status: draft\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 ships as a DRAFT so it does not run in production\n#   evaluations automatically. To activate it, change status to \"active\"\n# or remove the status line entirely (defaults to active).\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: full\n\n  # Example tasks ship as drafts so they don't run in production evals.\n  # Change to \"active\" (or remove this line) to activate.\n  status: draft\n";
 // ---------------------------------------------------------------------------
 // Aggregate task exports
 // ---------------------------------------------------------------------------

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

@@ -15,3 +15,6 @@ export * from "./schemas/index.js";
 export * from "./ports/index.js";
 export * from "./services/index.js";
 export * from "./examples/index.js";
+export { defineConfig, defineFeatures, defineModels, definePricingTable, definePreset, definePrompts, defineRubrics, defineSchedules, defineSinks, defineSources, defineTask, defineThresholds, } from "./config-helpers.js";
+export type { PresetConfig, PricingEntry, PromptEntry, SourceEntry, } from "./config-helpers.js";
+export { env } from "./env-helper.js";

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

@@ -15,3 +15,8 @@ export * from "./schemas/index.js";
 export * from "./ports/index.js";
 export * from "./services/index.js";
 export * from "./examples/index.js";
+// ---------------------------------------------------------------------------
+// Architecture overhaul — Phase 0 helpers
+// ---------------------------------------------------------------------------
+export { defineConfig, defineFeatures, defineModels, definePricingTable, definePreset, definePrompts, defineRubrics, defineSchedules, defineSinks, defineSources, defineTask, defineThresholds, } from "./config-helpers.js";
+export { env } from "./env-helper.js";

package/dist/_vendor/ailf-core/ports/context.d.ts

@@ -11,7 +11,7 @@
  * Fields marked optional are transitional — they will become required
  * as downstream consumers are converted to use them.
  */
-import type { DebugOptions, EvalMode } from "../types/index.js";
+import type { DebugOptions, EvalMode, PluginRegistry } from "../types/index.js";
 import type { CacheStore } from "./cache-store.js";
 import type { DocFetcher } from "./doc-fetcher.js";
 import type { EvalRunner } from "./eval-runner.js";
@@ -27,8 +27,19 @@ import type { TaskSource } from "./task-source.js";
 export interface ResolvedConfig {
     /** Eval package root directory */
     rootDir: string;
-    /** Evaluation mode */
+    /** Evaluation mode — canonical name (e.g., "literacy", "knowledge-probe") */
     mode: EvalMode;
+    /**
+     * Literacy variant — only meaningful when mode is "literacy".
+     *
+     * When a user passes `--mode baseline`, the CLI normalizes this to
+     * `mode: "literacy", variant: "baseline"`. This keeps the pipeline
+     * mode-agnostic while preserving literacy's multi-variant behavior.
+     *
+     * Values: "baseline" | "agentic" | "observed" | "full" | undefined
+     * Undefined means "use the default variant for the mode" (baseline for literacy).
+     */
+    variant?: string;
     /** Debug options */
     debug?: DebugOptions;
     /** Feature area filter */
@@ -153,6 +164,8 @@ export interface AppContext {
     readonly evalRunner: EvalRunner;
     /** Structured logger */
     readonly logger: Logger;
+    /** Plugin registry — mode handlers, assertions, rubric templates, etc. */
+    readonly registry: PluginRegistry;
     /**
      * Persistent report store (Sanity Content Lake).
      * Optional — not all commands need it. Commands that publish or

package/dist/_vendor/ailf-core/ports/doc-fetcher.d.ts

@@ -9,7 +9,7 @@
  * The pipeline orchestrator and all downstream steps work with
  * FetchResult regardless of where the documentation came from.
  */
-import type { TaskDefinition } from "./task-source.js";
+import type { GeneralizedTaskDefinition } from "../types/generalized-task.js";
 /**
  * A fetched documentation context ready for injection into prompts.
  *
@@ -127,5 +127,5 @@ export interface DocFetcher {
      * @param source — Where to fetch documentation from
      * @returns Fetched doc contexts + optional metadata
      */
-    fetch(tasks: TaskDefinition[], source?: DocSourceConfig): Promise<FetchResult>;
+    fetch(tasks: GeneralizedTaskDefinition[], source?: DocSourceConfig): Promise<FetchResult>;
 }

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

@@ -9,7 +9,8 @@ export type { ConfigSource } from "./config-source.js";
 export type { AppContext, ReportSinkPort, ReportStorePort, ResolvedConfig, } from "./context.js";
 export type { DocContext, DocFetcher, DocSourceConfig, DocumentManifestEntry, DocumentOverlaySummary, FetchMetadata, FetchResult, ReleaseImpact, UrlFetchEntry, UrlFetchSummary, } from "./doc-fetcher.js";
 export type { EvalRunConfig, EvalRunner } from "./eval-runner.js";
+export type { CompilationContext, CompileResultAssertion, CompileResultPrompt, CompileResultProvider, CompileResultTestCase, ModeCompileResult, ModeHandler, ModeProviderEntry, ModeRubricConfig, PromptTemplate, } from "./mode-handler.js";
 export type { Logger } from "./logger.js";
 export type { PipelineStep } from "./pipeline-step.js";
-export type { AssertionDefinition, BaselineConfig, CanonicalDocRef, IdDocRef, PathDocRef, PerspectiveDocRef, SlugDocRef, TaskDefinition, TaskSource, TemplatedAssertion, ValueAssertion, } from "./task-source.js";
+export type { TaskSource } from "./task-source.js";
 export { canonicalDocRefLabel, isIdRef, isPathRef, isPerspectiveRef, isSlugRef, isTemplatedAssertion, } from "./task-source.js";

package/dist/_vendor/ailf-core/ports/mode-handler.d.ts

@@ -0,0 +1,129 @@
+/**
+ * ModeHandler — the common interface every evaluation mode implements.
+ *
+ * The pipeline dispatches to mode handlers through the PluginRegistry:
+ *   1. Look up the mode: `ctx.registry.getMode(mode)`
+ *   2. Import the handler module: `import(registration.handlerModule)`
+ *   3. Call: `module.handler.compileTask(task, ctx)`
+ *
+ * Each handler file exports a `handler` object conforming to this interface.
+ * The handler narrows the GeneralizedTaskDefinition to its mode-specific
+ * variant and produces a ModeCompileResult.
+ *
+ * Types here are minimal structural contracts — the eval package's Promptfoo
+ * types satisfy them via TypeScript structural compatibility.
+ *
+ * @see docs/design-docs/architecture-overhaul/extensibility-plugins.md
+ * @see packages/eval/src/pipeline/compiler/mode-handlers/
+ */
+import type { GeneralizedTaskDefinition } from "../types/generalized-task.js";
+/**
+ * A prompt template owned by a mode handler.
+ *
+ * Mode handlers can return these via `getPrompts()` to override the global
+ * config/prompts.ts templates. This lets non-literacy modes define their
+ * own prompt structures without polluting the global config.
+ */
+export interface PromptTemplate {
+    /** Unique identifier (e.g. "with-docs", "agentic") */
+    id: string;
+    /** Human-readable label for display */
+    label: string;
+    /** The prompt template string with {{variable}} placeholders */
+    template: string;
+    /** Variable names used by this template — for documentation only */
+    variables?: string[];
+}
+/** Compilation context — shared state the pipeline provides to every handler */
+export interface CompilationContext {
+    /** Eval package root directory (for resolving file paths) */
+    rootDir: string;
+    /** Grader provider ID for LLM-graded assertions */
+    graderProvider?: string;
+    /** Model providers to include in the evaluation */
+    models?: ModeProviderEntry[];
+    /** Rubric config (templates, weights) — loaded from config/rubrics */
+    rubricConfig?: ModeRubricConfig;
+}
+/** A model provider entry for compilation */
+export interface ModeProviderEntry {
+    id: string;
+    label: string;
+    config?: Record<string, unknown>;
+}
+/** Minimal rubric config needed by mode handlers */
+export interface ModeRubricConfig {
+    templates: Record<string, {
+        dimension?: string;
+        header: string;
+        scale: string[];
+        criteria_label?: string;
+    }>;
+}
+/** A provider entry in the compile result */
+export interface CompileResultProvider {
+    id: string;
+    label?: string;
+    config?: Record<string, unknown>;
+}
+/** A prompt entry in the compile result */
+export interface CompileResultPrompt {
+    id: string;
+    label: string;
+    raw: string;
+}
+/** A test case entry in the compile result */
+export interface CompileResultTestCase {
+    description: string;
+    vars: Record<string, unknown>;
+    assert?: CompileResultAssertion[];
+    prompts?: string[];
+}
+/** An assertion entry in a test case */
+export interface CompileResultAssertion {
+    type: string;
+    value?: unknown;
+    weight?: number;
+    provider?: string;
+    metadata?: Record<string, unknown>;
+}
+/**
+ * ModeCompileResult — the common output every mode handler produces.
+ *
+ * All four fields (providers, tests, prompts, warnings) are present in
+ * every handler's result type. Mode-specific extras (sandbox config,
+ * metadata, extensions) go in the `extras` bag.
+ */
+export interface ModeCompileResult {
+    /** Provider configurations for Promptfoo */
+    providers: CompileResultProvider[];
+    /** Compiled test cases */
+    tests: CompileResultTestCase[];
+    /** Prompt templates */
+    prompts: CompileResultPrompt[];
+    /** Warnings generated during compilation */
+    warnings: string[];
+    /** Mode-specific extras (extensions, sandboxConfig, metadata, etc.) */
+    extras?: Record<string, unknown>;
+}
+/**
+ * ModeHandler — the interface every evaluation mode handler exports.
+ *
+ * Handler modules are referenced by `ModeRegistration.handlerModule` in the
+ * plugin registry. The pipeline imports the module and calls `handler.compileTask()`.
+ *
+ * Each handler file should export:
+ *   export const handler: ModeHandler = { ... }
+ */
+export interface ModeHandler {
+    /** Compile a task definition into evaluation configuration */
+    compileTask(task: GeneralizedTaskDefinition, ctx: CompilationContext): ModeCompileResult;
+    /**
+     * Return prompt templates owned by this mode.
+     *
+     * When defined, the compiler uses these instead of global config/prompts.ts.
+     * Keys are prompt IDs (e.g. "with-docs", "agentic"). Returning undefined
+     * or omitting the method falls back to global prompts.
+     */
+    getPrompts?(): Record<string, PromptTemplate>;
+}

package/dist/_vendor/ailf-core/ports/mode-handler.js

@@ -0,0 +1,19 @@
+/**
+ * ModeHandler — the common interface every evaluation mode implements.
+ *
+ * The pipeline dispatches to mode handlers through the PluginRegistry:
+ *   1. Look up the mode: `ctx.registry.getMode(mode)`
+ *   2. Import the handler module: `import(registration.handlerModule)`
+ *   3. Call: `module.handler.compileTask(task, ctx)`
+ *
+ * Each handler file exports a `handler` object conforming to this interface.
+ * The handler narrows the GeneralizedTaskDefinition to its mode-specific
+ * variant and produces a ModeCompileResult.
+ *
+ * Types here are minimal structural contracts — the eval package's Promptfoo
+ * types satisfy them via TypeScript structural compatibility.
+ *
+ * @see docs/design-docs/architecture-overhaul/extensibility-plugins.md
+ * @see packages/eval/src/pipeline/compiler/mode-handlers/
+ */
+export {};

package/dist/_vendor/ailf-core/ports/task-source.d.ts

@@ -7,150 +7,44 @@
  * - RepoTaskSource (tasks-as-content Phase 4) — reads .ailf/tasks/
  *
  * The key invariant: the pipeline orchestrator and all downstream steps
- * work with TaskDefinition[] regardless of where they came from.
+ * work with GeneralizedTaskDefinition[] regardless of where they came from.
  */
+import type { GeneralizedAssertionDefinition, GeneralizedDocRef, GeneralizedTaskDefinition, GeneralizedTemplatedAssertion, IdDocRef, PathDocRef, PerspectiveDocRef, SlugDocRef } from "../types/generalized-task.js";
 import type { FilterOptions } from "../types/index.js";
-/** A templated assertion referencing a rubric template from config/rubrics.yaml */
-export interface TemplatedAssertion {
-    type: "llm-rubric";
-    template: string;
-    criteria: string[];
-    weight?: number;
-}
-/** A value-based assertion (contains, javascript, etc.) */
-export interface ValueAssertion {
-    type: string;
-    value?: unknown;
-    weight?: number;
-    [key: string]: unknown;
-}
-/** Any assertion definition — either templated or value-based */
-export type AssertionDefinition = TemplatedAssertion | ValueAssertion;
-/** Baseline variant configuration */
-export interface BaselineConfig {
-    /** Whether to generate a baseline variant. Default: true */
-    enabled?: boolean;
-    /** Rubric mode for baseline. Default: "abbreviated" */
-    rubric?: "abbreviated" | "full" | "none";
-}
-/**
- * A canonical documentation reference. Each entry resolves docs through
- * one of four strategies, discriminated by key presence (no explicit
- * `type` field). All strategies carry an optional `reason` for context.
- *
- * Strategies:
- * - `slug`        — one article by slug field (legacy, may not be unique)
- * - `path`        — one article by URL path (unique across sections)
- * - `id`          — one document by Sanity `_id` (drafts, imports)
- * - `perspective` — all articles in a content release (one-to-many)
- *
- * @see docs/design-docs/canonical-doc-resolution.md
- */
-export type CanonicalDocRef = SlugDocRef | PathDocRef | IdDocRef | PerspectiveDocRef;
-/** Resolve by article slug field. Legacy — prefer `path` for uniqueness. */
-export interface SlugDocRef {
-    slug: string;
-    reason?: string;
-}
-/** Resolve by URL path (after /docs/). Unique across sections. */
-export interface PathDocRef {
-    path: string;
-    reason?: string;
-}
-/** Resolve by Sanity document `_id`. The primary resolution strategy.
- *
- * Optional `slug` and `path` provide human-readable context — they are
- * NOT used for resolution (the `_id` is authoritative) but help YAML
- * authors understand which document is being referenced. The Content Lake
- * adapter populates them from the dereferenced article.
- */
-export interface IdDocRef {
-    id: string;
-    reason?: string;
-    /** Human-readable slug (informational only — not used for resolution) */
-    slug?: string;
-    /** Human-readable path (informational only — not used for resolution) */
-    path?: string;
-}
-/** Resolve all articles in a content release. One-to-many. */
-export interface PerspectiveDocRef {
-    perspective: string;
-    reason?: string;
-}
-/**
- * A loaded, validated task definition ready for expansion.
- *
- * This is the canonical intermediate representation — adapters produce
- * this from YAML, Content Lake, or .ailf/ files. Downstream consumers
- * (expansion, doc fetching, validation) work exclusively with this type.
- *
- * Design notes:
- * - `taskPrompt` is extracted from `vars.task` in YAML format
- * - `docsPath` is NOT included — it's an infrastructure detail derived
- *   from convention (`file://contexts/canonical/${id}.md`)
- * - `featureArea` is derived by the adapter (filename stem, document
- *   field, directory structure — depends on the source)
- */
-export interface TaskDefinition {
-    /** Unique task identifier */
-    id: string;
-    /** Human-readable description */
-    description: string;
-    /** Feature area this task belongs to */
-    featureArea: string;
-    /** The implementation task prompt (the user-facing request) */
-    taskPrompt: string;
-    /** Canonical doc references with reasons */
-    canonicalDocs: CanonicalDocRef[];
-    /** Path to the reference solution (relative to eval package root) */
-    referenceSolution: string;
-    /** Whether doc coverage rubric should be auto-generated */
-    docCoverage: boolean;
-    /** Assertion definitions (rubric templates + value assertions) */
-    assertions: AssertionDefinition[];
-    /** Baseline variant configuration */
-    baseline?: BaselineConfig;
-    /** Additional template variables beyond task (e.g., custom vars) */
-    extraVars?: Record<string, unknown>;
-    /** Lifecycle status — controls pipeline inclusion. Absent = "active". */
-    status?: "active" | "archived" | "draft" | "paused";
-    /** Freeform labels for filtering and organization */
-    tags?: string[];
-}
-/** Check if a canonical doc ref resolves by slug.
+/** Check if a doc ref resolves by slug.
  *
  * Excludes IdDocRef (which may carry an optional `slug` for display).
  * When both `id` and `slug` are present, it's an IdDocRef, not a SlugDocRef.
  */
-export declare function isSlugRef(ref: CanonicalDocRef): ref is SlugDocRef;
-/** Check if a canonical doc ref resolves by path.
+export declare function isSlugRef(ref: GeneralizedDocRef): ref is SlugDocRef;
+/** Check if a doc ref resolves by path.
  *
  * Excludes IdDocRef (which may carry an optional `path` for display).
  * When both `id` and `path` are present, it's an IdDocRef, not a PathDocRef.
  */
-export declare function isPathRef(ref: CanonicalDocRef): ref is PathDocRef;
-/** Check if a canonical doc ref resolves by document ID.
+export declare function isPathRef(ref: GeneralizedDocRef): ref is PathDocRef;
+/** Check if a doc ref resolves by document ID.
  *
  * Uses `"id" in ref` as the primary discriminator. IdDocRef may also carry
  * optional `slug` and `path` for display purposes, so we cannot exclude
  * on those keys. When both `id` and `slug` are present, `id` wins.
  */
-export declare function isIdRef(ref: CanonicalDocRef): ref is IdDocRef;
-/** Check if a canonical doc ref resolves by content release perspective */
-export declare function isPerspectiveRef(ref: CanonicalDocRef): ref is PerspectiveDocRef;
+export declare function isIdRef(ref: GeneralizedDocRef): ref is IdDocRef;
+/** Check if a doc ref resolves by content release perspective */
+export declare function isPerspectiveRef(ref: GeneralizedDocRef): ref is PerspectiveDocRef;
 /**
- * Extract a display identifier from any canonical doc ref.
+ * Extract a display identifier from any doc ref.
  * Useful for logging, error messages, and retrieval metrics.
  */
-export declare function canonicalDocRefLabel(ref: CanonicalDocRef): string;
+export declare function canonicalDocRefLabel(ref: GeneralizedDocRef): string;
 /** Check if an assertion uses the templated format (template + criteria) */
-export declare function isTemplatedAssertion(entry: AssertionDefinition): entry is TemplatedAssertion;
+export declare function isTemplatedAssertion(entry: GeneralizedAssertionDefinition): entry is GeneralizedTemplatedAssertion;
 /**
  * Port: Where task definitions come from.
  *
  * The pipeline never knows HOW tasks are loaded — it only sees
- * TaskDefinition[]. The adapter handles YAML parsing, GROQ queries,
- * filesystem scanning, etc.
+ * GeneralizedTaskDefinition[]. The adapter handles YAML parsing, GROQ
+ * queries, filesystem scanning, etc.
  */
 export interface TaskSource {
     /**
@@ -159,5 +53,5 @@ export interface TaskSource {
      * @param filter — Area, task ID, or changed-doc filters
      * @returns Validated task definitions ready for expansion
      */
-    loadTasks(filter?: FilterOptions): Promise<TaskDefinition[]>;
+    loadTasks(filter?: FilterOptions): Promise<GeneralizedTaskDefinition[]>;
 }

package/dist/_vendor/ailf-core/ports/task-source.js

@@ -7,12 +7,12 @@
  * - RepoTaskSource (tasks-as-content Phase 4) — reads .ailf/tasks/
  *
  * The key invariant: the pipeline orchestrator and all downstream steps
- * work with TaskDefinition[] regardless of where they came from.
+ * work with GeneralizedTaskDefinition[] regardless of where they came from.
  */
 // ---------------------------------------------------------------------------
-// Type guards — canonical doc refs
+// Type guards — doc refs
 // ---------------------------------------------------------------------------
-/** Check if a canonical doc ref resolves by slug.
+/** Check if a doc ref resolves by slug.
  *
  * Excludes IdDocRef (which may carry an optional `slug` for display).
  * When both `id` and `slug` are present, it's an IdDocRef, not a SlugDocRef.
@@ -20,7 +20,7 @@
 export function isSlugRef(ref) {
     return "slug" in ref && !("id" in ref);
 }
-/** Check if a canonical doc ref resolves by path.
+/** Check if a doc ref resolves by path.
  *
  * Excludes IdDocRef (which may carry an optional `path` for display).
  * When both `id` and `path` are present, it's an IdDocRef, not a PathDocRef.
@@ -28,7 +28,7 @@ export function isSlugRef(ref) {
 export function isPathRef(ref) {
     return "path" in ref && !("id" in ref);
 }
-/** Check if a canonical doc ref resolves by document ID.
+/** Check if a doc ref resolves by document ID.
  *
  * Uses `"id" in ref` as the primary discriminator. IdDocRef may also carry
  * optional `slug` and `path` for display purposes, so we cannot exclude
@@ -37,12 +37,12 @@ export function isPathRef(ref) {
 export function isIdRef(ref) {
     return "id" in ref;
 }
-/** Check if a canonical doc ref resolves by content release perspective */
+/** Check if a doc ref resolves by content release perspective */
 export function isPerspectiveRef(ref) {
     return "perspective" in ref;
 }
 /**
- * Extract a display identifier from any canonical doc ref.
+ * Extract a display identifier from any doc ref.
  * Useful for logging, error messages, and retrieval metrics.
  */
 export function canonicalDocRefLabel(ref) {

package/dist/_vendor/ailf-core/schemas/eval-config.d.ts

@@ -29,10 +29,15 @@ export declare const EvalConfigSchema: z.ZodObject<{
     graderReplications: z.ZodOptional<z.ZodNumber>;
     headers: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>;
     mode: z.ZodOptional<z.ZodEnum<{
-        agentic: "agentic";
+        custom: "custom";
+        literacy: "literacy";
+        "mcp-server": "mcp-server";
+        "agent-harness": "agent-harness";
+        "knowledge-probe": "knowledge-probe";
         baseline: "baseline";
-        full: "full";
+        agentic: "agentic";
         observed: "observed";
+        full: "full";
     }>>;
     noAutoScope: z.ZodOptional<z.ZodBoolean>;
     noCache: z.ZodOptional<z.ZodBoolean>;