Files
Parsons/docs/reference/retroactive-review-plan.md
Richie 87e596ddb2 Add component lifecycle + retroactive review plan
- docs/reference/component-lifecycle.md: 10-stage quality gate sequence
  (build → stories → audit/critique/harden → fix → polish → present →
  iterate → normalize → preflight → commit)
- docs/reference/retroactive-review-plan.md: Plan to review 30+ existing
  components using condensed process (~3.5 sessions)
- Updated /build-atom, /build-molecule, /build-organism to include
  internal QA stages automatically
- CLAUDE.md: added lifecycle reference as critical rule #8

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-27 16:49:48 +11:00

138 lines
5.2 KiB
Markdown

# 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)?