# Phase 11: Visual Design, Responsive Layout & Cleanup - Discussion Log

> **Audit trail only.** Do not use as input to planning, research, or execution agents.
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

**Date:** 2026-06-16
**Phase:** 11-visual-design-responsive-layout-cleanup
**Areas discussed:** Sidebar state, Visual polish depth, Dead code scope

---

## Existing Plans Gate

| Option | Description | Selected |
|--------|-------------|----------|
| View existing plans | Show what plans were created before deciding | ✓ |
| Continue and replan after | Capture context now, then replan | |
| Cancel | Stop here | |

**User's choice:** Viewed plans first, then chose "Continue and replan after"
**Notes:** User reviewed all 6 existing plans (11-01 through 11-06) before proceeding. Plans looked solid in structure; user wants context captured so plans can be rebuilt with decisions locked in.

---

## Sidebar State

| Option | Description | Selected |
|--------|-------------|----------|
| App.vue / AdminLayout.vue refs | Local ref() in layout root. Simple, no store overhead. | |
| Shared useLayoutStore (Pinia) | One store, two fields. Any component can close the drawer. | |
| You decide | Researcher picks cleanest option given actual component tree | ✓ |

**User's choice:** You decide (Claude's discretion)
**Notes:** ROADMAP.md pitfall constraint (§Pitfall 8) is locked — state must not live in AppSidebar/AdminSidebar own data(). Researcher will read actual component tree and choose between Pinia store or layout-root ref based on whether child components (e.g., nav links, "Back to app" button) need to close the drawer.

---

## Visual Polish Depth

**Question 1: Ambition level**

| Option | Description | Selected |
|--------|-------------|----------|
| Discipline only | Fix VISUAL-01..04 only. No visual redesign. | |
| Polish + subtle refinements | Fix requirements AND allow minor improvements where things look off (shadows, border radius, color tone drift). Still no new palette. | ✓ |

**User's choice:** Polish + subtle refinements
**Notes:** User wants things to look noticeably better where there's clear visual drift, not just mechanically compliant.

**Question 2: Known problem areas**

| Option | Description | Selected |
|--------|-------------|----------|
| No, let the researcher find them | Systematic full audit | ✓ |
| Yes, I have specific complaints | User would specify targets | |

**User's choice:** Researcher does full audit
**Notes:** No specific components flagged by user. Full discovery expected.

---

## Dead Code Scope

| Option | Description | Selected |
|--------|-------------|----------|
| Frontend only | Stick to 6 existing plans. Backend was cleaned in Phase 8. | ✓ |
| Frontend + backend | Also sweep backend for unused routes, dead utilities, stale imports. | |

**User's choice:** Frontend only
**Notes:** Backend was decomposed and cleaned in Phase 8. No backend dead-code sweep needed in this phase.

---

## Claude's Discretion

- **Sidebar state implementation** — Pinia store vs. layout refs; researcher decides based on actual component tree
- **Focus ring color** — pick one consistent color for focus-visible rings (recommendation: `ring-amber-500` or neutral `ring-blue-500`)
- **Typography scale definition** — enumerate actual sizes found in codebase, normalize to smallest consistent set, document in plan verification
- **Minor visual refinement scope** — researcher flags specific items during audit; apply only what has clear improvement value

## Deferred Ideas

None — discussion stayed within phase scope.