gstack/test/fixtures/autoplan/v-ceo-dangling-references.json

{
  "sourceEvidence": "/home/vercel-sandbox/gstack/.context/ship-source-v-full-paid-20260909-0842/autoplan-continuity-presignal-v1/proof.json",
  "sourceEvidenceSha256": "618d1bad46c73f9b48e94a97eef61af5bf38c6b42fdec392aa033cfc152a9a8a",
  "initialImplementation": "# Plan: User Dashboard Page\n\n## Context\nWe're shipping a new user dashboard at `/dashboard` showing recent activity,\nnotifications panel, and quick-action buttons. Users land here after login.\n\n## UI Scope\n- New React page component `UserDashboard.tsx` at `src/pages/`\n- Three new sub-components: `ActivityFeed`, `NotificationsPanel`, `QuickActions`\n- Tailwind CSS for layout, mobile-first responsive (breakpoints: sm/md/lg)\n- Empty state, loading skeleton, error state for each panel\n- Hover states + focus-visible outlines on every interactive element\n- Modal dialog for \"Mark all as read\" on notifications panel\n- Toast notification system for action feedback\n\n## Backend\n- New REST endpoint `GET /api/dashboard` returns `{ activity, notifications, quickActions }`\n- Backed by existing PostgreSQL tables; no schema changes\n\n## Out of scope\n- Dark mode (separate plan)\n- Personalization / customization (separate plan)\n\n## Existing product and application contracts\n\nThis is the existing single-role member workspace, not a new product or a new\nonboarding flow. Members currently visit three separate pages after login to\nresume work, check alerts, and inspect recent changes. In the team's last task\nwalkthrough, finding the next item took a median 75 seconds. The dashboard's\nsuccess measure is login-to-first-completed-task time, targeting 45 seconds,\nwith completed-task rate and permission-error rate as guardrails. Existing\nanalytics records login, action start, action completion, and permission errors;\nthe new page still needs its own exposure and interaction instrumentation.\n\nActivity is the immutable audit history of workspace changes. Notifications are\nmember-specific alerts with persistent read state; acknowledging an alert does\nnot alter audit history. The existing action registry supplies three actions\n(create an item, resume assigned work, invite a member), with stable IDs, labels,\nroute targets, and server-side eligibility predicates. These are links into\nexisting workflows; action ranking and a new configuration service do not exist.\n\nThe application already uses cookie sessions and workspace membership middleware.\nIts request context supplies the authenticated member and workspace IDs. Existing\nrepository methods apply both IDs where appropriate; callers do not accept a\nworkspace ID from query parameters. Mutations already require CSRF tokens. The\nnew dashboard endpoint must compose these methods and follow the same boundaries;\nits handler, authorization integration, and failure paths have not been written.\n\nExisting list methods return the latest 20 records plus a cursor and have indexed\nworkspace/member and created-at access paths. The existing full activity and\nnotification pages own older-page navigation. The member-scoped bulk-read API is\nidempotent and marks only notifications at or before the supplied snapshot time,\nso later arrivals remain unread. Existing HTTP clients expose typed unauthenticated,\nforbidden, validation, retryable-service, and network errors. Each dashboard panel\nstill needs to map these results to its loading, empty, error, retry, and success\nstates; the aggregate endpoint's response composition and partial-failure behavior\nremain new implementation work. No schema migration or new mutation API is needed.\n\nThe app already has Tailwind spacing/color/type tokens, a responsive page shell,\nbuttons, links, and a dialog primitive with focus trapping, Escape dismissal, and\nfocus return. These primitives do not implement any dashboard panel, confirmation\nflow, or toast system. The new modal and toast feedback must also work with keyboard\nand screen readers; existing accessibility policy requires named controls, a live\nregion for nonblocking feedback, sufficient contrast, and reduced-motion support.\nThe dashboard still needs its own layout, content hierarchy, mobile behavior, and\nstate-specific copy at sm/md/lg breakpoints.\n\nVitest, React Testing Library, and Playwright already run in CI. Existing fixtures\ncover authenticated members, another workspace, empty lists, and service failures;\nthere are no dashboard-specific tests yet. Existing staging feature flags and\nrequest/error metrics support a member-cohort rollout and rollback to the current\nlanding page. The dashboard's rollout criteria, endpoint performance checks,\ninteraction tests, and accessibility verification must be specified and added.\n\nAll dashboard screen, panel, aggregate-endpoint, modal, and toast work listed above\nis new. The existing contracts describe dependencies to reuse, not completed work\nor prior approval of an implementation approach.\n",
  "activeAfterAmend": "<!-- /autoplan restore point: \"/tmp/gstack-paid-shard-kbujLT/tmp/gstack-hermetic-1359490-fo9PNo/skill-home-a0GLT8/.gstack/projects/gstack-autoplan-chain-U4F9I6/main-autoplan-restore-20260909-084423.md\" -->\n## Implementation plan\n# Plan: User Dashboard Page\n\n## Context\nWe're shipping a new user dashboard at `/dashboard` showing recent activity,\nnotifications panel, and quick-action buttons. Users land here after login.\n\n## UI Scope\n- New React page component `UserDashboard.tsx` at `src/pages/`\n- Three new sub-components: `ActivityFeed`, `NotificationsPanel`, `QuickActions`\n- Tailwind CSS for layout, mobile-first responsive (breakpoints: sm/md/lg)\n- Empty state, loading skeleton, error state for each panel\n- Hover states + focus-visible outlines on every interactive element\n- Modal dialog for \"Mark all as read\" on notifications panel\n- Toast notification system for action feedback\n\n## Backend\n- New REST endpoint `GET /api/dashboard` returns `{ activity, notifications, quickActions }`\n- Backed by existing PostgreSQL tables; no schema changes\n\n## Out of scope\n- Dark mode (separate plan)\n- Personalization / customization (separate plan)\n\n## Existing product and application contracts\n\nThis is the existing single-role member workspace, not a new product or a new\nonboarding flow. Members currently visit three separate pages after login to\nresume work, check alerts, and inspect recent changes. In the team's last task\nwalkthrough, finding the next item took a median 75 seconds. The dashboard's\nsuccess measure is login-to-first-completed-task time, targeting 45 seconds,\nwith completed-task rate and permission-error rate as guardrails. Existing\nanalytics records login, action start, action completion, and permission errors;\nthe new page still needs its own exposure and interaction instrumentation.\n\nActivity is the immutable audit history of workspace changes. Notifications are\nmember-specific alerts with persistent read state; acknowledging an alert does\nnot alter audit history. The existing action registry supplies three actions\n(create an item, resume assigned work, invite a member), with stable IDs, labels,\nroute targets, and server-side eligibility predicates. These are links into\nexisting workflows; action ranking and a new configuration service do not exist.\n\nThe application already uses cookie sessions and workspace membership middleware.\nIts request context supplies the authenticated member and workspace IDs. Existing\nrepository methods apply both IDs where appropriate; callers do not accept a\nworkspace ID from query parameters. Mutations already require CSRF tokens. The\nnew dashboard endpoint must compose these methods and follow the same boundaries;\nits handler, authorization integration, and failure paths have not been written.\n\nExisting list methods return the latest 20 records plus a cursor and have indexed\nworkspace/member and created-at access paths. The existing full activity and\nnotification pages own older-page navigation. The member-scoped bulk-read API is\nidempotent and marks only notifications at or before the supplied snapshot time,\nso later arrivals remain unread. Existing HTTP clients expose typed unauthenticated,\nforbidden, validation, retryable-service, and network errors. Each dashboard panel\nstill needs to map these results to its loading, empty, error, retry, and success\nstates; the aggregate endpoint's response composition and partial-failure behavior\nremain new implementation work. No schema migration or new mutation API is needed.\n\nThe app already has Tailwind spacing/color/type tokens, a responsive page shell,\nbuttons, links, and a dialog primitive with focus trapping, Escape dismissal, and\nfocus return. These primitives do not implement any dashboard panel, confirmation\nflow, or toast system. The new modal and toast feedback must also work with keyboard\nand screen readers; existing accessibility policy requires named controls, a live\nregion for nonblocking feedback, sufficient contrast, and reduced-motion support.\nThe dashboard still needs its own layout, content hierarchy, mobile behavior, and\nstate-specific copy at sm/md/lg breakpoints.\n\nVitest, React Testing Library, and Playwright already run in CI. Existing fixtures\ncover authenticated members, another workspace, empty lists, and service failures;\nthere are no dashboard-specific tests yet. Existing staging feature flags and\nrequest/error metrics support a member-cohort rollout and rollback to the current\nlanding page. The dashboard's rollout criteria, endpoint performance checks,\ninteraction tests, and accessibility verification must be specified and added.\n\nAll dashboard screen, panel, aggregate-endpoint, modal, and toast work listed above\nis new. The existing contracts describe dependencies to reuse, not completed work\nor prior approval of an implementation approach.\n\n<!-- autoplan-accepted:ceo -->\n- Dashboard endpoint returns panel-level partial failure: `{error: true, message: string}` per failing panel; successful panels always returned. Frontend panels independently handle error state.\n- Aggregate endpoint uses parallel fetches (Promise.all or backend equivalent) — sequential execution prohibited.\n- Rate limiting applied to GET /api/dashboard at API gateway layer (same tier as existing endpoints).\n- XSS: all user-generated content (notification messages, activity text) rendered as text nodes, never innerHTML. React JSX default is sufficient if props are string-typed; no dangerouslySetInnerHTML.\n- Double-click protection: confirm button disabled on modal submit; re-enabled on error response.\n- Network error on mark-all-read mutation: error toast shown, modal stays open for retry.\n- Quick action eligibility server-side re-check: 403 → toast \"Action no longer available.\"\n- Panel retry: re-fetches GET /api/dashboard; failed panel re-renders from new response.\n- DashboardPanel shared wrapper component: handles loading/empty/error/retry state machine. Each panel specializes only success content.\n- All 12 test scenarios in Section 6 required before rollout.\n- 20% holdout group in feature flag rollout. Go/no-go: login-to-first-task mean ≤ 45s vs. holdout, permission-error delta ≤ +2%, p95 < 200ms.\n- p95 target: GET /api/dashboard < 200ms. Alert at > 500ms p95.\n- Dashboard instrumentation: metrics and structured logs as specified in Section 8.\n- Rollout criteria: Phase 1 (5% internal), Phase 2 (20% + 20% holdout), Phase 3 (full). Rollback: feature flag flip on error rate > 5%/5m.\n- Toast system: singleton store. API: `toast.show({message, type, duration?})`. Max 3 concurrent. Bottom-right. `aria-live=\"polite\"`.\n- Panel order: QuickActions (top), NotificationsPanel (middle), ActivityFeed (bottom). Mobile: vertical stack. md/lg: 2-column (QA+NP left, AF right).\n- State copy: Activity empty: \"No recent workspace activity.\" Notif empty: \"You're all caught up.\" Error: panel-specific \"Could not load X — Retry.\"\n- Accessibility gate: required before phase-1 rollout. axe scan zero violations + keyboard walkthrough + VoiceOver/NVDA spot-check.\n<!-- /autoplan-accepted:ceo -->\n## Review record\n\n---\n\n## Phase 1: CEO Review (SELECTIVE EXPANSION)\n\n**Mode:** SELECTIVE EXPANSION (pre-selected by /autoplan override rule — Decision #0, mechanical)\n\n### System Audit\n- 1 commit: `8a14ab7 init UI-heavy fixture`\n- No stashes, no TODO/FIXME markers\n- No design doc found\n- No handoff note\n- Brain context: unavailable (new project)\n\n---\n\n### Step 0A: Premise Challenge\n\nThree premises examined:\n\n**Premise 1 (accepted):** Three-page flow causes friction; aggregation reduces it.\n75s median → 45s target is plausible. The existing analytics baseline already exists. Accepted (P6 — bias toward action; user has context we lack).\n\n**Premise 2 (accepted):** Existing PostgreSQL tables require no schema changes.\nPlan says endpoint composes existing repo methods. Plausible given read-only aggregation. Accepted.\n\n**Premise 3 (CRITICAL GAP — auto-fixed):** Aggregate endpoint partial-failure behavior is undefined.\nIf the activity fetch fails but notifications succeed, the plan does not specify whether the endpoint returns 500 or partial data. This is implementation-blocking. Auto-fixed: endpoint returns panel-level isolation — partial data with failed panels returning `{error: true}` (Decision #2).\n\n**Premise 4 (accepted as-is):** Action registry (create item, resume assigned work, invite member) is the correct action set.\nNo usage frequency data provided. User has more context. Accepted, noted in NOT IN SCOPE for future validation.\n\n**CEO Subagent challenge on premises (HIGH):** The subagent identified that Premise 1 may be wrong — the friction could be cognitive load, not navigation cost. If users take 75s because they are evaluating what to do next (not because they are navigating), a dashboard does not reduce that. This is surfaced as Taste Decision T1 for Final Gate.\n\n---\n\n### Step 0B: Existing Code Leverage\n\n```\nSub-problem                        → Existing code to reuse\n─────────────────────────────────────────────────────────────\nCookie auth / session              → Cookie session + workspace membership middleware\nMember + workspace ID in context   → Request context (already injected by middleware)\nCSRF protection for mutation       → Existing CSRF token system\nActivity records (20 latest)       → activityRepo methods (indexed workspace/member/created_at)\nNotification records (20 latest)   → notifRepo methods (same index pattern)\nMark all as read                   → Existing member-scoped bulk-read API (idempotent, snapshot time)\nQuick actions (3 stable)           → Action registry (stable IDs, labels, routes, eligibility predicates)\nModal dialog                       → Existing dialog primitive (focus trap, Escape, focus return)\nLayout shell                       → Existing responsive page shell\nTailwind tokens                    → Existing spacing/color/type tokens\nTest infra                         → Vitest + RTL + Playwright (already in CI)\nTest fixtures                      → Existing fixtures: auth member, workspace, empty lists, service failures\nFeature flag + rollout             → Existing staging feature flags + request/error metrics\n```\n\nNet-new (not reusable):\n- `UserDashboard.tsx` page component\n- `ActivityFeed`, `NotificationsPanel`, `QuickActions` sub-components\n- `DashboardPanel` shared wrapper (proposed — Decision #8)\n- `GET /api/dashboard` endpoint handler + partial-failure logic\n- Toast system (singleton, new infrastructure)\n- Dashboard-specific tests\n\n---\n\n### Step 0C: Dream State Mapping\n\n```\nCURRENT STATE                    THIS PLAN                      12-MONTH IDEAL\n─────────────────────────────────────────────────────────────────────────────────\nMembers visit 3 separate     →   Single /dashboard page      →  Intelligent \"next\npages post-login to              aggregating activity,            action\" surface:\nresume work, check alerts,       notifications, 3 quick           proactive ranking\nand view activity.               actions. Feature-flag            of highest-priority\n75s median to first task.        member-cohort rollout.           item, role-aware\nNo single landing surface.       45s target with holdout          personalization,\n                                 measurement. No schema           real-time notifs\n                                 changes. Accessibility           (SSE/WS), <30s\n                                 compliant.                       to first task.\n```\n\n**Dream state delta:** This plan captures ~55% of the 12-month ideal. Missing: intelligent ranking, personalization, real-time push. Both correctly deferred. The plan moves in the right direction and does not create technical debt against those goals — the component architecture supports future panel additions.\n\n---\n\n### Step 0C-bis: Implementation Alternatives\n\n```\nAPPROACH A: Full Dashboard (current plan)\n  Effort:  M (human ~5-8 days / CC ~45min)\n  Risk:    Med — 3 sub-component state machines, new endpoint, accessible modal+toast\n  Pros:    Complete solution; component patterns reusable; enables future personalization\n           Validates the 75s→45s hypothesis with real user data\n  Cons:    Larger surface area; accessible toast+modal require careful implementation\n  Reuses:  All existing primitives, auth, repo methods\n  Completeness: 10/10 — ships the complete specified scope\n\nAPPROACH B: Lightweight Enhancement (notification badge + Cmd+K launcher)\n  Effort:  S (human ~2 days / CC ~15min)\n  Risk:    Low — no new endpoint, minimal state, no new infrastructure\n  Pros:    Faster to ship; globally reusable; smaller accessibility surface\n  Cons:    Activity feed context missing; less discoverable for new users\n           Does not directly test the 75s→45s hypothesis\n  Reuses:  Same auth/repos, much smaller component surface\n  Completeness: 6/10 — achieves core quick-action reduction, not the full scope\n\nAPPROACH C: Deeplink Email/Push Nudges\n  Effort:  XL (human ~4+ weeks / CC ~2hrs) — requires notification infrastructure\n  Risk:    High — new infrastructure, deliverability complexity\n  Pros:    Can reduce app visit entirely; highest time-to-task reduction potential\n  Cons:    Far outside this plan's stated scope; blocks on email/push infrastructure\n  Completeness: 3/10 — only nudge path, no in-app surface\n```\n\n**RECOMMENDATION: Approach A** — auto-decided (P6 bias toward action; user has scoped this; P1 complete solution; Approach B noted in NOT IN SCOPE for future consideration).\nDecision #1: Mechanical.\n\n---\n\n### Step 0E: Temporal Interrogation\n\n```\nHOUR 1 (foundations):    Endpoint handler structure, auth integration, parallel fetch setup.\n                         Decision needed NOW: partial-failure contract (auto-decided: panel isolation).\n\nHOUR 2-3 (core logic):  Three sub-components + DashboardPanel wrapper. State machines per panel.\n                         Ambiguity: shared state vs. independent fetches. (Recommendation: each panel\n                         fetches from the aggregate endpoint; no independent panel-level fetches.)\n\nHOUR 4-5 (integration): Modal for mark-all-read, toast system, CSRF integration.\n                         Surprise: dialog primitive does not implement confirmation flows — must compose.\n                         Toast system has no existing implementation — full new build.\n\nHOUR 6+ (polish/tests): Accessibility audit (axe + keyboard + VoiceOver). Playwright E2E.\n                         These will take longer than expected. Budget accordingly.\n                         Rollout criteria and feature flag holdout group must be configured.\n```\n\n---\n\n### Step 0F: Mode Confirmation\n\nSELECTIVE EXPANSION selected (pre-set by /autoplan). No scope expansions added from cherry-pick ceremony (auto-decided: all CEO subagent expansion suggestions handled as implementation requirements or taste decisions). Scope is the plan as written + the auto-decided additions below.\n\n---\n\n## CEO Review Sections\n\n### Section 1: Architecture Review\n\n**System architecture:**\n\n```\nBrowser                     API Layer                      DB / Registry\n──────────                  ─────────                      ─────────────\nGET /dashboard  ──────────► DashboardPage\n                             ├─ DashboardPanel (shared wrapper)\n                             │   ├─ ActivityFeed\n                             │   ├─ NotificationsPanel\n                             │   └─ QuickActions\n                             │\n                             ▼\n                            GET /api/dashboard  ─────────► Promise.all([\n                             │                               activityRepo.list(member, ws),\n                             │                               notifRepo.list(member, ws),\n                             │                               actionRegistry.eligible(member)\n                             │                             ])\n                             │                             ▼\n                             │                     Panel-level isolation:\n                             │                     {activity: data|{error:true},\n                             │                      notifications: data|{error:true},\n                             │                      quickActions: data|{error:true}}\n                             │\n                            Toast singleton ◄──────── \"Mark all read\" modal\n                                                       CSRF token + snapshot time\n                                                       PATCH /api/notifications/read-all\n```\n\n**Data flow (happy path):**\n```\nUser → /dashboard → GET /api/dashboard → Promise.all(3 queries) → 200 {activity, notifications, quickActions}\n→ Dashboard renders 3 panels in success state\n```\n\n**Data flow (partial failure):**\n```\nactivityRepo fails (TimeoutError) → activity: {error:true}\nnotifRepo succeeds → notifications: data\nactionRegistry succeeds → quickActions: data\nEndpoint returns 200 with mixed payload → frontend: ActivityFeed shows error UI, others show success\n```\n\n**Finding S1-1: Partial failure contract undefined** → Auto-fixed (Decision #2): endpoint returns panel-level isolation; failed panels return `{error: true, message: string}`.\n\n**Finding S1-2: Sequential vs parallel fetches unspecified** → Auto-fixed (Decision #3): `Promise.all` (or backend equivalent) for all three sub-calls. Sequential would triple p99 latency.\n\n**Security architecture:**\n- Auth: cookie session + workspace membership middleware. No new query params for member/workspace IDs. ✓\n- CSRF: mark-all-read mutation uses existing CSRF tokens. ✓\n- No new secrets. ✓\n- No new dependencies. ✓\n\n**Rollback posture:** Feature flag flip = immediate rollback. No DB migration to reverse. ✓\n\n**Finding S1-3: Rate limiting on aggregate endpoint** → Auto-fixed (Decision #4): rate limit at API gateway layer matching existing endpoint limits. Dashboard is called per page load; without rate limiting, a rapid refresher makes 3 parallel DB queries per call.\n\n### Section 2: Error & Rescue Map\n\n```\nMETHOD/CODEPATH               | WHAT CAN GO WRONG              | EXCEPTION CLASS\n------------------------------|--------------------------------|-------------------\nGET /api/dashboard handler    | DB connection failure          | ConnectionError\n                              | Individual repo timeout        | TimeoutError\n                              | Auth session expired           | UnauthenticatedError\n                              | Workspace access revoked       | ForbiddenError\nPATCH notifications/read-all  | CSRF token expired             | CSRFError\n                              | Network failure                | NetworkError\n                              | Auth expired mid-modal         | UnauthenticatedError\nFrontend panel fetch          | Typed HTTP 4xx/5xx             | typed HTTPError\n\nEXCEPTION CLASS         | RESCUED? | RESCUE ACTION                        | USER SEES\n------------------------|----------|--------------------------------------|-------------------\nConnectionError         | Y        | Return panel {error:true}             | Panel error UI + retry\nTimeoutError            | Y        | Return panel {error:true}             | Panel error UI + retry\nUnauthenticatedError    | Y        | 401 → frontend redirects to login    | Login page\nForbiddenError          | Y        | 403 → panel error or page redirect   | Access denied UI\nCSRFError               | Y        | 403 → toast \"Session expired, refresh\"| Error toast\nNetworkError            | Y        | Error toast, modal stays open        | \"Request failed, try again\"\ntyped HTTPError         | Y        | Per-type: 4xx→panel error, 5xx→retry | Panel error UI\n```\n\n**Finding S2-1 (auto-fixed, Decision #5):** Add this error rescue table to the implementation plan. Catch-all error handling explicitly prohibited; each exception class named.\n\n### Section 3: Security & Threat Model\n\n```\nTHREAT                               | LIKELIHOOD | IMPACT | MITIGATED?\n-------------------------------------|-----------|--------|------------\nIDOR via dashboard endpoint          | Low        | High   | YES — member+ws from session, not params\nSession fixation / auth bypass       | Low        | High   | YES — existing cookie+middleware\nCSRF on mark-all-read mutation       | Low        | Med    | YES — existing CSRF token system\nRate limiting on aggregate endpoint  | Med        | Med    | ADDED (Decision #4)\nXSS via notification/activity content| Med        | High   | Depends on rendering (sanitize)\n```\n\n**Finding S3-1: XSS in notification/activity content** — The plan doesn't specify that notification messages and activity text are rendered as text, not innerHTML. If any field is rendered raw, XSS is possible.\n→ Auto-decide (Decision #6): Add to plan: \"All user-generated content (notification messages, activity descriptions) rendered as text nodes, never innerHTML. React's default JSX rendering satisfies this if props are string-typed.\"\n\nNo other critical security findings. Auth boundaries are correctly specified.\n\n### Section 4: Data Flow & Interaction Edge Cases\n\n**Data flows diagrammed in Section 1.** Shadow paths:\n- Nil activity/notification input → empty state panels ✓ (plan specifies empty states)\n- Network failure during load → error state panels ✓ (plan specifies error states)\n- Concurrent new notification during dashboard session → not addressed (static snapshot on page load, no real-time updates — acceptable given no SSE/polling in scope)\n\n**Interaction edge cases:**\n\n```\nINTERACTION               | EDGE CASE                      | STATUS    | FIX\n--------------------------|--------------------------------|-----------|----------------------------------------\nModal confirm             | Double-click submit            | GAP       | Disable button on submit, re-enable on error\nModal confirm             | Network error during mutation  | GAP       | Error toast, modal stays open for retry\nQuick action click        | Eligibility changes post-load  | GAP       | Server-side eligibility re-check; 403 → toast\nDashboard load            | Session expires between panels | Handled   | UnauthenticatedError → redirect to login\nMark-all-read             | New notif arrives during open  | Handled   | Snapshot time prevents marking future notifs\nPanel retry button        | User clicks retry on error     | GAP       | Retry re-fetches GET /api/dashboard, panel re-renders\nActivity/notif list       | Zero results                   | Handled   | Empty states specified\n```\n\n**Finding S4-1 (auto-fixed, Decision #7):** Double-click protection — disable confirm button on submit.\n**Finding S4-2 (auto-fixed, Decision #8):** Network error during mutation — error toast + modal stays open.\n**Finding S4-3 (auto-fixed, Decision #9):** Quick action eligibility re-check — server-side 403 → toast \"Action no longer available.\"\n**Finding S4-4 (auto-fixed, Decision #10):** Panel retry — re-fetches aggregate endpoint, failed panel re-renders.\n\n### Section 5: Code Quality Review\n\n**DRY finding:** Three panels each need loading/empty/error/retry state machines. Implementing this 3× in each sub-component is a DRY violation.\n\n**Finding S5-1 (auto-fixed, Decision #11):** Extract `DashboardPanel` shared wrapper component that handles loading/empty/error/retry. Each panel (ActivityFeed, NotificationsPanel, QuickActions) specializes only its success content. Single state machine implementation, 3 specialized consumers.\n\nCode organization: `UserDashboard.tsx` in `src/pages/` ✓. Sub-components in `src/components/dashboard/` (follow existing pattern). Endpoint in existing API route structure ✓.\n\nNaming: `ActivityFeed`, `NotificationsPanel`, `QuickActions`, `DashboardPanel` — clear, domain-language names. ✓\n\nNo over-engineering concerns. No complexity violations (each component has a simple, well-defined role).\n\n### Section 6: Test Review\n\n**New UX flows:**\n1. Dashboard loads → all 3 panels populated (success state)\n2. Dashboard loads → empty states per panel\n3. Dashboard loads → 1+ panel in error state (partial failure)\n4. Mark all as read → happy path (modal → confirm → toast → panel refresh)\n5. Mark all as read → cancel path (modal → cancel → no change)\n6. Mark all as read → error path (mutation fails → error toast → modal stays)\n7. Quick action click → navigates to correct destination\n8. Panel retry → re-fetches → panel recovers to success\n9. Keyboard navigation through all interactive elements\n10. Mobile rendering at sm/md/lg breakpoints\n\n**New data flows:**\n1. `GET /api/dashboard` → parallel fetch → aggregate response (all success)\n2. `GET /api/dashboard` → partial failure → mixed response\n3. `PATCH /api/notifications/read-all` → success\n4. `PATCH /api/notifications/read-all` → failure\n\n**Test coverage map:**\n\n```\nFLOW / CODEPATH                        | TEST TYPE         | EXISTS?\n---------------------------------------|-------------------|--------\nDashboard page render (all success)    | RTL component     | No → T-S6-1\nDashboard page render (empty panels)   | RTL component     | No → T-S6-2\nDashboard page render (partial failure)| RTL component     | No → T-S6-3\nAggregate endpoint (all success)       | Vitest unit       | No → T-S6-4\nAggregate endpoint (partial failure)   | Vitest unit       | No → T-S6-5\nMark all read (success)                | RTL + Playwright  | No → T-S6-6\nMark all read (failure)                | RTL               | No → T-S6-7\nQuick action click                     | RTL               | No → T-S6-8\nKeyboard nav (full flow)               | Playwright        | No → T-S6-9\nAccessibility (axe scan)               | Playwright/axe    | No → T-S6-10\nMobile responsive (sm/md/lg)           | Playwright        | No → T-S6-11\nHoldout group rollout metrics          | Manual / feature flag | No → T-S6-12\n```\n\n**Finding S6-1 (auto-fixed, Decision #12):** All test specs listed above added to implementation plan. Tests are non-negotiable (P1).\n\n**Finding S6-2 (auto-fixed, Decision #13):** Feature flag holdout group — 20% holdout for controlled A/B measurement of login-to-first-completed-task. Without a holdout, the 45s target cannot be verified.\n\n### Section 7: Performance Review\n\n**Query analysis:**\n- 2 indexed DB queries per page load (activity + notifications), parallel\n- Action registry: in-memory, no DB hit\n- Total: 2 parallel indexed queries → estimated p95 < 100ms under normal load\n\nN+1: No association traversal. Flat list queries only. ✓\nMemory: 20 records × 2 panels = 40 rows in memory. Trivial. ✓\n\n**Finding S7-1 (auto-fixed, Decision #14):** Add p95 latency target to plan: `GET /api/dashboard` target p95 < 200ms. Alert threshold: p95 > 500ms. Monitor via existing request metrics.\n\nCaching: Quick actions are static — can be cached in memory (trivially). Activity and notifications are user-specific and frequently updated — do not cache. No caching added (P3 pragmatic — caching adds complexity for minimal gain on 2 fast indexed queries).\n\n### Section 8: Observability & Debuggability Review\n\n**Required instrumentation (auto-decided — Decision #15):**\n\n```\nMetric/log                                        | Type\n--------------------------------------------------|------\ndashboard.page.loaded                             | Counter (exposure)\ndashboard.page.load_time_ms                       | Histogram\ndashboard.panel.{activity|notifications|actions}.{success|error|empty} | Counter\ndashboard.mark_all_read.{attempted|succeeded|failed} | Counter\ndashboard.quick_action.{id}.clicked              | Counter\napi.dashboard.latency_ms                          | Histogram\napi.dashboard.error_rate                          | Gauge (per 1m)\napi.dashboard.partial_failure_rate                | Counter\n```\n\n**Structured log lines:**\n- Endpoint entry: `{event: \"dashboard_fetch_start\", member_id, workspace_id}`\n- Per-panel result: `{event: \"dashboard_panel_result\", panel: \"activity|notifications|actions\", status: \"ok|error\", latency_ms}`\n- Endpoint exit: `{event: \"dashboard_fetch_complete\", panels_ok: N, panels_failed: N, total_ms}`\n- Mutation: `{event: \"mark_all_read\", status: \"ok|error\", notif_count, snapshot_time}`\n\nDebuggability: With these logs, a bug reported 3 weeks post-ship is fully reconstructable (which panels succeeded, which failed, what the member did).\n\n### Section 9: Deployment & Rollout Review\n\nNo DB migration. ✓\nNo backward-compat risk (new endpoint, existing pages unchanged during rollout). ✓\n\n**Finding S9-1 (auto-fixed, Decision #16):** Rollout criteria added to plan:\n\n```\nPhase 1 (day 1):     Internal team only (flag %: 5%)\n                     Verify: endpoint error rate < 1%, accessibility gate passed\nPhase 2 (week 1):    20% member cohort + 20% holdout\n                     Gate to phase 3: login-to-first-task mean ≤ 45s vs. holdout baseline\n                                      permission-error rate delta ≤ +2%\n                                      p95 latency < 200ms\nPhase 3 (week 2+):   Full rollout\nRollback trigger:    Dashboard endpoint error rate > 5% over 5m window\n                     OR user-facing permission errors spike > +5% vs. baseline\nRollback action:     Flip feature flag off (instant, no deploy needed)\n```\n\nPost-deploy verification checklist:\n1. Check `api.dashboard.error_rate` in first 5 minutes post-phase-1 deploy\n2. Confirm activity and notification counts are plausible for internal test accounts\n3. Verify mark-all-read works end-to-end in staging\n4. Run accessibility axe scan + manual keyboard walkthrough\n\n### Section 10: Long-Term Trajectory Review\n\n**Technical debt introduced:**\n- Toast system: new UI primitive, must be maintained. If a toast library is added later, this custom implementation becomes migration debt. Mitigated by keeping it simple (Decision #17: toast is a thin singleton store, not a framework).\n- `DashboardPanel` wrapper: positive — reduces future dashboard-adjacent components from implementing their own state machines.\n\n**Path dependency:** The 3-panel layout becomes the primary post-login pattern. Future personalization (deferred) will modify this layout — the component architecture supports adding/removing panels without full rewrites. ✓\n\n**Reversibility:** 4/5. Feature flag enables instant rollback. No schema changes. The toast system and DashboardPanel are the only new shared primitives.\n\n**12-month question:** A new engineer reading this plan in 12 months would see: component boundaries are clear, endpoint partial-failure contract is explicit, rollout criteria are defined, and test coverage is mapped. The plan is legible. ✓\n\n**Finding S10-1 (auto-fixed, Decision #17):** Toast system must be implemented as a singleton with a defined API: `toast.show({message, type, duration?})`. Max 3 concurrent. Bottom-right position. Live region for accessibility. This prevents multiple toast implementations proliferating.\n\n### Section 11: Design & UX Review (UI scope detected)\n\n**Information architecture (panel order):**\nPlan does not specify visual hierarchy. Auto-decided (Decision #18): QuickActions first (primary action path), NotificationsPanel second (alerts/unread state), ActivityFeed third (audit context). On mobile (sm), vertical stack in this order. On md/lg, 2-column layout: QuickActions+NotificationsPanel left, ActivityFeed right.\n\n**State coverage:**\n```\nPANEL           | LOADING  | EMPTY              | ERROR              | SUCCESS\n----------------|----------|--------------------|--------------------|--------\nActivityFeed    | ✓ spec'd | \"No recent         | \"Could not load    | ✓ spec'd\n                |          |  workspace          |  activity — Retry\" |\n                |          |  activity.\"        |                    |\nNotifPanel      | ✓ spec'd | \"You're all        | \"Could not load    | ✓ spec'd\n                |          |  caught up.\"       |  notifications —   |\n                |          |                    |  Retry\"            |\nQuickActions    | N/A      | N/A (static)       | \"Actions           | ✓ spec'd\n                |          |                    |  unavailable —     |\n                |          |                    |  Refresh\"          |\nModal confirm   | —        | —                  | Error toast +      | ✓ spec'd\n                |          |                    | modal stays open   |\nToast           | —        | —                  | —                  | ✓ spec'd\n```\n\n**Finding S11-1 (auto-fixed, Decision #18):** Panel order + state copy specified above. Added to plan.\n\n**Accessibility checklist:**\n- Named controls on all interactive elements ✓ (plan specifies this)\n- Live region for toast notifications — must be implemented as `aria-live=\"polite\"` ✓ (add to toast spec)\n- Modal: focus trap + Escape + focus return → handled by existing dialog primitive ✓\n- Focus-visible outlines on all interactive elements ✓ (plan specifies this)\n- Reduced-motion support required for loading skeleton and toast animations ✓ (plan specifies)\n- Keyboard walkthrough gate required before phase-1 rollout (Decision #19: add to rollout checklist)\n- Color contrast: Tailwind tokens must meet WCAG AA for all state-specific copy ✓ (existing token compliance)\n\n**CEO subagent observation (HIGH — auto-fixed):** Dashboard layout not validated before full build. Auto-decided: a static mockup with internal team review during phase-1 internal cohort covers this. Full prototype testing deferred (Taste Decision T2 for Final Gate — user decides if they want a pre-build prototype instead).\n\n---\n\n## CEO Review: NOT In Scope\n\nItems explicitly excluded from this plan (with rationale):\n\n1. **Dark mode** — separate plan, stated in original scope. ✓\n2. **Personalization / customization** — separate plan, stated in original scope. ✓\n3. **Real-time notifications (SSE/WS)** — 12-month ideal; deferred to avoid infrastructure complexity\n4. **Command palette (Cmd+K)** — viable alternative (CEO subagent HIGH finding); deferred. Consider after measuring dashboard time-to-task impact.\n5. **Deeplink email/push nudges** — requires notification infrastructure; separate scope\n6. **Quick action ranking / configuration service** — plan explicitly excludes; action registry is static\n7. **Older-page pagination on dashboard panels** — existing pages own this; dashboard shows 20 records only\n8. **Real-time notification polling** — separate scope; dashboard is a page-load snapshot\n\n---\n\n## CEO Review: What Already Exists\n\n| Sub-problem | Existing code | Plan reuses? |\n|---|---|---|\n| Auth session validation | Cookie session + workspace middleware | Yes |\n| Member + workspace context | Request context injection | Yes |\n| CSRF protection | Existing CSRF token system | Yes |\n| Activity list (20 latest) | activityRepo.list() with indexes | Yes |\n| Notification list (20 latest) | notifRepo.list() with indexes | Yes |\n| Mark all as read | Bulk-read API (idempotent, snapshot-time) | Yes |\n| Quick action definitions | Action registry (stable IDs, routes, predicates) | Yes |\n| Modal dialog | Existing dialog primitive (focus trap, Escape, focus return) | Yes — for Mark All Read modal |\n| Responsive shell | Existing page shell | Yes |\n| Design tokens | Tailwind spacing/color/type tokens | Yes |\n| Test infrastructure | Vitest + RTL + Playwright | Yes |\n| Test fixtures | Auth member, workspace, empty lists, service failures | Yes (extend for dashboard) |\n| Feature flag + rollout | Existing staging feature flags + metrics | Yes |\n\nNot reused: Toast system (net-new), DashboardPanel wrapper (net-new), UserDashboard page (net-new), 3 sub-components (net-new), aggregate endpoint (net-new).\n\n---\n\n## CEO Review: Dream State Delta\n\n```\nWhat this plan delivers vs. the 12-month ideal:\n─────────────────────────────────────────────────────────────────\nDELIVERED BY THIS PLAN:\n  ✓ Single post-login landing surface (eliminates 3-page navigation)\n  ✓ Activity + notification + quick action aggregation\n  ✓ Member-cohort rollout with measurable time-to-task target\n  ✓ Accessible modal + toast infrastructure\n  ✓ Feature flag rollback path\n\nDEFERRED (correct decisions):\n  ○ Intelligent action ranking (needs usage data first)\n  ○ Personalization (separate plan)\n  ○ Real-time notifications (SSE/WS — infrastructure investment)\n  ○ Deep action links (beyond what the registry currently provides)\n  ○ Command palette (may outperform dashboard for power users)\n\nARCHITECTURAL FOUNDATION:\n  ✓ DashboardPanel wrapper enables future panels without new state machines\n  ✓ Aggregate endpoint pattern reusable for future views\n  ✓ Holdout measurement will tell us if the hypothesis is right\n```\n\n---\n\n## CEO Review: Error & Rescue Registry\n\n| Method/Codepath | What Can Go Wrong | Exception Class | Rescued? | Rescue Action | User Sees |\n|---|---|---|---|---|---|\n| GET /api/dashboard | DB connection failure | ConnectionError | Y | Panel `{error:true}` | Panel error UI + retry |\n| GET /api/dashboard | Repo timeout | TimeoutError | Y | Panel `{error:true}` | Panel error UI + retry |\n| GET /api/dashboard | Auth session expired | UnauthenticatedError | Y | 401 → redirect login | Login page |\n| GET /api/dashboard | Workspace access revoked | ForbiddenError | Y | 403 → page error | Access denied UI |\n| PATCH notifications/read-all | CSRF expired | CSRFError | Y | 403 → error toast | \"Session expired, refresh\" |\n| PATCH notifications/read-all | Network failure | NetworkError | Y | Error toast, modal stays | \"Request failed, try again\" |\n| PATCH notifications/read-all | Auth expired | UnauthenticatedError | Y | 401 → redirect | Login page |\n| Quick action navigate | Eligibility changed | ForbiddenError | Y | Toast \"Action unavailable\" | Error toast |\n| Frontend panel retry | Repeated fetch failure | typed HTTPError | Y | Panel stays in error state | Panel error UI |\n\nNo catch-all handlers. Each exception class explicitly named. No \"swallow and continue\" paths.\n\n---\n\n## CEO Review: Failure Modes Registry\n\n```\nCODEPATH                          | FAILURE MODE      | RESCUED? | TEST? | USER SEES?        | LOGGED?\n----------------------------------|-------------------|----------|-------|-------------------|--------\nAggregate endpoint — activity     | DB timeout        | Y        | Req'd | Panel error UI    | Y (structured log)\nAggregate endpoint — notifications| DB timeout        | Y        | Req'd | Panel error UI    | Y\nAggregate endpoint — all panels   | All fail          | Y        | Req'd | All panels error  | Y\nMark all read — mutation          | Network error     | Y        | Req'd | Error toast       | Y\nMark all read — mutation          | CSRF expired      | Y        | Req'd | Toast + refresh   | Y\nQuick action click                | Eligibility lost  | Y        | Req'd | Error toast       | Y\nDashboard load                    | Auth expired      | Y        | Req'd | Redirect login    | Y\nToast system                      | Concurrent toasts | Y        | Req'd | Max 3 shown       | N/A\n```\n\nAll rows: RESCUED=Y, TEST=Required (added to test plan), USER SEES=explicit. No CRITICAL GAPSremaining after auto-decisions.\n\n---\n\n## CEO Review: TODOS.md Updates\n\nNo TODOs surfaced for deferred work. Items that could have been TODOS were incorporated as implementation requirements (rollout criteria, test specs, error mapping) or are captured in NOT IN SCOPE above.\n\n---\n\n## CEO Dual Voices\n\n**Native primary review:** Completed (above — 11 sections, 19 auto-decisions).\n\n**Claude CEO subagent:** Completed. Key findings (all addressed):\n- CRITICAL: No rollout criteria / holdout → Decision #16 (rollout criteria + holdout added)\n- HIGH: Partial failure contract undefined → Decision #2 (panel isolation contract added)\n- HIGH: Dashboard layout not validated → Taste Decision T2 (surface at Final Gate)\n- HIGH: Accessibility not gated as hard blocker → Decision #19 (accessibility gate added to rollout)\n- HIGH: No pre-implementation spike to validate hypothesis → Taste Decision T1 (surface at Final Gate)\n- MEDIUM: Alternatives not documented → Decision #0-alt (NOT IN SCOPE section written)\n- MEDIUM: Quick action frequency not validated → noted in NOT IN SCOPE\n\n**Codex CEO voice:** Skipped (codex_reviews disabled). Outside_status: disabled.\n\n**CEO DUAL VOICES — CONSENSUS TABLE:**\n```\n═══════════════════════════════════════════════════════════════\n  Dimension                           Claude  Codex  Consensus\n  ──────────────────────────────────── ─────── ─────── ─────────\n  1. Premises valid?                   COND    N/A    N/A\n  2. Right problem to solve?           COND    N/A    N/A\n  3. Scope calibration correct?        YES     N/A    N/A\n  4. Alternatives sufficiently explored? COND  N/A    N/A\n  5. Competitive/market risks covered? MED     N/A    N/A\n  6. 6-month trajectory sound?         COND    N/A    N/A\n═══════════════════════════════════════════════════════════════\nCOND = Conditional on taste decisions T1/T2. N/A = Codex disabled.\nOutside disabled: Consensus cells N/A — not CONFIRMED.\n```\n\n---\n\n## CEO Review: Implementation Tasks\n\nSynthesized from this review's findings. Each task derives from a specific finding. Run with Claude Code; checkbox as you ship.\n\n- [ ] **T1 (P1, human: ~2h / CC: ~10min)** — Endpoint — Define partial-failure contract + parallel fetches\n  - Surfaced by: Section 1 — aggregate endpoint returns panel-level `{error:true}` on partial failure; use Promise.all\n  - Files: `src/api/dashboard.ts` (new)\n  - Verify: Unit test with one mock fetch rejecting; assert other panels still populated\n\n- [ ] **T2 (P1, human: ~30min / CC: ~5min)** — Endpoint — Add rate limiting to GET /api/dashboard\n  - Surfaced by: Section 3 — new endpoint, no rate limit = DoS vector\n  - Files: API gateway config or middleware layer\n  - Verify: Verify rate limit applies at same tier as existing endpoints\n\n- [ ] **T3 (P1, human: ~1h / CC: ~10min)** — Frontend — DashboardPanel shared wrapper component\n  - Surfaced by: Section 5 — 3 identical state machines is a DRY violation\n  - Files: `src/components/dashboard/DashboardPanel.tsx` (new)\n  - Verify: All 3 panel components use DashboardPanel; no duplicated loading/error/empty code\n\n- [ ] **T4 (P1, human: ~30min / CC: ~5min)** — Frontend — Double-click protection on modal confirm\n  - Surfaced by: Section 4 — double-click submits mutation twice\n  - Files: `src/components/dashboard/NotificationsPanel.tsx`\n  - Verify: RTL test: submit → button disabled; resolve → button re-enabled\n\n- [ ] **T5 (P1, human: ~30min / CC: ~5min)** — Frontend — Network error handling for mark-all-read mutation\n  - Surfaced by: Section 4 — mutation failure leaves modal in ambiguous state\n  - Files: `src/components/dashboard/NotificationsPanel.tsx`\n  - Verify: RTL test: mock mutation failure → toast shown → modal stays open\n\n- [ ] **T6 (P1, human: ~1h / CC: ~10min)** — Toast system — Singleton toast implementation\n  - Surfaced by: Section 10 — new infrastructure, needs a defined API\n  - Files: `src/lib/toast.ts` + `src/components/Toast.tsx` (new)\n  - Verify: Test: max 3 concurrent, live region attribute present, dismiss works\n\n- [ ] **T7 (P1, human: ~30min / CC: ~5min)** — Security — XSS prevention in notification/activity content\n  - Surfaced by: Section 3 — user-generated content must not be rendered as innerHTML\n  - Files: `src/components/dashboard/ActivityFeed.tsx`, `NotificationsPanel.tsx`\n  - Verify: Lint rule or code review: no dangerouslySetInnerHTML on user content fields\n\n- [ ] **T8 (P1, human: ~2h / CC: ~15min)** — Observability — Add dashboard instrumentation\n  - Surfaced by: Section 8 — no metrics, no structured logs\n  - Files: endpoint handler + page component\n  - Verify: Verify metrics appear in existing dashboard on staging after phase-1 deploy\n\n- [ ] **T9 (P1, human: ~1h / CC: ~10min)** — Rollout — Define rollout criteria + holdout group\n  - Surfaced by: Section 9, CEO subagent CRITICAL — no rollout criteria, no holdout\n  - Files: Feature flag config, rollout runbook\n  - Verify: 20% holdout group configured; success metrics defined before phase-2 begins\n\n- [ ] **T10 (P1, human: ~3h / CC: ~20min)** — Tests — All test specs in Section 6\n  - Surfaced by: Section 6 — 12 test scenarios mapped, none exist\n  - Files: `src/tests/dashboard/` (new)\n  - Verify: All 12 scenarios pass in CI; axe accessibility test included\n\n- [ ] **T11 (P2, human: ~30min / CC: ~5min)** — UX — Panel order + state copy\n  - Surfaced by: Section 11 — panel hierarchy and empty/error copy unspecified\n  - Files: `src/pages/UserDashboard.tsx`, each panel component\n  - Verify: Visual review on sm/md/lg; copy matches spec\n\n- [ ] **T12 (P2, human: ~1h / CC: ~10min)** — UX — Accessibility gate pre-rollout\n  - Surfaced by: Section 11 — accessibility requirements named but no gate specified\n  - Files: Test config (axe integration in Playwright), rollout checklist\n  - Verify: axe scan zero violations; keyboard walkthrough documented; VoiceOver/NVDA spot-check\n\n---\n\n## CEO Completion Summary\n\n```\n+====================================================================+\n|            MEGA PLAN REVIEW — CEO COMPLETION SUMMARY              |\n+====================================================================+\n| Mode selected        | SELECTIVE EXPANSION                        |\n| System Audit         | Clean. 1 commit, no prior review context   |\n| Step 0               | Approach A confirmed; 3 alternatives eval'd|\n| Section 1  (Arch)    | 3 issues found (partial failure, parallel, |\n|                      | rate limit) — all auto-fixed               |\n| Section 2  (Errors)  | 9 error paths mapped, 0 GAPS remaining     |\n| Section 3  (Security)| 1 issue (XSS in content render) — auto-fix|\n| Section 4  (Data/UX) | 4 edge cases mapped — all auto-fixed       |\n| Section 5  (Quality) | 1 issue (DRY: DashboardPanel) — auto-fixed |\n| Section 6  (Tests)   | 12 test scenarios mapped, all new          |\n| Section 7  (Perf)    | 1 issue (p95 target) — auto-fixed          |\n| Section 8  (Observ)  | 1 gap (instrumentation) — auto-fixed       |\n| Section 9  (Deploy)  | 1 critical (rollout criteria) — auto-fixed |\n| Section 10 (Future)  | Reversibility: 4/5, toast debt noted       |\n| Section 11 (Design)  | 2 issues (panel order, copy) — auto-fixed  |\n+--------------------------------------------------------------------+\n| NOT in scope         | Written (8 items)                           |\n| What already exists  | Written (13 items)                         |\n| Dream state delta    | Written                                     |\n| Error/rescue registry| 9 methods, 0 CRITICAL GAPS                 |\n| Failure modes        | 8 total, 0 CRITICAL GAPS                   |\n| TODOS.md updates     | 0 items (all incorporated as requirements) |\n| Scope proposals      | 0 accepted (SELECTIVE, no cherry-picks)    |\n| CEO plan             | Skipped (no accepted scope expansions)     |\n| Outside voice        | Codex: disabled. Claude subagent: complete |\n| Lake Score           | 19/19 — all decisions chose complete option|\n| Diagrams produced    | 4 (system arch, data flow, error flow, UX states)|\n| Stale diagrams found | 0 (no existing diagrams in repo)           |\n| Unresolved decisions | 2 (T1: pre-build spike, T2: prototype test)|\n+====================================================================+\n```\n\n**Auto-decided: 19 decisions (mechanical).**\n**Taste decisions for Final Gate: 2 (T1: pre-implementation validation spike, T2: prototype test before full build).**\n\n**Phase 1 complete.**\nCodex: disabled. Claude subagent: completed (8 findings, all incorporated).\nConsensus: N/A (outside disabled). Passing to Phase 2 (Design Review — UI scope detected).\n\n<!-- autoplan-accepted:ceo -->\n- Dashboard endpoint returns panel-level partial failure: `{error: true, message: string}` per failing panel; successful panels always returned. Frontend panels independently handle error state.\n- Aggregate endpoint uses parallel fetches (Promise.all or backend equivalent) — sequential execution prohibited.\n- Rate limiting applied to GET /api/dashboard at API gateway layer (same tier as existing endpoints).\n- XSS: all user-generated content (notification messages, activity text) rendered as text nodes, never innerHTML. React JSX default is sufficient if props are string-typed; no dangerouslySetInnerHTML.\n- Double-click protection: confirm button disabled on modal submit; re-enabled on error response.\n- Network error on mark-all-read mutation: error toast shown, modal stays open for retry.\n- Quick action eligibility server-side re-check: 403 → toast \"Action no longer available.\"\n- Panel retry: re-fetches GET /api/dashboard; failed panel re-renders from new response.\n- DashboardPanel shared wrapper component: handles loading/empty/error/retry state machine. Each panel specializes only success content.\n- All 12 test scenarios in Section 6 required before rollout.\n- 20% holdout group in feature flag rollout. Go/no-go: login-to-first-task mean ≤ 45s vs. holdout, permission-error delta ≤ +2%, p95 < 200ms.\n- p95 target: GET /api/dashboard < 200ms. Alert at > 500ms p95.\n- Dashboard instrumentation: metrics and structured logs as specified in Section 8.\n- Rollout criteria: Phase 1 (5% internal), Phase 2 (20% + 20% holdout), Phase 3 (full). Rollback: feature flag flip on error rate > 5%/5m.\n- Toast system: singleton store. API: `toast.show({message, type, duration?})`. Max 3 concurrent. Bottom-right. `aria-live=\"polite\"`.\n- Panel order: QuickActions (top), NotificationsPanel (middle), ActivityFeed (bottom). Mobile: vertical stack. md/lg: 2-column (QA+NP left, AF right).\n- State copy: Activity empty: \"No recent workspace activity.\" Notif empty: \"You're all caught up.\" Error: panel-specific \"Could not load X — Retry.\"\n- Accessibility gate: required before phase-1 rollout. axe scan zero violations + keyboard walkthrough + VoiceOver/NVDA spot-check.\n<!-- /autoplan-accepted:ceo -->\n\n<!-- AUTONOMOUS DECISION LOG -->\n## Decision Audit Trail\n\n| # | Phase | Decision | Classification | Principle | Rationale | Rejected |\n|---|-------|----------|----------------|-----------|-----------|---------|\n| 0 | CEO | SELECTIVE EXPANSION mode | Mechanical | P6 | Pre-selected by /autoplan; feature enhancement on existing system | N/A |\n| 1 | CEO | Approach A (full dashboard) | Mechanical | P6, P1 | User has scoped this; complete solution preferred | Approach B (partial, 6/10 completeness), Approach C (out of scope) |\n| 2 | CEO | Partial failure: panel isolation | Mechanical | P1 | Complete solution — partial data returned, failed panels show error UI | 500 on any panel failure |\n| 3 | CEO | Parallel fetches (Promise.all) | Mechanical | P1, P5 | Sequential would triple p99; explicit parallel is the complete solution | Sequential fetch |\n| 4 | CEO | Rate limit on GET /api/dashboard | Mechanical | P1 | Security non-optional; new endpoint is a DoS vector without rate limit | No rate limit |\n| 5 | CEO | Error rescue table added to plan | Mechanical | P1 | Named exception classes, explicit rescue actions — no catch-all | Unspecified rescue |\n| 6 | CEO | XSS: text nodes for user content | Mechanical | P1 | Security non-optional; HTML render of user content = XSS | innerHTML allowed |\n| 7 | CEO | Double-click protection on modal | Mechanical | P1 | Duplicate mutation on double-click = data integrity risk | No protection |\n| 8 | CEO | Error toast + modal stays on mutation failure | Mechanical | P1 | User must be able to retry; closing modal on failure loses context | Close modal on failure |\n| 9 | CEO | Quick action server-side eligibility re-check | Mechanical | P1 | Stale client eligibility = silent access error; server authoritative | Client-only check |\n| 10 | CEO | Panel retry re-fetches aggregate endpoint | Mechanical | P1 | Retry must fetch fresh data; stale retry = bad UX | No retry mechanism |\n| 11 | CEO | DashboardPanel shared wrapper (DRY) | Mechanical | P4, P5 | 3 identical state machines = DRY violation; single implementation | 3 independent state machines |\n| 12 | CEO | All 12 test scenarios required | Mechanical | P1 | Well-tested code non-negotiable; named codepaths need named tests | Partial test coverage |\n| 13 | CEO | 20% holdout group in rollout | Mechanical | P1 | Without holdout, 45s target cannot be measured vs. baseline | A/B without holdout |\n| 14 | CEO | p95 target < 200ms, alert > 500ms | Mechanical | P1 | Observability non-optional; target needed before rollout | No latency target |\n| 15 | CEO | Instrumentation plan added | Mechanical | P1 | Observability non-optional; new codepaths need metrics + logs | No instrumentation |\n| 16 | CEO | Rollout criteria + phases defined | Mechanical | P1 | CEO subagent CRITICAL — no criteria = ship without knowing if it worked | Unspecified rollout |\n| 17 | CEO | Toast singleton + defined API | Mechanical | P1, P5 | New infra needs defined contract; singleton prevents stacking issues | Ad-hoc toast impl |\n| 18 | CEO | Panel order + state copy | Mechanical | P1, P5 | Explicit hierarchy + copy prevents AI slop at implementation time | Unspecified |\n| 19 | CEO | Accessibility gate pre-rollout | Mechanical | P1 | Accessibility is hard gate (plan requirement); no gate = slip risk | Checklist item only |\n"
}