# Ralph Wiggum Loop - Iteration Prompt

You are operating inside an automated loop. Each iteration you receive fresh context - you have NO memory of previous iterations. Your only persistence is the filesystem.

You are implementing **Design 7: The Clinical Record** — a Patient Medical Record (PMR) system that presents Andy's CV as a clinician would view a patient record. This is a visual redesign rebuilding existing components to achieve absolute thematic fidelity to real NHS clinical software.

**The Concept:**
The "patient" is Andy's career. Users navigate a genuine NHS clinical software interface (similar to EMIS Web, SystmOne, Vision) with a patient banner, sidebar navigation, consultation journal, medications table, clinical alerts, and a login sequence. The clinical metaphor lives in the LAYOUT and VISUAL PRESENTATION — the sidebar labels use CV-friendly terms (Experience, Skills, Achievements, Projects, Education, Contact) while each view is laid out like its clinical equivalent (consultation journal, medications table, problems list, etc.).

**IMPORTANT — Sidebar Label Convention:**
The sidebar uses CV-intuitive labels, NOT clinical jargon. But each view's content is presented in the clinical format:
- **Summary** → Patient summary layout
- **Experience** (not "Consultations") → Consultation journal layout with History/Examination/Plan
- **Skills** (not "Medications") → Medications table layout with dosages/frequency
- **Achievements** (not "Problems") → Problems list layout with traffic lights
- **Projects** (not "Investigations") → Investigation results layout
- **Education** (not "Documents") → Attached documents layout
- **Contact** (not "Referrals") → Referral form layout

## Your Task This Iteration

1. **Read the Design Guidance in the reference file** (REQUIRED for visual components): Each reference file in `Ralph/refs/` contains a "Design Guidance (from /frontend-design)" section at the bottom with pre-generated design direction, code patterns, and implementation details. You MUST read this section before writing code — it provides the aesthetic direction and code examples for the component. Do NOT invoke the `/frontend-design` skill at runtime — the guidance is already embedded in the ref files.

2. **Read the plan**: Open `IMPLEMENTATION_PLAN.md` and find the highest-priority unchecked item (`- [ ]`). Items are listed in priority order - pick the first unchecked one.

3. **Read accumulated learnings**: Open `progress.txt` and read the "Codebase Patterns" section. This contains learnings from previous iterations about PMR design system, data architecture, animation approach, and clinical system authenticity.

4. **Read guardrails**: Open `guardrails.md` and read ALL guardrails. These are hard rules you MUST follow. Key guardrails include:
   - Light-mode only (clinical systems don't have dark mode)
   - Instant view switching (no animations between views)
   - Proper semantic table markup for all data tables
   - Traffic lights must always have text labels
   - Exact NHS blue color (#005EB8)
   - ECG must end with flatline (not fade to white)
   - Login typing animation specifics
   - Consultation History/Examination/Plan format
   - Coded entries in [XXX000] format
   - Sidebar labels are CV-friendly (Experience, Skills, etc.), NOT clinical jargon

5. **Implement the item**: Complete the single task you selected. Keep changes focused - one task per iteration. Write production-quality React/TypeScript code that faithfully reproduces a clinical information system. This is a design showcase requiring absolute thematic fidelity.

6. **Run quality checks**: Execute the quality check commands listed in `IMPLEMENTATION_PLAN.md` under "Quality Checks". Fix any issues before proceeding.

7. **Visual Review** (Tasks 1b-11 only — skip for non-visual tasks like Task 1, 12-15): After quality checks pass, verify your work visually in the browser using the Playwright MCP browser tools:
   a. Navigate to `http://localhost:5173` using `mcp__playwright__browser_navigate`.
   b. **First load only**: The app plays a boot→ECG→login→PMR sequence (~15s). Use `mcp__playwright__browser_wait_for` with `time: 15` then take a snapshot. On subsequent navigations, the app stays in PMR phase — no waiting needed.
   c. Navigate to the hash route for your task's view:
      - Task 1b (Boot/ECG): Refresh page, screenshot during boot sequence, then again during ECG animation
      - Task 2 (Login): Refresh page, wait ~8s (after boot+ECG), screenshot the login screen
      - Task 3 (Banner): Any PMR view — review the patient banner at top
      - Task 4 (Sidebar): Any PMR view — review left sidebar
      - Task 5 (Layout/Breadcrumb): Any PMR view — review overall composition
      - Task 6: `#summary` | Task 7: `#experience` | Task 8: `#skills`
      - Task 9: `#achievements` | Task 10: `#projects` then `#education` | Task 11: `#contact`
   d. Use `mcp__playwright__browser_snapshot` (accessibility tree) or `mcp__playwright__browser_take_screenshot` (visual) to capture the page, and compare against your reference file.
   e. Check specifically: colors match spec, correct font (Inter vs Geist Mono), proper spacing, `1px solid #E5E7EB` borders, 4px border-radius, layout alignment, NHS blue `#005EB8`.
   f. If discrepancies are found: fix them, re-run quality checks, take another screenshot to confirm.
   g. Note the visual review outcome in your progress.txt entry (step 10).

8. **Commit your changes**: Stage and commit all changes with a descriptive message referencing the task you completed.

9. **Mark the item complete**: In `IMPLEMENTATION_PLAN.md`, change the item from `- [ ]` to `- [x]`.

10. **Update progress.txt**: Append to the "Iteration Log" section with:
   - Which task you completed
   - Any learnings or codebase patterns discovered (add to "Codebase Patterns" section)
   - Any issues encountered
   - Design decisions made (if visual component)
   - Visual review outcome (what was checked, any fixes made)

11. **Commit the progress update**: Stage and commit the updated `IMPLEMENTATION_PLAN.md` and `progress.txt`.

12. **Recommend model for next iteration**: Look at the NEXT unchecked task in `IMPLEMENTATION_PLAN.md` (the one after the task you just completed). Assess its complexity and output a model recommendation on its own line:

    ```
    <next-model>sonnet</next-model>
    ```

    or

    ```
    <next-model>opus</next-model>
    ```

    **Use this decision framework:**
    - **Use `sonnet`** for: configuration tasks, search/utility implementation, responsive fixes, accessibility audits, tasks with very prescriptive specs, tasks that are mostly wiring/plumbing
    - **Use `opus`** for: visual component rebuilds that invoke /frontend-design (design quality matters), complex animation work, tasks requiring strong aesthetic judgment, tasks where the previous iteration left issues that need creative problem-solving
    - **Default to `sonnet`** if unsure — it's cheaper and handles well-specified tasks fine
    - If there IS no next task (you just completed the last one), skip this step

13. **Determine if another iteration is needed**: Review your work and the codebase. The project needs another iteration if ANY of these are true:
    - Any task in the checklist is unchecked (`- [ ]`) or blocked (`- [B]`)
    - Quality checks would fail (run them to verify)
    - There are uncommitted changes
    - progress.txt has open questions or guidance for "next iteration"
    - The implementation doesn't fully satisfy the plan requirements
    - You have lingering doubts about correctness or completeness

14. **Send completion signal ONLY if truly complete**: If and ONLY if the project definitely does NOT need another iteration — all tasks verified done, quality checks pass, no guidance for next iteration — output this exact signal on its own line:

    ```
    <promise>COMPLETE</promise>
    ```

    DO NOT output this string if there's any chance another iteration is needed. When in doubt, do NOT send the promise — leave it for the next iteration to determine.

## Critical Rules

- **ALWAYS read the "Design Guidance" section in the ref file before writing visual component code** — do NOT invoke /frontend-design at runtime (it's pre-baked into the ref files)
- **Do NOT invoke the /frontend-design skill** — the design guidance is already embedded in each ref file. Invoking it at runtime will consume your context and stall the iteration.
- **ALWAYS visually review visual components (Tasks 1b-11) in the browser** — use Playwright MCP tools to screenshot and verify against the spec before committing
- **Only work on ONE task per iteration**
- **Always read progress.txt AND guardrails.md before starting** — previous iterations may have left important context
- **If a task is blocked or unclear**, document why in progress.txt and move to the next unchecked item
- **Keep commits atomic and well-described**
- **If quality checks fail, fix the issues before committing**
- **The visual quality bar is HIGH** — this must look like real clinical software
- **Preserve clinical system authenticity** — instant navigation, proper tables, NHS blue, coded entries, traffic lights
- **Sidebar labels are CV-friendly** — Experience (not Consultations), Skills (not Medications), etc.
- **Use TypeScript strictly** — no `any` types, proper interfaces for all PMR data structures
- **Follow the established project structure** — components in `src/components/`, data in `src/data/`, types in `src/types/`
- **Respect prefers-reduced-motion** — animations must have instant fallbacks

## Reference Files

Each task in the implementation plan references specific files in `Ralph/refs/`:
- `Ralph/refs/ref-boot-ecg.md` — Boot sequence + ECG animation improvements
- `Ralph/refs/ref-design-system.md` — Colors, typography, spacing, borders, motion
- `Ralph/refs/ref-transition-login.md` — ECG flatline + login sequence
- `Ralph/refs/ref-banner-sidebar.md` — Patient banner + sidebar + navigation
- `Ralph/refs/ref-summary-alert.md` — Summary view + clinical alert
- `Ralph/refs/ref-consultations.md` — Experience view (consultation journal layout)
- `Ralph/refs/ref-medications.md` — Skills view (medications table layout)
- `Ralph/refs/ref-problems.md` — Achievements view (problems list layout)
- `Ralph/refs/ref-investigations-documents.md` — Projects + Education views
- `Ralph/refs/ref-referrals.md` — Contact view (referral form layout)
- `Ralph/refs/ref-interactions.md` — Interactions, responsive, accessibility
- `References/CV_v4.md` — Source CV content (roles, achievements, numbers, dates)

Read ONLY the referenced file(s) for each task. Do NOT read goal.md directly.

## Design Document Highlights

**Color Palette (Light-mode only):**
- Main content: `#F5F7FA`
- Cards: `#FFFFFF`
- Sidebar: `#1E293B`
- NHS blue: `#005EB8`
- Green (active): `#22C55E`
- Amber (alerts): `#F59E0B`

**Typography:**
- Inter for general text
- Geist Mono for coded entries and data values

**Key Interactions:**
- Login sequence: typing username/password character-by-character
- Clinical alert: slides down, acknowledges with checkmark → collapse
- Consultation entries: expand/collapse with History/Examination/Plan
- Medications table: sortable columns, expandable prescribing history
- Sidebar: instant view switching, no animations

**Responsive Strategy:**
- Desktop (>1024px): 220px sidebar with labels
- Tablet (768-1024px): 56px icon-only sidebar
- Mobile (<768px): Bottom navigation bar