Canary Refactor Analysis

Decision (2026-03-19): canary-refactor/ contents are not resolved during the component consolidation. Neither branch’s version is canonical. The directory is adapted as a follow-on task after consolidated components are in place, serving as an integration test for the consolidated library.

What is canary-refactor/?

src/canary-refactor/ contains copies of selected stories from dev-witness/, ported to use components under src/components/canary/ instead of vendored components. The goal is to maintain high-level visual and behavioral equivalence with the original vendored pages — not pixel-identical, but faithful.

It is a validation harness, not a deliverable. Its purpose is to prove that the canary component library can reproduce the functionality of the vendored application pages.

Current State

Both branches modified canary-refactor/ files:

File	Main Clone	Worktree
components/ItemsPage.tsx	Large monolithic page	-2817 lines (major reduction)
components/ItemDetailsPanel.tsx	Present	Deleted
components/ItemTableAGGrid.tsx	Not present	Added
components/columnPresets.tsx	Not present	Added
components/ItemDetailPage.tsx	Present	Modified
reference/items/item-detail.stories.tsx	Present	Modified
reference/items/items-grid.stories.tsx	Present	Modified

The worktree version likely delegates to callil’s new organisms (item-grid, item-details, app-header) rather than implementing everything inline. The main clone version uses the entity-data-grid factory and cell atoms from the jmpicnic branch.

Neither version will survive as-is. Both were written against their respective branch’s component APIs, which will change during consolidation.

Consolidation Strategy

canary-refactor/ is excluded from the component consolidation scope. It becomes a follow-on task that:

1. Depends on the component consolidation being complete (all canary atoms, molecules, organisms in their final locations with final APIs).
2. Serves as an integration test — adapting the stories to consolidated components will surface gaps, API mismatches, and missing capabilities.
3. May trigger changes to the consolidated components themselves until enough convergence is achieved between the canary renderings and the original vendored pages.

Deferred Sub-Tasks

To be captured when planning the canary-refactor adaptation task:

• ItemDetailsPanel.tsx: Determine if its functionality was absorbed into the item-details organism or needs recreation against the consolidated API.
• ItemTableAGGrid.tsx and columnPresets.tsx: Determine if these extracted pieces are still needed or were superseded by the consolidated item-grid / entity-data-grid integration.
• Adapt all stories: Port each story to use the consolidated canary components, verifying visual and behavioral equivalence against the dev-witness originals.
• Feedback loop: Use divergences found during adaptation to drive fixes back into the consolidated component library.