@sanity/ailf-studio 0.3.0 → 0.4.0

package/dist/index.d.ts

@@ -1,6 +1,8 @@
 import * as sanity from 'sanity';
 import { DocumentActionComponent, ObjectInputProps, StringInputProps, ReleaseActionComponent, Tool } from 'sanity';
 import * as react_jsx_runtime from 'react/jsx-runtime';
+import * as react from 'react';
+import { ReactNode } from 'react';
 import { DocumentRef } from './document-ref.js';
 
 /**
@@ -210,386 +212,46 @@ interface RunEvaluationActionOptions {
  */
 declare function createRunEvaluationAction(options?: RunEvaluationActionOptions): ReleaseActionComponent;
 
+interface HelpContextValue {
+    /** Whether the drawer is open */
+    open: boolean;
+    /** Current topic ID */
+    topicId: string | null;
+    /** Open the drawer to a specific topic, or the context-derived default */
+    openHelp: (topicId?: string) => void;
+    /** Close the drawer */
+    closeHelp: () => void;
+    /** Navigate to a specific topic (adds to history) */
+    navigateTo: (topicId: string) => void;
+    /** Go back to the previous topic in history */
+    goBack: () => void;
+    /** Whether there's history to go back to */
+    canGoBack: boolean;
+}
+interface HelpProviderProps {
+    children: ReactNode;
+    /** Fallback topic when `openHelp()` is called without an argument */
+    defaultTopicId?: string;
+}
+declare function HelpProvider({ children, defaultTopicId }: HelpProviderProps): react.FunctionComponentElement<react.ProviderProps<HelpContextValue | null>>;
 /**
- * glossary.ts
- *
- * Centralized tooltip descriptions for all evaluation metrics.
- *
- * Every user-facing metric label in the Studio dashboard should use
- * a description from this file. This ensures consistent wording across
- * stat cards, table headers, and comparison views.
- *
- * @see docs/design-docs/scenario-matrix/evaluation-ceiling.md (three reference points)
- * @see docs/ARCHITECTURE.md (scoring model)
- */
-declare const GLOSSARY: {
-    readonly overallScore: "A weighted average across all feature areas: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%).";
-    readonly docLift: "How much the docs help, compared to the model's training data alone. This is the score with docs minus the score without. Higher is better.";
-    readonly actualScore: "How well an AI agent scores when it has to find docs on its own through web search and page fetching. This is the real-world scenario. Only available in full mode.";
-    readonly retrievalGap: "The score lost because agents can't find or use all the relevant docs. Calculated as ceiling minus actual. Lower is better; zero means agents find everything.";
-    readonly infraEfficiency: "What percentage of the docs' potential quality actually reaches agents (actual ÷ ceiling). 100% means agents find and use all relevant docs perfectly.";
-    readonly floor: "Score without any documentation. This tells you what the model already knows from its training data.";
-    readonly ceiling: "Score with gold-standard docs injected directly into the prompt. This is the best the documentation can do.";
-    readonly actual: "Score when an AI agent finds docs on its own through web search and page fetching. This is the real-world experience.";
-    readonly retGap: "Quality lost to discoverability (ceiling minus actual). The gap between what the docs could deliver and what agents actually get.";
-    readonly efficiency: "What fraction of the docs' quality reaches agents in practice (actual ÷ ceiling, shown as a percentage).";
-    readonly invertedRetGap: "⚠️ Inverted retrieval gap: agents that can't find the docs actually score higher, because the docs hurt performance. This usually means there's a doc quality problem.";
-    readonly score: "Weighted score for this feature area: Task Completion × 50% + Code Correctness × 25% + Doc Coverage × 25%.";
-    readonly taskCompletion: "Can the LLM implement the requested feature? Graded 0–100.";
-    readonly codeCorrectness: "Is the generated code idiomatic, correct, and following best practices? Graded 0–100.";
-    readonly docCoverage: "Did the docs provide the information needed to implement the feature? Graded 0–100.";
-    readonly tests: "Number of test cases in this feature area.";
-    readonly overallDelta: "Change in overall score between the two runs. Positive means the experiment scored higher.";
-    readonly actualDelta: "Change in actual (agent-retrieved) score between runs. Positive means agents did better.";
-    readonly retGapDelta: "Change in retrieval gap between runs. Negative is good here: it means the gap shrank and agents found more relevant docs.";
-    readonly efficiencyDelta: "Change in infrastructure efficiency between runs. Positive means agents are capturing more of the docs' potential.";
-    readonly baseline: "The reference run you're comparing against.";
-    readonly experiment: "The new run you're evaluating.";
-    readonly delta: "Difference between experiment and baseline. Positive means improvement, negative means regression.";
-    readonly change: "Whether the change is meaningful: improved, regressed, or unchanged (within the noise threshold).";
-    readonly lowScoringJudgments: "The grading model's explanations for tests that scored below 70/100.";
-    readonly judgmentReason: "The grading model's natural language explanation of what went wrong.";
-    readonly healthStrong: "Feature areas scoring 80 or above. The docs are working well for these features — AI agents produce correct, complete implementations.";
-    readonly healthAttention: "Feature areas scoring 70–79. These are okay but could be improved — there may be gaps in specific dimensions like doc coverage or code correctness.";
-    readonly healthWeak: "Feature areas scoring below 70. The docs are not providing enough support for AI agents to implement these features correctly.";
-    readonly negativeDocLiftMetric: "Number of areas where the documentation actually hurts AI performance — the model scores higher without docs than with them. This usually means the docs contain outdated patterns or incorrect examples.";
-    readonly weakAreas: "Feature areas where the overall score is below 70. These need the most attention — low scores mean AI agents consistently struggle to implement these features.";
-    readonly docsHurt: "Areas where the floor score (no docs) is higher than the ceiling score (with docs). The documentation is actively misleading the model. These docs need to be rewritten or removed.";
-    readonly retrievalIssues: "Areas where AI agents can find less than 70% of the available doc quality. The docs exist and are good, but agents can't discover them through search. Consider improving page titles, metadata, or search engine indexing.";
-    readonly dimWeaknesses: "Individual grading dimensions scoring below 50 within an area. These are the specific skills where AI agents fail most — task completion (can it build the feature?), code correctness (is the code right?), or doc coverage (did it use the docs?).";
-    readonly efficiencyAnomalies: "Areas where agent efficiency exceeds 100% — meaning agents perform better with self-found docs than with gold-standard docs injected directly. This can indicate doc quality issues (injected docs confuse the model) or agent memorization.";
-    readonly docLiftWins: "Areas where documentation boosts AI performance by 5 or more points. Higher doc lift means the docs are providing crucial information that the model doesn't already know.";
-    readonly retrievalExcellence: "Areas where AI agents successfully find and use at least 85% of the available doc quality through web search. Good retrieval means your docs are well-indexed and easy for agents to discover.";
-    readonly strengths: "What's working well: high-scoring areas, dimensions where the docs are strong, and areas where AI agents successfully find and use the documentation.";
-    readonly recommendations: "Prioritized remediation plan from gap analysis. Each recommendation identifies a documentation problem, the affected feature area, and the estimated score lift from fixing it.";
-    readonly totalPotentialLift: "Aggregate potential score lift if all identified gaps were fixed. This is a conservative estimate — each gap targets the median of non-bottlenecked dimensions, not 100.";
-    readonly failureMode: "The type of documentation problem: missing-docs (functionality not covered), incorrect-docs (factual errors), outdated-docs (stale API/patterns), or poor-structure (hard to find/understand).";
-    readonly estimatedLift: "Estimated composite score improvement if this gap is fully fixed. Based on raising bottleneck dimensions to the median of non-bottlenecked dimensions.";
-    readonly confidence: "How confident the classifier is in this diagnosis. High = strong keyword + structural signal agreement. Medium = partial agreement. Low = weak signals only.";
-    readonly agentBehaviorOverview: "How AI agents interacted with your documentation during evaluation: what they searched for, which pages they visited, and how much time they spent on network requests.";
-    readonly searchQueries: "The exact search queries agents used to find documentation. Helps you understand how agents discover your content and whether your docs appear for relevant queries.";
-    readonly docSlugsVisited: "Documentation page slugs that agents actually visited during evaluation. Compare against canonical docs to see if agents found the right pages.";
-    readonly externalDomains: "Non-Sanity domains that agents contacted during evaluation. High external domain counts may indicate agents couldn't find what they needed in your docs.";
-    readonly avgDocPagesVisited: "Average number of documentation pages visited per test. Higher counts can mean agents need to consult many pages (complex task) or can't find the right one quickly.";
-    readonly avgSearchesPerformed: "Average number of web searches performed per test. High search counts can indicate docs are hard to discover through search engines.";
-    readonly avgNetworkTimeMs: "Average time spent on network requests per test. Includes page fetches, search queries, and API calls.";
-    readonly totalRequests: "Total number of HTTP requests the agent made during the test, including searches, page visits, and API calls.";
-    readonly totalBytesDownloaded: "Total bytes downloaded by the agent. Large downloads may indicate the agent is fetching many pages or very large documents.";
-    readonly dimTaskCompletion: "Change in task completion between runs. Positive means implementations are more complete.";
-    readonly dimCodeCorrectness: "Change in code correctness between runs. Positive means better code quality.";
-    readonly dimDocCoverage: "Change in doc coverage between runs. Positive means the docs are providing more useful information.";
-    readonly areaDelta: "Score change for this area compared to the previous evaluation run.";
-    readonly sourceProduction: "Production source — docs fetched from the live production dataset. Scores reflect what real users and AI agents experience today.";
-    readonly sourceBranch: "Branch source — docs fetched from a branch or draft dataset. Use this to preview how content changes affect scores before publishing.";
-    readonly sourceLocal: "Local source — docs fetched from local files or a local dev server. Useful for testing doc changes before pushing.";
-    readonly reportScore: "The overall weighted score for this evaluation run: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%), averaged across all feature areas.";
-    readonly reportMode: "The evaluation mode determines which reference points are measured. Different modes test different aspects of how AI agents interact with documentation.";
-    readonly reportTrigger: "What initiated this evaluation run. Knowing the trigger helps you understand whether a score change was from a content edit, a code deploy, or a scheduled check.";
-    readonly modeBaseline: "Baseline mode — tests the model with gold-standard docs injected directly. Measures ceiling performance (best the docs can do).";
-    readonly modeFull: "Full mode — runs baseline + agentic. Compares ceiling (injected docs) against actual (agent-retrieved docs) to measure retrieval gap and infrastructure efficiency.";
-    readonly modeAgentic: "Agentic mode — the AI agent finds docs on its own via web search. Measures real-world performance: can agents actually discover and use your documentation?";
-    readonly modeObserved: "Observed mode — records how agents interact with docs without scoring. Captures search queries, pages visited, and browsing patterns for analysis.";
-    readonly modeDebug: "Debug mode — a diagnostic run for pipeline development. May use non-standard configurations or limited task sets.";
-    readonly triggerManual: "Manually triggered — someone ran the evaluation pipeline by hand, either locally or via the Studio UI.";
-    readonly triggerCi: "CI-triggered — the evaluation ran automatically as part of a pull request or merge pipeline.";
-    readonly triggerSchedule: "Scheduled — the evaluation ran on a recurring schedule (e.g. nightly or weekly) to track score trends over time.";
-    readonly triggerWebhook: "Webhook-triggered — a content change in Sanity triggered the evaluation automatically. Helps catch doc regressions early.";
-    readonly triggerCrossRepo: "Cross-repo — triggered from another repository via the dispatch API. Used when external repos want to validate their docs against AILF tasks.";
-};
-
-/**
- * queries.ts
- *
- * GROQ queries for the AILF Studio dashboard.
- *
- * All dashboard views are powered by GROQ — no backend needed.
- * These queries run directly against the Sanity Content Lake using
- * the Studio's built-in client.
- *
- * @see docs/design-docs/report-store/architecture.md — Query capabilities
- */
-/**
- * Fetch the N most recent reports, optionally filtered by source and/or mode.
- *
- * Used by: LatestReports view, Dashboard overview
- */
-declare const latestReportsQuery: string;
-/**
- * Fetch score data points for a time range, projected into a chart-friendly shape.
- *
- * Used by: ScoreTimeline view
- */
-declare const scoreTimelineQuery: string;
-/**
- * Fetch a single report by ID with full detail.
- *
- * Used by: ReportDetail view
- */
-declare const reportDetailQuery = "\n  *[_type == \"ailf.report\" && reportId == $reportId][0] {\n    _id,\n    reportId,\n    completedAt,\n    durationMs,\n    tag,\n    provenance,\n    summary,\n    comparison\n  }\n";
-/**
- * Find all reports that evaluated a specific Sanity document or perspective.
- *
- * Used by: ContentImpact view (answer: "what did my edit do to scores?")
- *
- * Supports optional source/mode filtering via the shared filter helpers.
- * When $documentId and $perspective are both null, the filter clause
- * `(null in [] || ...)` evaluates to false — callers should use
- * `recentDocumentEvalsQuery` for the browse-mode (no search) case.
- */
-declare const contentImpactQuery: string;
-/**
- * Browse recent reports that have document-level targeting or perspectives.
- *
- * Used by: ContentImpact view browse mode (no search active).
- * Shows the most recent document-scoped evaluations to help users discover
- * what content has been evaluated recently.
- */
-declare const recentDocumentEvalsQuery: string;
-/** All unique targetDocuments across reports (for autocomplete) */
-declare const distinctTargetDocumentsQuery = "\n  array::unique(*[_type == \"ailf.report\" && defined(provenance.targetDocuments)].provenance.targetDocuments[])\n";
-/**
- * Search articles by title, slug, or _id.
- *
- * Used by: ContentImpact document search autocomplete.
- * Returns a lightweight projection for the dropdown — title, slug, section path, and _id.
- * The `score()` function ranks title matches highest, then slug, then _id.
- *
- * Includes all document versions (published, drafts, perspectives) so the UI
- * can show provenance badges. The `_id` prefix determines the version type:
- * - No prefix → published (production)
- * - `drafts.` → unpublished draft
- * - `versions.<perspectiveId>.` → content release perspective
- */
-declare const articleSearchQuery = "\n  *[_type == \"article\"\n    && (\n      title match $query + \"*\"\n      || slug.current match $query + \"*\"\n      || _id match $query + \"*\"\n    )\n  ] | score(\n    boost(title match $query + \"*\", 3),\n    boost(slug.current match $query + \"*\", 2),\n    boost(_id match $query + \"*\", 1)\n  ) [0...40] {\n    _id,\n    title,\n    \"slug\": slug.current,\n    \"section\": primarySection->{ \"slug\": slug.current, \"title\": title }\n  }\n";
-/** All unique perspectives across reports (for autocomplete) */
-declare const distinctPerspectivesQuery = "\n  array::unique(*[_type == \"ailf.report\" && defined(provenance.source.perspective)].provenance.source.perspective)\n";
-/**
- * Fetch two reports by their IDs for comparison.
- *
- * Used by: ComparisonView — user selects two reports to compare
- */
-declare const comparisonPairQuery = "\n  *[_type == \"ailf.report\" && reportId in [$baselineId, $experimentId]] {\n    _id,\n    reportId,\n    completedAt,\n    tag,\n    provenance,\n    summary\n  }\n";
-/** All unique source names (for filter dropdowns) */
-declare const distinctSourcesQuery = "\n  array::unique(*[_type == \"ailf.report\"].provenance.source.name)\n";
-/** All unique modes (for filter dropdowns) */
-declare const distinctModesQuery = "\n  array::unique(*[_type == \"ailf.report\"].provenance.mode)\n";
-/** All unique feature areas (for filter dropdowns) */
-declare const distinctAreasQuery = "\n  array::unique(*[_type == \"ailf.report\"].provenance.areas[])\n";
-/** All unique trigger types (for filter dropdowns) */
-declare const distinctTriggersQuery = "\n  array::unique(*[_type == \"ailf.report\"].provenance.trigger.type)\n";
-
-/**
- * schema/eval-request.ts
- *
- * Sanity document schema for `ailf.evalRequest` — an intent document that
- * requests an evaluation pipeline run.
- *
- * The Studio creates this document programmatically (e.g. from the release
- * action component). A Sanity webhook watches for new `ailf.evalRequest`
- * documents with `status == "pending"` and dispatches a GitHub Actions
- * workflow. The webhook handler updates `status` to "dispatched", and a
- * callback from the pipeline sets it to "completed" or "failed".
- *
- * Intent documents are immutable — all fields are `readOnly: true`. The
- * document is created once and only updated server-side by the webhook
- * handler or pipeline callback.
- */
-declare const evalRequestSchema: {
-    type: "document";
-    name: "ailf.evalRequest";
-} & Omit<sanity.DocumentDefinition, "preview"> & {
-    preview?: sanity.PreviewConfig<{
-        perspective: string;
-        status: string;
-        tasks: string;
-    }, Record<string, unknown>> | undefined;
-};
-
-/**
- * schema/feature-area.ts
- *
- * Sanity document schema for `ailf.featureArea` — a feature area that groups
- * related evaluation tasks for score aggregation and filtering.
- *
- * Feature areas are lightweight metadata documents. They exist primarily to
- * provide referential integrity (tasks reference areas by document reference
- * instead of plain strings) and to enable Studio-based browsing/filtering.
- *
- * Initial areas (migrated from YAML filenames): groq, frameworks, functions,
- * nextjs-live, studio-setup, visual-editing.
+ * Access the help drawer state and actions.
  *
- * @see docs/design-docs/tasks-as-content.md
+ * @throws {Error} If called outside of a {@link HelpProvider}.
  */
-declare const featureAreaSchema: {
-    type: "document";
-    name: "ailf.featureArea";
-} & Omit<sanity.DocumentDefinition, "preview"> & {
-    preview?: sanity.PreviewConfig<{
-        areaId: string;
-        description: string;
-    }, Record<string, unknown>> | undefined;
-};
+declare function useHelp(): HelpContextValue;
 
 /**
- * schema/reference-solution.ts
+ * types.ts
  *
- * Sanity document schema for `ailf.referenceSolution` — a gold-standard
- * implementation that demonstrates the correct approach for a task.
+ * Shared types for the AILF Studio dashboard plugin.
  *
- * Reference solutions contain code blocks and prose explaining why the
- * approach is correct. They are referenced by `ailf.task` documents.
+ * These mirror the shapes returned by the GROQ queries in queries.ts.
+ * They're kept separate from the eval package types to avoid a build
+ * dependency — the Studio plugin reads from Sanity directly.
  *
- * @see docs/design-docs/tasks-as-content.md
- */
-declare const referenceSolutionSchema: {
-    type: "document";
-    name: "ailf.referenceSolution";
-} & Omit<sanity.DocumentDefinition, "preview"> & {
-    preview?: sanity.PreviewConfig<{
-        title: string;
-    }, Record<"title", any>> | undefined;
-};
-
-/**
- * schema/report.ts
- *
- * Sanity document schema for `ailf.report` — the persisted evaluation report.
- *
- * This schema defines how reports appear in Sanity Studio and enables
- * GROQ queries for the dashboard. The document shape mirrors the
- * `Report` type in `packages/eval/src/pipeline/types.ts`.
- *
- * Reports are immutable events (P1) — once created, they should not be
- * edited. The schema uses `readOnly: true` on all fields to enforce this.
- *
- * @see docs/design-docs/report-store/domain-model.md
- * @see docs/design-docs/report-store/architecture.md
- */
-declare const reportSchema: {
-    type: "document";
-    name: "ailf.report";
-} & Omit<sanity.DocumentDefinition, "preview"> & {
-    preview?: sanity.PreviewConfig<{
-        completedAt: string;
-        mode: string;
-        overall: string;
-        tag: string;
-    }, Record<string, unknown>> | undefined;
-};
-
-/**
- * schema/task.ts
- *
- * Sanity document schema for `ailf.task` — an evaluation task definition.
- *
- * This is the core unit of the AI Literacy Framework. A task defines:
- * - What the LLM should implement (the task prompt)
- * - Which docs are relevant (canonical doc references)
- * - How to grade the output (assertions with rubric templates)
- * - A gold-standard implementation (reference solution)
- * - When/how the task runs (execution controls)
- *
- * ## Execution paths
- *
- * Published tasks are automatically discovered by the pipeline — no
- * registration step needed. There are four ways to execute a task:
- *
- * 1. **Run Task Eval** — click ▶ on any ailf.task document in Studio.
- *    Creates an ailf.evalRequest scoped to this task. Webhook dispatches
- *    the pipeline; score appears inline when complete (~10–15 min).
- * 2. **Run AI Eval** — click on a content release page. Auto-scopes to
- *    tasks whose canonical docs are in the release.
- * 3. **CLI** — `ailf pipeline --task <id>` or `ailf pipeline --area <area>`.
- * 4. **Scheduled** — GitHub Actions cron (daily baseline, weekly full).
- *
- * Tasks can be authored natively in Studio or mirrored from external
- * repositories. Mirrored tasks have a read-only `origin` block that
- * tracks their source repo provenance.
- *
- * @see docs/CONTRIBUTING_TASKS.md#running-your-task — full execution guide
- * @see docs/design-docs/tasks-as-content.md
- * @see docs/design-docs/tasks-as-content.md#decision-8-domain-specific-assertion-types-not-a-promptfoo-subset
- */
-declare const taskSchema: {
-    type: "document";
-    name: "ailf.task";
-} & Omit<sanity.DocumentDefinition, "preview"> & {
-    preview?: sanity.PreviewConfig<{
-        area: string;
-        description: string;
-        id: string;
-        origin: string;
-        ownership: string;
-        status: string;
-    }, Record<string, unknown>> | undefined;
-};
-
-/**
- * schema/webhook-config.ts
- *
- * Sanity document schema for `ailf.webhookConfig` — the "evaluate on publish"
- * toggle and webhook-triggered evaluation settings.
- *
- * This is a singleton document (only one should exist) that controls
- * whether content changes automatically trigger evaluation pipelines.
- *
- * @see docs/design-docs/report-store/visibility-workflows.md
- */
-declare const webhookConfigSchema: {
-    type: "document";
-    name: "ailf.webhookConfig";
-} & Omit<sanity.DocumentDefinition, "preview"> & {
-    preview?: sanity.PreviewConfig<{
-        enabled: string;
-    }, Record<string, unknown>> | undefined;
-};
-
-/**
- * tool.tsx
- *
- * Sanity Studio tool definition for the AILF dashboard.
- *
- * Registers as a top-level Studio tool accessible from the sidebar.
- * Defines URL-based routing so each view is bookmarkable and
- * supports browser back/forward navigation.
- *
- * Route structure:
- *   /ailf                        → Latest Reports (home)
- *   /ailf/report/:reportId       → Report Detail
- *   /ailf/timeline               → Score Timeline
- *   /ailf/compare                → Compare
- */
-
-/**
- * AILF Dashboard tool configuration.
- *
- * Add to your sanity.config.ts:
- * ```ts
- * import { ailfTool } from "@sanity/ailf-studio"
- *
- * export default defineConfig({
- *   // ...
- *   tools: [ailfTool()],
- * })
- * ```
- */
-interface AilfToolOptions {
-    name?: string;
-    title?: string;
-}
-declare function ailfTool(options?: AilfToolOptions): Tool;
-
-/**
- * types.ts
- *
- * Shared types for the AILF Studio dashboard plugin.
- *
- * These mirror the shapes returned by the GROQ queries in queries.ts.
- * They're kept separate from the eval package types to avoid a build
- * dependency — the Studio plugin reads from Sanity directly.
- *
- * Cross-package contract types (DocumentRef, ScoreGrade, scoreGrade) are
- * imported from @sanity/ailf-shared — the single source of truth.
+ * Cross-package contract types (DocumentRef, ScoreGrade, scoreGrade) are
+ * imported from @sanity/ailf-shared — the single source of truth.
  */
 
 /** Comparison data as stored in Sanity */
@@ -844,6 +506,451 @@ interface TimelineDataPoint {
     source: string;
     tag: null | string;
 }
+/**
+ * A single help topic extracted from markdown docs at build time.
+ *
+ * Topics are authored using `:::help` remark container directives in markdown
+ * files under `docs/`. The extraction script (`scripts/extract-help.ts`) reads
+ * these directives and emits a generated TypeScript module that the HelpDrawer
+ * component imports.
+ *
+ * @see docs/design-docs/contextual-help-sidebar.md
+ */
+interface HelpTopic {
+    /** URL-safe identifier — matches the #id in the :::help directive */
+    id: string;
+    /** Display title shown in the drawer header */
+    title: string;
+    /** Markdown body content (rendered in the drawer) */
+    body: string;
+    /** Source file path (for debugging / "Edit this page" links) */
+    source: string;
+    /** Related topic IDs — rendered as "See also" links */
+    related?: string[];
+    /** Tags for search/filtering */
+    tags?: string[];
+}
+
+/**
+ * lib/help-topics.ts
+ *
+ * Utility functions for help topic lookup and context-aware topic
+ * derivation. Used by the HelpDrawer and HelpContext to determine
+ * which topic to show based on the current router state.
+ *
+ * @see docs/design-docs/contextual-help-sidebar.md
+ */
+
+/** Router state shape (matches Dashboard.tsx) */
+interface RouterState {
+    focus?: string;
+    reportId?: string;
+    subTab?: string;
+    tab?: string;
+    view?: string;
+}
+/**
+ * Derive the default help topic from the current router state.
+ * This is the "help finds you" mechanism — the drawer shows a
+ * relevant topic based on what the user is currently viewing.
+ */
+declare function deriveHelpTopic(routerState: RouterState): string;
+/**
+ * Find a help topic by ID. Returns undefined if not found.
+ */
+declare function findTopic(topicId: string): HelpTopic | undefined;
+/**
+ * Simple client-side text search across help topics.
+ * Matches against title and body (case-insensitive substring).
+ * Returns all topics if query is empty.
+ */
+declare function searchTopics(query: string): HelpTopic[];
+
+/**
+ * HelpDrawer.tsx
+ *
+ * Sliding help panel for the AILF Studio dashboard. Anchored to the
+ * right edge of the tool viewport, pushes main content left (non-modal).
+ *
+ * The drawer:
+ * - Reads current topic from HelpContext
+ * - Renders markdown body via HelpMarkdown
+ * - Shows "See also" links for related topics
+ * - Includes a search bar for topic discovery
+ * - Supports back navigation through topic history
+ *
+ * @see docs/design-docs/contextual-help-sidebar.md
+ */
+declare function HelpDrawer(): react_jsx_runtime.JSX.Element | null;
+
+/**
+ * glossary.ts
+ *
+ * Centralized tooltip descriptions for all evaluation metrics.
+ *
+ * Every user-facing metric label in the Studio dashboard should use
+ * a description from this file. This ensures consistent wording across
+ * stat cards, table headers, and comparison views.
+ *
+ * @see docs/design-docs/scenario-matrix/evaluation-ceiling.md (three reference points)
+ * @see docs/ARCHITECTURE.md (scoring model)
+ */
+declare const GLOSSARY: {
+    readonly overallScore: "A weighted average across all feature areas: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%).";
+    readonly docLift: "How much the docs help, compared to the model's training data alone. This is the score with docs minus the score without. Higher is better.";
+    readonly actualScore: "How well an AI agent scores when it has to find docs on its own through web search and page fetching. This is the real-world scenario. Only available in full mode.";
+    readonly retrievalGap: "The score lost because agents can't find or use all the relevant docs. Calculated as ceiling minus actual. Lower is better; zero means agents find everything.";
+    readonly infraEfficiency: "What percentage of the docs' potential quality actually reaches agents (actual ÷ ceiling). 100% means agents find and use all relevant docs perfectly.";
+    readonly floor: "Score without any documentation. This tells you what the model already knows from its training data.";
+    readonly ceiling: "Score with gold-standard docs injected directly into the prompt. This is the best the documentation can do.";
+    readonly actual: "Score when an AI agent finds docs on its own through web search and page fetching. This is the real-world experience.";
+    readonly retGap: "Quality lost to discoverability (ceiling minus actual). The gap between what the docs could deliver and what agents actually get.";
+    readonly efficiency: "What fraction of the docs' quality reaches agents in practice (actual ÷ ceiling, shown as a percentage).";
+    readonly invertedRetGap: "⚠️ Inverted retrieval gap: agents that can't find the docs actually score higher, because the docs hurt performance. This usually means there's a doc quality problem.";
+    readonly score: "Weighted score for this feature area: Task Completion × 50% + Code Correctness × 25% + Doc Coverage × 25%.";
+    readonly taskCompletion: "Can the LLM implement the requested feature? Graded 0–100.";
+    readonly codeCorrectness: "Is the generated code idiomatic, correct, and following best practices? Graded 0–100.";
+    readonly docCoverage: "Did the docs provide the information needed to implement the feature? Graded 0–100.";
+    readonly tests: "Number of test cases in this feature area.";
+    readonly overallDelta: "Change in overall score between the two runs. Positive means the experiment scored higher.";
+    readonly actualDelta: "Change in actual (agent-retrieved) score between runs. Positive means agents did better.";
+    readonly retGapDelta: "Change in retrieval gap between runs. Negative is good here: it means the gap shrank and agents found more relevant docs.";
+    readonly efficiencyDelta: "Change in infrastructure efficiency between runs. Positive means agents are capturing more of the docs' potential.";
+    readonly baseline: "The reference run you're comparing against.";
+    readonly experiment: "The new run you're evaluating.";
+    readonly delta: "Difference between experiment and baseline. Positive means improvement, negative means regression.";
+    readonly change: "Whether the change is meaningful: improved, regressed, or unchanged (within the noise threshold).";
+    readonly lowScoringJudgments: "The grading model's explanations for tests that scored below 70/100.";
+    readonly judgmentReason: "The grading model's natural language explanation of what went wrong.";
+    readonly healthStrong: "Feature areas scoring 80 or above. The docs are working well for these features — AI agents produce correct, complete implementations.";
+    readonly healthAttention: "Feature areas scoring 70–79. These are okay but could be improved — there may be gaps in specific dimensions like doc coverage or code correctness.";
+    readonly healthWeak: "Feature areas scoring below 70. The docs are not providing enough support for AI agents to implement these features correctly.";
+    readonly negativeDocLiftMetric: "Number of areas where the documentation actually hurts AI performance — the model scores higher without docs than with them. This usually means the docs contain outdated patterns or incorrect examples.";
+    readonly weakAreas: "Feature areas where the overall score is below 70. These need the most attention — low scores mean AI agents consistently struggle to implement these features.";
+    readonly docsHurt: "Areas where the floor score (no docs) is higher than the ceiling score (with docs). The documentation is actively misleading the model. These docs need to be rewritten or removed.";
+    readonly retrievalIssues: "Areas where AI agents can find less than 70% of the available doc quality. The docs exist and are good, but agents can't discover them through search. Consider improving page titles, metadata, or search engine indexing.";
+    readonly dimWeaknesses: "Individual grading dimensions scoring below 50 within an area. These are the specific skills where AI agents fail most — task completion (can it build the feature?), code correctness (is the code right?), or doc coverage (did it use the docs?).";
+    readonly efficiencyAnomalies: "Areas where agent efficiency exceeds 100% — meaning agents perform better with self-found docs than with gold-standard docs injected directly. This can indicate doc quality issues (injected docs confuse the model) or agent memorization.";
+    readonly docLiftWins: "Areas where documentation boosts AI performance by 5 or more points. Higher doc lift means the docs are providing crucial information that the model doesn't already know.";
+    readonly retrievalExcellence: "Areas where AI agents successfully find and use at least 85% of the available doc quality through web search. Good retrieval means your docs are well-indexed and easy for agents to discover.";
+    readonly strengths: "What's working well: high-scoring areas, dimensions where the docs are strong, and areas where AI agents successfully find and use the documentation.";
+    readonly recommendations: "Prioritized remediation plan from gap analysis. Each recommendation identifies a documentation problem, the affected feature area, and the estimated score lift from fixing it.";
+    readonly totalPotentialLift: "Aggregate potential score lift if all identified gaps were fixed. This is a conservative estimate — each gap targets the median of non-bottlenecked dimensions, not 100.";
+    readonly failureMode: "The type of documentation problem: missing-docs (functionality not covered), incorrect-docs (factual errors), outdated-docs (stale API/patterns), or poor-structure (hard to find/understand).";
+    readonly estimatedLift: "Estimated composite score improvement if this gap is fully fixed. Based on raising bottleneck dimensions to the median of non-bottlenecked dimensions.";
+    readonly confidence: "How confident the classifier is in this diagnosis. High = strong keyword + structural signal agreement. Medium = partial agreement. Low = weak signals only.";
+    readonly agentBehaviorOverview: "How AI agents interacted with your documentation during evaluation: what they searched for, which pages they visited, and how much time they spent on network requests.";
+    readonly searchQueries: "The exact search queries agents used to find documentation. Helps you understand how agents discover your content and whether your docs appear for relevant queries.";
+    readonly docSlugsVisited: "Documentation page slugs that agents actually visited during evaluation. Compare against canonical docs to see if agents found the right pages.";
+    readonly externalDomains: "Non-Sanity domains that agents contacted during evaluation. High external domain counts may indicate agents couldn't find what they needed in your docs.";
+    readonly avgDocPagesVisited: "Average number of documentation pages visited per test. Higher counts can mean agents need to consult many pages (complex task) or can't find the right one quickly.";
+    readonly avgSearchesPerformed: "Average number of web searches performed per test. High search counts can indicate docs are hard to discover through search engines.";
+    readonly avgNetworkTimeMs: "Average time spent on network requests per test. Includes page fetches, search queries, and API calls.";
+    readonly totalRequests: "Total number of HTTP requests the agent made during the test, including searches, page visits, and API calls.";
+    readonly totalBytesDownloaded: "Total bytes downloaded by the agent. Large downloads may indicate the agent is fetching many pages or very large documents.";
+    readonly dimTaskCompletion: "Change in task completion between runs. Positive means implementations are more complete.";
+    readonly dimCodeCorrectness: "Change in code correctness between runs. Positive means better code quality.";
+    readonly dimDocCoverage: "Change in doc coverage between runs. Positive means the docs are providing more useful information.";
+    readonly areaDelta: "Score change for this area compared to the previous evaluation run.";
+    readonly sourceProduction: "Production source — docs fetched from the live production dataset. Scores reflect what real users and AI agents experience today.";
+    readonly sourceBranch: "Branch source — docs fetched from a branch or draft dataset. Use this to preview how content changes affect scores before publishing.";
+    readonly sourceLocal: "Local source — docs fetched from local files or a local dev server. Useful for testing doc changes before pushing.";
+    readonly reportScore: "The overall weighted score for this evaluation run: Task Completion (50%), Code Correctness (25%), and Doc Coverage (25%), averaged across all feature areas.";
+    readonly reportMode: "The evaluation mode determines which reference points are measured. Different modes test different aspects of how AI agents interact with documentation.";
+    readonly reportTrigger: "What initiated this evaluation run. Knowing the trigger helps you understand whether a score change was from a content edit, a code deploy, or a scheduled check.";
+    readonly modeBaseline: "Baseline mode — tests the model with gold-standard docs injected directly. Measures ceiling performance (best the docs can do).";
+    readonly modeFull: "Full mode — runs baseline + agentic. Compares ceiling (injected docs) against actual (agent-retrieved docs) to measure retrieval gap and infrastructure efficiency.";
+    readonly modeAgentic: "Agentic mode — the AI agent finds docs on its own via web search. Measures real-world performance: can agents actually discover and use your documentation?";
+    readonly modeObserved: "Observed mode — records how agents interact with docs without scoring. Captures search queries, pages visited, and browsing patterns for analysis.";
+    readonly modeDebug: "Debug mode — a diagnostic run for pipeline development. May use non-standard configurations or limited task sets.";
+    readonly triggerManual: "Manually triggered — someone ran the evaluation pipeline by hand, either locally or via the Studio UI.";
+    readonly triggerCi: "CI-triggered — the evaluation ran automatically as part of a pull request or merge pipeline.";
+    readonly triggerSchedule: "Scheduled — the evaluation ran on a recurring schedule (e.g. nightly or weekly) to track score trends over time.";
+    readonly triggerWebhook: "Webhook-triggered — a content change in Sanity triggered the evaluation automatically. Helps catch doc regressions early.";
+    readonly triggerCrossRepo: "Cross-repo — triggered from another repository via the dispatch API. Used when external repos want to validate their docs against AILF tasks.";
+};
+
+/**
+ * queries.ts
+ *
+ * GROQ queries for the AILF Studio dashboard.
+ *
+ * All dashboard views are powered by GROQ — no backend needed.
+ * These queries run directly against the Sanity Content Lake using
+ * the Studio's built-in client.
+ *
+ * @see docs/design-docs/report-store/architecture.md — Query capabilities
+ */
+/**
+ * Fetch the N most recent reports, optionally filtered by source and/or mode.
+ *
+ * Used by: LatestReports view, Dashboard overview
+ */
+declare const latestReportsQuery: string;
+/**
+ * Fetch score data points for a time range, projected into a chart-friendly shape.
+ *
+ * Used by: ScoreTimeline view
+ */
+declare const scoreTimelineQuery: string;
+/**
+ * Fetch a single report by ID with full detail.
+ *
+ * Used by: ReportDetail view
+ */
+declare const reportDetailQuery = "\n  *[_type == \"ailf.report\" && reportId == $reportId][0] {\n    _id,\n    reportId,\n    completedAt,\n    durationMs,\n    tag,\n    provenance,\n    summary,\n    comparison\n  }\n";
+/**
+ * Find all reports that evaluated a specific Sanity document or perspective.
+ *
+ * Used by: ContentImpact view (answer: "what did my edit do to scores?")
+ *
+ * Supports optional source/mode filtering via the shared filter helpers.
+ * When $documentId and $perspective are both null, the filter clause
+ * `(null in [] || ...)` evaluates to false — callers should use
+ * `recentDocumentEvalsQuery` for the browse-mode (no search) case.
+ */
+declare const contentImpactQuery: string;
+/**
+ * Browse recent reports that have document-level targeting or perspectives.
+ *
+ * Used by: ContentImpact view browse mode (no search active).
+ * Shows the most recent document-scoped evaluations to help users discover
+ * what content has been evaluated recently.
+ */
+declare const recentDocumentEvalsQuery: string;
+/** All unique targetDocuments across reports (for autocomplete) */
+declare const distinctTargetDocumentsQuery = "\n  array::unique(*[_type == \"ailf.report\" && defined(provenance.targetDocuments)].provenance.targetDocuments[])\n";
+/**
+ * Search articles by title, slug, or _id.
+ *
+ * Used by: ContentImpact document search autocomplete.
+ * Returns a lightweight projection for the dropdown — title, slug, section path, and _id.
+ * The `score()` function ranks title matches highest, then slug, then _id.
+ *
+ * Includes all document versions (published, drafts, perspectives) so the UI
+ * can show provenance badges. The `_id` prefix determines the version type:
+ * - No prefix → published (production)
+ * - `drafts.` → unpublished draft
+ * - `versions.<perspectiveId>.` → content release perspective
+ */
+declare const articleSearchQuery = "\n  *[_type == \"article\"\n    && (\n      title match $query + \"*\"\n      || slug.current match $query + \"*\"\n      || _id match $query + \"*\"\n    )\n  ] | score(\n    boost(title match $query + \"*\", 3),\n    boost(slug.current match $query + \"*\", 2),\n    boost(_id match $query + \"*\", 1)\n  ) [0...40] {\n    _id,\n    title,\n    \"slug\": slug.current,\n    \"section\": primarySection->{ \"slug\": slug.current, \"title\": title }\n  }\n";
+/** All unique perspectives across reports (for autocomplete) */
+declare const distinctPerspectivesQuery = "\n  array::unique(*[_type == \"ailf.report\" && defined(provenance.source.perspective)].provenance.source.perspective)\n";
+/**
+ * Fetch two reports by their IDs for comparison.
+ *
+ * Used by: ComparisonView — user selects two reports to compare
+ */
+declare const comparisonPairQuery = "\n  *[_type == \"ailf.report\" && reportId in [$baselineId, $experimentId]] {\n    _id,\n    reportId,\n    completedAt,\n    tag,\n    provenance,\n    summary\n  }\n";
+/** All unique source names (for filter dropdowns) */
+declare const distinctSourcesQuery = "\n  array::unique(*[_type == \"ailf.report\"].provenance.source.name)\n";
+/** All unique modes (for filter dropdowns) */
+declare const distinctModesQuery = "\n  array::unique(*[_type == \"ailf.report\"].provenance.mode)\n";
+/** All unique feature areas (for filter dropdowns) */
+declare const distinctAreasQuery = "\n  array::unique(*[_type == \"ailf.report\"].provenance.areas[])\n";
+/** All unique trigger types (for filter dropdowns) */
+declare const distinctTriggersQuery = "\n  array::unique(*[_type == \"ailf.report\"].provenance.trigger.type)\n";
+
+/**
+ * schema/eval-request.ts
+ *
+ * Sanity document schema for `ailf.evalRequest` — an intent document that
+ * requests an evaluation pipeline run.
+ *
+ * The Studio creates this document programmatically (e.g. from the release
+ * action component). A Sanity webhook watches for new `ailf.evalRequest`
+ * documents with `status == "pending"` and dispatches a GitHub Actions
+ * workflow. The webhook handler updates `status` to "dispatched", and a
+ * callback from the pipeline sets it to "completed" or "failed".
+ *
+ * Intent documents are immutable — all fields are `readOnly: true`. The
+ * document is created once and only updated server-side by the webhook
+ * handler or pipeline callback.
+ */
+declare const evalRequestSchema: {
+    type: "document";
+    name: "ailf.evalRequest";
+} & Omit<sanity.DocumentDefinition, "preview"> & {
+    preview?: sanity.PreviewConfig<{
+        perspective: string;
+        status: string;
+        tasks: string;
+    }, Record<string, unknown>> | undefined;
+};
+
+/**
+ * schema/feature-area.ts
+ *
+ * Sanity document schema for `ailf.featureArea` — a feature area that groups
+ * related evaluation tasks for score aggregation and filtering.
+ *
+ * Feature areas are lightweight metadata documents. They exist primarily to
+ * provide referential integrity (tasks reference areas by document reference
+ * instead of plain strings) and to enable Studio-based browsing/filtering.
+ *
+ * Initial areas (migrated from YAML filenames): groq, frameworks, functions,
+ * nextjs-live, studio-setup, visual-editing.
+ *
+ * @see docs/design-docs/tasks-as-content.md
+ */
+declare const featureAreaSchema: {
+    type: "document";
+    name: "ailf.featureArea";
+} & Omit<sanity.DocumentDefinition, "preview"> & {
+    preview?: sanity.PreviewConfig<{
+        areaId: string;
+        description: string;
+    }, Record<string, unknown>> | undefined;
+};
+
+/**
+ * schema/reference-solution.ts
+ *
+ * Sanity document schema for `ailf.referenceSolution` — a gold-standard
+ * implementation that demonstrates the correct approach for a task.
+ *
+ * Reference solutions contain code blocks and prose explaining why the
+ * approach is correct. They are referenced by `ailf.task` documents.
+ *
+ * @see docs/design-docs/tasks-as-content.md
+ */
+declare const referenceSolutionSchema: {
+    type: "document";
+    name: "ailf.referenceSolution";
+} & Omit<sanity.DocumentDefinition, "preview"> & {
+    preview?: sanity.PreviewConfig<{
+        title: string;
+    }, Record<"title", any>> | undefined;
+};
+
+/**
+ * schema/report.ts
+ *
+ * Sanity document schema for `ailf.report` — the persisted evaluation report.
+ *
+ * This schema defines how reports appear in Sanity Studio and enables
+ * GROQ queries for the dashboard. The document shape mirrors the
+ * `Report` type in `packages/eval/src/pipeline/types.ts`.
+ *
+ * Reports are immutable events (P1) — once created, they should not be
+ * edited. The schema uses `readOnly: true` on all fields to enforce this.
+ *
+ * @see docs/design-docs/report-store/domain-model.md
+ * @see docs/design-docs/report-store/architecture.md
+ */
+declare const reportSchema: {
+    type: "document";
+    name: "ailf.report";
+} & Omit<sanity.DocumentDefinition, "preview"> & {
+    preview?: sanity.PreviewConfig<{
+        completedAt: string;
+        mode: string;
+        overall: string;
+        tag: string;
+    }, Record<string, unknown>> | undefined;
+};
+
+/**
+ * schema/task.ts
+ *
+ * Sanity document schema for `ailf.task` — an evaluation task definition.
+ *
+ * This is the core unit of the AI Literacy Framework. A task defines:
+ * - What the LLM should implement (the task prompt)
+ * - Which docs are relevant (canonical doc references)
+ * - How to grade the output (assertions with rubric templates)
+ * - A gold-standard implementation (reference solution)
+ * - When/how the task runs (execution controls)
+ *
+ * ## Execution paths
+ *
+ * Published tasks are automatically discovered by the pipeline — no
+ * registration step needed. There are four ways to execute a task:
+ *
+ * 1. **Run Task Eval** — click ▶ on any ailf.task document in Studio.
+ *    Creates an ailf.evalRequest scoped to this task. Webhook dispatches
+ *    the pipeline; score appears inline when complete (~10–15 min).
+ * 2. **Run AI Eval** — click on a content release page. Auto-scopes to
+ *    tasks whose canonical docs are in the release.
+ * 3. **CLI** — `ailf pipeline --task <id>` or `ailf pipeline --area <area>`.
+ * 4. **Scheduled** — GitHub Actions cron (daily baseline, weekly full).
+ *
+ * Tasks can be authored natively in Studio or mirrored from external
+ * repositories. Mirrored tasks have a read-only `origin` block that
+ * tracks their source repo provenance.
+ *
+ * @see docs/CONTRIBUTING_TASKS.md#running-your-task — full execution guide
+ * @see docs/design-docs/tasks-as-content.md
+ * @see docs/design-docs/tasks-as-content.md#decision-8-domain-specific-assertion-types-not-a-promptfoo-subset
+ */
+declare const taskSchema: {
+    type: "document";
+    name: "ailf.task";
+} & Omit<sanity.DocumentDefinition, "preview"> & {
+    preview?: sanity.PreviewConfig<{
+        area: string;
+        description: string;
+        id: string;
+        origin: string;
+        ownership: string;
+        status: string;
+    }, Record<string, unknown>> | undefined;
+};
+
+/**
+ * schema/webhook-config.ts
+ *
+ * Sanity document schema for `ailf.webhookConfig` — the "evaluate on publish"
+ * toggle and webhook-triggered evaluation settings.
+ *
+ * This is a singleton document (only one should exist) that controls
+ * whether content changes automatically trigger evaluation pipelines.
+ *
+ * @see docs/design-docs/report-store/visibility-workflows.md
+ */
+declare const webhookConfigSchema: {
+    type: "document";
+    name: "ailf.webhookConfig";
+} & Omit<sanity.DocumentDefinition, "preview"> & {
+    preview?: sanity.PreviewConfig<{
+        enabled: string;
+    }, Record<string, unknown>> | undefined;
+};
+
+/**
+ * tool.tsx
+ *
+ * Sanity Studio tool definition for the AILF dashboard.
+ *
+ * Registers as a top-level Studio tool accessible from the sidebar.
+ * Defines URL-based routing so each view is bookmarkable and
+ * supports browser back/forward navigation.
+ *
+ * Route structure:
+ *   /ailf                        → Latest Reports (home)
+ *   /ailf/report/:reportId       → Report Detail
+ *   /ailf/timeline               → Score Timeline
+ *   /ailf/compare                → Compare
+ */
+
+/**
+ * AILF Dashboard tool configuration.
+ *
+ * Add to your sanity.config.ts:
+ * ```ts
+ * import { ailfTool } from "@sanity/ailf-studio"
+ *
+ * export default defineConfig({
+ *   // ...
+ *   tools: [ailfTool()],
+ * })
+ * ```
+ */
+interface AilfToolOptions {
+    name?: string;
+    title?: string;
+}
+declare function ailfTool(options?: AilfToolOptions): Tool;
 
 /**
  * AILF Studio plugin — registers the report schema, dashboard tool,
@@ -855,4 +962,4 @@ interface TimelineDataPoint {
  */
 declare const ailfPlugin: sanity.Plugin<void>;
 
-export { AssertionInput, CanonicalDocInput, type ComparisonData, type ContentImpactItem, GLOSSARY, GraduateToNativeAction, MirrorBanner, type ProvenanceData, ReleasePicker, type ReportDetail, type ReportListItem, type RunEvaluationActionOptions, RunTaskEvaluationAction, type ScoreItem, type SummaryData, SyncStatusBadge, type TimelineDataPoint, ailfPlugin, ailfTool, articleSearchQuery, comparisonPairQuery, contentImpactQuery, createRunEvaluationAction, distinctAreasQuery, distinctModesQuery, distinctPerspectivesQuery, distinctSourcesQuery, distinctTargetDocumentsQuery, distinctTriggersQuery, evalRequestSchema, featureAreaSchema, latestReportsQuery, recentDocumentEvalsQuery, referenceSolutionSchema, reportDetailQuery, reportSchema, scoreTimelineQuery, taskSchema, webhookConfigSchema };
+export { AssertionInput, CanonicalDocInput, type ComparisonData, type ContentImpactItem, GLOSSARY, GraduateToNativeAction, HelpDrawer, HelpProvider, type HelpTopic, MirrorBanner, type ProvenanceData, ReleasePicker, type ReportDetail, type ReportListItem, type RunEvaluationActionOptions, RunTaskEvaluationAction, type ScoreItem, type SummaryData, SyncStatusBadge, type TimelineDataPoint, ailfPlugin, ailfTool, articleSearchQuery, comparisonPairQuery, contentImpactQuery, createRunEvaluationAction, deriveHelpTopic, distinctAreasQuery, distinctModesQuery, distinctPerspectivesQuery, distinctSourcesQuery, distinctTargetDocumentsQuery, distinctTriggersQuery, evalRequestSchema, featureAreaSchema, findTopic, latestReportsQuery, recentDocumentEvalsQuery, referenceSolutionSchema, reportDetailQuery, reportSchema, scoreTimelineQuery, searchTopics, taskSchema, useHelp, webhookConfigSchema };