Lovable: 4-Chat Workflow Prompts

Pre-implementation review: {SPEC_ID}

Role:    Reviewer. Audit spec/plan/tasks against repo reality and produce a doc-fix plan for Chat 2 (WS-DOCS) to apply.
Mode:    Chat / Plan mode. STRICTLY READ-ONLY. Do NOT create or edit ANY file (no .ts, .tsx, .sql, or .md).
         If you feel the urge to call an edit tool, stop and put the change in the Doc Fix Plan instead.
Inputs:  Read these files:
         - specs/{core}/specs/{SPEC_ID}-*.md  (spec)
         - specs/{core}/plans/{SPEC_ID}-*-PLAN.md  (plan, if present)
         - specs/{core}/tasks/{SPEC_ID}-TASKS.md  (tasks)
         - specs/{core}/specs/{SPEC_ID}-CONTEXT.md  (or specs/{core}/ux/... if wizard, if present)
         - docs/architecture/integrations/{SPEC_ID}-*-INTEGRATION.md  (if present)
         - docs/architecture/integrations/CROSS_CORE_INTEGRATIONS.md  (find {SPEC_ID} row)
         - docs/architecture/integrations/EVENT_CONTRACTS.md  (find any {SPEC_ID} events)
         - src/cores/{core}/AGENTS.md  (module patterns + status)

Do (in order, do not skip):
1. Read all inputs. Note any missing files.
2. Validate the spec against constitution.md and SPEC_TEMPLATE.md. Flag missing required sections. Read the spec header `Status:` line — if it is `🚫 BLOCKED on <other-spec>`, halt the audit and note the blocker as the only finding.
3. Cross-reference integration docs: every consumer/publisher listed? RLS helpers (e.g. pf_has_org_access, pm_is_org_admin) exist in deployed migrations with matching signatures? Every FK target table exists in types.ts with matching column names?
4. Spec checklist — for each, mark Pass / Fail / N-A:
   - RLS: all CRUD policies present? UPDATE has WITH CHECK?
   - Security: PHI scoped? Secrets via env? sanitizeErrorMessage on all user-facing errors?
   - Permissions: permission keys defined? role mappings explicit?
   - Integration: cross-core touchpoints documented in CROSS_CORE / EVENT_CONTRACTS?
   - Data model: table category correct (Business / Transaction / Junction / Audit / Config)? required indexes listed?
   - Clinical (CL/PM only): codes use PF-70 (no hard-coded ICD/CPT)? encounter context via @/platform/scheduling?
   - Wizard ({CORE}-UX-## only): shell choice (DialogWizardShell / WizardShell / ModuleWizardRenderer) matches spec? every step has type + validation? draft persistence excludes PHI for CL? completion calls a documented mutation? no migration tasks unless schema work is genuinely required?
5. CONTEXT consistency: if CONTEXT.md exists, does the spec/tasks contradict any CONTEXT decision? Flag every contradiction.
6. Dependency block: if TASKS.md has a Phase 0 / Dependency Verification section, list each T0* check verbatim so Chat §2 Phase 0 can re-run it.

Output (use this exact format):

## Findings
| # | Finding | Severity (blocker/major/minor) | File / Section | Recommendation |
|---|---------|---|---|---|

## Blockers
- (one bullet per blocker; empty list = "None")

## Doc Fix Plan
For each fix that requires a spec/task/plan .md change:

### Fix N
- File: <path>
- Current:
  > <quote exact lines>
- Replacement:
  > <new lines>

## Escalations
- (architecture or governance concerns the user must decide; empty = "None")

## HANDOFF → Chat 2 — {SPEC_ID}
Wrap this in a fenced code block exactly:
```text
# HANDOFF → Chat 2 — {SPEC_ID}
- Spec: {SPEC_ID}
- Spec status: <Draft | In Progress | BLOCKED on X | Complete>
- Blockers: <count>
- Doc fixes to apply: <count>
- Phase 0 preflight checks: <list T0a/T0b/T0c verbatim, or "None">
- For next chat: §2 Plan + Execute
- Payload: <paste the entire Doc Fix Plan and Phase 0 list verbatim here>

---

## §2 Chat 2 — Plan + Execute

> **Mode:** **Default mode throughout.** Phase 0 = preflight (read-only checks); Phase A = plan + apply doc fixes (WS-DOCS); Phase B = execute remaining workstreams after `Confirm`.

```text
Plan + Execute: {SPEC_ID}

Role:    Implementer. Phase A = propose workstreams (no code). Phase B = execute after I confirm.
Mode:    Default mode for ALL phases. (Chat / Plan mode is read-only and cannot edit .md — that's why
         doc fixes are folded into WS-DOCS instead of run as a "Chat-mode pre-step".)
         Phase 0 = read-only preflight. Phase A = propose workstreams + apply WS-DOCS. Phase B = execute
         remaining workstreams ONLY AFTER I reply "Confirm".
Inputs:  - The HANDOFF block from Chat 1 (paste it as the first message of this chat if not already)
         - The Pre-Review Doc Fix Plan (in the handoff payload)
         - specs/{core}/specs/{SPEC_ID}-*.md
         - specs/{core}/tasks/{SPEC_ID}-TASKS.md
         - specs/{core}/specs/{SPEC_ID}-CONTEXT.md (if present — its decisions are pre-approved; flag conflicts, do not override)
         - src/cores/{core}/AGENTS.md

== PHASE 0 — PREFLIGHT (read-only, run once) ==

1. Re-run every Phase 0 / dependency check the Chat 1 handoff listed (e.g. T0a/T0b/T0c) using
   `rg`, file reads, and Supabase MCP read-only queries.
2. ALL PASS → continue to Phase A.
3. ANY FAIL → STOP and present the user with these THREE exit options, then wait for a reply:

   (a) FILE-AND-WAIT (default): output a one-paragraph dependency request the user can file
       against the blocking spec (e.g. FA-09). Mark this spec BLOCKED and stop.
   (b) DOC-ONLY: skip code workstreams; run WS-DOCS only; flip the spec header `Status:` to
       `🚫 BLOCKED on <spec>`; update TASKS.md header accordingly; stop.
   (c) SHIM-AND-PROCEED: author code with `(supabase as any)` casts and `.skip()` E2E tests,
       knowing runtime cannot work until the blocker ships. Discouraged — user must explicitly
       opt in by replying "Confirm shim".

   Default if user gives no answer = (b) DOC-ONLY.

== PHASE A — PLAN ==

Do:
1. WS-DOCS (always first, always Phase A): apply every Doc Fix Plan item from Chat 1 to the .md
   files now. This is the only code-touching work allowed before user "Confirm".
2. Propose remaining workstreams using the default 3 tracks:
   - WS-SCHEMA: migration + types.ts regen + permission seeding — INCLUDE ONLY IF spec adds
     tables/columns/permissions. Otherwise omit.
   - WS-APP: hooks + components + routes + breadcrumbs.
   - WS-VERIFY: tests + status updates.

   SPLIT RULE (numeric, no judgment calls):
   - Default = 3 workstreams (WS-DOCS + WS-APP + WS-VERIFY), or 4 if WS-SCHEMA applies.
   - Split a workstream ONLY IF its source-file count would exceed 8 OR it requires a types.ts
     regen between two file groups.
   - HARD CAP: 5 workstreams total. If you would need 6+, the spec is too large — STOP and
     tell the user to split it into two specs.
3. For each workstream output the table row below. Then ask the user to confirm.

Output for Phase A (use this exact format):

## Workstreams
| WS# | Goal | Files (exact paths) | Success criteria | Risk |
|-----|------|---------------------|------------------|------|
| WS-DOCS | Apply Doc Fix Plan | <list> | All .md edits applied; no code touched | Low |
| ...     | ...                | ...    | ...                                   | ... |

## CONTEXT decisions to honor
- (list of CONTEXT items relevant to execution; empty = "None")

## Phase 0 result
- ALL PASS / BLOCKED on <X> — exit chosen: <(a)/(b)/(c)>

Reply ends with the literal line:
STOP — PLAN READY — N workstreams. Awaiting "Confirm" or "Revise: <feedback>".

== PHASE B — EXECUTE ==

(Only after I reply "Confirm". Stay in Default mode.)

Do:
1. Execute workstreams in order. Do NOT stop between workstreams unless typecheck fails or you hit a blocker.
2. Schema workstream rules: after migration, regenerate types.ts via Supabase MCP; verify new tables appear in types.ts BEFORE writing hooks that reference them. If types.ts regen lags, use (supabase as any) with comment:
     // TODO: Remove (supabase as any) after types.ts regeneration
3. After each workstream, verify success criteria; if anything fails, stop and report instead of moving on.
4. After ALL workstreams: run typecheck mentally on touched files; report any remaining issues.

Output for Phase B (use this exact format):

## Execution Report
| WS# | Status (✅/⚠️/❌) | Files changed | Notes |
|-----|---|---|---|

## Deviations from plan
- (or "None")

## Known issues for Chat §3a
- (or "None")

## HANDOFF → Chat 3a — {SPEC_ID}
```text
# HANDOFF → Chat 3a — {SPEC_ID}
- Spec: {SPEC_ID}
- Workstreams: <count> executed, <count> blocked
- Files changed: <count>
- Known issues for verify: <bulleted list, or "None">
- For next chat: §3a Verify + Status
- Payload: <list of files changed grouped by workstream, plus any deviations>

---

## §3a Chat 3a — Post-Implementation Verify + Status Updates

> **Mode:** Default. No browser tools. Spec coverage + stub scan + the 5 mandatory status-file updates. The browser E2E moves to §3b so this chat doesn't time out.

```text
Post-implementation verify + status updates: {SPEC_ID}

Role:    Verifier. Confirm spec coverage, update status files. NO browser work in this chat.
Mode:    Default. May edit .md status files. No browser tools.
Inputs:  - The HANDOFF block from Chat 2 (paste as first message)
         - The {SPEC_ID} spec, plan, tasks, CONTEXT.md (if present), integration doc

Do:
1. Spec coverage: for every acceptance criterion and task, locate the implementing code. Flag any gap.
2. CONTEXT compliance (if CONTEXT.md exists): every CONTEXT decision implemented? Flag (a) decisions skipped, (b) implementation that contradicts CONTEXT, (c) deferred items accidentally implemented.
3. Schema/types check: every column referenced in code appears in types.ts? Flag mismatches.
4. Stub/placeholder scan — flag every instance of:
   - Components that return null or "Placeholder"
   - Empty event handlers, TODO/FIXME in new code
   - Buttons/links wired with no handler
   - Test files containing expect(true).toBe(true) or .skip
   - API responses with "Not implemented"
5. Update the 5 mandatory status files (mark each ✅ or note why skipped):
   - [ ] src/cores/{core}/AGENTS.md — status emoji + date
   - [ ] specs/{core}/tasks/{SPEC_ID}-TASKS.md — header to ✅ Complete (or 🚫 BLOCKED if Phase 0 failed)
   - [ ] docs/architecture/integrations/CROSS_CORE_INTEGRATIONS.md — {SPEC_ID} row to ✅
   - [ ] specs/{core}/IMPLEMENTATION_LOG.md — new entry with final column list
   - [ ] The spec file header itself

Output:

## Verification
- Spec coverage: ...
- CONTEXT compliance: ...
- Schema/types: ...
- Stub scan: ...

## Status updates
- [x] AGENTS.md
- [x] TASKS.md header
- [x] CROSS_CORE_INTEGRATIONS.md
- [x] IMPLEMENTATION_LOG.md
- [x] Spec header

## Must-fix surfaced (for §3b or this chat)
| Severity | Issue | Fix in this session? |
|---|---|---|

## HANDOFF → Chat 3b — {SPEC_ID}
```text
# HANDOFF → Chat 3b — {SPEC_ID}
- Spec: {SPEC_ID}
- Status files: 5/5 updated
- Must-fix open: <count>
- For next chat: §3b Browser E2E
- Payload: <list nav path, expected seed entity name, any feature-specific gates to verify>

---

## §3b Chat 3b — Browser E2E + Screenshots

> **Mode:** Default + browser tools. Seed → login → checklist → screenshots. This is the only chat that uses the browser tool.

```text
Browser E2E: {SPEC_ID}

Role:    Browser verifier. Seed test data, log in, run the E2E checklist, capture screenshots.
Mode:    Default + browser tools.
Inputs:  - The HANDOFF block from Chat 3a (paste as first message)
         - docs/testing/AI_BROWSER_TESTING.md (test credentials and login flow)

Do:
1. Seed via Supabase insert tool (NOT migrations): 3 rows scoped to an existing org/chart, named:
   Test-{SPEC_ID}-Normal, Test-{SPEC_ID}-Edge, Test-{SPEC_ID}-Empty
2. Open the preview. If at /auth, log in with credentials from docs/testing/AI_BROWSER_TESTING.md.
3. Navigate to the feature (use the nav, not direct URL paste, so breadcrumbs render).
4. Run this checklist; mark each ✅ / ⚠️ / ❌:
   - Data renders (list/detail show seeded rows)
   - Forms submit successfully
   - Permission gates block when user lacks the role (if applicable)
   - Loading uses <Skeleton />, not blank screen
   - Errors show sanitized text (never raw error.message)
   - Mobile viewport (~390px width): no broken layout, 44px touch targets
   - Wizard ({CORE}-UX-## only): happy path through final step; Back keeps required data; Next blocked on validation fail; draft resumes after close+reopen (if draft enabled); CL wizards — no PHI in draft payloads
5. Screenshot: empty state, loaded state, one error state if reproducible, mobile view.
6. Optional: read back from Supabase to confirm mutations persisted.

Output (use this exact format):

## Browser E2E
- Seeded: 3 rows (Normal/Edge/Empty)
- Login: ✅
- Checklist:
  - Data renders: ✅
  - Forms submit: ✅
  - Permission gate: ✅ / N-A
  - Skeleton loading: ✅
  - Sanitized errors: ✅
  - Mobile (390px): ✅
  - Wizard checks: ✅ / N-A
- Screenshots: <list>

## Must-fix vs Follow-up
| Severity | Issue | Fix in this session? |
|---|---|---|

Fix every "must-fix" in this session; defer "follow-up" with a TODO note in IMPLEMENTATION_LOG.md.

Stop when your reply ends with the literal line:
STOP — BROWSER E2E COMPLETE — N screenshots, K issues found.

Fix {SPEC_ID} defect: {one-line description}

Mode: Default. Apply the fix only — do not refactor neighboring code. After the fix:
- Confirm typecheck on touched files
- If UI changed, screenshot the affected view
Reply ends with: STOP — FIX DONE — {N} files changed.

The same error continues. Investigate before changing code. Examine: browser console, Supabase network tab, edge function logs, RLS policies, types.ts vs migrations. Report findings, then propose a single fix. Do not edit code yet.

Issue persists. Stop all edits. Map the full flow (auth → query → RLS → UI). For each step list expected vs actual. Identify root cause with evidence (logs/queries). Do not speculate; do not fix yet.

This blocker requires re-evaluating the whole flow. Halt edits. Outline auth, DB calls, integrations, state, redirects step by step. Pinpoint where reality diverges from intent. Deliver a written analysis before any code change.

List every console.log / console.warn in {area}. For each: keep, replace with sanitizeErrorMessage, or remove. Show the plan before editing.

Visual change only. Do NOT change logic, queries, or hooks. Use semantic tokens (no hardcoded Tailwind colors), standard dialog sizes (sm:max-w-md/lg/2xl/3xl/4xl), <PageContainer> for pages, mobile-first (44px touch targets). After the change: confirm functionality unchanged.

Audit responsiveness at standard Tailwind breakpoints (sm/md/lg/xl). Mobile-first; no custom breakpoints unless asked. List every issue with viewport width. Then fix.

Verify after UI change: semantic tokens (no hardcoded colors), <Skeleton /> loading, <EmptyState /> for empty, standard dialog sizes with sm: prefix, <PageContainer> wrapping page content. Flag violations.

Refactor {file/area} for clarity. UI and behavior must stay identical. Document existing behavior first; refactor in small steps; confirm typecheck after each. Pause if uncertain.

Mode: Chat Mode. Audit {area} for architecture cleanliness: misplaced files, separation of concerns, duplicate logic, missing platform abstractions. Output a prioritized table of recommendations. Do NOT edit code.

Confirm post-refactor: UI identical, behavior identical, no new typecheck errors, no regressions in related tests. Report any drift.