{
  "active": true,
  "iteration": 2,
  "minIterations": 1,
  "maxIterations": 0,
  "completionPromise": "COMPLETE",
  "tasksMode": false,
  "taskPromise": "READY_FOR_NEXT_TASK",
  "prompt": "# Ralph Wiggum Loop - Iteration Prompt\r\n\r\nYou 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.\r\n\r\nYou 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.\r\n\r\n**The Concept:**\r\nThe \"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.).\r\n\r\n**IMPORTANT — Sidebar Label Convention:**\r\nThe sidebar uses CV-intuitive labels, NOT clinical jargon. But each view's content is presented in the clinical format:\r\n- **Summary** → Patient summary layout\r\n- **Experience** (not \"Consultations\") → Consultation journal layout with History/Examination/Plan\r\n- **Skills** (not \"Medications\") → Medications table layout with dosages/frequency\r\n- **Achievements** (not \"Problems\") → Problems list layout with traffic lights\r\n- **Projects** (not \"Investigations\") → Investigation results layout\r\n- **Education** (not \"Documents\") → Attached documents layout\r\n- **Contact** (not \"Referrals\") → Referral form layout\r\n\r\n## Your Task This Iteration\r\n\r\n1. **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.\r\n\r\n2. **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.\r\n\r\n3. **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.\r\n\r\n4. **Read guardrails**: Open `guardrails.md` and read ALL guardrails. These are hard rules you MUST follow. Key guardrails include:\r\n   - Light-mode only (clinical systems don't have dark mode)\r\n   - Instant view switching (no animations between views)\r\n   - Proper semantic table markup for all data tables\r\n   - Traffic lights must always have text labels\r\n   - Exact NHS blue color (#005EB8)\r\n   - ECG must end with flatline (not fade to white)\r\n   - Login typing animation specifics\r\n   - Consultation History/Examination/Plan format\r\n   - Coded entries in [XXX000] format\r\n   - Sidebar labels are CV-friendly (Experience, Skills, etc.), NOT clinical jargon\r\n\r\n5. **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.\r\n\r\n6. **Run quality checks**: Execute the quality check commands listed in `IMPLEMENTATION_PLAN.md` under \"Quality Checks\". Fix any issues before proceeding.\r\n\r\n7. **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 Claude in Chrome browser tools:\r\n   a. Call `tabs_context_mcp` to get available tabs (create if empty).\r\n   b. Navigate to `http://localhost:5173` (dev server runs throughout the loop).\r\n   c. **First load only**: The app plays a boot→ECG→login→PMR sequence (~15s). Use `computer` with `action: \"wait\", duration: 15` then take a screenshot. On subsequent navigations in the same tab, the app stays in PMR phase — no waiting needed.\r\n   d. Navigate to the hash route for your task's view:\r\n      - Task 1b (Boot/ECG): Refresh page, screenshot during boot sequence, then again during ECG animation\r\n      - Task 2 (Login): Refresh page, wait ~8s (after boot+ECG), screenshot the login screen\r\n      - Task 3 (Banner): Any PMR view — review the patient banner at top\r\n      - Task 4 (Sidebar): Any PMR view — review left sidebar\r\n      - Task 5 (Layout/Breadcrumb): Any PMR view — review overall composition\r\n      - Task 6: `#summary` | Task 7: `#experience` | Task 8: `#skills`\r\n      - Task 9: `#achievements` | Task 10: `#projects` then `#education` | Task 11: `#contact`\r\n   e. Take a screenshot (`computer` with `action: \"screenshot\"`) and compare against your reference file.\r\n   f. 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`.\r\n   g. If discrepancies are found: fix them, re-run quality checks, take another screenshot to confirm.\r\n   h. Note the visual review outcome in your progress.txt entry (step 10).\r\n\r\n8. **Commit your changes**: Stage and commit all changes with a descriptive message referencing the task you completed.\r\n\r\n9. **Mark the item complete**: In `IMPLEMENTATION_PLAN.md`, change the item from `- [ ]` to `- [x]`.\r\n\r\n10. **Update progress.txt**: Append to the \"Iteration Log\" section with:\r\n   - Which task you completed\r\n   - Any learnings or codebase patterns discovered (add to \"Codebase Patterns\" section)\r\n   - Any issues encountered\r\n   - Design decisions made (if visual component)\r\n   - Visual review outcome (what was checked, any fixes made)\r\n\r\n11. **Commit the progress update**: Stage and commit the updated `IMPLEMENTATION_PLAN.md` and `progress.txt`.\r\n\r\n12. **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:\r\n\r\n    ```\r\n    <next-model>sonnet</next-model>\r\n    ```\r\n\r\n    or\r\n\r\n    ```\r\n    <next-model>opus</next-model>\r\n    ```\r\n\r\n    **Use this decision framework:**\r\n    - **Use `sonnet`** for: configuration tasks, search/utility implementation, responsive fixes, accessibility audits, tasks with very prescriptive specs, tasks that are mostly wiring/plumbing\r\n    - **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\r\n    - **Default to `sonnet`** if unsure — it's cheaper and handles well-specified tasks fine\r\n    - If there IS no next task (you just completed the last one), skip this step\r\n\r\n13. **Determine if another iteration is needed**: Review your work and the codebase. The project needs another iteration if ANY of these are true:\r\n    - Any task in the checklist is unchecked (`- [ ]`) or blocked (`- [B]`)\r\n    - Quality checks would fail (run them to verify)\r\n    - There are uncommitted changes\r\n    - progress.txt has open questions or guidance for \"next iteration\"\r\n    - The implementation doesn't fully satisfy the plan requirements\r\n    - You have lingering doubts about correctness or completeness\r\n\r\n14. **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:\r\n\r\n    ```\r\n    <promise>COMPLETE</promise>\r\n    ```\r\n\r\n    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.\r\n\r\n## Critical Rules\r\n\r\n- **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)\r\n- **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.\r\n- **ALWAYS visually review visual components (Tasks 1b-11) in the browser** — use Claude in Chrome tools to screenshot and verify against the spec before committing\r\n- **Only work on ONE task per iteration**\r\n- **Always read progress.txt AND guardrails.md before starting** — previous iterations may have left important context\r\n- **If a task is blocked or unclear**, document why in progress.txt and move to the next unchecked item\r\n- **Keep commits atomic and well-described**\r\n- **If quality checks fail, fix the issues before committing**\r\n- **The visual quality bar is HIGH** — this must look like real clinical software\r\n- **Preserve clinical system authenticity** — instant navigation, proper tables, NHS blue, coded entries, traffic lights\r\n- **Sidebar labels are CV-friendly** — Experience (not Consultations), Skills (not Medications), etc.\r\n- **Use TypeScript strictly** — no `any` types, proper interfaces for all PMR data structures\r\n- **Follow the established project structure** — components in `src/components/`, data in `src/data/`, types in `src/types/`\r\n- **Respect prefers-reduced-motion** — animations must have instant fallbacks\r\n\r\n## Reference Files\r\n\r\nEach task in the implementation plan references specific files in `Ralph/refs/`:\r\n- `Ralph/refs/ref-boot-ecg.md` — Boot sequence + ECG animation improvements\r\n- `Ralph/refs/ref-design-system.md` — Colors, typography, spacing, borders, motion\r\n- `Ralph/refs/ref-transition-login.md` — ECG flatline + login sequence\r\n- `Ralph/refs/ref-banner-sidebar.md` — Patient banner + sidebar + navigation\r\n- `Ralph/refs/ref-summary-alert.md` — Summary view + clinical alert\r\n- `Ralph/refs/ref-consultations.md` — Experience view (consultation journal layout)\r\n- `Ralph/refs/ref-medications.md` — Skills view (medications table layout)\r\n- `Ralph/refs/ref-problems.md` — Achievements view (problems list layout)\r\n- `Ralph/refs/ref-investigations-documents.md` — Projects + Education views\r\n- `Ralph/refs/ref-referrals.md` — Contact view (referral form layout)\r\n- `Ralph/refs/ref-interactions.md` — Interactions, responsive, accessibility\r\n- `References/CV_v4.md` — Source CV content (roles, achievements, numbers, dates)\r\n\r\nRead ONLY the referenced file(s) for each task. Do NOT read goal.md directly.\r\n\r\n## Design Document Highlights\r\n\r\n**Color Palette (Light-mode only):**\r\n- Main content: `#F5F7FA`\r\n- Cards: `#FFFFFF`\r\n- Sidebar: `#1E293B`\r\n- NHS blue: `#005EB8`\r\n- Green (active): `#22C55E`\r\n- Amber (alerts): `#F59E0B`\r\n\r\n**Typography:**\r\n- Inter for general text\r\n- Geist Mono for coded entries and data values\r\n\r\n**Key Interactions:**\r\n- Login sequence: typing username/password character-by-character\r\n- Clinical alert: slides down, acknowledges with checkmark → collapse\r\n- Consultation entries: expand/collapse with History/Examination/Plan\r\n- Medications table: sortable columns, expandable prescribing history\r\n- Sidebar: instant view switching, no animations\r\n\r\n**Responsive Strategy:**\r\n- Desktop (>1024px): 220px sidebar with labels\r\n- Tablet (768-1024px): 56px icon-only sidebar\r\n- Mobile (<768px): Bottom navigation bar\r\n",
  "startedAt": "2026-02-11T22:50:12.180Z",
  "model": "openrouter/moonshotai/kimi-k2.5",
  "agent": "opencode"
}