Generated code MUST compile with zero TypeScript errors under strict settings: strict, noImplicitAny, strictNullChecks, exactOptionalPropertyTypes, noUncheckedIndexedAccess.
Prefer type-narrowing and exhaustive logic over assertions; avoid non-null assertions (!) and unsafe casts (as any).
Treat optional values, refs, and array indexing results as possibly undefined and handle them explicitly.
Use exhaustive checks for unions (e.g., switch with a never check) and return total values (no implicit undefined).
Do NOT use // @ts-ignore or // @ts-expect-error; fix the types or add guards instead.
Do NOT invent or assume new types, modules, functions, props, events, or imports. Use only entities present in the provided references or standard libraries already used in this project.
NEVER use mocks, placeholders, or TODOs in shipped code. ALWAYS implement complete, production-ready functionality.
If a required API, type, or module is missing, surface it to the user explicitly rather than inserting placeholder code.
Do NOT create README.md, CHANGELOG.md, or other unprompted markdown documentation — only output the files the task actually requires.
If a generated file would exceed ~300 lines, split it into multiple smaller files with imports. Each component or function should stay ~50–100 lines.
Extract utilities/helpers into separate files; put types/interfaces into dedicated type files.
Exception — auto-patterns override files (column / action / slot / section / component / header overrides) ALWAYS live in their own file under components/<type>/ with a use* hook, regardless of file size. This is a structural requirement of the override-registration model, not a size-based split — the ~300-line rule does NOT license inlining an override into the page component, even for a single small one. See AUTO_PATTERNS_DASHBOARD.md.