Olivia/pmm 1025 add prompts ai copilot guidance what context to provide#3460
Closed
Olivia/pmm 1025 add prompts ai copilot guidance what context to provide#3460
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
Summary by CodeRabbit
WalkthroughThis PR adds a CopilotCallout MDX component and exposes it in the MDX renderer, introduces a copilot prompt preprocessor that injects referenced context files into MDX, rewrites the performant-dashboards guide to use Copilot-driven prompts with Phase 1–3 checkpoint documents, and adds an example dashboard-migration workspace (templates, example order-fulfillment code, and test-cases). Changes
Sequence Diagram(s)sequenceDiagram
participant Preprocessor as Preprocessor (server)
participant FS as FileSystem
participant MDX as MDX Compiler
participant Browser as Client Browser
participant User as User
Preprocessor->>FS: read MDX, find <CopilotCallout contentFile=...>
Preprocessor->>FS: load referenced content file (CONTENT_ROOT/...)
Preprocessor-->>Preprocessor: strip frontmatter, json-escape content
Preprocessor-->>MDX: inject rawContent prop into CopilotCallout tag
MDX->>Browser: deliver compiled page with <CopilotCallout />
User->>Browser: click "Copy Prompt" button
Browser->>Browser: build prompt from systemPrompt + rawContent
Browser->>Browser: navigator.clipboard.writeText(prompt)
Browser-->>User: show "Copied" state
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
Outdated
Show resolved
Hide resolved
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 13
🤖 Fix all issues with AI agents
In `@apps/framework-docs-v2/content/guides/performant-dashboards.mdx`:
- Line 1020: The systemPrompt string uses inconsistent
"precompute"/"pre-computes" wording; update the systemPrompt value to use a
single variant (recommend "precomputes") throughout so the prompt reads "...that
precomputes the joins and aggregations..." and ensure any other occurrences in
the same file or nearby prompt variables (e.g., systemPrompt) are changed to the
same variant for consistency.
- Line 1004: The include directives use the wrong format for the build-time
include processor; update each occurrence that looks like :::include /shared/...
to the expected processIncludes() format by replacing them with {{ include
"shared/relative/path.mdx" }} (e.g., {{ include
"shared/guides/performant-dashboards/phase-1-checkpoints.mdx" }}), ensuring all
instances referenced (the lines noted and any others) follow the {{ include
"..." }} pattern so processIncludes() can resolve them during the build.
In
`@apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx`:
- Around line 132-168: The TS code block for the example (the snippet containing
runParity, ParityInput, ParityRow and the SQL statement) is missing the `@test`
directive; update the opening code fence from ```ts to ```ts `@test` so the
TypeScript snippet (including function runParity and related interfaces) will be
validated by the docs test runner.
In
`@apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx`:
- Around line 15-49: Update the TypeScript code fences in the MDX docs to
include the `@test` directive so snippet validation runs: add `@test` to the first
sql/typescript block containing the existingQuery (variable `existingQuery`) and
to the TypeScript block that defines `OrderFulfillmentServing` (symbol
`OrderFulfillmentServing` and the OlapTable declaration), and also add `@test` to
the other TS blocks referenced (lines 79–115) — simply change the opening fences
from ```typescript or ```ts to ```typescript `@test` or ```ts `@test` respectively.
In
`@apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx`:
- Around line 15-49: The TypeScript code fences in
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx
are missing the `@test` directive so snippet validation will fail; update each TS
fenced block (including the block containing the orderFulfillmentModel and any
other TS blocks around lines mentioned) to use ```ts `@test` instead of ```ts,
ensuring snippets that define symbols like orderFulfillmentModel,
OrderFulfillmentServing, dimensions, metrics, filters, and sortable are all
annotated.
In `@apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx`:
- Around line 30-31: The component sets a timeout via timeoutRef and may call
setCopied(false) after unmount, so add a cleanup effect that clears timeoutRef
on unmount; create a useEffect with an empty dependency array that returns a
cleanup function which checks timeoutRef.current and calls
clearTimeout(timeoutRef.current) to avoid calling setCopied after the component
unmounts (refer to the copied state, setCopied setter and timeoutRef useRef).
In `@apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts`:
- Around line 76-78: The current replacement uses result.replace(fullTag, () =>
newTag) inside the Copilot callout processing, which only replaces the first
occurrence and breaks when identical <CopilotCallout ...> tags appear; change
the logic in the copilot prompt preprocessor to either use
result.replaceAll(fullTag, () => newTag) (or a global regex) or collect all
matches (using the existing fullTag, newTag, and the replacer function), then
apply replacements by iterating the collected match indices in reverse order so
earlier replacements don't shift later indexes; update the code paths that
compute fullTag, newTag, and call result.replace(...) accordingly.
- Around line 51-56: The current resolution of contentFilePath into fullPath can
allow path traversal (e.g., contentFile="../../etc/passwd"); change the logic
that computes fullPath (using contentFilePath, relativePath, path.join, and
CONTENT_ROOT) to resolve and normalize the absolute path (e.g., path.resolve)
and then verify it is inside CONTENT_ROOT (e.g., check
path.relative(CONTENT_ROOT, resolvedFullPath) does not start with '..' or that
resolvedFullPath startsWith CONTENT_ROOT + path.sep) and throw or reject the
input if the check fails before using fullPath.
In
`@examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts`:
- Around line 1-2: The import of the local model Orders currently comes directly
from "./source-orders"; update to use the directory barrel export by
re-exporting Orders from the directory's index.ts and change the import in
order-fulfillment-daily-mv.ts to import { Orders } from "." (or the directory
path) so local models follow the barrel-export rule and import grouping
conventions.
- Around line 10-29: Summary: The OlapTable OrderFulfillmentDaily needs
SummingMergeTree to avoid duplicate-key non-merged inserts. Update the OlapTable
call for OrderFulfillmentDaily to include an engine property using
ClickHouseEngines.SummingMergeTree (e.g.,
OlapTable<OrderFulfillmentDailyModel>("OrderFulfillmentDaily", { orderByFields:
["merchant_id", "day"], engine: ClickHouseEngines.SummingMergeTree })), so
incremental inserts with the same merchant_id+day merge correctly;
alternatively, if you cannot change the table engine, ensure all reads from
OrderFulfillmentDailyMV explicitly SUM() the metric columns (fulfilled, total)
to aggregate duplicates.
In `@examples/dashboard-migration/example-order-fulfillment/code/query-model.ts`:
- Around line 1-2: The import in query-model.ts should use the local barrel
export instead of importing OrderFulfillmentDaily directly from
"./order-fulfillment-daily-mv"; update the import to pull OrderFulfillmentDaily
from the module's index barrel (so the external import group remains unchanged
and internal module uses the barrel), keeping the defineQueryModel usage intact;
locate the import statement that references OrderFulfillmentDaily and switch it
to import { OrderFulfillmentDaily } from the local barrel (index) to match
repository conventions.
In `@examples/dashboard-migration/example-order-fulfillment/context-map.md`:
- Around line 26-27: The "## Test cases" heading is missing a blank line after
it which violates markdownlint MD022; insert a single blank line between the "##
Test cases" heading and the subsequent list item (the "-
`test-cases/01-last-30-days.md`" line) so the heading is separated from the
paragraph/list that follows.
- Around line 5-6: Add a blank line immediately before the "## Status legend"
heading to satisfy markdownlint rule MD022; locate the heading string "## Status
legend" in context-map.md and insert one empty line above it so the heading is
separated from the previous paragraph or content.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (19)
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/src/components/mdx-renderer.tsxapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxapps/framework-docs-v2/src/components/mdx/index.tsapps/framework-docs-v2/src/lib/content.tsapps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsexamples/dashboard-migration/README.mdexamples/dashboard-migration/_templates/context-map-template.mdexamples/dashboard-migration/component-context-pack-template.mdexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/context-map.mdexamples/dashboard-migration/example-order-fulfillment/test-cases/01-last-30-days.mdexamples/dashboard-migration/prompt.md
💤 Files with no reviewable changes (2)
- examples/dashboard-migration/prompt.md
- examples/dashboard-migration/component-context-pack-template.md
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Run linting checks before submitting PRs for TypeScript/JavaScript code
**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g.,_unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier usingexperimentalTernaries: true; auto-formats on commit via Husky + lint-staged
Files:
apps/framework-docs-v2/src/components/mdx/index.tsapps/framework-docs-v2/src/lib/content.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsapps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsapps/framework-docs-v2/src/components/mdx-renderer.tsxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.ts
apps/framework-docs-v2/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Component library must use shadcn/ui components located in
src/components/ui/
Files:
apps/framework-docs-v2/src/components/mdx/index.tsapps/framework-docs-v2/src/lib/content.tsapps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxapps/framework-docs-v2/src/components/mdx-renderer.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs
Files:
apps/framework-docs-v2/src/components/mdx/index.tsapps/framework-docs-v2/src/lib/content.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsapps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsapps/framework-docs-v2/src/components/mdx-renderer.tsxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.ts
apps/framework-docs-v2/content/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
apps/framework-docs-v2/content/**/*.mdx: Use{{ include "shared/path.mdx" }}directives to reuse content fragments, which are processed viaprocessIncludes()during build
Validate code snippets in documentation with the@testdirective for TypeScript and Python code blocks
TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
apps/framework-docs-v2/content/guides/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Guide MDX files in
content/guides/must include frontmatter with title and description fields
Files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
🧠 Learnings (19)
📓 Common learnings
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/web-app/src/features/dashboard/*.tsx : Dashboard components should follow React hooks patterns: use useState for local data, useEffect for data fetching, handle errors with fallback data, and wrap visualizations in Card/CardHeader/CardContent from Radix UI
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/**/*.mdx : Use `{{ include "shared/path.mdx" }}` directives to reuse content fragments, which are processed via `processIncludes()` during build
Applied to files:
apps/framework-docs-v2/src/lib/content.tsapps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsapps/framework-docs-v2/src/components/mdx-renderer.tsxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Validate `{{ include }}` directives in content before build using `pnpm run validate:includes` with `scripts/validate-includes.ts`
Applied to files:
apps/framework-docs-v2/src/lib/content.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layer
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2025-12-17T23:59:22.807Z
Learnt from: callicles
Repo: 514-labs/moosestack PR: 3143
File: apps/framework-docs/llm-docs/python/table-setup.md:331-336
Timestamp: 2025-12-17T23:59:22.807Z
Learning: In apps/framework-docs/llm-docs/**/*.md (LLM documentation), prefer exact class and type names (e.g., "MaterializedView", "OlapTable") over lowercase prose variants (e.g., "materialized view") to help LLMs generate correct code with proper imports and syntax.
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/views/*.ts : Use SummingMergeTree engine for materialized views that require incremental updates, and wrap aggregated metrics with SUM() when querying to properly merge partial rows
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Server actions serve as the primary bridge between frontend React components and backend moose query functions. The communication flow should always be: React Component → Hook → Server Action → Moose Query Function → eventsModel.toSql() → ClickHouse
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-28T14:50:00.978Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1402-1406
Timestamp: 2026-01-28T14:50:00.978Z
Learning: When reviewing WebApp implementations that run in a Node.js backend, prefer Node.js-specific types (e.g., Buffer) and avoid browser-focused cross-platform compatibility considerations. This guideline applies to MDX documentation and code examples across the repository where backend/runtime code is discussed; ensure reviewers distinguish server-side context from frontend/browser constraints and validate type usage accordingly.
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/moose/src/query-examples/model.ts : Query model definitions must include `dimensions` (for GROUP BY), `metrics` (for aggregates), `filters` (with allowed operators), and `sortable` (list of sortable fields)
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/query-model.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/ingest/models.ts : Data models in ingest/models.ts should define interfaces using the Model naming convention, and create corresponding IngestPipeline instances with table, stream, and ingestApi options enabled
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts
📚 Learning: 2026-01-08T18:32:03.114Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3170
File: apps/framework-docs-v2/src/components/copy-page-button.tsx:36-38
Timestamp: 2026-01-08T18:32:03.114Z
Learning: Enforce the following multiline ternary formatting for conditional JSX without parentheses: place the condition and the '?' on the first line, place the true branch on the next indented line, and place the ':' plus the false branch on the third line. This pattern is commonly used for copy/check icon toggles in the moosestack repository (apps/framework-docs-v2). Apply this style to all TSX files under apps/framework-docs-v2/src/**/*.tsx to ensure consistency and readability.
Applied to files:
apps/framework-docs-v2/src/components/mdx/copilot-callout.tsxapps/framework-docs-v2/src/components/mdx-renderer.tsx
📚 Learning: 2026-01-28T14:50:11.465Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1402-1406
Timestamp: 2026-01-28T14:50:11.465Z
Learning: Moose WebApp handlers are Node.js-only server-side code that runs in the backend runtime, never in browsers. When reviewing WebApp implementations, Node.js-specific types like `Buffer` are appropriate and don't need cross-platform browser compatibility considerations.
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/moose/src/query-examples/**/*.ts : Query example functions must use `eventsModel.toSql()` to generate SQL, ensuring consistent query construction through the defined model
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/query-model.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/components/dashboard/**/*.ts : Dashboard hooks must call server actions (not moose functions directly) to decouple React components from ClickHouse implementation details
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/app/actions.ts : Server actions must import query functions from the moose package and wrap them, serving as the bridge between frontend React components and backend moose query functions
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/components/report-builder/**/*.ts : Report builder components must use `prepareModel()` to transform backend model definitions for frontend consumption, configuring UI input types and options
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/**/*.ts : Use type inference helpers (`$inferRequest`, `$inferDimensions`, `$inferMetrics`) from query model definitions to ensure type-safe query parameter construction
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/query-model.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/web-app/src/features/dashboard/*.tsx : Dashboard components should follow React hooks patterns: use useState for local data, useEffect for data fetching, handle errors with fallback data, and wrap visualizations in Card/CardHeader/CardContent from Radix UI
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-28T14:55:13.411Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1585-1616
Timestamp: 2026-01-28T14:55:13.411Z
Learning: In documentation and tutorial files under apps/framework-docs-v2/content/guides/, prefer explicit, self-contained code examples that may duplicate small snippets for clarity over abstracting with DRY helpers. Ensure examples are easy to understand in isolation, even if it means a bit of repetition, to aid learning and reduce cognitive load for readers.
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
🧬 Code graph analysis (5)
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts (1)
apps/framework-docs-v2/src/lib/includes.ts (1)
CONTENT_ROOT(9-9)
apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx (1)
apps/framework-docs-v2/src/components/mdx/index.ts (1)
CopilotCallout(52-52)
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts (1)
examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts (1)
Orders(9-12)
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts (1)
examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts (1)
Orders(9-12)
examples/dashboard-migration/example-order-fulfillment/code/query-model.ts (1)
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts (1)
OrderFulfillmentDaily(10-15)
🪛 LanguageTool
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx
[style] ~115-~115: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...ry into ClickHouse SQL that returns the exact same response shape. Steps: 1. Create `moo...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
[style] ~121-~121: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...Write a function that: - accepts the exact same parameters as the existing handler/quer...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
[style] ~175-~175: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...: prove the parity function returns the exact same JSON as the OLTP endpoint for every tes...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
[uncategorized] ~1020-~1020: Do not mix variants of the same word (‘pre-compute’ and ‘precompute’) within a single text.
Context: ...erving table and Materialized View that pre-computes the joins and aggregations from the par...
(EN_WORD_COHERENCY)
🪛 markdownlint-cli2 (0.20.0)
examples/dashboard-migration/example-order-fulfillment/context-map.md
[warning] 5-5: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 26-26: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🔇 Additional comments (11)
examples/dashboard-migration/example-order-fulfillment/test-cases/01-last-30-days.md (1)
1-32: LGTM!Clear structure with replayable curl and expected response. Good use of environment variables for secrets.
Minor nit: filename says "last-30-days" but Jan 1–31 spans 31 days. Consider renaming to
01-jan-2024.mdor adjusting the date range if precision matters for test naming.examples/dashboard-migration/_templates/context-map-template.md (1)
1-36: LGTM!Clean, well-structured template. Clear phase separation with explicit input/output tracking.
apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx (1)
52-73: LGTM!Clean component structure. Correct use of shadcn/ui Alert and Button components per guidelines. Ternary formatting follows repository convention.
examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts (1)
1-12: LGTM!Clean OLAP table definition with proper typing.
EXTERNALLY_MANAGEDlifecycle andorderByFieldsare correctly configured.apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts (1)
28-28: LGTM on regex design.Negative lookbehind
(?<!\/)correctly excludes self-closing tags. Good use of[\s\S]*?for non-greedy multiline prop matching.apps/framework-docs-v2/src/lib/content.ts (2)
21-21: LGTM!Import properly grouped with other internal modules.
101-102: LGTM!Correct pipeline ordering:
processIncludesruns first (so included content with CopilotCallout tags is expanded), thenprocessCopilotPromptsinjects rawContent into all CopilotCallout tags.apps/framework-docs-v2/src/components/mdx/index.ts (1)
51-52: CopilotCallout export wiring looks good.apps/framework-docs-v2/src/components/mdx-renderer.tsx (1)
3-44: CopilotCallout is correctly surfaced to MDX.Also applies to: 181-183
examples/dashboard-migration/README.md (1)
1-32: Clearer workspace instructions and structure.examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts (1)
1-38: LGTM. Clear types, explicit return, and the query construction is straightforward.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
Outdated
Show resolved
Hide resolved
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx
Show resolved
Hide resolved
Comment on lines
15
to
49
| ```typescript | ||
| import { sql } from "@514labs/moose-lib"; | ||
|
|
||
| const existingQuery = sql` | ||
| SELECT | ||
| merchant_id, | ||
| merchant_name, | ||
| day, | ||
| total_orders, | ||
| fulfilled_orders, | ||
| fulfillment_rate | ||
| FROM OrderMetrics om | ||
| JOIN Merchants m ON m.id = om.merchant_id | ||
| WHERE om.merchant_id = ${merchantId} | ||
| GROUP BY om.merchant_id, m.merchant_name, toDate(om.created_at)` | ||
| ``` | ||
|
|
||
| Then your serving table should contain the columns from the existing query function, and `orderByFields` should match the grain (here, `["merchant_id", "day"]`). | ||
| ```ts | ||
| // File: moosestack/app/models/OrderFulfillmentServing-mv.ts | ||
|
|
||
| import { OlapTable, Int64 } from "@514labs/moose-lib"; | ||
|
|
||
| interface OrderFulfillmentServing { | ||
| merchant_id: string; | ||
| merchant_name: string; | ||
| day: Date; | ||
| total_orders: Int64; | ||
| fulfilled_orders: Int64; | ||
| fulfillment_rate: number; | ||
| } | ||
| export const OrderFulfillmentServing = new OlapTable<OrderFulfillmentServing>("OrderFulfillmentServing", { | ||
| orderByFields: ["merchant_id", "day"], | ||
| }); | ||
| ``` |
Contributor
There was a problem hiding this comment.
Add @test directives to TypeScript snippets.
These TS code fences won’t be validated without @test, which violates the doc snippet validation rule. Please add @test to each TS block.
🛠️ Suggested update
-```typescript
+```typescript `@test`
...
-```ts
+```ts `@test`As per coding guidelines, “Validate code snippets in documentation with the @test directive for TypeScript and Python code blocks”.
Also applies to: 79-115
🤖 Prompt for AI Agents
In
`@apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx`
around lines 15 - 49, Update the TypeScript code fences in the MDX docs to
include the `@test` directive so snippet validation runs: add `@test` to the first
sql/typescript block containing the existingQuery (variable `existingQuery`) and
to the TypeScript block that defines `OrderFulfillmentServing` (symbol
`OrderFulfillmentServing` and the OlapTable declaration), and also add `@test` to
the other TS blocks referenced (lines 79–115) — simply change the opening fences
from ```typescript or ```ts to ```typescript `@test` or ```ts `@test` respectively.
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx
Show resolved
Hide resolved
Comment on lines
1
to
2
| import { MaterializedView, OlapTable, sql } from "@514-labs/moose-lib"; | ||
| import { Orders } from "./source-orders"; |
Contributor
There was a problem hiding this comment.
Use barrel export for local model imports.
Import local models via the directory index.ts and re-export Orders there to align with the repo’s barrel-export rule.
🔧 Suggested change
-import { Orders } from "./source-orders";
+import { Orders } from "./index";As per coding guidelines: **/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts).
🤖 Prompt for AI Agents
In
`@examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts`
around lines 1 - 2, The import of the local model Orders currently comes
directly from "./source-orders"; update to use the directory barrel export by
re-exporting Orders from the directory's index.ts and change the import in
order-fulfillment-daily-mv.ts to import { Orders } from "." (or the directory
path) so local models follow the barrel-export rule and import grouping
conventions.
Comment on lines
10
to
29
| export const OrderFulfillmentDaily = OlapTable<OrderFulfillmentDailyModel>( | ||
| "OrderFulfillmentDaily", | ||
| { | ||
| orderByFields: ["merchant_id", "day"], | ||
| }, | ||
| ); | ||
| export const OrderFulfillmentDailyMV = | ||
| MaterializedView<OrderFulfillmentDailyModel>({ | ||
| targetTable: OrderFulfillmentDaily, | ||
| materializedViewName: "OrderFulfillmentDailyMV", | ||
| selectTables: [Orders], | ||
| selectStatement: sql` | ||
| SELECT | ||
| merchant_id, | ||
| toDate(order_ts) AS day, | ||
| sumIf(1, status = 'fulfilled') AS fulfilled, | ||
| count() AS total | ||
| FROM ${Orders} | ||
| GROUP BY merchant_id, day | ||
| `, |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, find the OlapTable definition and type signature
fd -t f "\.ts$" --path "*OlapTable*" | head -20Repository: 514-labs/moosestack
Length of output: 296
🏁 Script executed:
# Search for OlapTable usage and definitions
rg "OlapTable" -A 5 --max-count 20 | head -100Repository: 514-labs/moosestack
Length of output: 6830
🏁 Script executed:
# Look for SummingMergeTree or AggregatingMergeTree usage
rg "SummingMergeTree|AggregatingMergeTree" --type tsRepository: 514-labs/moosestack
Length of output: 9147
🏁 Script executed:
# Check the actual file mentioned in the review
cat -n examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsRepository: 514-labs/moosestack
Length of output: 1090
🏁 Script executed:
# Look for examples of OlapTable with engine configuration
rg "engine\s*:" --type ts -B 3 -A 3 | head -50Repository: 514-labs/moosestack
Length of output: 3772
Use SummingMergeTree for incremental aggregates.
OrderFulfillmentDaily groups by merchant_id, day and stores aggregated metrics (fulfilled, total). Without SummingMergeTree, multiple insert batches create duplicate keys that won't auto-merge. Add engine: ClickHouseEngines.SummingMergeTree to the OlapTable config, or ensure downstream reads always wrap metrics with SUM().
🤖 Prompt for AI Agents
In
`@examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts`
around lines 10 - 29, Summary: The OlapTable OrderFulfillmentDaily needs
SummingMergeTree to avoid duplicate-key non-merged inserts. Update the OlapTable
call for OrderFulfillmentDaily to include an engine property using
ClickHouseEngines.SummingMergeTree (e.g.,
OlapTable<OrderFulfillmentDailyModel>("OrderFulfillmentDaily", { orderByFields:
["merchant_id", "day"], engine: ClickHouseEngines.SummingMergeTree })), so
incremental inserts with the same merchant_id+day merge correctly;
alternatively, if you cannot change the table engine, ensure all reads from
OrderFulfillmentDailyMV explicitly SUM() the metric columns (fulfilled, total)
to aggregate duplicates.
examples/dashboard-migration/example-order-fulfillment/code/query-model.ts
Outdated
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Fix all issues with AI agents
In `@apps/framework-docs-v2/content/guides/performant-dashboards.mdx`:
- Line 1004: Replace the raw :::include directive with the repository's include
syntax so processIncludes() can resolve it during build: change occurrences like
:::include /shared/guides/performant-dashboards/phase-1-checkpoints.mdx to the
repo-approved {{ include
"shared/guides/performant-dashboards/phase-1-checkpoints.mdx" }} pattern in the
file (apps/framework-docs-v2/content/guides/performant-dashboards.mdx) and
similarly update the other occurrences noted (lines around 1031 and 1058) so
processIncludes() can process them correctly.
- Around line 1017-1021: The CopilotCallout's systemPrompt uses "pre-computes"
while earlier text uses "precomputed" causing inconsistent word form; update the
systemPrompt in the CopilotCallout component (the systemPrompt prop) to use
"precomputes" (or change earlier occurrences to "pre-compute"/"pre-computes" if
you prefer that form) so wording is consistent across the document, and make
sure any other instances in this file (search for "precomputed", "pre-computes",
"precompute") are normalized to the chosen form.
In
`@apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx`:
- Around line 132-169: The TypeScript snippet containing the runParity function
needs the documentation test directive added so it will be validated; update the
code fence for the TS block that wraps the runParity / ParityInput / ParityRow
code to start with ```ts `@test` instead of ```ts, ensuring the block around the
MooseClient/sql example (the runParity function and its interfaces) is
recognized by the docs test runner.
In
`@apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx`:
- Around line 15-115: The three TypeScript code fences in this MDX (the snippet
starting with "import { sql } from \"@514labs/moose-lib\";", the OlapTable
definition with "export const OrderFulfillmentServing = new
OlapTable<OrderFulfillmentServing>(\"OrderFulfillmentServing\"", and the example
file snippet that imports Int64/MaterializedView and defines OrderFulfillmentMV)
are missing the required `@test` directive; update each opening fence to include
`@test` (e.g., ```typescript `@test` or ```ts `@test`) so the documentation test
harness can run those blocks.
In
`@apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx`:
- Around line 15-110: The three TypeScript code fences in the MDX file for the
examples (the orderFulfillment model snippet in
moosestack/app/query-models/orderFulfillment.model.ts, the getOrderFulfillment
API snippet in moosestack/app/apis/orderFulfillment.api.ts, and the integration
example showing the route using getOrderFulfillment) are missing the required
`@test` directive; update each opening ```ts fence to ```ts `@test` so the
TypeScript snippets (including the orderFulfillmentModel definition, the
getOrderFulfillment function, and the integration route example that imports
getOrderFulfillment) will be validated by the docs test runner.
In `@apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx`:
- Around line 3-7: Replace the direct component imports with named imports from
the UI barrel: import Button, Alert, AlertTitle, and AlertDescription from the
UI barrel index instead of "@/components/ui/button" and "@/components/ui/alert";
if those symbols are not exported from the barrel, add them to the UI barrel
(index.ts) so they are re-exported, then update the import line in
copilot-callout.tsx to use the barrel export for all four components to comply
with the project grouping/export guideline.
- Around line 30-47: The timeout handling in handleCopy uses NodeJS.Timeout
typing and doesn't clear the pending timer on unmount; change timeoutRef to
browser-safe typing and add an effect cleanup: update timeoutRef to
useRef<number | null>(null) (or ReturnType<typeof window.setTimeout>), assign
timers with window.setTimeout(...), clear timers with
window.clearTimeout(timeoutRef.current as number) (or clearTimeout) and add a
useEffect that returns a cleanup function which clears timeoutRef.current and
sets it to null; update places referencing timeoutRef.current to handle null
safely.
- Around line 23-29: The exported React component CopilotCallout is missing an
explicit return type; update its signature to declare the return type as
React.JSX.Element (e.g., change the function declaration for CopilotCallout to
include : React.JSX.Element) so the public API has an explicit JSX return type;
ensure the import/tsconfig supports React.JSX.Element if needed and run
typecheck to confirm.
In `@apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts`:
- Around line 74-75: The current rebuild of the opening tag always injects
rawContentProp which can duplicate an existing rawContent prop and cause
conflicts; update the logic that constructs newTag so it first detects and
removes any existing rawContent attribute from propsString (or skips adding
rawContentProp when one already exists) before composing `<CopilotCallout
${rawContentProp} ${propsString.trim()}>`, ensuring only a single rawContent
prop is present (refer to newTag, rawContentProp and propsString).
In `@examples/dashboard-migration/_templates/context-map-template.md`:
- Around line 5-27: The markdown headings "## Status legend" and "## Test cases"
are missing a blank line after them causing MD022 lint failures; add a single
blank line immediately after each of those headings (the "## Status legend"
heading at the top of the template and the "## Test cases" heading near the end)
so there is an empty line between the heading and the following
content/table/text to satisfy markdownlint MD022.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (19)
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/src/components/mdx-renderer.tsxapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxapps/framework-docs-v2/src/components/mdx/index.tsapps/framework-docs-v2/src/lib/content.tsapps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsexamples/dashboard-migration/README.mdexamples/dashboard-migration/_templates/context-map-template.mdexamples/dashboard-migration/component-context-pack-template.mdexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/context-map.mdexamples/dashboard-migration/example-order-fulfillment/test-cases/01-last-30-days.mdexamples/dashboard-migration/prompt.md
💤 Files with no reviewable changes (2)
- examples/dashboard-migration/prompt.md
- examples/dashboard-migration/component-context-pack-template.md
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Run linting checks before submitting PRs for TypeScript/JavaScript code
**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g.,_unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier usingexperimentalTernaries: true; auto-formats on commit via Husky + lint-staged
Files:
apps/framework-docs-v2/src/components/mdx/index.tsapps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsapps/framework-docs-v2/src/lib/content.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxapps/framework-docs-v2/src/components/mdx-renderer.tsxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
apps/framework-docs-v2/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Component library must use shadcn/ui components located in
src/components/ui/
Files:
apps/framework-docs-v2/src/components/mdx/index.tsapps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsapps/framework-docs-v2/src/lib/content.tsapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxapps/framework-docs-v2/src/components/mdx-renderer.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs
Files:
apps/framework-docs-v2/src/components/mdx/index.tsapps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsapps/framework-docs-v2/src/lib/content.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxapps/framework-docs-v2/src/components/mdx-renderer.tsxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
apps/framework-docs-v2/content/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
apps/framework-docs-v2/content/**/*.mdx: Use{{ include "shared/path.mdx" }}directives to reuse content fragments, which are processed viaprocessIncludes()during build
Validate code snippets in documentation with the@testdirective for TypeScript and Python code blocks
TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
apps/framework-docs-v2/content/guides/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Guide MDX files in
content/guides/must include frontmatter with title and description fields
Files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
🧠 Learnings (19)
📓 Common learnings
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Guide promotion workflow: start guides with `status: "draft"` in navigation config, then progress to `status: "beta"`, finally remove status field for public release
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/**/*.mdx : Use `{{ include "shared/path.mdx" }}` directives to reuse content fragments, which are processed via `processIncludes()` during build
Applied to files:
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsapps/framework-docs-v2/src/lib/content.tsapps/framework-docs-v2/src/components/mdx-renderer.tsx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/moose/src/query-examples/model.ts : Query model definitions must include `dimensions` (for GROUP BY), `metrics` (for aggregates), `filters` (with allowed operators), and `sortable` (list of sortable fields)
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/ingest/models.ts : Data models in ingest/models.ts should define interfaces using the Model naming convention, and create corresponding IngestPipeline instances with table, stream, and ingestApi options enabled
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Validate `{{ include }}` directives in content before build using `pnpm run validate:includes` with `scripts/validate-includes.ts`
Applied to files:
apps/framework-docs-v2/src/lib/content.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layer
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/moose/src/query-examples/**/*.ts : Query example functions must use `eventsModel.toSql()` to generate SQL, ensuring consistent query construction through the defined model
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/**/*.ts : Use type inference helpers (`$inferRequest`, `$inferDimensions`, `$inferMetrics`) from query model definitions to ensure type-safe query parameter construction
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/views/*.ts : Use SummingMergeTree engine for materialized views that require incremental updates, and wrap aggregated metrics with SUM() when querying to properly merge partial rows
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/components/dashboard/**/*.ts : Dashboard hooks must call server actions (not moose functions directly) to decouple React components from ClickHouse implementation details
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2025-12-17T23:59:22.807Z
Learnt from: callicles
Repo: 514-labs/moosestack PR: 3143
File: apps/framework-docs/llm-docs/python/table-setup.md:331-336
Timestamp: 2025-12-17T23:59:22.807Z
Learning: In apps/framework-docs/llm-docs/**/*.md (LLM documentation), prefer exact class and type names (e.g., "MaterializedView", "OlapTable") over lowercase prose variants (e.g., "materialized view") to help LLMs generate correct code with proper imports and syntax.
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Server actions serve as the primary bridge between frontend React components and backend moose query functions. The communication flow should always be: React Component → Hook → Server Action → Moose Query Function → eventsModel.toSql() → ClickHouse
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-28T14:50:00.978Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1402-1406
Timestamp: 2026-01-28T14:50:00.978Z
Learning: When reviewing WebApp implementations that run in a Node.js backend, prefer Node.js-specific types (e.g., Buffer) and avoid browser-focused cross-platform compatibility considerations. This guideline applies to MDX documentation and code examples across the repository where backend/runtime code is discussed; ensure reviewers distinguish server-side context from frontend/browser constraints and validate type usage accordingly.
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/components/report-builder/**/*.ts : Report builder components must use `prepareModel()` to transform backend model definitions for frontend consumption, configuring UI input types and options
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/app/actions.ts : Server actions must import query functions from the moose package and wrap them, serving as the bridge between frontend React components and backend moose query functions
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts
📚 Learning: 2026-01-08T18:32:03.114Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3170
File: apps/framework-docs-v2/src/components/copy-page-button.tsx:36-38
Timestamp: 2026-01-08T18:32:03.114Z
Learning: Enforce the following multiline ternary formatting for conditional JSX without parentheses: place the condition and the '?' on the first line, place the true branch on the next indented line, and place the ':' plus the false branch on the third line. This pattern is commonly used for copy/check icon toggles in the moosestack repository (apps/framework-docs-v2). Apply this style to all TSX files under apps/framework-docs-v2/src/**/*.tsx to ensure consistency and readability.
Applied to files:
apps/framework-docs-v2/src/components/mdx/copilot-callout.tsxapps/framework-docs-v2/src/components/mdx-renderer.tsx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/services/analyticsService.ts : Service functions in analyticsService.ts should execute queries using executeQuery helper, transform raw results, and return typed data structures defined in types/analytics.ts
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/web-app/src/features/dashboard/*.tsx : Dashboard components should follow React hooks patterns: use useState for local data, useEffect for data fetching, handle errors with fallback data, and wrap visualizations in Card/CardHeader/CardContent from Radix UI
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-28T14:55:13.411Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1585-1616
Timestamp: 2026-01-28T14:55:13.411Z
Learning: In documentation and tutorial files under apps/framework-docs-v2/content/guides/, prefer explicit, self-contained code examples that may duplicate small snippets for clarity over abstracting with DRY helpers. Ensure examples are easy to understand in isolation, even if it means a bit of repetition, to aid learning and reduce cognitive load for readers.
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
🧬 Code graph analysis (6)
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts (1)
apps/framework-docs-v2/src/lib/includes.ts (1)
CONTENT_ROOT(9-9)
apps/framework-docs-v2/src/lib/content.ts (2)
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts (1)
processCopilotPrompts(35-88)apps/framework-docs-v2/src/lib/includes.ts (1)
processIncludes(37-138)
examples/dashboard-migration/example-order-fulfillment/code/query-model.ts (1)
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts (1)
OrderFulfillmentDaily(10-15)
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts (1)
examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts (1)
Orders(9-12)
apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx (1)
apps/framework-docs-v2/src/components/mdx/index.ts (1)
CopilotCallout(52-52)
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts (1)
examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts (1)
Orders(9-12)
🪛 LanguageTool
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx
[style] ~115-~115: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...ry into ClickHouse SQL that returns the exact same response shape. Steps: 1. Create `moo...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
[style] ~121-~121: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...Write a function that: - accepts the exact same parameters as the existing handler/quer...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
[style] ~175-~175: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...: prove the parity function returns the exact same JSON as the OLTP endpoint for every tes...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
[uncategorized] ~1020-~1020: Do not mix variants of the same word (‘pre-compute’ and ‘precompute’) within a single text.
Context: ...erving table and Materialized View that pre-computes the joins and aggregations from the par...
(EN_WORD_COHERENCY)
🪛 markdownlint-cli2 (0.20.0)
examples/dashboard-migration/_templates/context-map-template.md
[warning] 5-5: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 26-26: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🔇 Additional comments (23)
apps/framework-docs-v2/content/guides/performant-dashboards.mdx (7)
8-20: LGTM: FileTree import addition.
942-946: Clear, concise phase framing.
948-957: Context-pack step is crisp and actionable.
962-1002: Phase 1 prompt is well-scaffolded.
1008-1015: Phase 2 setup text reads well.
1039-1043: Query Layer copy step is concise.
1045-1056: Phase 3 prompt is clear and scoped.examples/dashboard-migration/example-order-fulfillment/code/query-model.ts (1)
1-10: LGTM!Query model correctly defines all required components: dimensions, metrics, filters, and sortable fields. Structure aligns with Moose query layer patterns. Based on learnings: "Query model definitions must include
dimensions(for GROUP BY),metrics(for aggregates),filters(with allowed operators), andsortable(list of sortable fields)".examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts (1)
1-12: LGTM!Clean source table definition.
LifeCycle.EXTERNALLY_MANAGEDcorrectly indicates this is an existing table managed outside Moose.orderByFieldsalign with expected query patterns.apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts (1)
35-88: LGTM overall.Solid preprocessing logic. Graceful error handling with warnings. Correct use of replacer function to prevent
$&interpretation.apps/framework-docs-v2/src/lib/content.ts (2)
21-21: LGTM!Import correctly placed with internal modules.
101-102: LGTM!Correct processing order: includes expanded first, then CopilotCallout tags processed. This ensures callouts in included content are also handled.
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts (2)
10-14: Verifydaytype matches query result.The interface defines
day: string, but the SQL query returnstoDate(order_ts)which is a Date type. The actual type depends on how moose-lib serializes query results (often as ISO string). Confirm this matches runtime behavior.
20-38: LGTM!Clean OLAP translation function. SQL uses proper ClickHouse aggregation functions. Half-open date range interval (
>= start,< end) is correct practice.examples/dashboard-migration/README.md (2)
1-32: Documentation is clear and actionable.Concise workflow with specific file paths. Good simplification from previous component-by-component approach.
15-17: Verify tiged source repository path.The command pulls from
514-labs/moose/examples/dashboard-migration-context, but this cannot be verified within the moosestack repository. Confirm that this directory exists in the moose repository or update the path if incorrect.examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts (2)
1-30: LGTM overall.MV correctly references Orders source, aggregates by merchant and day. SQL is consistent with the translation handler.
10-15: 🧹 Nitpick | 🔵 TrivialConsider specifying table engine for incremental updates.
If this MV needs incremental aggregation,
SummingMergeTreeengine should be specified. Current config uses default engine.Based on learnings: "Use SummingMergeTree engine for materialized views that require incremental updates, and wrap aggregated metrics with SUM() when querying to properly merge partial rows."
⛔ Skipped due to learnings
Learnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/cdp-analytics/CLAUDE.md:0-0 Timestamp: 2026-01-15T19:41:53.563Z Learning: Applies to examples/cdp-analytics/app/views/*.ts : Use SummingMergeTree engine for materialized views that require incremental updates, and wrap aggregated metrics with SUM() when querying to properly merge partial rowsLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/nextjs-moose/CLAUDE.md:0-0 Timestamp: 2026-01-27T17:36:29.854Z Learning: Applies to examples/nextjs-moose/moose/src/query-examples/model.ts : Query model definitions must include `dimensions` (for GROUP BY), `metrics` (for aggregates), `filters` (with allowed operators), and `sortable` (list of sortable fields)Learnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/nextjs-moose/CLAUDE.md:0-0 Timestamp: 2026-01-27T17:36:29.854Z Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layerLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/nextjs-moose/CLAUDE.md:0-0 Timestamp: 2026-01-27T17:36:29.854Z Learning: Applies to examples/nextjs-moose/moose/src/query-examples/**/*.ts : Query example functions must use `eventsModel.toSql()` to generate SQL, ensuring consistent query construction through the defined modelLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/cdp-analytics/CLAUDE.md:0-0 Timestamp: 2026-01-15T19:41:53.563Z Learning: For slow dashboard queries (>500ms) that aggregate across multiple tables or need cohort-based breakdowns, implement a materialized view instead of real-time queriesexamples/dashboard-migration/example-order-fulfillment/context-map.md (1)
1-27: Clear and usable context map.
Tables and notes are consistent with the phase workflow.apps/framework-docs-v2/src/components/mdx/index.ts (1)
51-52: CopilotCallout export looks good.
Exposed via the MDX barrel as expected.apps/framework-docs-v2/src/components/mdx-renderer.tsx (1)
41-183: CopilotCallout is correctly registered in the MDX map.examples/dashboard-migration/example-order-fulfillment/test-cases/01-last-30-days.md (1)
1-32: Well-structured test case.
Request and expected response are easy to replay.apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx (1)
1-7: Confirm lint checks were run for TSX changes.Please verify the project’s lint script was executed for this TS/JS change set.
As per coding guidelines, "**/*.{ts,tsx,js,jsx}: Run linting checks before submitting PRs for TypeScript/JavaScript code".
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx
Show resolved
Hide resolved
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
Outdated
Show resolved
Hide resolved
Comment on lines
+15
to
+110
| ```ts | ||
| // File: moosestack/app/query-models/orderFulfillment.model.ts | ||
|
|
||
| import { sql } from "@514labs/moose-lib"; | ||
| import { defineQueryModel } from "../query-layer"; | ||
| import { OrderFulfillmentServing } from "../models/OrderFulfillmentServing.model"; | ||
|
|
||
| export const orderFulfillmentModel = defineQueryModel({ | ||
| table: OrderFulfillmentServing, | ||
|
|
||
| // Dimensions: fields users can group by | ||
| dimensions: { | ||
| merchantName: { column: "merchant_name" }, | ||
| day: { column: "day" }, | ||
| }, | ||
|
|
||
| // Metrics: aggregations users can request | ||
| metrics: { | ||
| totalOrders: { agg: sql`sum(total_orders)` }, | ||
| fulfilledOrders: { agg: sql`sum(fulfilled_orders)` }, | ||
| fulfillmentRate: { | ||
| agg: sql`round(100 * sum(fulfilled_orders) / nullIf(sum(total_orders), 0), 2)` | ||
| }, | ||
| }, | ||
|
|
||
| // Filters: fields users can filter on | ||
| filters: { | ||
| merchantId: { column: "merchant_id", operators: ["eq", "in"] as const }, | ||
| day: { column: "day", operators: ["gte", "lte"] as const }, | ||
| }, | ||
|
|
||
| // Sortable: fields users can sort by | ||
| sortable: ["merchantName", "day", "totalOrders", "fulfillmentRate"] as const, | ||
| }); | ||
| ``` | ||
|
|
||
| ##### Checkpoint 2 — Wire the handler | ||
|
|
||
| Goal: rewire your existing query handler function to call the QueryModel and map results back to the exact response shape. | ||
|
|
||
| Steps: | ||
|
|
||
| 1. Build a QueryModel request from your endpoint inputs (filters, sort, pagination). | ||
| 2. Execute the QueryModel against ClickHouse using the `query` method. | ||
| 3. Map the QueryModel results back to the exact response shape the endpoint already produces. | ||
|
|
||
| ```ts | ||
| // File: moosestack/app/apis/orderFulfillment.api.ts | ||
|
|
||
| import { getMooseUtils } from "@514labs/moose-lib"; | ||
| import { orderFulfillmentModel } from "../query-models/orderFulfillment.model"; | ||
|
|
||
| interface OrderFulfillmentRequest { | ||
| merchantId?: string; | ||
| startDate?: string; | ||
| endDate?: string; | ||
| limit?: number; | ||
| offset?: number; | ||
| orderBy?: "merchantName" | "day" | "totalOrders" | "fulfillmentRate"; | ||
| } | ||
|
|
||
| export async function getOrderFulfillment( | ||
| request: OrderFulfillmentRequest, | ||
| ) { | ||
| const { client } = await getMooseUtils(); | ||
|
|
||
| return await orderFulfillmentModel.query( | ||
| { | ||
| dimensions: ["merchantName", "day"], | ||
| metrics: ["totalOrders", "fulfilledOrders", "fulfillmentRate"], | ||
| filters: { | ||
| ...(request.merchantId && { merchantId: { eq: request.merchantId } }), | ||
| ...(request.startDate && { day: { gte: request.startDate } }), | ||
| ...(request.endDate && { day: { lte: request.endDate } }), | ||
| }, | ||
| sortBy: request.orderBy ?? "merchantName", | ||
| sortDir: "ASC", | ||
| limit: request.limit ?? 100, | ||
| offset: request.offset ?? 0, | ||
| }, | ||
| client.query, | ||
| ); | ||
| } | ||
| ``` | ||
|
|
||
| **Integration point:** In your existing backend handler (Express, Fastify, Next.js, etc.), replace the OLTP query call with a call to this new function and return the result: | ||
|
|
||
| ```ts | ||
| // In your existing backend handler (e.g. Express route) | ||
| import { getOrderFulfillment } from "moosestack/app/apis/orderFulfillment.api"; | ||
|
|
||
| app.post("/api/order-fulfillment", async (req, res) => { | ||
| const result = await getOrderFulfillment(req.body); | ||
| res.json(result); // Same response shape as before | ||
| }); | ||
| ``` |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check if the file exists and view the relevant lines
wc -l apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxRepository: 514-labs/moosestack
Length of output: 157
🏁 Script executed:
# Show lines 15-110 to see the actual code fences
sed -n '15,110p' apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx | head -50Repository: 514-labs/moosestack
Length of output: 1693
🏁 Script executed:
# Run the suggested rg command to find TS fences without `@test`
rg -nP '```(?:ts|typescript)(?!.*@test)' apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxRepository: 514-labs/moosestack
Length of output: 92
Add @test directives to all three TypeScript code fences.
Lines 15, 61, and 102 contain untagged ts blocks. Per documentation guidelines, TypeScript snippets must include the @test directive for validation.
✏️ Apply to each TS fence
-```ts
+```ts `@test`🤖 Prompt for AI Agents
In
`@apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx`
around lines 15 - 110, The three TypeScript code fences in the MDX file for the
examples (the orderFulfillment model snippet in
moosestack/app/query-models/orderFulfillment.model.ts, the getOrderFulfillment
API snippet in moosestack/app/apis/orderFulfillment.api.ts, and the integration
example showing the route using getOrderFulfillment) are missing the required
`@test` directive; update each opening ```ts fence to ```ts `@test` so the
TypeScript snippets (including the orderFulfillmentModel definition, the
getOrderFulfillment function, and the integration route example that imports
getOrderFulfillment) will be validated by the docs test runner.
Comment on lines
+23
to
+29
| export function CopilotCallout({ | ||
| systemPrompt, | ||
| rawContent = "", | ||
| title = "AI Copilot", | ||
| buttonLabel = "Copy Prompt", | ||
| children, | ||
| }: CopilotCalloutProps) { |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n apps/framework-docs-v2/src/components/mdx/copilot-callout.tsxRepository: 514-labs/moosestack
Length of output: 2851
Add explicit return type to the exported component.
Public APIs require explicit return types. This component returns JSX and should declare React.JSX.Element as its return type.
Suggested update
-export function CopilotCallout({
+export function CopilotCallout({
systemPrompt,
rawContent = "",
title = "AI Copilot",
buttonLabel = "Copy Prompt",
children,
-}: CopilotCalloutProps) {
+}: CopilotCalloutProps): React.JSX.Element {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| export function CopilotCallout({ | |
| systemPrompt, | |
| rawContent = "", | |
| title = "AI Copilot", | |
| buttonLabel = "Copy Prompt", | |
| children, | |
| }: CopilotCalloutProps) { | |
| export function CopilotCallout({ | |
| systemPrompt, | |
| rawContent = "", | |
| title = "AI Copilot", | |
| buttonLabel = "Copy Prompt", | |
| children, | |
| }: CopilotCalloutProps): React.JSX.Element { |
🤖 Prompt for AI Agents
In `@apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx` around lines
23 - 29, The exported React component CopilotCallout is missing an explicit
return type; update its signature to declare the return type as
React.JSX.Element (e.g., change the function declaration for CopilotCallout to
include : React.JSX.Element) so the public API has an explicit JSX return type;
ensure the import/tsconfig supports React.JSX.Element if needed and run
typecheck to confirm.
Comment on lines
+30
to
+47
| const [copied, setCopied] = useState(false); | ||
| const timeoutRef = useRef<NodeJS.Timeout | null>(null); | ||
|
|
||
| const handleCopy = async () => { | ||
| if (typeof window === "undefined" || !navigator.clipboard?.writeText) { | ||
| return; | ||
| } | ||
|
|
||
| try { | ||
| const cleaned = cleanContent(rawContent); | ||
| const prompt = `${systemPrompt.trim()}\n\n---\n\n${cleaned}`; | ||
| await navigator.clipboard.writeText(prompt); | ||
| setCopied(true); | ||
| if (timeoutRef.current) { | ||
| clearTimeout(timeoutRef.current); | ||
| } | ||
| timeoutRef.current = setTimeout(() => setCopied(false), 2000); | ||
| } catch (error) { |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Harden timeout lifecycle and typing in the client component.
Avoid stale timeouts on unmount and use browser-safe timeout typing.
Suggested update
-import { useState, useRef } from "react";
+import { useEffect, useRef, useState } from "react";
@@
- const timeoutRef = useRef<NodeJS.Timeout | null>(null);
+ const timeoutRef = useRef<ReturnType<typeof setTimeout> | null>(null);
+
+ useEffect(() => {
+ return () => {
+ if (timeoutRef.current) {
+ clearTimeout(timeoutRef.current);
+ }
+ };
+ }, []);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const [copied, setCopied] = useState(false); | |
| const timeoutRef = useRef<NodeJS.Timeout | null>(null); | |
| const handleCopy = async () => { | |
| if (typeof window === "undefined" || !navigator.clipboard?.writeText) { | |
| return; | |
| } | |
| try { | |
| const cleaned = cleanContent(rawContent); | |
| const prompt = `${systemPrompt.trim()}\n\n---\n\n${cleaned}`; | |
| await navigator.clipboard.writeText(prompt); | |
| setCopied(true); | |
| if (timeoutRef.current) { | |
| clearTimeout(timeoutRef.current); | |
| } | |
| timeoutRef.current = setTimeout(() => setCopied(false), 2000); | |
| } catch (error) { | |
| const [copied, setCopied] = useState(false); | |
| const timeoutRef = useRef<ReturnType<typeof setTimeout> | null>(null); | |
| useEffect(() => { | |
| return () => { | |
| if (timeoutRef.current) { | |
| clearTimeout(timeoutRef.current); | |
| } | |
| }; | |
| }, []); | |
| const handleCopy = async () => { | |
| if (typeof window === "undefined" || !navigator.clipboard?.writeText) { | |
| return; | |
| } | |
| try { | |
| const cleaned = cleanContent(rawContent); | |
| const prompt = `${systemPrompt.trim()}\n\n---\n\n${cleaned}`; | |
| await navigator.clipboard.writeText(prompt); | |
| setCopied(true); | |
| if (timeoutRef.current) { | |
| clearTimeout(timeoutRef.current); | |
| } | |
| timeoutRef.current = setTimeout(() => setCopied(false), 2000); | |
| } catch (error) { |
🤖 Prompt for AI Agents
In `@apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx` around lines
30 - 47, The timeout handling in handleCopy uses NodeJS.Timeout typing and
doesn't clear the pending timer on unmount; change timeoutRef to browser-safe
typing and add an effect cleanup: update timeoutRef to useRef<number |
null>(null) (or ReturnType<typeof window.setTimeout>), assign timers with
window.setTimeout(...), clear timers with window.clearTimeout(timeoutRef.current
as number) (or clearTimeout) and add a useEffect that returns a cleanup function
which clears timeoutRef.current and sets it to null; update places referencing
timeoutRef.current to handle null safely.
Comment on lines
+74
to
+75
| // Rebuild the opening tag with rawContent injected | ||
| const newTag = `<CopilotCallout ${rawContentProp} ${propsString.trim()}>`; |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider handling pre-existing rawContent prop.
If a tag already contains rawContent, the new tag will have duplicate props. This could cause unexpected behavior.
Proposed fix
// Build the rawContent prop value as a JSON-escaped JS string literal
const rawContentProp = `rawContent={${JSON.stringify(fileContent.trim())}}`;
+ // Strip any existing rawContent prop to avoid duplicates
+ const cleanedPropsString = propsString.replace(/rawContent=\{[^}]*\}\s*/g, '').trim();
+
// Rebuild the opening tag with rawContent injected
- const newTag = `<CopilotCallout ${rawContentProp} ${propsString.trim()}>`;
+ const newTag = `<CopilotCallout ${rawContentProp} ${cleanedPropsString}>`;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| // Rebuild the opening tag with rawContent injected | |
| const newTag = `<CopilotCallout ${rawContentProp} ${propsString.trim()}>`; | |
| // Build the rawContent prop value as a JSON-escaped JS string literal | |
| const rawContentProp = `rawContent={${JSON.stringify(fileContent.trim())}}`; | |
| // Strip any existing rawContent prop to avoid duplicates | |
| const cleanedPropsString = propsString.replace(/rawContent=\{[^}]*\}\s*/g, '').trim(); | |
| // Rebuild the opening tag with rawContent injected | |
| const newTag = `<CopilotCallout ${rawContentProp} ${cleanedPropsString}>`; |
🤖 Prompt for AI Agents
In `@apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts` around lines
74 - 75, The current rebuild of the opening tag always injects rawContentProp
which can duplicate an existing rawContent prop and cause conflicts; update the
logic that constructs newTag so it first detects and removes any existing
rawContent attribute from propsString (or skips adding rawContentProp when one
already exists) before composing `<CopilotCallout ${rawContentProp}
${propsString.trim()}>`, ensuring only a single rawContent prop is present
(refer to newTag, rawContentProp and propsString).
Contributor
There was a problem hiding this comment.
Actionable comments posted: 12
🤖 Fix all issues with AI agents
In `@apps/framework-docs-v2/content/guides/performant-dashboards.mdx`:
- Line 1020: Normalize hyphenation for the term "precompute"/"pre-computes"
across the document: search for the systemPrompt string variable
(systemPrompt="Goal: ... pre-computes the joins...") and any headings or text
instances that currently use "Precompute" (capitalized) and change them all to
the same form (either "precompute" or "pre-compute") consistently; update the
systemPrompt instance and the "Precompute" heading/text so they match exactly
(choose one form) throughout the file.
- Line 19: Remove the unused FileTree import from the top-level import list in
the guides/performant-dashboards file: locate the import statement that includes
FileTree and delete only the FileTree token (and any trailing comma if
necessary) so the rest of the imports remain unchanged; ensure there are no
other references to FileTree in the file after removal.
In
`@apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx`:
- Line 135: Update the import line to match the real example: remove the
MooseClient named import and change the package name to "@514-labs/moose-lib" so
only sql is imported (e.g., import { sql } from "@514-labs/moose-lib";), and
add/keep a local MooseClient interface definition in this MDX file (referencing
the MooseClient identifier) rather than importing it from the package; ensure
any usage of MooseClient in the example refers to the locally defined interface.
In `@apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx`:
- Around line 30-31: The component currently sets a 2s timeout using timeoutRef
but never clears it on unmount, which can cause setCopied(false) to run on an
unmounted component; update the CopilotCallout component to clear any existing
timeout before creating a new one and add a useEffect cleanup that, on unmount,
checks timeoutRef.current and calls clearTimeout(timeoutRef.current) and sets
timeoutRef.current = null to prevent stale state updates (referencing the
copied, setCopied state and timeoutRef ref).
In `@apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts`:
- Around line 51-56: The code currently builds fullPath from contentFilePath
without validating path traversal; update the logic around contentFilePath /
relativePath / fullPath to resolve the absolute path (use path.resolve) and then
verify the resolved fullPath is contained within CONTENT_ROOT (e.g., compare
path.relative(CONTENT_ROOT, fullPath) does not start with '..' or ensure
fullPath.startsWith(path.resolve(CONTENT_ROOT))). If the check fails, reject or
throw an error (or skip the file) to prevent escaping CONTENT_ROOT. Ensure all
references use the same resolved forms for comparison.
In
`@examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts`:
- Around line 10-19: Rename the exported constant identifiers
OrderFulfillmentDaily and OrderFulfillmentDailyMV to UPPER_SNAKE_CASE (e.g.,
ORDER_FULFILLMENT_DAILY and ORDER_FULFILLMENT_DAILY_MV) where they are declared
(the OlapTable and MaterializedView calls referencing
OrderFulfillmentDailyModel, OlapTable and MaterializedView) and update every
downstream import/usage to the new names to avoid breakage; keep the type/class
names (OrderFulfillmentDailyModel, OlapTable, MaterializedView) unchanged and
ensure export statements still export the renamed constants.
In `@examples/dashboard-migration/example-order-fulfillment/code/query-model.ts`:
- Around line 4-10: The exported constant OrderFulfillmentQM should follow
UPPER_SNAKE_CASE; rename the export to ORDER_FULFILLMENT_QM where it's declared
(the const returned from defineQueryModel using table OrderFulfillmentDaily,
dimensions, metrics, filters, sortable) and update all imports/usages to use
ORDER_FULFILLMENT_QM instead of OrderFulfillmentQM so all references remain
consistent.
In `@examples/dashboard-migration/example-order-fulfillment/context-map.md`:
- Around line 5-6: The Markdown heading "## Status legend" is not surrounded by
a blank line; update the document so there is an empty line immediately above
the "## Status legend" heading (i.e., insert a single blank line before the
heading) to satisfy markdownlint MD022 and ensure proper heading separation.
- Around line 26-27: Add a blank line immediately before the "## Test cases"
heading to satisfy the MD022 rule; edit the block containing the list item
"`test-cases/01-last-30-days.md`" and insert a single empty line above the "##
Test cases" line so the ATX heading is separated by one blank line.
In
`@examples/dashboard-migration/example-order-fulfillment/test-cases/01-last-30-days.md`:
- Around line 1-19: The test filename 01-last-30-days.md is inconsistent with
the JSON payload dates (startDate "2024-01-01" to endDate "2024-01-31"); update
either the file name or the payload so they match: change the endDate in the
request body from "2024-01-31" to "2024-01-30" to reflect a 30-day range, or
rename the file to reflect a 31-day range; make this change where the JSON
payload’s startDate/endDate are defined in the example order-fulfillment test.
In `@examples/dashboard-migration/README.md`:
- Line 27: The README's "replace placeholders" instruction is too vague—open the
prompt.md template and identify each placeholder token (e.g., any {{...}} or
similar markers) and update the README to list each placeholder name with a
short description and example value; specifically, edit the README line that
references the prompt template to replace "replace placeholders" with a brief
mapping (placeholder → meaning → example) and optionally a short note about
required format for values.
- Line 16: Update the tiged invocation in the README by removing the erroneous
"-context" suffix from the source path: replace the string "pnpm dlx tiged
514-labs/moose/examples/dashboard-migration-context moosestack/context" with
"pnpm dlx tiged 514-labs/moose/examples/dashboard-migration moosestack/context"
so the source path matches the actual examples/dashboard-migration directory
referenced in the repo.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (19)
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/src/components/mdx-renderer.tsxapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxapps/framework-docs-v2/src/components/mdx/index.tsapps/framework-docs-v2/src/lib/content.tsapps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsexamples/dashboard-migration/README.mdexamples/dashboard-migration/_templates/context-map-template.mdexamples/dashboard-migration/component-context-pack-template.mdexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/context-map.mdexamples/dashboard-migration/example-order-fulfillment/test-cases/01-last-30-days.mdexamples/dashboard-migration/prompt.md
💤 Files with no reviewable changes (2)
- examples/dashboard-migration/prompt.md
- examples/dashboard-migration/component-context-pack-template.md
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Run linting checks before submitting PRs for TypeScript/JavaScript code
**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g.,_unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier usingexperimentalTernaries: true; auto-formats on commit via Husky + lint-staged
Files:
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsapps/framework-docs-v2/src/components/mdx/index.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsapps/framework-docs-v2/src/lib/content.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsapps/framework-docs-v2/src/components/mdx-renderer.tsxapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
apps/framework-docs-v2/src/**/*.{ts,tsx}
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Component library must use shadcn/ui components located in
src/components/ui/
Files:
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsapps/framework-docs-v2/src/components/mdx/index.tsapps/framework-docs-v2/src/lib/content.tsapps/framework-docs-v2/src/components/mdx-renderer.tsxapps/framework-docs-v2/src/components/mdx/copilot-callout.tsx
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs
Files:
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsapps/framework-docs-v2/src/components/mdx/index.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsapps/framework-docs-v2/src/lib/content.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsapps/framework-docs-v2/src/components/mdx-renderer.tsxapps/framework-docs-v2/src/components/mdx/copilot-callout.tsxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
apps/framework-docs-v2/content/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
apps/framework-docs-v2/content/**/*.mdx: Use{{ include "shared/path.mdx" }}directives to reuse content fragments, which are processed viaprocessIncludes()during build
Validate code snippets in documentation with the@testdirective for TypeScript and Python code blocks
TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
apps/framework-docs-v2/content/guides/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Guide MDX files in
content/guides/must include frontmatter with title and description fields
Files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
🧠 Learnings (18)
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/**/*.mdx : Use `{{ include "shared/path.mdx" }}` directives to reuse content fragments, which are processed via `processIncludes()` during build
Applied to files:
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.tsapps/framework-docs-v2/src/lib/content.tsapps/framework-docs-v2/src/components/mdx-renderer.tsx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layer
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsapps/framework-docs-v2/content/guides/performant-dashboards.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Server actions serve as the primary bridge between frontend React components and backend moose query functions. The communication flow should always be: React Component → Hook → Server Action → Moose Query Function → eventsModel.toSql() → ClickHouse
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-28T14:50:00.978Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1402-1406
Timestamp: 2026-01-28T14:50:00.978Z
Learning: When reviewing WebApp implementations that run in a Node.js backend, prefer Node.js-specific types (e.g., Buffer) and avoid browser-focused cross-platform compatibility considerations. This guideline applies to MDX documentation and code examples across the repository where backend/runtime code is discussed; ensure reviewers distinguish server-side context from frontend/browser constraints and validate type usage accordingly.
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdxapps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/moose/src/query-examples/model.ts : Query model definitions must include `dimensions` (for GROUP BY), `metrics` (for aggregates), `filters` (with allowed operators), and `sortable` (list of sortable fields)
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/source-orders.tsapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/ingest/models.ts : Data models in ingest/models.ts should define interfaces using the Model naming convention, and create corresponding IngestPipeline instances with table, stream, and ingestApi options enabled
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/moose/src/query-examples/**/*.ts : Query example functions must use `eventsModel.toSql()` to generate SQL, ensuring consistent query construction through the defined model
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/components/report-builder/**/*.ts : Report builder components must use `prepareModel()` to transform backend model definitions for frontend consumption, configuring UI input types and options
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/app/actions.ts : Server actions must import query functions from the moose package and wrap them, serving as the bridge between frontend React components and backend moose query functions
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Validate `{{ include }}` directives in content before build using `pnpm run validate:includes` with `scripts/validate-includes.ts`
Applied to files:
apps/framework-docs-v2/src/lib/content.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/**/*.ts : Use type inference helpers (`$inferRequest`, `$inferDimensions`, `$inferMetrics`) from query model definitions to ensure type-safe query parameter construction
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-08T18:32:03.114Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3170
File: apps/framework-docs-v2/src/components/copy-page-button.tsx:36-38
Timestamp: 2026-01-08T18:32:03.114Z
Learning: Enforce the following multiline ternary formatting for conditional JSX without parentheses: place the condition and the '?' on the first line, place the true branch on the next indented line, and place the ':' plus the false branch on the third line. This pattern is commonly used for copy/check icon toggles in the moosestack repository (apps/framework-docs-v2). Apply this style to all TSX files under apps/framework-docs-v2/src/**/*.tsx to ensure consistency and readability.
Applied to files:
apps/framework-docs-v2/src/components/mdx-renderer.tsxapps/framework-docs-v2/src/components/mdx/copilot-callout.tsx
📚 Learning: 2026-02-01T23:07:12.361Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-02-01T23:07:12.361Z
Learning: Audit documentation when changing user-facing features
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/web-app/src/features/dashboard/*.tsx : Dashboard components should follow React hooks patterns: use useState for local data, useEffect for data fetching, handle errors with fallback data, and wrap visualizations in Card/CardHeader/CardContent from Radix UI
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/components/dashboard/**/*.ts : Dashboard hooks must call server actions (not moose functions directly) to decouple React components from ClickHouse implementation details
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-28T14:55:13.411Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1585-1616
Timestamp: 2026-01-28T14:55:13.411Z
Learning: In documentation and tutorial files under apps/framework-docs-v2/content/guides/, prefer explicit, self-contained code examples that may duplicate small snippets for clarity over abstracting with DRY helpers. Ensure examples are easy to understand in isolation, even if it means a bit of repetition, to aid learning and reduce cognitive load for readers.
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/views/*.ts : Use SummingMergeTree engine for materialized views that require incremental updates, and wrap aggregated metrics with SUM() when querying to properly merge partial rows
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-28T14:50:11.465Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1402-1406
Timestamp: 2026-01-28T14:50:11.465Z
Learning: Moose WebApp handlers are Node.js-only server-side code that runs in the backend runtime, never in browsers. When reviewing WebApp implementations, Node.js-specific types like `Buffer` are appropriate and don't need cross-platform browser compatibility considerations.
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
🧬 Code graph analysis (4)
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts (1)
apps/framework-docs-v2/src/lib/includes.ts (1)
CONTENT_ROOT(9-9)
apps/framework-docs-v2/src/lib/content.ts (2)
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts (1)
processCopilotPrompts(35-88)apps/framework-docs-v2/src/lib/includes.ts (1)
processIncludes(37-138)
examples/dashboard-migration/example-order-fulfillment/code/query-model.ts (1)
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts (1)
OrderFulfillmentDaily(10-15)
apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx (1)
apps/framework-docs-v2/src/components/mdx/index.ts (1)
CopilotCallout(52-52)
🪛 LanguageTool
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx
[style] ~115-~115: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...ry into ClickHouse SQL that returns the exact same response shape. Steps: 1. Create `moo...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
[style] ~121-~121: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...Write a function that: - accepts the exact same parameters as the existing handler/quer...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
[style] ~175-~175: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...: prove the parity function returns the exact same JSON as the OLTP endpoint for every tes...
(EN_WORDINESS_PREMIUM_EXACT_SAME)
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
[uncategorized] ~1020-~1020: Do not mix variants of the same word (‘pre-compute’ and ‘precompute’) within a single text.
Context: ...erving table and Materialized View that pre-computes the joins and aggregations from the par...
(EN_WORD_COHERENCY)
🪛 markdownlint-cli2 (0.20.0)
examples/dashboard-migration/example-order-fulfillment/context-map.md
[warning] 5-5: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 26-26: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🔇 Additional comments (20)
apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts (1)
35-88: Solid implementation overall.Good use of replacer function to avoid
$&interpolation issues. Consistent error handling with logging. Aligns well with existingprocessIncludespatterns.apps/framework-docs-v2/src/lib/content.ts (2)
21-21: LGTM.Import properly grouped with other internal modules.
101-102: Correct processing order.Includes resolve first, then CopilotCallout tags are processed—ensures tags from included files are also handled.
examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts (1)
1-12: LGTM.Clean OlapTable definition with appropriate lifecycle and ordering configuration.
examples/dashboard-migration/_templates/context-map-template.md (1)
1-36: LGTM.Well-structured template. Clear phase organization and test case guidance.
apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx (1)
52-73: Clean UI implementation.Proper use of shadcn/ui components. Ternary formatting follows repo conventions. SSR-safe clipboard access.
apps/framework-docs-v2/src/components/mdx/index.ts (1)
51-52: LGTM!Export follows the established barrel file pattern. Comment style is consistent with line 54.
apps/framework-docs-v2/src/components/mdx-renderer.tsx (1)
43-43: LGTM!Import and component registration follow established patterns. Consistent with other MDX component wiring.
Also applies to: 181-182
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts (1)
1-38: LGTM!Clean example demonstrating OLTP-to-ClickHouse parity translation. Follows naming conventions. Half-open date interval is correct.
sqltemplate handles parameterization safely.apps/framework-docs-v2/content/guides/performant-dashboards.mdx (1)
944-1059: Phase restructuring with CopilotCallout is well-organized.Clear separation of concerns across phases. Context attachment instructions are explicit. Include directives properly reference shared checkpoint files.
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-3-checkpoints.mdx (1)
1-153: LGTM!Checkpoint progression is logical. Code examples demonstrate QueryModel pattern correctly. Verification workflow aligns with Phase 1 test case structure.
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx (1)
1-143: LGTM!Serving table design guidance is clear. MV decision heuristic (single vs staged) is practical. Code examples demonstrate the pattern comprehensively.
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx (1)
1-214: Phase 1 checkpoints are comprehensive.Test case capture → OLTP semantics → seed → parity function → verification flow is logical. Templates and verification commands are practical.
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts (2)
4-9: Interface shape looks good.
21-29: Aggregation and GROUP BY are consistent.examples/dashboard-migration/example-order-fulfillment/code/query-model.ts (1)
1-2:⚠️ Potential issue | 🟠 MajorRename constant to UPPER_SNAKE_CASE.
OrderFulfillmentQMshould beORDER_FULFILLMENT_QMper coding guidelines for constants in TypeScript.⛔ Skipped due to learnings
Learnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/nextjs-moose/CLAUDE.md:0-0 Timestamp: 2026-01-27T17:36:29.854Z Learning: Applies to examples/nextjs-moose/moose/src/query-examples/model.ts : Query model definitions must include `dimensions` (for GROUP BY), `metrics` (for aggregates), `filters` (with allowed operators), and `sortable` (list of sortable fields)Learnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/nextjs-moose/CLAUDE.md:0-0 Timestamp: 2026-01-27T17:36:29.854Z Learning: Applies to examples/nextjs-moose/moose/src/query-examples/**/*.ts : Query example functions must use `eventsModel.toSql()` to generate SQL, ensuring consistent query construction through the defined modelLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/nextjs-moose/CLAUDE.md:0-0 Timestamp: 2026-01-27T17:36:29.854Z Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layerLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/nextjs-moose/CLAUDE.md:0-0 Timestamp: 2026-01-27T17:36:29.854Z Learning: Applies to examples/nextjs-moose/components/report-builder/**/*.ts : Report builder components must use `prepareModel()` to transform backend model definitions for frontend consumption, configuring UI input types and optionsLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/nextjs-moose/CLAUDE.md:0-0 Timestamp: 2026-01-27T17:36:29.854Z Learning: Applies to examples/nextjs-moose/**/*.ts : Use type inference helpers (`$inferRequest`, `$inferDimensions`, `$inferMetrics`) from query model definitions to ensure type-safe query parameter constructionLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: examples/nextjs-moose/CLAUDE.md:0-0 Timestamp: 2026-01-27T17:36:29.854Z Learning: Applies to examples/nextjs-moose/app/actions.ts : Server actions must import query functions from the moose package and wrap them, serving as the bridge between frontend React components and backend moose query functionsLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: AGENTS.md:0-0 Timestamp: 2026-02-01T23:07:12.361Z Learning: Applies to **/*.{ts,tsx,js,jsx} : Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScriptLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: apps/framework-cli/AGENTS.md:0-0 Timestamp: 2025-12-16T23:09:10.917Z Learning: Applies to apps/framework-cli/**/*.rs : Use `UPPER_SNAKE_CASE` naming for constantsLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: packages/protobuf/AGENTS.md:0-0 Timestamp: 2025-12-16T23:09:39.883Z Learning: Applies to packages/protobuf/**/*.proto : Use `UPPER_SNAKE_CASE` for Protocol Buffer enum values (e.g., `STATUS_ACTIVE`, `TYPE_PREMIUM`)examples/dashboard-migration/README.md (4)
1-4: LGTM.Clear title and accurate description of the workspace bundle.
8-9: LGTM.Contents list aligns with the described workspace structure.
13-13: 🧹 Nitpick | 🔵 TrivialClarify behavior when
moosestack/doesn't exist.The instruction assumes
moosestack/exists at the repo root. Consider adding guidance for users whose project layout differs or who need to create this directory first.⛔ Skipped due to learnings
Learnt from: CR Repo: 514-labs/moosestack PR: 0 File: AGENTS.md:0-0 Timestamp: 2026-02-01T23:07:12.361Z Learning: Always run end-to-end tests when changing MooseStack functionalityLearnt from: CR Repo: 514-labs/moosestack PR: 0 File: apps/framework-docs-v2/CLAUDE.md:0-0 Timestamp: 2026-01-22T19:02:52.316Z Learning: Always install dependencies from the monorepo root using `pnpm install`, never run `pnpm install` directly from `apps/framework-docs-v2/`
32-32: The guide URL could not be verified as accessible.Web search was unable to reach https://docs.fiveonefour.com/moose/guides/performant-dashboards (fetch errors prevented verification). Confirm the URL is correct and the guide is published before merging.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| SelectField, | ||
| ConditionalContent, | ||
| CommunityCallout, | ||
| FileTree, |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if FileTree is used in the main file or included checkpoints
rg -n "FileTree" apps/framework-docs-v2/content/guides/performant-dashboards.mdx
echo "---"
# Check shared content directory
rg -n "FileTree" apps/framework-docs-v2/content/shared/guides/performant-dashboards/Repository: 514-labs/moosestack
Length of output: 81
🏁 Script executed:
#!/bin/bash
# View the import section to see full context
head -30 apps/framework-docs-v2/content/guides/performant-dashboards.mdxRepository: 514-labs/moosestack
Length of output: 870
Remove unused FileTree import.
FileTree is imported on line 19 but is not used in the file or any included content. Remove it from the import statement.
🤖 Prompt for AI Agents
In `@apps/framework-docs-v2/content/guides/performant-dashboards.mdx` at line 19,
Remove the unused FileTree import from the top-level import list in the
guides/performant-dashboards file: locate the import statement that includes
FileTree and delete only the FileTree token (and any trailing comma if
necessary) so the rest of the imports remain unchanged; ensure there are no
other references to FileTree in the file after removal.
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
Outdated
Show resolved
Hide resolved
| ```ts | ||
| // File: moosestack/app/queries/<component>-olap-translation.ts | ||
|
|
||
| import { sql, MooseClient } from "@514labs/moose-lib"; |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if MooseClient is exported from moose-lib
rg -n "export.*MooseClient" --type ts -g "*.ts"Repository: 514-labs/moosestack
Length of output: 504
🏁 Script executed:
# Find the example file mentioned
fd "order-fulfillment-handler-olap-translation.ts" --type fRepository: 514-labs/moosestack
Length of output: 168
🏁 Script executed:
# Check the documentation file to understand context
head -150 "apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx" | tail -30Repository: 514-labs/moosestack
Length of output: 1108
🏁 Script executed:
# Examine the actual example file to see what it imports
cat -n "examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts" | head -30Repository: 514-labs/moosestack
Length of output: 1066
Update documentation example to match actual code: remove MooseClient import and define locally; fix package name.
The documentation imports MooseClient from "@514labs/moose-lib" and uses "@514labs/moose-lib", but the actual example file defines MooseClient as a local interface and imports sql from "@514-labs/moose-lib" (with hyphen). Align the documentation example with the actual example file pattern.
🤖 Prompt for AI Agents
In
`@apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-1-checkpoints.mdx`
at line 135, Update the import line to match the real example: remove the
MooseClient named import and change the package name to "@514-labs/moose-lib" so
only sql is imported (e.g., import { sql } from "@514-labs/moose-lib";), and
add/keep a local MooseClient interface definition in this MDX file (referencing
the MooseClient identifier) rather than importing it from the package; ensure
any usage of MooseClient in the example refers to the locally defined interface.
Comment on lines
+30
to
+31
| const [copied, setCopied] = useState(false); | ||
| const timeoutRef = useRef<NodeJS.Timeout | null>(null); |
Contributor
There was a problem hiding this comment.
Clear timeout on unmount to prevent state updates after unmount.
If the component unmounts within the 2-second window, setCopied(false) will fire on a stale component.
🧹 Proposed fix using useEffect cleanup
+"use client";
+
+import { useState, useRef, useEffect } from "react";
import { IconCheck, IconCopy, IconRobot } from "@tabler/icons-react";Then add cleanup:
const [copied, setCopied] = useState(false);
const timeoutRef = useRef<NodeJS.Timeout | null>(null);
+
+ useEffect(() => {
+ return () => {
+ if (timeoutRef.current) {
+ clearTimeout(timeoutRef.current);
+ }
+ };
+ }, []);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const [copied, setCopied] = useState(false); | |
| const timeoutRef = useRef<NodeJS.Timeout | null>(null); | |
| "use client"; | |
| import { useState, useRef, useEffect } from "react"; | |
| import { IconCheck, IconCopy, IconRobot } from "@tabler/icons-react"; | |
| // ... other imports ... | |
| export function CopilotCallout({ rawContent, contentFile }: CopilotCalloutProps) { | |
| const [copied, setCopied] = useState(false); | |
| const timeoutRef = useRef<NodeJS.Timeout | null>(null); | |
| useEffect(() => { | |
| return () => { | |
| if (timeoutRef.current) { | |
| clearTimeout(timeoutRef.current); | |
| } | |
| }; | |
| }, []); | |
| // ... rest of the component |
🤖 Prompt for AI Agents
In `@apps/framework-docs-v2/src/components/mdx/copilot-callout.tsx` around lines
30 - 31, The component currently sets a 2s timeout using timeoutRef but never
clears it on unmount, which can cause setCopied(false) to run on an unmounted
component; update the CopilotCallout component to clear any existing timeout
before creating a new one and add a useEffect cleanup that, on unmount, checks
timeoutRef.current and calls clearTimeout(timeoutRef.current) and sets
timeoutRef.current = null to prevent stale state updates (referencing the
copied, setCopied state and timeoutRef ref).
Comment on lines
+51
to
+56
| const contentFilePath = contentFileMatch[1] as string; | ||
| const relativePath = | ||
| contentFilePath.startsWith("/") ? | ||
| contentFilePath.slice(1) | ||
| : contentFilePath; | ||
| const fullPath = path.join(CONTENT_ROOT, relativePath); |
Contributor
There was a problem hiding this comment.
Path traversal risk: validate resolved path stays within CONTENT_ROOT.
contentFilePath from MDX could contain ../ sequences. The resolved fullPath should be verified to remain within CONTENT_ROOT.
🛡️ Proposed fix
const contentFilePath = contentFileMatch[1] as string;
const relativePath =
contentFilePath.startsWith("/") ?
contentFilePath.slice(1)
: contentFilePath;
const fullPath = path.join(CONTENT_ROOT, relativePath);
+
+ // Prevent path traversal attacks
+ const normalizedPath = path.normalize(fullPath);
+ if (!normalizedPath.startsWith(CONTENT_ROOT)) {
+ console.warn(
+ `[processCopilotPrompts] Path traversal attempt blocked: ${contentFilePath}`,
+ );
+ continue;
+ }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| const contentFilePath = contentFileMatch[1] as string; | |
| const relativePath = | |
| contentFilePath.startsWith("/") ? | |
| contentFilePath.slice(1) | |
| : contentFilePath; | |
| const fullPath = path.join(CONTENT_ROOT, relativePath); | |
| const contentFilePath = contentFileMatch[1] as string; | |
| const relativePath = | |
| contentFilePath.startsWith("/") ? | |
| contentFilePath.slice(1) | |
| : contentFilePath; | |
| const fullPath = path.join(CONTENT_ROOT, relativePath); | |
| // Prevent path traversal attacks | |
| const normalizedPath = path.normalize(fullPath); | |
| if (!normalizedPath.startsWith(CONTENT_ROOT)) { | |
| console.warn( | |
| `[processCopilotPrompts] Path traversal attempt blocked: ${contentFilePath}`, | |
| ); | |
| continue; | |
| } |
🤖 Prompt for AI Agents
In `@apps/framework-docs-v2/src/lib/copilot-prompt-preprocessor.ts` around lines
51 - 56, The code currently builds fullPath from contentFilePath without
validating path traversal; update the logic around contentFilePath /
relativePath / fullPath to resolve the absolute path (use path.resolve) and then
verify the resolved fullPath is contained within CONTENT_ROOT (e.g., compare
path.relative(CONTENT_ROOT, fullPath) does not start with '..' or ensure
fullPath.startsWith(path.resolve(CONTENT_ROOT))). If the check fails, reject or
throw an error (or skip the file) to prevent escaping CONTENT_ROOT. Ensure all
references use the same resolved forms for comparison.
Comment on lines
+5
to
+6
| ## Status legend | ||
| Not started | In progress | Done | Blocked |
Contributor
There was a problem hiding this comment.
Add blank line before heading.
Per markdownlint MD022: headings should be surrounded by blank lines.
📝 Proposed fix
This example shows a minimal, end-to-end map for Phases 1–3. Replace values with your real endpoint and paths.
+
## Status legend
Not started | In progress | Done | Blocked📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ## Status legend | |
| Not started | In progress | Done | Blocked | |
| This example shows a minimal, end-to-end map for Phases 1–3. Replace values with your real endpoint and paths. | |
| ## Status legend | |
| Not started | In progress | Done | Blocked |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 5-5: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🤖 Prompt for AI Agents
In `@examples/dashboard-migration/example-order-fulfillment/context-map.md` around
lines 5 - 6, The Markdown heading "## Status legend" is not surrounded by a
blank line; update the document so there is an empty line immediately above the
"## Status legend" heading (i.e., insert a single blank line before the heading)
to satisfy markdownlint MD022 and ensure proper heading separation.
Comment on lines
+26
to
+27
| ## Test cases | ||
| - `test-cases/01-last-30-days.md` |
Contributor
There was a problem hiding this comment.
Add blank line before heading.
Same MD022 issue.
📝 Proposed fix
| - Serving table + MV: `code/order-fulfillment-daily-mv.ts` <br/>- Handler: `path/to/order-fulfillment.handler.ts` <br/>- Contract: `/api/order-fulfillment` | - `code/query-model.ts` <br/>- Handler update: `path/to/order-fulfillment.handler.ts` | Done | Keep stable ordering by `day`. |
+
## Test cases
- `test-cases/01-last-30-days.md`📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ## Test cases | |
| - `test-cases/01-last-30-days.md` | |
| | - Serving table + MV: `code/order-fulfillment-daily-mv.ts` <br/>- Handler: `path/to/order-fulfillment.handler.ts` <br/>- Contract: `/api/order-fulfillment` | - `code/query-model.ts` <br/>- Handler update: `path/to/order-fulfillment.handler.ts` | Done | Keep stable ordering by `day`. | | |
| ## Test cases | |
| - `test-cases/01-last-30-days.md` |
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 26-26: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🤖 Prompt for AI Agents
In `@examples/dashboard-migration/example-order-fulfillment/context-map.md` around
lines 26 - 27, Add a blank line immediately before the "## Test cases" heading
to satisfy the MD022 rule; edit the block containing the list item
"`test-cases/01-last-30-days.md`" and insert a single empty line above the "##
Test cases" line so the ATX heading is separated by one blank line.
Comment on lines
+1
to
+19
| # Test case: last-30-days | ||
|
|
||
| ## Request (curl) | ||
|
|
||
| ```bash | ||
| # Method: POST | ||
| # Expected: HTTP 200 | ||
| # Auth: Bearer token via $API_TOKEN (do not paste secrets) | ||
|
|
||
| curl -sS -X POST "$API_BASE_URL/api/order-fulfillment" \ | ||
| -H "Authorization: Bearer $API_TOKEN" \ | ||
| -H "Content-Type: application/json" \ | ||
| -d @- << 'JSON' \ | ||
| | jq . | ||
| { | ||
| "merchantId": "123", | ||
| "startDate": "2024-01-01", | ||
| "endDate": "2024-01-31" | ||
| } |
Contributor
There was a problem hiding this comment.
Minor: Test case name vs. date range mismatch.
File named 01-last-30-days.md but the request spans 2024-01-01 to 2024-01-31 (31 days). Consider aligning the name or adjusting the endDate to 2024-01-30.
🤖 Prompt for AI Agents
In
`@examples/dashboard-migration/example-order-fulfillment/test-cases/01-last-30-days.md`
around lines 1 - 19, The test filename 01-last-30-days.md is inconsistent with
the JSON payload dates (startDate "2024-01-01" to endDate "2024-01-31"); update
either the file name or the payload so they match: change the endDate in the
request body from "2024-01-31" to "2024-01-30" to reflect a 30-day range, or
rename the file to reflect a 31-day range; make this change where the JSON
payload’s startDate/endDate are defined in the example order-fulfillment test.
|
|
||
| ```bash | ||
| pnpm dlx tiged 514-labs/moosestack/examples/dashboard-migration context/migrations | ||
| pnpm dlx tiged 514-labs/moose/examples/dashboard-migration-context moosestack/context |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for both dashboard-migration and dashboard-migration-context directories
echo "=== Checking examples/ directory structure ==="
fd -t d '^dashboard-migration' examples/ 2>/dev/null || echo "No dashboard-migration* dirs found with fd"
echo ""
echo "=== Listing examples/ directories ==="
ls -la examples/ | grep -E "^d" | grep migration || echo "No migration dirs found"
echo ""
echo "=== Checking if dashboard-migration-context exists ==="
if [ -d "examples/dashboard-migration-context" ]; then
echo "✓ examples/dashboard-migration-context EXISTS"
echo "Contents:"
ls -la examples/dashboard-migration-context/
else
echo "✗ examples/dashboard-migration-context NOT FOUND"
fi
echo ""
echo "=== Checking if dashboard-migration exists ==="
if [ -d "examples/dashboard-migration" ]; then
echo "✓ examples/dashboard-migration EXISTS"
echo "Contents:"
ls -la examples/dashboard-migration/
else
echo "✗ examples/dashboard-migration NOT FOUND"
fiRepository: 514-labs/moosestack
Length of output: 753
🏁 Script executed:
#!/bin/bash
# Verify the moose repo path that tiged references
# Check the README content first to understand the exact command
echo "=== README content (lines 13-22) ==="
sed -n '13,22p' examples/dashboard-migration/README.md
echo ""
echo "=== Checking if moose repo path is accessible via git ==="
# Try to list remote repository contents via git ls-remote
git ls-remote --heads https://github.com/514-labs/moose.git | head -5
echo ""
echo "=== Attempting to verify moose repo structure ==="
# Check if we can access the moose repo structure
if command -v curl &> /dev/null; then
echo "Checking moose repo directory via GitHub API:"
curl -s https://api.github.com/repos/514-labs/moose/contents/examples | jq -r '.[].name' 2>/dev/null | grep migration || echo "Could not retrieve moose repo contents"
fiRepository: 514-labs/moosestack
Length of output: 1101
🌐 Web query:
514-labs moose github examples dashboard-migration-context directory
💡 Result:
In the 514-labs/moosestack GitHub repo, there is a top-level examples/ directory. [1]
However, I could not find any directory (or file) named dashboard-migration-context in that repo via public GitHub/web search (i.e., no indexed matches for the string dashboard-migration-context). [2]
If you expect it to exist, the quickest way to confirm is to use GitHub’s in-repo search (or “Go to file”) for dashboard-migration-context, or search for likely shorter names like migration-context / dashboard-migration. [1]
Sources:
[1] 514-labs/moosestack repository (folder list shows examples/) (github.com)
[2] Search results showing no indexed dashboard-migration-context hits in 514-labs/moosestack (github.com)
Citations:
🏁 Script executed:
#!/bin/bash
# The tiged command references 514-labs/moose repo, not moosestack
# Let's verify the moose repo has the dashboard-migration-context directory
echo "=== Checking 514-labs/moose repo (via git) ==="
git ls-remote --heads https://github.com/514-labs/moose.git main | head -1
echo ""
echo "=== Attempting to check moose repo examples directory ==="
# Try to access moose repo via GitHub raw content
if command -v curl &> /dev/null; then
echo "Checking if dashboard-migration-context exists in moose/examples:"
curl -s -I https://raw.githubusercontent.com/514-labs/moose/main/examples/dashboard-migration-context/ 2>/dev/null | head -1
echo ""
echo "Listing examples directory in moose repo:"
curl -s https://api.github.com/repos/514-labs/moose/contents/examples 2>/dev/null | jq -r '.[].name' 2>/dev/null | sort || echo "Failed to fetch"
fiRepository: 514-labs/moosestack
Length of output: 347
🏁 Script executed:
#!/bin/bash
# Check the moose repo structure more carefully
echo "=== Checking moose repo main branch structure ==="
# Create a temporary directory and shallow clone just the examples
tmpdir=$(mktemp -d)
cd "$tmpdir"
git clone --depth 1 --filter=blob:none --sparse https://github.com/514-labs/moose.git moose 2>&1 | grep -E "(Cloning|branch)"
cd moose
git sparse-checkout set examples
ls -la examples/ 2>/dev/null | head -20
echo ""
echo "=== Checking for any dashboard-migration* directories ==="
find examples -type d -name "*dashboard-migration*" 2>/dev/null || echo "No dashboard-migration directories found"Repository: 514-labs/moosestack
Length of output: 713
🏁 Script executed:
#!/bin/bash
tmpdir=$(mktemp -d)
cd "$tmpdir"
git clone --depth 1 --filter=blob:none --sparse https://github.com/514-labs/moose.git moose 2>&1 | tail -1
cd moose
git sparse-checkout set examples/dashboard-migration
echo "=== Contents of moose/examples/dashboard-migration ==="
find examples/dashboard-migration -type f -o -type d | head -20Repository: 514-labs/moosestack
Length of output: 350
Fix tiged source path: remove -context suffix.
The command references examples/dashboard-migration-context, which does not exist in the moose repository. The correct path is examples/dashboard-migration. Update line 16 to:
pnpm dlx tiged 514-labs/moose/examples/dashboard-migration moosestack/context🤖 Prompt for AI Agents
In `@examples/dashboard-migration/README.md` at line 16, Update the tiged
invocation in the README by removing the erroneous "-context" suffix from the
source path: replace the string "pnpm dlx tiged
514-labs/moose/examples/dashboard-migration-context moosestack/context" with
"pnpm dlx tiged 514-labs/moose/examples/dashboard-migration moosestack/context"
so the source path matches the actual examples/dashboard-migration directory
referenced in the repo.
| ## How to use | ||
|
|
||
| 1. **Duplicate the context map template** for the component you’re migrating, e.g. `moosestack/context/dashboard-migration/<component-name>/context-map.md`. | ||
| 2. **Open the prompt template** at `moosestack/context/dashboard-migration/_templates/prompt.md`, replace placeholders, and paste it into your copilot. |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Clarify what placeholders need replacement.
"Replace placeholders" is mentioned but not specified. Consider documenting which placeholders exist in the prompt template and what values users should provide.
🤖 Prompt for AI Agents
In `@examples/dashboard-migration/README.md` at line 27, The README's "replace
placeholders" instruction is too vague—open the prompt.md template and identify
each placeholder token (e.g., any {{...}} or similar markers) and update the
README to list each placeholder name with a short description and example value;
specifically, edit the README line that references the prompt template to
replace "replace placeholders" with a brief mapping (placeholder → meaning →
example) and optionally a short note about required format for values.
| SelectField, | ||
| ConditionalContent, | ||
| CommunityCallout, | ||
| FileTree, |
There was a problem hiding this comment.
Unused FileTree import added to MDX file
Low Severity
FileTree is newly imported but never used anywhere in performant-dashboards.mdx or its included files (phase-1-checkpoints.mdx, phase-2-checkpoints.mdx, phase-3-checkpoints.mdx). This is dead code.
| } | ||
|
|
||
| try { | ||
| const cleaned = cleanContent(rawContent); |
There was a problem hiding this comment.
Copied prompt loses uppercase placeholder tags via cleaning
Medium Severity
When the user clicks "Copy Prompt", cleanContent strips uppercase-initial angle-bracket placeholders like <ServingTable> from the raw checkpoint content because its JSX-removal regex (/<[A-Z][A-Za-z0-9]*...>/g) matches them. For example, the Phase 2 instruction moosestack/app/models/<ServingTable>-mv.ts becomes moosestack/app/models/-mv.ts in the copied text. Only triple-backtick code fences are protected; inline-code backtick placeholders are not.
Additional Locations (1)
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| const rawContentProp = `rawContent={${JSON.stringify(fileContent.trim())}}`; | ||
|
|
||
| // Rebuild the opening tag with rawContent injected | ||
| const newTag = `<CopilotCallout ${rawContentProp} ${propsString.trim()}>`; |
There was a problem hiding this comment.
Injected rawContent breaks LLM endpoint JSX stripping
Medium Severity
processCopilotPrompts injects rawContent containing the full checkpoint file as a JSON string (with literal < and > characters like <TABLE_NAME>, >=). This content flows through parseMarkdownContent into the LLM endpoint, where cleanContent tries to strip JSX using [^<>]*. That character class stops at the first angle bracket inside rawContent, so the regex can't match the full CopilotCallout opening tag. The tag (with its massive JSON blob) remains in the LLM output as garbled text, while the closing </CopilotCallout> is stripped separately.
Additional Locations (1)
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@apps/framework-docs-v2/content/guides/performant-dashboards.mdx`:
- Around line 948-954: The documented tiged CLI command references a wrong
repository/path string ("514-labs/moose/examples/dashboard-migration") which
doesn't exist; update the command in the MDX so the repo and example path match
the actual source (e.g., replace "514-labs/moose" with "514-labs/moosestack" and
correct or remove "examples/dashboard-migration"), verify the correct example
folder in the 514-labs/moosestack repo, and update the bash snippet (the pnpm
dlx tiged invocation) to point to that existing repo/path so the command
succeeds.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
🧰 Additional context used
📓 Path-based instructions (2)
apps/framework-docs-v2/content/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
apps/framework-docs-v2/content/**/*.mdx: Use{{ include "shared/path.mdx" }}directives to reuse content fragments, which are processed viaprocessIncludes()during build
Validate code snippets in documentation with the@testdirective for TypeScript and Python code blocks
TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
apps/framework-docs-v2/content/guides/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Guide MDX files in
content/guides/must include frontmatter with title and description fields
Files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
🧠 Learnings (18)
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/**/*.mdx : Use `{{ include "shared/path.mdx" }}` directives to reuse content fragments, which are processed via `processIncludes()` during build
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/web-app/src/features/dashboard/*.tsx : Dashboard components should follow React hooks patterns: use useState for local data, useEffect for data fetching, handle errors with fallback data, and wrap visualizations in Card/CardHeader/CardContent from Radix UI
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Validate `{{ include }}` directives in content before build using `pnpm run validate:includes` with `scripts/validate-includes.ts`
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Content in the `shared/` folder must only be used via the `include` system (processed by `src/lib/includes.ts`), not directly as routes
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/guides/**/*.mdx : Guide MDX files in `content/guides/` must include frontmatter with title and description fields
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/**/*.mdx : TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/**/*.mdx : Validate code snippets in documentation with the `test` directive for TypeScript and Python code blocks
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2025-12-17T23:59:22.807Z
Learnt from: callicles
Repo: 514-labs/moosestack PR: 3143
File: apps/framework-docs/llm-docs/python/table-setup.md:331-336
Timestamp: 2025-12-17T23:59:22.807Z
Learning: In apps/framework-docs/llm-docs/**/*.md (LLM documentation), prefer exact class and type names (e.g., "MaterializedView", "OlapTable") over lowercase prose variants (e.g., "materialized view") to help LLMs generate correct code with proper imports and syntax.
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: For slow dashboard queries (>500ms) that aggregate across multiple tables or need cohort-based breakdowns, implement a materialized view instead of real-time queries
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layer
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Server actions serve as the primary bridge between frontend React components and backend moose query functions. The communication flow should always be: React Component → Hook → Server Action → Moose Query Function → eventsModel.toSql() → ClickHouse
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2026-01-28T14:50:00.978Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1402-1406
Timestamp: 2026-01-28T14:50:00.978Z
Learning: When reviewing WebApp implementations that run in a Node.js backend, prefer Node.js-specific types (e.g., Buffer) and avoid browser-focused cross-platform compatibility considerations. This guideline applies to MDX documentation and code examples across the repository where backend/runtime code is discussed; ensure reviewers distinguish server-side context from frontend/browser constraints and validate type usage accordingly.
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdxapps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2026-01-28T14:55:13.411Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1585-1616
Timestamp: 2026-01-28T14:55:13.411Z
Learning: In documentation and tutorial files under apps/framework-docs-v2/content/guides/, prefer explicit, self-contained code examples that may duplicate small snippets for clarity over abstracting with DRY helpers. Ensure examples are easy to understand in isolation, even if it means a bit of repetition, to aid learning and reduce cognitive load for readers.
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/views/*.ts : Use SummingMergeTree engine for materialized views that require incremental updates, and wrap aggregated metrics with SUM() when querying to properly merge partial rows
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2026-02-01T23:07:12.361Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-02-01T23:07:12.361Z
Learning: Add E2E tests to `python-tests` and `typescript-tests` templates when changing user-facing features
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2026-01-19T22:37:05.393Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3282
File: apps/framework-cli-e2e/test/utils/llm-agent-utils.ts:613-742
Timestamp: 2026-01-19T22:37:05.393Z
Learning: In the LLM Documentation Automation test (`apps/framework-cli-e2e/test/llm-docs-automation.test.ts` and `apps/framework-cli-e2e/test/utils/llm-agent-utils.ts`), token limit failures are intentional. The test should fail if the agent exceeds Claude's context window, as this signals that documentation or task complexity needs improvement and represents what a real user would experience.
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2026-02-01T23:07:12.361Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-02-01T23:07:12.361Z
Learning: Applies to **/*.{ts,tsx} : Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
📚 Learning: 2025-12-16T23:08:31.521Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-16T23:08:31.521Z
Learning: Ensure all tests pass: `cargo test` for Rust components and appropriate test commands for TS/JS
Applied to files:
apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx
🪛 LanguageTool
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
[uncategorized] ~1017-~1017: Do not mix variants of the same word (‘pre-compute’ and ‘precompute’) within a single text.
Context: ...erving table and Materialized View that pre-computes the joins and aggregations at write tim...
(EN_WORD_COHERENCY)
🔇 Additional comments (4)
apps/framework-docs-v2/content/guides/performant-dashboards.mdx (1)
944-999: Copilot-driven phase structure looks good.The three-phase pattern (Parity → Precompute → Serve) with
CopilotCalloutblocks containingsystemPrompt,contentFile, and contextual guidance for each phase is clean and well-organized. The prompts are actionable, the "attach these files" instructions are specific, and the rules (sequential checkpoints, no fabrication, record in context-map) are solid guardrails.apps/framework-docs-v2/content/shared/guides/performant-dashboards/phase-2-checkpoints.mdx (3)
81-96: MV example is clear and idiomatic.The
MaterializedViewdefinition correctly demonstratesselectStatementviasqltagged template, table interpolation (${SourceTableA}),targetTablewiring, andselectTablesregistration. ThesumIf(1, ...)pattern for conditional counting is valid ClickHouse SQL.
101-131: Verification checkpoint is well-structured.Covers creation logs, row-count checks, spot-check queries with
FINAL, and cross-referencing against Phase 1 test cases. The note to not backfill manually duringmoose devis a useful guardrail.One nit: line 123 and 126 use
<ServingTable>as a placeholder inmoose querycommands. Users should be reminded these are placeholders — but the "adapt to your component" framing from checkpoint 1 already covers that.
1-10: Phase 2 checkpoints are well-organized.The four-checkpoint structure (design → plan → implement → verify) provides a clear, sequential workflow. The grain/orderByFields guidance and the single-MV vs staged-pipeline heuristic are practical decision frameworks.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
Comment on lines
+948
to
954
| #### (Recommended) Build a copilot context pack | ||
|
|
||
| Before starting the migration, prepare your development environment by seeding your local ClickHouse database with a deterministic slice of production data. You’ll use this data to validate parity during Phase 1. | ||
|
|
||
| Ensure your dev server is running and accessible: | ||
| ```shell | ||
| moose dev | ||
| ``` | ||
|
|
||
| First, export the **HTTPS** ClickHouse connection string from the **previous Boreal step** (the ClickHouse connection details Boreal shows you) as an environment variable: | ||
|
|
||
| ```shell | ||
| export CLICKHOUSE_PROD_URL="<YOUR_HTTPS_CONNECTION_STRING>" | ||
| ``` | ||
|
|
||
| **Important:** `moose seed clickhouse` uses ClickHouse's HTTPS protocol. Your connection string should start with `https://` (for example, `https://username:password@host:8443/database`). | ||
|
|
||
| Then run the [`moose seed` command](https://docs.fiveonefour.com/moosestack/moose-cli?lang=typescript#seed-clickhouse) to pull data from your production ClickHouse database: | ||
|
|
||
| ```shell | ||
| moose seed clickhouse --connection-string "$CLICKHOUSE_PROD_URL" --limit 1000 | ||
| ``` | ||
|
|
||
| **Recommended (seed for parity):** seed the specific table(s) your component will query, ordered by recency, with a large-enough limit to cover the time window you’ll test (e.g. “last 7–30 days”). | ||
|
|
||
| Run this once per table your endpoint depends on: | ||
|
|
||
| ```shell | ||
| moose seed clickhouse \ | ||
| --connection-string "$CLICKHOUSE_PROD_URL" \ | ||
| --table <TABLE_NAME> \ | ||
| --order-by '<TIMESTAMP_COLUMN> DESC' \ | ||
| --limit 100000 | ||
| ``` | ||
|
|
||
| If you hit missing-data issues during parity validation, re-run seeding with a larger `--limit` (or seed full tables with `--all`). | ||
|
|
||
| **Strict parity (slowest):** seed full production tables with `--all` (can take hours for large datasets): | ||
|
|
||
| ```shell | ||
| moose seed clickhouse --connection-string $CLICKHOUSE_PROD_URL --all | ||
| ``` | ||
|
|
||
| Once your local database is seeded, proceed to Step 1. | ||
|
|
||
| <ToggleBlock openText="Advanced: seed local ClickHouse from remote via HTTP" closeText="Hide advanced seeding"> | ||
| Prompt your copilot to seed your local database from each remote table: | ||
| Copy the starter kit to create a dedicated workspace to compile all the context your copilot needs to migrate each component. It includes a template for a `context-map.md` file (a worksheet that tracks the location of relevant files in your codebase for each component) and a full example to help your copilot complete each phase of the migration. | ||
|
|
||
| ```bash | ||
| pnpm dlx tiged 514-labs/moose/examples/dashboard-migration moosestack/context | ||
| ``` |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
git ls-remote --heads https://github.com/514-labs/moose.git | head -1Repository: 514-labs/moosestack
Length of output: 131
🏁 Script executed:
git ls-tree -r --name-only https://github.com/514-labs/moose.git HEAD | grep -i "examples/dashboard-migration" | head -20Repository: 514-labs/moosestack
Length of output: 131
🌐 Web query:
514-labs moose moosestack examples dashboard-migration tiged
💡 Result:
Here’s what those keywords most likely map to, with concrete places to look:
514-labs / Moose / MooseStack
- Main repo + core “examples” (code snippets + CLI commands):
514-labs/moosestack(README showsmoose init …and TS/Python example code for tables/streams/APIs). (github.com) - Larger end-to-end example project(s):
514-labs/oltp-to-olap-showcase(multiple app examples with Moose OLAP tables/transformations). (github.com) - Official Moose templates (starter dashboards/apps): Moose “Templates” docs (use
moose template list, andmoose init <project> <template-name>). (docs.fiveonefour.com)
“dashboard-migration”
This phrase doesn’t appear to be a MooseStack-specific module name from the MooseStack repo/docs above; it more commonly refers to other ecosystems’ tooling, e.g.:
- Grafana dashboard migration system (Go package/docs): Grafana’s dashboard migration package docs. (pkg.go.dev)
- Vendure Admin UI → new Dashboard migration guide: Vendure’s Dashboard migration docs. (docs.vendure.io)
“tiged”
tiged is commonly used as a lightweight “download/copy a GitHub template repo” CLI (often shown as npx tiged owner/repo folder). Example usage is shown in various template repos’ READMEs. (github.com)
Quick clarification (so I can point to the exact repo/file)
When you say “dashboard-migration”, do you mean:
- a Moose template (some analytics dashboard starter), or
- Grafana dashboard JSON migrations, or
- something else (link/repo name)?
If you share the URL (or where you saw “dashboard-migration”), I can pull the exact “examples” and commands from the right place.
Citations:
- 1: https://github.com/514-labs/moosestack
- 2: https://github.com/514-labs/oltp-to-olap-showcase?utm_source=openai
- 3: https://docs.fiveonefour.com/templates?utm_source=openai
- 4: https://pkg.go.dev/github.com/grafana/grafana/apps/dashboard/pkg/migration?utm_source=openai
- 5: https://docs.vendure.io/guides/extending-the-dashboard/migration/?utm_source=openai
- 6: https://github.com/amannn/vite-react-starter?utm_source=openai
🌐 Web query:
site:github.com/514-labs/moosestack "dashboard-migration" examples
💡 Result:
I couldn’t find any occurrences of the exact string dashboard-migration in 514-labs/moosestack via GitHub/web indexing—search results only surfaced the repo homepage, not any matching code/files. [1]
If you want to confirm (and catch anything not indexed), run a local search:
gh repo clone 514-labs/moosestack
cd moosestack
rg -n "dashboard-migration"If you meant dashboard templates (not the literal string), Moose’s docs point to a separate “templates repository” that’s more likely to contain dashboard-related examples (e.g., “Github Analytics Dashboard”). [2]
Sources: [1], [2]
The tiged command references a non-existent path. The repo is 514-labs/moosestack (not moose), and examples/dashboard-migration does not exist in that repository. The command as documented will fail.
🤖 Prompt for AI Agents
In `@apps/framework-docs-v2/content/guides/performant-dashboards.mdx` around lines
948 - 954, The documented tiged CLI command references a wrong repository/path
string ("514-labs/moose/examples/dashboard-migration") which doesn't exist;
update the command in the MDX so the repo and example path match the actual
source (e.g., replace "514-labs/moose" with "514-labs/moosestack" and correct or
remove "examples/dashboard-migration"), verify the correct example folder in the
514-labs/moosestack repo, and update the bash snippet (the pnpm dlx tiged
invocation) to point to that existing repo/path so the command succeeds.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@apps/framework-docs-v2/content/guides/performant-dashboards.mdx`:
- Around line 1054-1065: The CopilotCallout usage in Phase 3 omits the explicit
buttonLabel prop causing inconsistency with Phases 1 and 2; update the
CopilotCallout invocation (the JSX block named CopilotCallout) to include
buttonLabel="Copy Prompt" so the prop is explicitly passed (even though a
default exists) to match the other phases and improve documentation clarity.
In `@examples/dashboard-migration/example-order-fulfillment/code/query-model.ts`:
- Around line 1-3: Reorder the import statements in query-model.ts so external
modules come first: move the import of the external package sql from
"@514labs/moose-lib" above the local imports; keep the local imports of
defineQueryModel (from "./query-layer") and OrderFulfillmentDaily (from
"./order-fulfillment-daily-mv") after the external import. Ensure imports remain
grouped as external dependencies then internal modules and that symbols
defineQueryModel and OrderFulfillmentDaily are unchanged.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
apps/framework-docs-v2/content/guides/performant-dashboards.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.ts
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Run linting checks before submitting PRs for TypeScript/JavaScript code
**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g.,_unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier usingexperimentalTernaries: true; auto-formats on commit via Husky + lint-staged
Files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs
Files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
apps/framework-docs-v2/content/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
apps/framework-docs-v2/content/**/*.mdx: Use{{ include "shared/path.mdx" }}directives to reuse content fragments, which are processed viaprocessIncludes()during build
Validate code snippets in documentation with the@testdirective for TypeScript and Python code blocks
TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
apps/framework-docs-v2/content/guides/**/*.mdx
📄 CodeRabbit inference engine (apps/framework-docs-v2/CLAUDE.md)
Guide MDX files in
content/guides/must include frontmatter with title and description fields
Files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
🧠 Learnings (26)
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/moose/src/query-examples/model.ts : Query model definitions must include `dimensions` (for GROUP BY), `metrics` (for aggregates), `filters` (with allowed operators), and `sortable` (list of sortable fields)
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/views/*.ts : Use SummingMergeTree engine for materialized views that require incremental updates, and wrap aggregated metrics with SUM() when querying to properly merge partial rows
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/moose/src/query-examples/**/*.ts : Query example functions must use `eventsModel.toSql()` to generate SQL, ensuring consistent query construction through the defined model
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-02-01T23:07:12.361Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-02-01T23:07:12.361Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Group imports by external dependencies, internal modules, and types; use named exports from barrel files (`index.ts`)
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/app/actions.ts : Server actions must import query functions from the moose package and wrap them, serving as the bridge between frontend React components and backend moose query functions
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/components/report-builder/**/*.ts : Report builder components must use `prepareModel()` to transform backend model definitions for frontend consumption, configuring UI input types and options
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-02-01T23:07:12.361Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-02-01T23:07:12.361Z
Learning: Applies to **/*.{ts,tsx,js,jsx} : Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2025-12-16T23:09:39.883Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: packages/protobuf/AGENTS.md:0-0
Timestamp: 2025-12-16T23:09:39.883Z
Learning: Applies to packages/protobuf/**/*.proto : Use `UPPER_SNAKE_CASE` for Protocol Buffer enum values (e.g., `STATUS_ACTIVE`, `TYPE_PREMIUM`)
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: The moose query layer represents a two-step OLAP migration pattern: Step 1 (not shown) shifts just-in-time joins to write-time via Materialized Views; Step 2 (this demo) accelerates endpoint creation with the query layer. This architecture assumes MVs/OLAP tables already exist and focuses on the read-time query selection and filtering layer
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.tsapps/framework-docs-v2/content/guides/performant-dashboards.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/**/*.ts : Use type inference helpers (`$inferRequest`, `$inferDimensions`, `$inferMetrics`) from query model definitions to ensure type-safe query parameter construction
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/query-model.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/ingest/models.ts : Data models in ingest/models.ts should define interfaces using the Model naming convention, and create corresponding IngestPipeline instances with table, stream, and ingestApi options enabled
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/source-orders.tsexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/**/*.mdx : Use `{{ include "shared/path.mdx" }}` directives to reuse content fragments, which are processed via `processIncludes()` during build
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/web-app/src/features/dashboard/*.tsx : Dashboard components should follow React hooks patterns: use useState for local data, useEffect for data fetching, handle errors with fallback data, and wrap visualizations in Card/CardHeader/CardContent from Radix UI
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Validate `{{ include }}` directives in content before build using `pnpm run validate:includes` with `scripts/validate-includes.ts`
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Content in the `shared/` folder must only be used via the `include` system (processed by `src/lib/includes.ts`), not directly as routes
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/guides/**/*.mdx : Guide MDX files in `content/guides/` must include frontmatter with title and description fields
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/**/*.mdx : TypeScript code snippets in documentation should be validated for syntax with brace matching; Python snippets should be validated for indentation
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-22T19:02:52.316Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: apps/framework-docs-v2/CLAUDE.md:0-0
Timestamp: 2026-01-22T19:02:52.316Z
Learning: Applies to apps/framework-docs-v2/content/**/*.mdx : Validate code snippets in documentation with the `test` directive for TypeScript and Python code blocks
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2025-12-17T23:59:22.807Z
Learnt from: callicles
Repo: 514-labs/moosestack PR: 3143
File: apps/framework-docs/llm-docs/python/table-setup.md:331-336
Timestamp: 2025-12-17T23:59:22.807Z
Learning: In apps/framework-docs/llm-docs/**/*.md (LLM documentation), prefer exact class and type names (e.g., "MaterializedView", "OlapTable") over lowercase prose variants (e.g., "materialized view") to help LLMs generate correct code with proper imports and syntax.
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: For slow dashboard queries (>500ms) that aggregate across multiple tables or need cohort-based breakdowns, implement a materialized view instead of real-time queries
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Applies to examples/nextjs-moose/components/dashboard/**/*.ts : Dashboard hooks must call server actions (not moose functions directly) to decouple React components from ClickHouse implementation details
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdxexamples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
📚 Learning: 2026-01-26T00:56:27.011Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-27T17:36:29.854Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/nextjs-moose/CLAUDE.md:0-0
Timestamp: 2026-01-27T17:36:29.854Z
Learning: Server actions serve as the primary bridge between frontend React components and backend moose query functions. The communication flow should always be: React Component → Hook → Server Action → Moose Query Function → eventsModel.toSql() → ClickHouse
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-28T14:50:00.978Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1402-1406
Timestamp: 2026-01-28T14:50:00.978Z
Learning: When reviewing WebApp implementations that run in a Node.js backend, prefer Node.js-specific types (e.g., Buffer) and avoid browser-focused cross-platform compatibility considerations. This guideline applies to MDX documentation and code examples across the repository where backend/runtime code is discussed; ensure reviewers distinguish server-side context from frontend/browser constraints and validate type usage accordingly.
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-28T14:55:13.411Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1585-1616
Timestamp: 2026-01-28T14:55:13.411Z
Learning: In documentation and tutorial files under apps/framework-docs-v2/content/guides/, prefer explicit, self-contained code examples that may duplicate small snippets for clarity over abstracting with DRY helpers. Ensure examples are easy to understand in isolation, even if it means a bit of repetition, to aid learning and reduce cognitive load for readers.
Applied to files:
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
📚 Learning: 2026-01-28T14:50:11.465Z
Learnt from: cjus
Repo: 514-labs/moosestack PR: 3407
File: apps/framework-docs-v2/content/guides/static-report-generation.mdx:1402-1406
Timestamp: 2026-01-28T14:50:11.465Z
Learning: Moose WebApp handlers are Node.js-only server-side code that runs in the backend runtime, never in browsers. When reviewing WebApp implementations, Node.js-specific types like `Buffer` are appropriate and don't need cross-platform browser compatibility considerations.
Applied to files:
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-daily-mv.ts
🧬 Code graph analysis (1)
examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts (1)
examples/dashboard-migration/example-order-fulfillment/code/source-orders.ts (1)
Orders(9-12)
🪛 LanguageTool
apps/framework-docs-v2/content/guides/performant-dashboards.mdx
[uncategorized] ~1017-~1017: Do not mix variants of the same word (‘pre-compute’ and ‘precompute’) within a single text.
Context: ...erving table and Materialized View that pre-computes the joins and aggregations at write tim...
(EN_WORD_COHERENCY)
🔇 Additional comments (5)
examples/dashboard-migration/example-order-fulfillment/code/query-model.ts (1)
5-20: Query model definition is solid.All four required sections present: dimensions, metrics, filters, sortable. Metrics correctly use
sum()wrappers, which handles partial-row merging at read time regardless of the backing table engine.examples/dashboard-migration/example-order-fulfillment/code/order-fulfillment-handler-olap-translation.ts (1)
1-38: Clean implementation. Import order correct, explicit return type, proper use ofsqltagged template for parameterized queries.The aggregation logic intentionally mirrors
OrderFulfillmentDailyMV— this is the runtime-translation approach (Phase 1 parity) vs. the pre-computed MV approach (Phase 2). No issues.apps/framework-docs-v2/content/guides/performant-dashboards.mdx (3)
966-999: Phase 1 CopilotCallout is well-structured.Clear goal, context list, rules, and sequential checkpoint instructions. The prompt design is solid.
944-946: Three-phase naming is clear and well-linked.Parity → Precompute → Serve is a logical progression. Anchor links match the headings below.
1048-1052: The514-labs/query-layerrepository exists and is publicly accessible. The tiged command structure confirms thesrc/directory is present and accessible.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
Comment on lines
+1054
to
+1065
| <CopilotCallout | ||
| title="Copy Checkpoints as Copilot Prompt" | ||
| contentFile="/shared/guides/performant-dashboards/phase-3-checkpoints.mdx" | ||
| systemPrompt="You are helping me with Phase 3 (Serve) of an OLTP → ClickHouse migration. Goal: expose the serving table via the Query Layer while preserving the existing API contract. Work sequentially and stop after each checkpoint." | ||
| > | ||
| Attach the following files as context alongside the prompt: | ||
|
|
||
| ```bash | ||
| time curl -s -X POST http://localhost:4000/api/order-fulfillment \ | ||
| -H "Content-Type: application/json" \ | ||
| -d @test-case-heaviest.request.json | ||
| ``` | ||
| - `moosestack/context/dashboard-migration/<component>/` — the context directory (test cases, context map) | ||
| - `moosestack/app/models/<ServingTable>-mv.ts` — the serving table and MV file from Phase 2 | ||
| - Your existing backend endpoint handler that currently calls the OLTP or parity query (e.g. Express route, Fastify handler) | ||
| - `moosestack/query-layer/` — the Query Layer source copied in the step above | ||
| </CopilotCallout> |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, verify the file and line numbers
echo "=== Checking file existence and line count ==="
wc -l apps/framework-docs-v2/content/guides/performant-dashboards.mdx
echo -e "\n=== Reading Phase 1 CopilotCallout (around line 989) ==="
sed -n '985,1005p' apps/framework-docs-v2/content/guides/performant-dashboards.mdx
echo -e "\n=== Reading Phase 2 CopilotCallout (around line 1029) ==="
sed -n '1025,1045p' apps/framework-docs-v2/content/guides/performant-dashboards.mdx
echo -e "\n=== Reading Phase 3 CopilotCallout (lines 1054-1075) ==="
sed -n '1054,1075p' apps/framework-docs-v2/content/guides/performant-dashboards.mdxRepository: 514-labs/moosestack
Length of output: 4040
🏁 Script executed:
#!/bin/bash
# Find CopilotCallout component definition
echo "=== Searching for CopilotCallout component definition ==="
fd -e tsx -e ts | xargs rg -l 'CopilotCallout' | grep -v node_modules | head -10
echo -e "\n=== Looking for the component implementation ==="
rg -A 15 'export.*CopilotCallout|function CopilotCallout|const CopilotCallout' --type=tsx --type=ts | head -100Repository: 514-labs/moosestack
Length of output: 487
🏁 Script executed:
#!/bin/bash
# Search for all buttonLabel usages to understand the pattern
echo "=== All buttonLabel occurrences ==="
rg 'buttonLabel' --type=mdx --type=tsx --type=ts -n -C 1Repository: 514-labs/moosestack
Length of output: 143
🏁 Script executed:
#!/bin/bash
echo "=== CopilotCallout component implementation ==="
cat apps/framework-docs-v2/src/components/mdx/copilot-callout.tsxRepository: 514-labs/moosestack
Length of output: 2381
🏁 Script executed:
#!/bin/bash
echo "=== Checking all buttonLabel usages without type flags ==="
rg 'buttonLabel' -n -C 2 apps/framework-docs-v2/Repository: 514-labs/moosestack
Length of output: 2789
Phase 3 CopilotCallout lacks explicit buttonLabel prop.
Phases 1 and 2 explicitly pass buttonLabel="Copy Prompt", while Phase 3 omits it. Although the component has a default (buttonLabel = "Copy Prompt"), the inconsistency with the other phases should be resolved for documentation clarity.
Suggested fix
<CopilotCallout
title="Copy Checkpoints as Copilot Prompt"
contentFile="/shared/guides/performant-dashboards/phase-3-checkpoints.mdx"
systemPrompt="You are helping me with Phase 3 (Serve) of an OLTP → ClickHouse migration. Goal: expose the serving table via the Query Layer while preserving the existing API contract. Work sequentially and stop after each checkpoint."
+ buttonLabel="Copy Prompt"
>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| <CopilotCallout | |
| title="Copy Checkpoints as Copilot Prompt" | |
| contentFile="/shared/guides/performant-dashboards/phase-3-checkpoints.mdx" | |
| systemPrompt="You are helping me with Phase 3 (Serve) of an OLTP → ClickHouse migration. Goal: expose the serving table via the Query Layer while preserving the existing API contract. Work sequentially and stop after each checkpoint." | |
| > | |
| Attach the following files as context alongside the prompt: | |
| ```bash | |
| time curl -s -X POST http://localhost:4000/api/order-fulfillment \ | |
| -H "Content-Type: application/json" \ | |
| -d @test-case-heaviest.request.json | |
| ``` | |
| - `moosestack/context/dashboard-migration/<component>/` — the context directory (test cases, context map) | |
| - `moosestack/app/models/<ServingTable>-mv.ts` — the serving table and MV file from Phase 2 | |
| - Your existing backend endpoint handler that currently calls the OLTP or parity query (e.g. Express route, Fastify handler) | |
| - `moosestack/query-layer/` — the Query Layer source copied in the step above | |
| </CopilotCallout> | |
| <CopilotCallout | |
| title="Copy Checkpoints as Copilot Prompt" | |
| contentFile="/shared/guides/performant-dashboards/phase-3-checkpoints.mdx" | |
| systemPrompt="You are helping me with Phase 3 (Serve) of an OLTP → ClickHouse migration. Goal: expose the serving table via the Query Layer while preserving the existing API contract. Work sequentially and stop after each checkpoint." | |
| buttonLabel="Copy Prompt" | |
| > | |
| Attach the following files as context alongside the prompt: | |
| - `moosestack/context/dashboard-migration/<component>/` — the context directory (test cases, context map) | |
| - `moosestack/app/models/<ServingTable>-mv.ts` — the serving table and MV file from Phase 2 | |
| - Your existing backend endpoint handler that currently calls the OLTP or parity query (e.g. Express route, Fastify handler) | |
| - `moosestack/query-layer/` — the Query Layer source copied in the step above | |
| </CopilotCallout> |
🤖 Prompt for AI Agents
In `@apps/framework-docs-v2/content/guides/performant-dashboards.mdx` around lines
1054 - 1065, The CopilotCallout usage in Phase 3 omits the explicit buttonLabel
prop causing inconsistency with Phases 1 and 2; update the CopilotCallout
invocation (the JSX block named CopilotCallout) to include buttonLabel="Copy
Prompt" so the prop is explicitly passed (even though a default exists) to match
the other phases and improve documentation clarity.
Comment on lines
+1
to
+3
| import { defineQueryModel } from "./query-layer"; | ||
| import { OrderFulfillmentDaily } from "./order-fulfillment-daily-mv"; | ||
| import { sql } from "@514labs/moose-lib"; |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Import order: external dependencies first.
@514labs/moose-lib (external) should precede the local ./query-layer and ./order-fulfillment-daily-mv imports.
Proposed fix
-import { defineQueryModel } from "./query-layer";
-import { OrderFulfillmentDaily } from "./order-fulfillment-daily-mv";
-import { sql } from "@514labs/moose-lib";
+import { sql } from "@514labs/moose-lib";
+import { defineQueryModel } from "./query-layer";
+import { OrderFulfillmentDaily } from "./order-fulfillment-daily-mv";As per coding guidelines: Group imports by external dependencies, internal modules, and types.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| import { defineQueryModel } from "./query-layer"; | |
| import { OrderFulfillmentDaily } from "./order-fulfillment-daily-mv"; | |
| import { sql } from "@514labs/moose-lib"; | |
| import { sql } from "@514labs/moose-lib"; | |
| import { defineQueryModel } from "./query-layer"; | |
| import { OrderFulfillmentDaily } from "./order-fulfillment-daily-mv"; |
🤖 Prompt for AI Agents
In `@examples/dashboard-migration/example-order-fulfillment/code/query-model.ts`
around lines 1 - 3, Reorder the import statements in query-model.ts so external
modules come first: move the import of the external package sql from
"@514labs/moose-lib" above the local imports; keep the local imports of
defineQueryModel (from "./query-layer") and OrderFulfillmentDaily (from
"./order-fulfillment-daily-mv") after the external import. Ensure imports remain
grouped as external dependencies then internal modules and that symbols
defineQueryModel and OrderFulfillmentDaily are unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
Medium Risk
Adds new MDX preprocessing and a client clipboard component; incorrect tag matching or content injection could break MDX compilation/rendering for pages using
CopilotCallout, but impact is limited to docs.Overview
Updates the performant dashboards migration guide to be copilot-driven: replaces the long inline Phase 1–3 instructions with reusable checkpoint includes and embeds
CopilotCalloutblocks that copy ready-to-run prompts (plus explicit “what files to attach” context lists).Adds the new
CopilotCalloutMDX component and a build-time preprocessor (processCopilotPrompts) that injects referencedcontentFilemarkdown into arawContentprop so the client-side button can copy a cleaned prompt to the clipboard.Introduces new shared checkpoint MDX files for each migration phase and refreshes the
examples/dashboard-migrationstarter kit (context-map template + example order-fulfillment migration) to match the new workflow.Written by Cursor Bugbot for commit b7fceb9. This will update automatically on new commits. Configure here.