Unified Component Pantry

The q-nuxt-layer already contains domain-specific components (security/, alert/, data-metric/) alongside generic primitives. The instinct to "keep it pure" doesn't hold up: Nuxt tree-shakes aggressively, so unused components cost nothing at runtime. The real value is a common pantry — stock ingredients and tools once, any current or future project can use them without an extraction cycle.

app.qpoint.io's local DevCanvas system (/pages/dev/components/, /pages/lib/) is an older fork that should consume the layer's DevCanvas directly.

1. Codify the "unified pantry" architecture decision — all visual components live in the layer regardless of how many projects currently use them
2. analyze qpp.qpoint.io's /dev and /lib examples.

• if there are examples of component usage that now exists in q-layer, note it as potential for moving to our component documentation page

3. Upgrade app.qpoint.io's DevCanvas to use the layer's versions (delete local forks)

1. Codify the architecture decision

• Update brand/component_philosophy.md — revise the boundary guidance to reflect the pantry model
• Update CLAUDE.md in both layer and design projects
• The boundary test becomes: "Is this a visual/presentational component?" → layer. "Is this business logic wired to app state/APIs?" → stays local in the consuming project.

2. Upgrade app's DevCanvas

App registers ~/pages/dev/components with prefix: 'dev' in nuxt.config.ts (line 73). Local forks override the layer's versions via Nuxt's component priority. Deleting the forks lets the layer versions take over automatically.

Delete 6 files (duplicates of layer):

• app.qpoint.io/app/pages/dev/components/Canvas.vue → layer's DevCanvas
• app.qpoint.io/app/pages/dev/components/Comment.vue → layer's DevComment
• app.qpoint.io/app/pages/dev/components/Frame.vue → layer's DevFrame
• app.qpoint.io/app/pages/dev/components/H.vue → layer's DevH
• app.qpoint.io/app/pages/dev/components/Label.vue → layer's DevLabel
• app.qpoint.io/app/pages/dev/components/_meta/PropsMachine.vue → layer's DevMetaPropsMachine

Keep (app-specific, no layer equivalent):

• NavItems.vue, NavSection.vue, TopNav.vue — dev section navigation
• README.txt, mock/ — documentation and mock data

API is identical between local and layer versions (same props, same v-model pattern). Only difference is visual styling — layer versions have dark theme and polished CSS.

Verify: /pages/lib/ and /pages/dev/ demos render correctly with layer versions

• Updated brand/component_philosophy.md — "Component scope" section rewritten as "unified pantry" model with clear boundary tests
• Updated CLAUDE.md in both design and q-nuxt-layer projects
• Deleted 6 local DevCanvas fork files from app.qpoint.io (Canvas, Comment, Frame, H, Label, _meta/PropsMachine)
• Verified 857+ component usages in app's lib/dev pages will resolve correctly from layer

Layer is the single pantry for all Qpoint visual components. App's DevCanvas uses layer versions. Architecture decision is documented and codified. 46 app lib demos identified as candidates for design site component documentation.

Layer (the pantry): All visual/presentational components — generic or domain-specific. Buttons, inputs, security cards, data-metric stats, sentence builders, prose blocks. If it renders UI, it belongs here.

Local to consumer: Components wired to app state, API calls, stores, or routing. Filters that call useTrafficQuery(), pages that fetch from Firestore, layouts tied to auth state. If it has side effects beyond its own props/emits, it stays local.

• Tarball friction for types/production builds. Local dev is already fast via NUXT_LOCAL_LAYER env var (direct path to ../q-nuxt-layer). The remaining tarball rebuild is only needed for TS type resolution and production builds — a narrow cost that doesn't block this cycle. Revisit later if it becomes painful (GitHub Packages, TS path aliases).

Scanned 101 lib demo files across 10 categories. Found 857+ usages of Dev components.

46 components (45%) already exist in the layer — candidates for design site documentation:

• data-metric: 100% coverage — all 11 demos (Background, Base, Compact, Date, InlineTrend, Label, PercentBar, Simple, Spark, TinyInline, Trend, Value)
• ux: 23 of 52 demos (Button, Toggle, Checkbox, Input, Modal, SimpleSelect, Tag, TagInput, ToggleCard, IconBtn, Avatar, BoxTag, Close, CopyBtn, DangerDelete, HelpText, HoverBox, LabelText, Link, ListItem, Message, AddBtn, StretchBox)
• data: 8 of 9 demos (Stat, Timeline, TrendDirection, Val, KeyVal, ChartUI, PercentBar, SparkChart)
• form: 4 of 6 demos (BigHeader, SmallHeader, Wrapper, SaveBar)

55 components (55%) are app-local — wired to app state/APIs, should stay:

• filter (8), health (5), wizard (5), page (2), task (2) — all domain-specific
• 29 app-specific ux variants (navigation, specialized buttons, code editors, etc.)

• Should app's /pages/lib/ demos be formalized with the same registry pattern as the design site?
• Does the design site document ALL layer components (including domain), or only shared ones?