@sanity/ailf 0.1.17 → 0.1.19
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/_vendor/ailf-core/examples/index.d.ts +123 -4
- package/dist/_vendor/ailf-core/examples/index.js +176 -4
- package/dist/_vendor/ailf-core/services/scoring.js +3 -3
- package/dist/adapters/task-sources/repo-task-source.js +8 -0
- package/dist/pipeline/agent-behavior-report.js +2 -0
- package/dist/pipeline/calculate-scores.js +4 -4
- package/dist/pipeline/expand-tasks.d.ts +2 -0
- package/dist/pipeline/expand-tasks.js +3 -1
- package/dist/pipeline/grader-compare-runner.js +2 -2
- package/dist/pipeline/grader-consistency-runner.js +2 -2
- package/package.json +1 -1
|
@@ -142,17 +142,133 @@ export declare const exampleGroqBlogListingData: readonly [{
|
|
|
142
142
|
readonly enabled: true;
|
|
143
143
|
readonly rubric: "abbreviated";
|
|
144
144
|
};
|
|
145
|
+
readonly execution: {
|
|
146
|
+
readonly enabled: false;
|
|
147
|
+
};
|
|
145
148
|
}];
|
|
146
149
|
/** Raw YAML string for example-groq-blog-listing (preserves comments) */
|
|
147
|
-
export declare const exampleGroqBlogListingYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\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: Blog listing with GROQ queries\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# 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#
|
|
150
|
+
export declare const exampleGroqBlogListingYaml = "# \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\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: Blog listing with GROQ queries\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# 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 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# Full field reference:\n# https://github.com/sanity-labs/ai-literacy-framework/blob/main/docs/CONTRIBUTING_TASKS.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# Unique identifier \u2014 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 \u2014 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 \u2014 the article's URL slug in your docs site\n # reason \u2014 why this doc is relevant (helps with auditing)\n #\n # This example uses slug-based references \u2014 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 \u2014 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 \u2014 leave empty (\"\"). The pipeline fills this in:\n # \u2022 Gold variant: injected with canonical doc content\n # \u2022 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 \u2014 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 \u2014 did the LLM implement the feature? (weight: 0.50)\n # code-correctness \u2014 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 \u2014 set to false to skip this task entirely\n # rubric \u2014 \"abbreviated\" (faster, default), \"full\", or \"none\"\n baseline:\n enabled: true\n rubric: abbreviated\n\n # Execution configuration.\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";
|
|
151
|
+
/** Parsed task data for example-id-based-ref (JSON-safe) */
|
|
152
|
+
export declare const exampleIdBasedRefData: readonly [{
|
|
153
|
+
readonly id: "example-id-based-ref";
|
|
154
|
+
readonly description: "Example — GROQ feature support (ID-based doc references)";
|
|
155
|
+
readonly featureArea: "groq";
|
|
156
|
+
readonly canonicalDocs: readonly [{
|
|
157
|
+
readonly id: "0ba88f1b-d1a7-418a-9267-2e343d01886a";
|
|
158
|
+
readonly slug: "groq-feature-support-by-context";
|
|
159
|
+
readonly reason: "GROQ feature support across different Sanity contexts";
|
|
160
|
+
}, {
|
|
161
|
+
readonly id: "5b9c2863-ef01-4565-af8e-ee54e081ee74";
|
|
162
|
+
readonly slug: "custom-groq-functions";
|
|
163
|
+
readonly reason: "Custom GROQ functions and pipelines";
|
|
164
|
+
}];
|
|
165
|
+
readonly docCoverage: true;
|
|
166
|
+
readonly vars: {
|
|
167
|
+
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";
|
|
168
|
+
readonly docs: "";
|
|
169
|
+
};
|
|
170
|
+
readonly assert: readonly [{
|
|
171
|
+
readonly type: "llm-rubric";
|
|
172
|
+
readonly template: "task-completion";
|
|
173
|
+
readonly criteria: readonly ["Explains GROQ availability across different Sanity contexts", "Describes custom GROQ function creation and usage", "Notes differences in GROQ support between contexts"];
|
|
174
|
+
}, {
|
|
175
|
+
readonly type: "llm-rubric";
|
|
176
|
+
readonly template: "code-correctness";
|
|
177
|
+
readonly criteria: readonly ["GROQ examples use valid syntax", "Custom function examples follow the correct API pattern"];
|
|
178
|
+
}];
|
|
179
|
+
readonly baseline: {
|
|
180
|
+
readonly enabled: true;
|
|
181
|
+
readonly rubric: "abbreviated";
|
|
182
|
+
};
|
|
183
|
+
readonly execution: {
|
|
184
|
+
readonly enabled: false;
|
|
185
|
+
};
|
|
186
|
+
}];
|
|
187
|
+
/** Raw YAML string for example-id-based-ref (preserves comments) */
|
|
188
|
+
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";
|
|
189
|
+
/** Parsed task data for example-path-based-ref (JSON-safe) */
|
|
190
|
+
export declare const examplePathBasedRefData: readonly [{
|
|
191
|
+
readonly id: "example-path-based-ref";
|
|
192
|
+
readonly description: "Example — GROQ mutations (path-based doc references)";
|
|
193
|
+
readonly featureArea: "groq";
|
|
194
|
+
readonly canonicalDocs: readonly [{
|
|
195
|
+
readonly path: "content-lake/mutations-introduction";
|
|
196
|
+
readonly reason: "Introduction to document mutations in the Content Lake";
|
|
197
|
+
}, {
|
|
198
|
+
readonly path: "content-lake/documents";
|
|
199
|
+
readonly reason: "Document structure and types (Content Lake, not CLI reference)";
|
|
200
|
+
}];
|
|
201
|
+
readonly docCoverage: true;
|
|
202
|
+
readonly vars: {
|
|
203
|
+
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";
|
|
204
|
+
readonly docs: "";
|
|
205
|
+
};
|
|
206
|
+
readonly assert: readonly [{
|
|
207
|
+
readonly type: "llm-rubric";
|
|
208
|
+
readonly template: "task-completion";
|
|
209
|
+
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"];
|
|
210
|
+
}, {
|
|
211
|
+
readonly type: "llm-rubric";
|
|
212
|
+
readonly template: "code-correctness";
|
|
213
|
+
readonly criteria: readonly ["Uses correct @sanity/client mutation API", "Patch operations use valid set/unset/inc syntax"];
|
|
214
|
+
}];
|
|
215
|
+
readonly baseline: {
|
|
216
|
+
readonly enabled: true;
|
|
217
|
+
readonly rubric: "abbreviated";
|
|
218
|
+
};
|
|
219
|
+
readonly execution: {
|
|
220
|
+
readonly enabled: false;
|
|
221
|
+
};
|
|
222
|
+
}];
|
|
223
|
+
/** Raw YAML string for example-path-based-ref (preserves comments) */
|
|
224
|
+
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";
|
|
225
|
+
/** Parsed task data for example-perspective-ref (JSON-safe) */
|
|
226
|
+
export declare const examplePerspectiveRefData: readonly [{
|
|
227
|
+
readonly id: "example-perspective-ref";
|
|
228
|
+
readonly description: "Example — GROQ features from content release (perspective-based doc references)";
|
|
229
|
+
readonly featureArea: "groq";
|
|
230
|
+
readonly canonicalDocs: readonly [{
|
|
231
|
+
readonly perspective: "rE9TSJvR4";
|
|
232
|
+
readonly reason: "All GROQ documentation updates in the test content release";
|
|
233
|
+
}, {
|
|
234
|
+
readonly slug: "groq-data-types";
|
|
235
|
+
readonly reason: "GROQ data type reference (published, stable)";
|
|
236
|
+
}];
|
|
237
|
+
readonly docCoverage: true;
|
|
238
|
+
readonly vars: {
|
|
239
|
+
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";
|
|
240
|
+
readonly docs: "";
|
|
241
|
+
};
|
|
242
|
+
readonly assert: readonly [{
|
|
243
|
+
readonly type: "llm-rubric";
|
|
244
|
+
readonly template: "task-completion";
|
|
245
|
+
readonly criteria: readonly ["Demonstrates GROQ join syntax for cross-document queries", "Shows GROQ filter patterns for webhook configuration", "Includes practical query examples from cheat sheet patterns"];
|
|
246
|
+
}, {
|
|
247
|
+
readonly type: "llm-rubric";
|
|
248
|
+
readonly template: "code-correctness";
|
|
249
|
+
readonly criteria: readonly ["All GROQ queries use valid syntax", "Reference joins use correct dereference operator (->)"];
|
|
250
|
+
}];
|
|
251
|
+
readonly baseline: {
|
|
252
|
+
readonly enabled: true;
|
|
253
|
+
readonly rubric: "abbreviated";
|
|
254
|
+
};
|
|
255
|
+
readonly execution: {
|
|
256
|
+
readonly enabled: false;
|
|
257
|
+
};
|
|
258
|
+
}];
|
|
259
|
+
/** Raw YAML string for example-perspective-ref (preserves comments) */
|
|
260
|
+
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";
|
|
148
261
|
/** Parsed task data for example-studio-custom-input (JSON-safe) */
|
|
149
262
|
export declare const exampleStudioCustomInputData: readonly [{
|
|
150
263
|
readonly id: "example-studio-custom-input";
|
|
151
264
|
readonly description: "Example — Custom input component in Sanity Studio";
|
|
152
265
|
readonly featureArea: "studio";
|
|
153
266
|
readonly canonicalDocs: readonly [{
|
|
154
|
-
readonly slug: "custom-input-
|
|
267
|
+
readonly slug: "custom-input-widgets";
|
|
155
268
|
readonly reason: "Guide for building custom form inputs in Sanity Studio";
|
|
269
|
+
}, {
|
|
270
|
+
readonly slug: "form-components";
|
|
271
|
+
readonly reason: "Form component API and customization patterns";
|
|
156
272
|
}];
|
|
157
273
|
readonly docCoverage: true;
|
|
158
274
|
readonly referenceSolution: "canonical/example-studio-custom-input.ts";
|
|
@@ -173,15 +289,18 @@ export declare const exampleStudioCustomInputData: readonly [{
|
|
|
173
289
|
readonly enabled: true;
|
|
174
290
|
readonly rubric: "abbreviated";
|
|
175
291
|
};
|
|
292
|
+
readonly execution: {
|
|
293
|
+
readonly enabled: false;
|
|
294
|
+
};
|
|
176
295
|
}];
|
|
177
296
|
/** Raw YAML string for example-studio-custom-input (preserves comments) */
|
|
178
|
-
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# To
|
|
297
|
+
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";
|
|
179
298
|
/** All task example data as a flat array (JSON-safe) */
|
|
180
299
|
export declare const allTaskData: readonly unknown[];
|
|
181
300
|
/** Map of task ID (filename stem) → raw YAML string (preserves comments) */
|
|
182
301
|
export declare const taskYamlFiles: Record<string, string>;
|
|
183
302
|
/** List of task file stems, in alphabetical order */
|
|
184
|
-
export declare const TASK_FILE_NAMES: readonly ["example-groq-blog-listing", "example-studio-custom-input"];
|
|
303
|
+
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"];
|
|
185
304
|
export type ExampleType = "config" | "source" | "rubric" | "threshold" | "ailf-config" | "task";
|
|
186
305
|
export declare const EXAMPLE_TYPES: readonly ExampleType[];
|
|
187
306
|
export interface ExampleRecord {
|
|
@@ -186,11 +186,170 @@ export const exampleGroqBlogListingData = [
|
|
|
186
186
|
"baseline": {
|
|
187
187
|
"enabled": true,
|
|
188
188
|
"rubric": "abbreviated"
|
|
189
|
+
},
|
|
190
|
+
"execution": {
|
|
191
|
+
"enabled": false
|
|
189
192
|
}
|
|
190
193
|
}
|
|
191
194
|
];
|
|
192
195
|
/** Raw YAML string for example-groq-blog-listing (preserves comments) */
|
|
193
|
-
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#
|
|
196
|
+
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 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# 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 # Execution configuration.\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";
|
|
197
|
+
/** Parsed task data for example-id-based-ref (JSON-safe) */
|
|
198
|
+
export const exampleIdBasedRefData = [
|
|
199
|
+
{
|
|
200
|
+
"id": "example-id-based-ref",
|
|
201
|
+
"description": "Example — GROQ feature support (ID-based doc references)",
|
|
202
|
+
"featureArea": "groq",
|
|
203
|
+
"canonicalDocs": [
|
|
204
|
+
{
|
|
205
|
+
"id": "0ba88f1b-d1a7-418a-9267-2e343d01886a",
|
|
206
|
+
"slug": "groq-feature-support-by-context",
|
|
207
|
+
"reason": "GROQ feature support across different Sanity contexts"
|
|
208
|
+
},
|
|
209
|
+
{
|
|
210
|
+
"id": "5b9c2863-ef01-4565-af8e-ee54e081ee74",
|
|
211
|
+
"slug": "custom-groq-functions",
|
|
212
|
+
"reason": "Custom GROQ functions and pipelines"
|
|
213
|
+
}
|
|
214
|
+
],
|
|
215
|
+
"docCoverage": true,
|
|
216
|
+
"vars": {
|
|
217
|
+
"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",
|
|
218
|
+
"docs": ""
|
|
219
|
+
},
|
|
220
|
+
"assert": [
|
|
221
|
+
{
|
|
222
|
+
"type": "llm-rubric",
|
|
223
|
+
"template": "task-completion",
|
|
224
|
+
"criteria": [
|
|
225
|
+
"Explains GROQ availability across different Sanity contexts",
|
|
226
|
+
"Describes custom GROQ function creation and usage",
|
|
227
|
+
"Notes differences in GROQ support between contexts"
|
|
228
|
+
]
|
|
229
|
+
},
|
|
230
|
+
{
|
|
231
|
+
"type": "llm-rubric",
|
|
232
|
+
"template": "code-correctness",
|
|
233
|
+
"criteria": [
|
|
234
|
+
"GROQ examples use valid syntax",
|
|
235
|
+
"Custom function examples follow the correct API pattern"
|
|
236
|
+
]
|
|
237
|
+
}
|
|
238
|
+
],
|
|
239
|
+
"baseline": {
|
|
240
|
+
"enabled": true,
|
|
241
|
+
"rubric": "abbreviated"
|
|
242
|
+
},
|
|
243
|
+
"execution": {
|
|
244
|
+
"enabled": false
|
|
245
|
+
}
|
|
246
|
+
}
|
|
247
|
+
];
|
|
248
|
+
/** Raw YAML string for example-id-based-ref (preserves comments) */
|
|
249
|
+
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";
|
|
250
|
+
/** Parsed task data for example-path-based-ref (JSON-safe) */
|
|
251
|
+
export const examplePathBasedRefData = [
|
|
252
|
+
{
|
|
253
|
+
"id": "example-path-based-ref",
|
|
254
|
+
"description": "Example — GROQ mutations (path-based doc references)",
|
|
255
|
+
"featureArea": "groq",
|
|
256
|
+
"canonicalDocs": [
|
|
257
|
+
{
|
|
258
|
+
"path": "content-lake/mutations-introduction",
|
|
259
|
+
"reason": "Introduction to document mutations in the Content Lake"
|
|
260
|
+
},
|
|
261
|
+
{
|
|
262
|
+
"path": "content-lake/documents",
|
|
263
|
+
"reason": "Document structure and types (Content Lake, not CLI reference)"
|
|
264
|
+
}
|
|
265
|
+
],
|
|
266
|
+
"docCoverage": true,
|
|
267
|
+
"vars": {
|
|
268
|
+
"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",
|
|
269
|
+
"docs": ""
|
|
270
|
+
},
|
|
271
|
+
"assert": [
|
|
272
|
+
{
|
|
273
|
+
"type": "llm-rubric",
|
|
274
|
+
"template": "task-completion",
|
|
275
|
+
"criteria": [
|
|
276
|
+
"Explains create, createOrReplace, patch, and delete mutations",
|
|
277
|
+
"Describes required document fields (_id, _type)",
|
|
278
|
+
"Shows patch operations for field-level updates",
|
|
279
|
+
"Includes practical code examples"
|
|
280
|
+
]
|
|
281
|
+
},
|
|
282
|
+
{
|
|
283
|
+
"type": "llm-rubric",
|
|
284
|
+
"template": "code-correctness",
|
|
285
|
+
"criteria": [
|
|
286
|
+
"Uses correct @sanity/client mutation API",
|
|
287
|
+
"Patch operations use valid set/unset/inc syntax"
|
|
288
|
+
]
|
|
289
|
+
}
|
|
290
|
+
],
|
|
291
|
+
"baseline": {
|
|
292
|
+
"enabled": true,
|
|
293
|
+
"rubric": "abbreviated"
|
|
294
|
+
},
|
|
295
|
+
"execution": {
|
|
296
|
+
"enabled": false
|
|
297
|
+
}
|
|
298
|
+
}
|
|
299
|
+
];
|
|
300
|
+
/** Raw YAML string for example-path-based-ref (preserves comments) */
|
|
301
|
+
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";
|
|
302
|
+
/** Parsed task data for example-perspective-ref (JSON-safe) */
|
|
303
|
+
export const examplePerspectiveRefData = [
|
|
304
|
+
{
|
|
305
|
+
"id": "example-perspective-ref",
|
|
306
|
+
"description": "Example — GROQ features from content release (perspective-based doc references)",
|
|
307
|
+
"featureArea": "groq",
|
|
308
|
+
"canonicalDocs": [
|
|
309
|
+
{
|
|
310
|
+
"perspective": "rE9TSJvR4",
|
|
311
|
+
"reason": "All GROQ documentation updates in the test content release"
|
|
312
|
+
},
|
|
313
|
+
{
|
|
314
|
+
"slug": "groq-data-types",
|
|
315
|
+
"reason": "GROQ data type reference (published, stable)"
|
|
316
|
+
}
|
|
317
|
+
],
|
|
318
|
+
"docCoverage": true,
|
|
319
|
+
"vars": {
|
|
320
|
+
"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",
|
|
321
|
+
"docs": ""
|
|
322
|
+
},
|
|
323
|
+
"assert": [
|
|
324
|
+
{
|
|
325
|
+
"type": "llm-rubric",
|
|
326
|
+
"template": "task-completion",
|
|
327
|
+
"criteria": [
|
|
328
|
+
"Demonstrates GROQ join syntax for cross-document queries",
|
|
329
|
+
"Shows GROQ filter patterns for webhook configuration",
|
|
330
|
+
"Includes practical query examples from cheat sheet patterns"
|
|
331
|
+
]
|
|
332
|
+
},
|
|
333
|
+
{
|
|
334
|
+
"type": "llm-rubric",
|
|
335
|
+
"template": "code-correctness",
|
|
336
|
+
"criteria": [
|
|
337
|
+
"All GROQ queries use valid syntax",
|
|
338
|
+
"Reference joins use correct dereference operator (->)"
|
|
339
|
+
]
|
|
340
|
+
}
|
|
341
|
+
],
|
|
342
|
+
"baseline": {
|
|
343
|
+
"enabled": true,
|
|
344
|
+
"rubric": "abbreviated"
|
|
345
|
+
},
|
|
346
|
+
"execution": {
|
|
347
|
+
"enabled": false
|
|
348
|
+
}
|
|
349
|
+
}
|
|
350
|
+
];
|
|
351
|
+
/** Raw YAML string for example-perspective-ref (preserves comments) */
|
|
352
|
+
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";
|
|
194
353
|
/** Parsed task data for example-studio-custom-input (JSON-safe) */
|
|
195
354
|
export const exampleStudioCustomInputData = [
|
|
196
355
|
{
|
|
@@ -199,8 +358,12 @@ export const exampleStudioCustomInputData = [
|
|
|
199
358
|
"featureArea": "studio",
|
|
200
359
|
"canonicalDocs": [
|
|
201
360
|
{
|
|
202
|
-
"slug": "custom-input-
|
|
361
|
+
"slug": "custom-input-widgets",
|
|
203
362
|
"reason": "Guide for building custom form inputs in Sanity Studio"
|
|
363
|
+
},
|
|
364
|
+
{
|
|
365
|
+
"slug": "form-components",
|
|
366
|
+
"reason": "Form component API and customization patterns"
|
|
204
367
|
}
|
|
205
368
|
],
|
|
206
369
|
"docCoverage": true,
|
|
@@ -232,26 +395,35 @@ export const exampleStudioCustomInputData = [
|
|
|
232
395
|
"baseline": {
|
|
233
396
|
"enabled": true,
|
|
234
397
|
"rubric": "abbreviated"
|
|
398
|
+
},
|
|
399
|
+
"execution": {
|
|
400
|
+
"enabled": false
|
|
235
401
|
}
|
|
236
402
|
}
|
|
237
403
|
];
|
|
238
404
|
/** Raw YAML string for example-studio-custom-input (preserves comments) */
|
|
239
|
-
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# To
|
|
405
|
+
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";
|
|
240
406
|
// ---------------------------------------------------------------------------
|
|
241
407
|
// Aggregate task exports
|
|
242
408
|
// ---------------------------------------------------------------------------
|
|
243
409
|
/** All task example data as a flat array (JSON-safe) */
|
|
244
410
|
export const allTaskData = [
|
|
245
411
|
...exampleGroqBlogListingData,
|
|
412
|
+
...exampleIdBasedRefData,
|
|
413
|
+
...examplePathBasedRefData,
|
|
414
|
+
...examplePerspectiveRefData,
|
|
246
415
|
...exampleStudioCustomInputData,
|
|
247
416
|
];
|
|
248
417
|
/** Map of task ID (filename stem) → raw YAML string (preserves comments) */
|
|
249
418
|
export const taskYamlFiles = {
|
|
250
419
|
"example-groq-blog-listing": exampleGroqBlogListingYaml,
|
|
420
|
+
"example-id-based-ref": exampleIdBasedRefYaml,
|
|
421
|
+
"example-path-based-ref": examplePathBasedRefYaml,
|
|
422
|
+
"example-perspective-ref": examplePerspectiveRefYaml,
|
|
251
423
|
"example-studio-custom-input": exampleStudioCustomInputYaml,
|
|
252
424
|
};
|
|
253
425
|
/** List of task file stems, in alphabetical order */
|
|
254
|
-
export const TASK_FILE_NAMES = ["example-groq-blog-listing", "example-studio-custom-input"];
|
|
426
|
+
export const TASK_FILE_NAMES = ["example-groq-blog-listing", "example-id-based-ref", "example-path-based-ref", "example-perspective-ref", "example-studio-custom-input"];
|
|
255
427
|
export const EXAMPLE_TYPES = ["config", "source", "rubric", "threshold", "ailf-config", "task"];
|
|
256
428
|
export const EXAMPLES = {
|
|
257
429
|
"config": {
|
|
@@ -63,12 +63,12 @@ export function detectFeatureArea(description) {
|
|
|
63
63
|
desc.includes("live preview")) {
|
|
64
64
|
return "visual-editing";
|
|
65
65
|
}
|
|
66
|
+
if (desc.includes("groq")) {
|
|
67
|
+
return "groq";
|
|
68
|
+
}
|
|
66
69
|
if (desc.includes("function") || desc.includes("webhook")) {
|
|
67
70
|
return "functions";
|
|
68
71
|
}
|
|
69
|
-
if (desc.startsWith("groq")) {
|
|
70
|
-
return "groq";
|
|
71
|
-
}
|
|
72
72
|
if (desc.includes("next") || desc.includes("app router")) {
|
|
73
73
|
return "nextjs-live";
|
|
74
74
|
}
|
|
@@ -57,6 +57,10 @@ export class RepoTaskSource {
|
|
|
57
57
|
throw new Error(`Failed to validate ${file}:\n${msg}`, { cause: err });
|
|
58
58
|
}
|
|
59
59
|
for (const entry of validated) {
|
|
60
|
+
// Filter stages:
|
|
61
|
+
// 1. Area filter — skip tasks outside requested feature areas
|
|
62
|
+
// 2. Task ID filter — skip tasks not matching explicit task IDs
|
|
63
|
+
// 3. Execution.enabled — skip tasks explicitly disabled
|
|
60
64
|
// Area filter
|
|
61
65
|
if (filter?.areas &&
|
|
62
66
|
filter.areas.length > 0 &&
|
|
@@ -71,6 +75,10 @@ export class RepoTaskSource {
|
|
|
71
75
|
!filter.taskIds.includes(entry.id)) {
|
|
72
76
|
continue;
|
|
73
77
|
}
|
|
78
|
+
// Execution.enabled filter — skip tasks explicitly disabled
|
|
79
|
+
if (entry.execution?.enabled === false) {
|
|
80
|
+
continue;
|
|
81
|
+
}
|
|
74
82
|
definitions.push(mapToTaskDefinition(entry));
|
|
75
83
|
}
|
|
76
84
|
}
|
|
@@ -53,6 +53,8 @@ export function detectFeatureArea(description) {
|
|
|
53
53
|
desc.includes("presentation") ||
|
|
54
54
|
desc.includes("live preview"))
|
|
55
55
|
return "visual-editing";
|
|
56
|
+
if (desc.includes("groq"))
|
|
57
|
+
return "groq";
|
|
56
58
|
if (desc.includes("function") || desc.includes("webhook"))
|
|
57
59
|
return "functions";
|
|
58
60
|
if (desc.includes("next") || desc.includes("app router"))
|
|
@@ -163,7 +163,7 @@ function aggregateAgentBehavior(resultsPath) {
|
|
|
163
163
|
const byFeature = {};
|
|
164
164
|
let hasBehaviorData = false;
|
|
165
165
|
for (const result of results) {
|
|
166
|
-
const feature = detectFeatureArea(result.description);
|
|
166
|
+
const feature = result.vars.__featureArea || detectFeatureArea(result.description);
|
|
167
167
|
const behavior = extractAgentBehavior(result);
|
|
168
168
|
if (!behavior) {
|
|
169
169
|
continue;
|
|
@@ -241,7 +241,7 @@ function aggregateUrlReferences(resultsPath) {
|
|
|
241
241
|
const results = readAndNormalizeResults(resultsPath);
|
|
242
242
|
const byFeature = {};
|
|
243
243
|
for (const result of results) {
|
|
244
|
-
const feature = detectFeatureArea(result.description);
|
|
244
|
+
const feature = result.vars.__featureArea || detectFeatureArea(result.description);
|
|
245
245
|
if (!byFeature[feature]) {
|
|
246
246
|
byFeature[feature] = {
|
|
247
247
|
baseline: { testCount: 0, urls: {} },
|
|
@@ -481,7 +481,7 @@ function scoreResults(results, weights, modelId) {
|
|
|
481
481
|
// Group by feature + docs/no-docs
|
|
482
482
|
const byFeature = {};
|
|
483
483
|
for (const result of results) {
|
|
484
|
-
const feature = detectFeatureArea(result.description);
|
|
484
|
+
const feature = result.vars.__featureArea || detectFeatureArea(result.description);
|
|
485
485
|
if (!byFeature[feature]) {
|
|
486
486
|
byFeature[feature] = { withDocs: [], withoutDocs: [] };
|
|
487
487
|
}
|
|
@@ -580,7 +580,7 @@ export function scoreAgenticResults(resultsPath, weights) {
|
|
|
580
580
|
// Group by feature area
|
|
581
581
|
const byFeature = {};
|
|
582
582
|
for (const result of results) {
|
|
583
|
-
const feature = detectFeatureArea(result.description);
|
|
583
|
+
const feature = result.vars.__featureArea || detectFeatureArea(result.description);
|
|
584
584
|
if (!byFeature[feature]) {
|
|
585
585
|
byFeature[feature] = [];
|
|
586
586
|
}
|
|
@@ -85,6 +85,8 @@ export interface SingleTaskDefinition {
|
|
|
85
85
|
description: string;
|
|
86
86
|
/** Opt-in: auto-generate a documentation coverage rubric for gold. */
|
|
87
87
|
doc_coverage?: boolean;
|
|
88
|
+
/** Feature area this task belongs to (flows through to scoring). */
|
|
89
|
+
featureArea?: string;
|
|
88
90
|
/** Explicit task ID — determines the canonical context filename. */
|
|
89
91
|
id: string;
|
|
90
92
|
/** Template variables: task prompt and docs path. */
|
|
@@ -168,7 +168,7 @@ export function expandTask(task, rubricConfig, mode = "baseline") {
|
|
|
168
168
|
assert: [...resolvedAsserts],
|
|
169
169
|
description: `${task.description} (gold)`,
|
|
170
170
|
...(mode === "baseline" ? { prompts: ["with-docs"] } : {}),
|
|
171
|
-
vars: { ...task.vars },
|
|
171
|
+
vars: { ...task.vars, __featureArea: task.featureArea ?? "" },
|
|
172
172
|
});
|
|
173
173
|
// Baseline entry — floor measurement (no docs, parametric knowledge only).
|
|
174
174
|
// Skipped entirely in agentic mode: the agentic prompt doesn't reference
|
|
@@ -188,6 +188,7 @@ export function expandTask(task, rubricConfig, mode = "baseline") {
|
|
|
188
188
|
vars: {
|
|
189
189
|
...task.vars,
|
|
190
190
|
docs: "",
|
|
191
|
+
__featureArea: task.featureArea ?? "",
|
|
191
192
|
},
|
|
192
193
|
...(baselineAsserts.length > 0 ? { assert: baselineAsserts } : {}),
|
|
193
194
|
});
|
|
@@ -204,6 +205,7 @@ function taskDefinitionToSingle(task) {
|
|
|
204
205
|
baseline: task.baseline,
|
|
205
206
|
description: task.description,
|
|
206
207
|
doc_coverage: task.docCoverage,
|
|
208
|
+
featureArea: task.featureArea,
|
|
207
209
|
id: task.id,
|
|
208
210
|
vars: {
|
|
209
211
|
docs: `file://contexts/canonical/${task.id}.md`,
|
|
@@ -52,10 +52,10 @@ function detectFeatureArea(description) {
|
|
|
52
52
|
desc.includes("presentation") ||
|
|
53
53
|
desc.includes("live preview"))
|
|
54
54
|
return "visual-editing";
|
|
55
|
+
if (desc.includes("groq"))
|
|
56
|
+
return "groq";
|
|
55
57
|
if (desc.includes("function") || desc.includes("webhook"))
|
|
56
58
|
return "functions";
|
|
57
|
-
if (desc.startsWith("groq"))
|
|
58
|
-
return "groq";
|
|
59
59
|
if (desc.includes("next") || desc.includes("app router"))
|
|
60
60
|
return "nextjs-live";
|
|
61
61
|
if (desc.includes("remix") ||
|
|
@@ -57,10 +57,10 @@ function detectFeatureArea(description) {
|
|
|
57
57
|
desc.includes("presentation") ||
|
|
58
58
|
desc.includes("live preview"))
|
|
59
59
|
return "visual-editing";
|
|
60
|
+
if (desc.includes("groq"))
|
|
61
|
+
return "groq";
|
|
60
62
|
if (desc.includes("function") || desc.includes("webhook"))
|
|
61
63
|
return "functions";
|
|
62
|
-
if (desc.startsWith("groq"))
|
|
63
|
-
return "groq";
|
|
64
64
|
if (desc.includes("next") || desc.includes("app router"))
|
|
65
65
|
return "nextjs-live";
|
|
66
66
|
if (desc.includes("remix") ||
|