richie/Parsons
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Archive FuneralFinder V1/V2, set V3 as production (D032)

Browse Source 
- V1 stories → Archive/FuneralFinder V1
- V2 stories → Archive/FuneralFinder V2
- V3 stories → Organisms/FuneralFinder (primary)
- Component registry updated (V3 = done, V1/V2 = archived)
- Retroactive review plan confirmed: P0/P1 only, interleaved (D033)
- CLAUDE.md: added proactive session startup review procedure
- Build skills updated with internal QA stages

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Richie
2026-03-27 21:22:06 +11:00
parent b9954464ba
commit 8a5a4dc128
7 changed files with 37 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/memory/decisions-log.md
View File

@@ -269,3 +269,19 @@ contradict a previous one.
**Rationale:** The codebase naturally evolved this dual-path pattern. Semantic tokens are mapped into the MUI theme by `src/theme/index.ts`, making `theme.palette.*` the idiomatic MUI access path. Component-tier tokens exist only as CSS variables (Style Dictionary output). Forcing all access through one path would either require mapping every component token into MUI (over-engineering) or abandoning MUI's type-safe theme accessors (losing DX).
**Affects:** All component files, `docs/conventions/component-conventions.md`, Badge.tsx (normalized to CSS vars for colour maps)
**Alternatives considered:** CSS vars only — rejected because it loses MUI's TypeScript-safe theme API. Theme accessors only — rejected because component tokens aren't in the MUI theme.
### D032 — FuneralFinder V3 is the production version
**Date:** 2026-03-27
**Category:** component
**Decision:** FuneralFinderV3 is the production widget. V1 and V2 are archived — their Storybook stories moved to `Archive/FuneralFinder V1` and `Archive/FuneralFinder V2`. Code remains in the repo for reference and client walkthroughs.
**Rationale:** User chose V3 after reviewing all three. V3 scored highest on usability (clean form, no sequential lock, always-active CTA) while maintaining audit/critique scores (18/20, 33/40). V1 and V2 must remain viewable for client presentations showing the design evolution.
**Affects:** FuneralFinder stories (title changes), component-registry (V3 = done, V1/V2 = archived), retroactive review (only V3 gets full treatment)
**Alternatives considered:** Deleting V1/V2 — rejected because user needs them for client walkthroughs.
### D033 — Retroactive review uses P0/P1 only, interleaved with new work
**Date:** 2026-03-27
**Category:** architecture
**Decision:** Existing components are reviewed using a condensed process (normalize → audit → fix P0/P1 only). Review runs as a proactive "morning housekeeping" pass at the start of each session (~30-60 min), then shifts to new component work.
**Rationale:** P0/P1 are the issues that affect usability and accessibility. P2/P3 are cosmetic — not worth the risk of changing approved components. Interleaving ensures the foundation is solid before building on it, without dedicating entire sessions to review.
**Affects:** Session workflow, CLAUDE.md startup procedure, docs/reference/retroactive-review-plan.md
**Alternatives considered:** Dedicated review sessions — rejected as less efficient. Full P0-P3 fixes — rejected as too risky for approved components.