Parsons/docs/reference/retroactive-review-plan.md

Retroactive Review Plan

Components built before the workflow upgrade (2026-03-27) haven't been through the full quality gate lifecycle. This plan reviews them using a lighter process focused on catching real issues, not re-polishing what already works.

Approach

Use the condensed review process from component-lifecycle.md:

1. /normalize {tier} — Scan the tier for cross-component consistency
2. /audit {component} — Score each component (only those scoring < 16/20 need fixes)
3. Fix P0/P1 issues only
4. /preflight → commit

Priority Order

Review bottom-up: atoms first (they're the foundation everything builds on), then molecules, then organisms. Within each tier, prioritise by usage — components used by many others matter more than standalone ones.

---

Phase 1: Atoms (foundation layer — highest priority)

Step 1.1 — Normalize all atoms

Run /normalize atoms once to get a cross-component consistency report. Expected findings: token access patterns (D031), transition timing, focus styles. Fix all issues in a single batch commit.

Step 1.2 — Audit each atom

Run /audit on each atom. Components already audited in previous sessions have scores on record. Focus on those that scored < 16/20 or were never audited.

Atom	Last Audit Score	Priority
Button	— (not formally audited)	High (most-used atom)
Typography	—	Medium (display-only)
Input	—	High (forms foundation)
Card	—	High (used by all cards)
Badge	—	Medium (fixed in D031)
Chip	—	Low (minimal wrapper)
Switch	—	Low (minimal wrapper)
Radio	—	Low (minimal wrapper)
IconButton	—	Low (minimal wrapper)
Divider	—	Low (minimal wrapper)
Link	—	Low (minimal wrapper)

Estimated effort: 1 session for normalize + audit of high/medium priority atoms.

---

Phase 2: Molecules (composition layer)

Step 2.1 — Normalize all molecules

Run /normalize molecules for cross-component consistency.

Step 2.2 — Audit + critique priority molecules

Run /audit and /critique on molecules with real layout complexity.

Molecule	Last Scores	Priority
ProviderCard	Critique 33/40 (v2 iteration)	Medium (user-approved)
VenueCard	Critique 33/40	Medium (user-approved)
SearchBar	Critique 35/40	Low (high scores already)
ServiceOption	—	Medium (used by ServiceSelector)
AddOnOption	—	Medium (similar pattern to ServiceOption)
StepIndicator	—	Low (display-only)
LineItem	Audit 19/20	Low (excellent score)
ProviderCardCompact	—	Medium (newer, less reviewed)

Estimated effort: 1 session for normalize + audit of medium priority molecules.

---

Phase 3: Organisms (page-level compositions)

Step 3.1 — Normalize all organisms

Run /normalize organisms for cross-component consistency.

Step 3.2 — Full review of critical organisms

Organisms are the most complex and user-facing. Run /audit + /critique + /harden on each.

Organism	Last Scores	Priority
Navigation	—	High (site-wide, visible on every page)
Footer	Critique 38/40	Low (excellent score)
ServiceSelector	—	High (arrangement flow core)
PackageDetail	Audit 19/20	Low (excellent score)
FuneralFinder V1	Audit 14/20, Critique 29/40	Medium (pending production decision)
FuneralFinder V2	Audit 18/20, Critique 33/40	Medium (pending production decision)
FuneralFinder V3	Audit 18/20, Critique 33/40	Medium (pending production decision)

Note on FuneralFinder: All three versions exist. A production decision (v1 vs v2 vs v3) is still pending. Only review the chosen version in depth. The others can be archived or retained as alternatives.

Estimated effort: 1 session for normalize + audit/critique of Navigation + ServiceSelector.

---

Phase 4: Cross-cutting concerns

After individual components are clean:

1. Run /adapt on all organisms + ProviderCard/VenueCard (responsive check)
2. Run /typeset across a representative sample of each tier
3. Run /preflight to verify the full codebase
4. Commit all fixes

Estimated effort: 0.5 session.

---

Total estimated effort: ~3.5 sessions

Phase	Focus	Effort
1	Atoms normalize + audit	1 session
2	Molecules normalize + audit	1 session
3	Organisms normalize + audit/critique/harden	1 session
4	Cross-cutting (adapt, typeset, preflight)	0.5 session

This can be interleaved with new component work — e.g., review atoms in the morning, build a new molecule in the afternoon. The review findings often improve the patterns used in new components.

---

Decision needed from user

Before starting, confirm:

1. FuneralFinder version — Which version (v1/v2/v3) should get the full review? The others can be lightly maintained or archived.
2. Depth vs speed — Do we fix all P2 issues too, or strictly P0/P1 only? P0/P1 only is faster and doesn't risk changing things that already work.
3. Interleave with new work — Review in dedicated sessions, or mix with building remaining components (FormField, ArrangementForm, PricingTable)?