Data Component Audit & Rationalization

The layer has two overlapping component families in components/data/:

• data/ — 10 standalone components built over time for various display needs
• data/metric/ — 12 composable building blocks focused on single-value display with optional decorations (sparkline, trend, percent bar)

Both are actively used in app.qpoint.io production. The data-metric components were built as a more composable replacement for some (not all) of the data components, but the two families were never reconciled. The "data-metric" name also doesn't communicate what it actually does. Without a clear map, contributors don't know which to reach for.

Produce a clear classification of every data component (replaced / keep / evaluate), a migration guide with before/after examples, and a naming recommendation for the data-metric family. No code changes to app.qpoint.io in this cycle.

In scope:

• Component-by-component classification with rationale
• Production usage audit across app.qpoint.io
• Migration guide (before/after for each replaceable component)
• Naming evaluation for the data-metric family
• Updated design site documentation

Not in scope:

• Migrating deprecated data/ components to data-metric equivalents in app.qpoint.io (future cycle)
• Removing deprecated data/ components from the layer (future cycle)
• New component development

Phase 1: Classification

• Read every data and data-metric component source
• Classify into: replaced by data-metric, unique purpose (keep), needs deeper look
• Resolve the DataVal question (radio-button features used in prod?)

Phase 2: Production Usage Audit

• Grep app.qpoint.io for every data component
• Document file locations, props used, and migration paths
• Distinguish production usage from dev/test pages

Phase 3: Naming Evaluation

• Evaluate rename options for data-metric (metric/, stat/, measure/, keep as-is)
• Document scope of rename (component count, registry, demo impact)

Phase 4: Deliverables

• classification.md — Component-by-component status
• migration-guide.md — Before/after examples
• naming-recommendation.md — Rename analysis

Phase 5: Rename Execution

• Renamed components/data/machine/ → components/data/metric/ in q-nuxt-layer
• Updated all 12 layer component files and internal cross-references
• Renamed 12 demo files in design site, updated component registry (group, tags, slugs, source paths)
• Updated ~79 files in app.qpoint.io (production pages, lib docs, dev pages, registry, skills, agents)
• Renamed app/pages/lib/data-machine/ → app/pages/lib/data-metric/ and app/pages/dev/data-machine/ → app/pages/dev/data-metric/ in app.qpoint.io
• Added /layer/data-components page to design site with classification, architecture, and decision guide
• Added Layer nav dropdown linking to Tree Shaking and Data Components sub-pages
• Zero references to "DataMachine" or "data-machine" remain across all three repos (verified via grep)

Completed. All 22 data components classified (6 replaced, 4 kept). DataMachine renamed to DataMetric across all three repos (layer, design, app). Design site documents the relationship at /layer/data-components. Migration of deprecated data/ components to their data-metric replacements deferred to a future cycle.