feat: build audit outreach review workspace

backlog/tasks/task-13 - Build-the-audit-and-outreach-review-workspace.md

@@ -4,7 +4,7 @@ title: Build the audit and outreach review workspace
 status: In Progress
 assignee: []
 created_date: '2026-06-03 19:14'
-updated_date: '2026-06-05 12:13'
+updated_date: '2026-06-05 14:21'
 labels:
   - mvp
   - review
@@ -26,20 +26,23 @@ Create the internal review workspace where Matthias can inspect and edit the fin
 
 ## Acceptance Criteria
 <!-- AC:BEGIN -->
-- [ ] #1 Review workspace shows lead details, contact sources, priority reason, contact strategy, audit summary, used skills, and raw/source detail toggles
-- [ ] #2 Audit content can be edited and manually approved before the public page shows customer-facing content
-- [ ] #3 Email subject and body are editable and generated as exactly one recommended version by default
-- [ ] #4 Phone script is available for Erst anrufen and Kontakt fehlt leads when a phone number exists
-- [ ] #5 Freigabe offen state clearly separates Audit veröffentlichen from E-Mail freigeben und senden
+- [x] #1 Review workspace shows lead details, contact sources, priority reason, contact strategy, audit summary, used skills, and raw/source detail toggles
+- [x] #2 Audit content can be edited and manually approved before the public page shows customer-facing content
+- [x] #3 Email subject and body are editable and generated as exactly one recommended version by default
+- [x] #4 Phone script is available for Erst anrufen and Kontakt fehlt leads when a phone number exists
+- [x] #5 Freigabe offen state clearly separates Audit veröffentlichen from E-Mail freigeben und senden
 <!-- AC:END -->
 
 ## Implementation Plan
 
 <!-- SECTION:PLAN:BEGIN -->
-1. Wire PageSpeed completion into audit_generation queue
-2. Verify handoff with regression tests
-3. Build review workspace UI and edit/approval flows
-4. Verify state transitions back into dashboard/funnel
+1. Orchestrator updates TASK-13 plan and coordinates only; no direct feature coding.
+2. Worker A (gpt-5.5 medium) uses TDD to add Convex outreach review contracts: listReviewWorkspace, saveReviewDraft, approveEmailDraft.
+3. Worker B (gpt-5.5 medium) uses TDD to replace /dashboard/outreach placeholder with the review workspace UI using the new contracts.
+4. Worker C (gpt-5.5 medium) uses TDD to separate Audit veröffentlichen from E-Mail freigeben and keep sending out of TASK-13.
+5. Worker D (gpt-5.5 medium) uses TDD to cover phone-script visibility and funnel/review state regressions.
+6. Spec and code-quality reviewer agents review each worker output before the next dependent slice proceeds.
+7. Orchestrator runs final verification: pnpm test, pnpm exec tsc --noEmit, pnpm lint, pnpm build; then updates Backlog notes and checked ACs without marking Done.
 <!-- SECTION:PLAN:END -->
 
 ## Implementation Notes
@@ -48,4 +51,8 @@ Create the internal review workspace where Matthias can inspect and edit the fin
 Starting TASK-13 with the missing PageSpeed-to-audit-generation handoff so generated audit content exists for the review workspace.
 
 Implemented first TASK-13 prerequisite: PageSpeed completion now queues audit_generation for the same lead via internal.auditGeneration.queueLeadAuditGeneration. Queue failures are logged as warnings and do not fail the PageSpeed run. Verified with pnpm test (245/245), pnpm exec tsc --noEmit, pnpm lint (0 errors, existing generated warnings), and pnpm build using .env.local.
+
+2026-06-05: Expanded TASK-13 into subagent-driven, test-driven execution plan on branch codex-task-13-review-workspace. Orchestrator will not hand-code feature patches; workers use gpt-5.5 medium and RED/GREEN tests.
+
+2026-06-05: Completed TASK-13 implementation subagent-driven and test-driven on branch codex-task-13-review-workspace. Worker A added authenticated Convex review workspace contracts, save/approve draft mutations, protected existing outreach create/list, audit ownership checks, sent-record protection, approval reset on regenerated copy, and combined review eligibility indexes. Worker B replaced /dashboard/outreach placeholder with the review workspace UI, editable audit/outreach drafts, raw/source toggles, used skills, phone-script gating, and save-before-approve/publish safeguards. Worker C fixed funnel regression so approved-but-unsent outreach remains in Freigabe offen. Reviews: backend spec approved, backend quality approved after fixes, UI spec approved, UI quality approved after fixes, funnel spec/quality approved, final TASK-13 spec approved. Verification passed: pnpm test (263/263), pnpm exec tsc --noEmit, pnpm lint (0 errors; existing BetterAuth generated warnings only), pnpm build with network escalation for Google Fonts.
 <!-- SECTION:NOTES:END -->

backlog/tasks/task-28 - Diagnose-dashboard-initial-load-retry-loop.md

@@ -0,0 +1,75 @@
+---
+id: TASK-28
+title: Diagnose dashboard initial-load retry loop
+status: In Progress
+assignee: []
+created_date: '2026-06-05 13:46'
+updated_date: '2026-06-05 14:01'
+labels: []
+dependencies: []
+priority: high
+ordinal: 30000
+---
+
+## Description
+
+<!-- SECTION:DESCRIPTION:BEGIN -->
+Find the root cause of the repeated dashboard requests on initial load, especially the repeated GET /dashboard/leads entries, and implement a targeted fix only after reproducing and tracing the loop.
+<!-- SECTION:DESCRIPTION:END -->
+
+## Acceptance Criteria
+<!-- AC:BEGIN -->
+- [x] #1 Root cause is identified with evidence from the relevant dashboard/auth/navigation code
+- [x] #2 A minimal fix prevents repeated dashboard/leads requests on initial load
+- [x] #3 Relevant tests or verification commands are run
+<!-- AC:END -->
+
+## Implementation Plan
+
+<!-- SECTION:PLAN:BEGIN -->
+1. Read provided logs and identify repeated route pattern
+2. Trace dashboard auth, routing, and navigation layers
+3. Reproduce the repeated requests locally or via tests
+4. Confirm the root cause with the smallest evidence-producing change
+5. Implement one targeted fix
+6. Run focused verification and update acceptance criteria
+<!-- SECTION:PLAN:END -->
+
+## Implementation Notes
+
+<!-- SECTION:NOTES:BEGIN -->
+Evidence gathered:
+- User-provided log repeatedly shows successful GET /dashboard/leads during dashboard use.
+- Existing Next dev log shows a hydration failure in components/dashboard-theme.tsx:88 inside DashboardThemeToggle during /dashboard rendering: server rendered Moon/aria-pressed=false while client rendered Sun/aria-pressed=true.
+- Next local docs confirm client/server render differences during hydration cause the tree to be regenerated.
+- Separate WIP issue observed: /dashboard/outreach imports a missing component, which can also produce repeated dev overlay errors, but the initial dashboard hydration error is the targeted root cause for this task.
+
+Implemented targeted fix:
+- DashboardThemeProvider now uses useSyncExternalStore with a stable server snapshot of light, preventing the server/client icon and aria-pressed mismatch on initial dashboard hydration.
+- Added tests/dashboard-theme.test.ts to guard against reintroducing localStorage reads in the initial render path.
+Verification:
+- node --test .test-output/tests/dashboard-theme.test.js passes.
+- pnpm test compiles and includes the new dashboard theme test as passing, but the full run still fails in existing TASK-13 outreach WIP test OutreachReviewWorkspace uses the review workspace API and required controls.
+- pnpm lint no longer reports components/dashboard-theme.tsx; it still fails in existing components/outreach/outreach-review-workspace.tsx WIP.
+
+Additional verification note:
+- pnpm exec tsc --noEmit fails in existing components/outreach/outreach-review-workspace.tsx WIP with type mismatches and missing fields; this is separate from the dashboard theme hydration fix and was already part of unrelated TASK-13 worktree changes.
+
+User retest on 2026-06-05 falsified the first hydration-only fix. New evidence: pnpm dev still logs repeated GET /dashboard/leads every roughly 300-400ms with 200 responses, with proxy.ts taking ~165-522ms each time, followed by one get-session and two convex token requests. Re-entering systematic debugging; no more fixes until request initiator is identified.
+
+Added temporary development-only proxy instrumentation for /dashboard/leads request classification. It logs non-sensitive request headers: accept, rsc, next-router-prefetch, next-router-segment-prefetch, next-hmr-refresh, next-url, sec-fetch-mode, purpose, referer, state-tree presence, and user-agent. Remove after confirming requester.
+
+Corrected root cause after user retest and header instrumentation:
+- First hydration hypothesis was incomplete and did not stop the request fan-out.
+- Development-only proxy header instrumentation showed real browser /dashboard/leads requests were same-origin CORS fetches with next-url set to the current dashboard route, not document reloads, HMR refreshes, or server redirect loops.
+- Code search showed the repeated target originates from visible Next Link surfaces: dashboard sidebar nav plus many LeadFunnelCard action links that can share href /dashboard/leads. Next App Router prefetches visible links, and each protected prefetch crosses proxy.ts and isAuthenticated(), producing many 200 GET /dashboard/leads entries.
+Implemented fix:
+- Set prefetch={false} on DashboardSidebar nav links and LeadFunnelCard action links to keep click navigation but stop automatic protected-route prefetch fan-out.
+- Removed temporary proxy/fetch diagnostics.
+- Added tests/dashboard-prefetch.test.ts to lock this behavior.
+Verification:
+- pnpm exec tsc -p tsconfig.test.json passes.
+- node --test .test-output/tests/dashboard-prefetch.test.js .test-output/tests/dashboard-theme.test.js passes.
+- pnpm test passes 260/260.
+- pnpm lint passes with existing generated/unused warnings only, no errors.
+<!-- SECTION:NOTES:END -->