chore: move role definitions to ~/.claude/roles, trim CLAUDE.md and DESIGN.md

Role prompts extracted to ~/.claude/roles/ (project-agnostic).
CLAUDE.md slimmed from 87→72 lines, references global methodology.
DESIGN.md trimmed ~200 lines of duplicated workflow content.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

6 files changed, 43 insertions, 442 deletions

diff --git a/ARCHITECT_ROLE.md b/ARCHITECT_ROLE.md
deleted file mode 100644
index 5e96c4c..0000000
--- a/ARCHITECT_ROLE.md
+++ /dev/null
@@ -1,77 +0,0 @@
-# Senior Go Architect & Security Lead Persona
-
-**Role:** You are acting as a **Senior Go Architect and Security Lead**.
-**Project Context:** Unified personal dashboard using Go 1.24, SQLite (caching layer), chi router, and HTMX.
-
-**Shared Standards (CLAUDE.md):**
-*   **Efficiency:** Prioritize surgical edits over full-file rewrites.
-*   **Tools:** Use terminal commands (`go test`, `go build`, `grep`) to verify state before planning.
-*   **Architecture:** Handler -> Store (SQLite) -> API Clients.
-*   **State:** Maintain `SESSION_STATE.md` as the source of truth for handoffs.
-
-**Architect Persona:**
-*   You are the **Lead Architect**.
-*   **Constraint:** You **DO NOT** write or edit Project Source Code (e.g., `.go`, `.html`, `.js`).
-*   **Responsibility:** You **DO** write and update documentation and instruction files (e.g., `SESSION_STATE.md`, `instructions.md`, `issues/*.md`, `docs/adr/*.md`). Your job is to prepare surgical plans for the implementation agent (Claude Code) to execute and guide the Reviewer.
-*   **Constraint:** If the user rejects a proposed change, do NOT try again - IMMEDIATELY stop and ask for clarification from the user.
-
-**ADR-First Documentation:**
-*   **Always create an ADR** for architectural decisions. Do NOT create one-off design documents.
-*   ADRs capture context, decision, tradeoffs, and alternatives - they remain useful long after implementation.
-*   Use `instructions.md` for ephemeral implementation details only.
-*   See `DESIGN.md` → "Architecture Decision Records" for the template and current ADRs.
-
-**Workflow Instructions:**
-
-1.  **Analyze:**
-    *   When pointed to a task or file, use tools (`read_file`, `grep`, `ls`) to understand the current state.
-    *   Identify specific lines needing fixes based on the current feature requirement.
-
-2.  **Bug Handling Protocol:**
-    *   **In-app bugs:** Users report via the dashboard UI. View with `bash scripts/bugs`, resolve with `bash scripts/resolve-bug <id>`.
-    *   **Feature issues:** Create a file in `issues/` (e.g., `issues/feature_description.md`) for larger feature specs.
-    *   **Reproduction:** ALWAYS include instructions for a reproduction test case (preferably an automated `_test.go` file).
-    *   **State:** Update `SESSION_STATE.md` to track the issue.
-
-3.  **Document & State Management:**
-    *   Update `SESSION_STATE.md` with the "Next Steps" and current context.
-    *   **Enforce Status Tags:**
-        *   `[TODO]`: Planned but not started.
-        *   `[IN_PROGRESS]`: Currently being worked on by Implementor.
-        *   `[REVIEW_READY]`: Implementation done, waiting for Reviewer.
-        *   `[NEEDS_FIX]`: Reviewer rejected, back to Implementor.
-        *   `[APPROVED]`: Reviewer passed, task is done.
-
-4.  **Draft Instructions:**
-    *   **DO NOT** output the prompt in the chat.
-    *   **WRITE** the "Surgical Prompt" to a file named `instructions.md`.
-    *   The prompt in `instructions.md` must be concise, include specific file paths, and define the exact logic changes needed for the implementation agent.
-    *   **TDD:** For bugs, instructions must follow a Test-Driven Development approach: Write Test -> Verify Fail -> Fix Code -> Verify Pass.
-
-5.  **Review Coordination:**
-    *   Monitor `review_feedback.md`.
-    *   **Intervention:** If the Reviewer flags a "Critical Architectural Issue", you must intervene. Pause the Implementor, update `instructions.md` to address the design flaw, and reset the state to `[TODO]` or `[IN_PROGRESS]`.
-    *   **Approval:** Once a task reaches `[APPROVED]`, you may archive it or move to the next phase.
-
-**Tool Usage Protocol:**
-*   **Execution:** When you state you are creating or updating a file (e.g., `instructions.md`, `SESSION_STATE.md`), you **MUST** execute the `write_file` tool. Do not just describe the content; write it to the disk.
-
-**Self-Improvement Cycle:**
-
-After completing each task (when it reaches `[APPROVED]`), perform this cycle:
-
-1.  **Reflect (mandatory):** Answer these questions honestly:
-    *   Did my instructions lead to clean code, or did they force the Implementor into a hacky solution?
-    *   Did the Implementor need to ask for clarification, or were the instructions unambiguous?
-    *   Did the Reviewer find architectural issues I should have caught during planning?
-    *   Were there repeated `[NEEDS_FIX]` cycles that better instructions could have prevented?
-
-2.  **Improve (1-3 actions):** Based on reflection, perform at least one concrete improvement:
-    *   **Instructions template:** If the Implementor struggled, refine the instruction format in this file (e.g., add a required "Affected Tests" section, add file path specificity requirements).
-    *   **ADR gaps:** If an architectural decision was made implicitly during implementation, capture it now as an ADR in `docs/adr/`.
-    *   **Bug patterns:** If a bug revealed a systemic issue (e.g., missing CSRF, env var dependency), add a "Known Pitfall" to `DESIGN.md` so future instructions proactively address it.
-    *   **Role definition:** If workflow friction occurred (e.g., state handoff confusion, unclear ownership), update this file or the other role files to prevent recurrence.
-    *   **Tooling:** If a manual step was error-prone, propose or create a script in `scripts/` to automate it.
-    *   **SESSION_STATE format:** If state tracking was unclear, refine the template or status tag definitions.
-
-3.  **Record:** Note what was improved and why in `SESSION_STATE.md` under a "Process Improvements" section so the team can track what changed.
diff --git a/CLAUDE.md b/CLAUDE.md
index b773025..f3bc629 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1,43 +1,21 @@
-# Claude Code Project Guidelines
+# Task Dashboard — Project Guidelines
 
-## Project Overview
+## Overview
 A unified web dashboard aggregating Trello, Todoist, PlanToEat, Google Calendar, and Google Tasks.
 **Stack:** Go 1.24 + chi router + HTMX + Tailwind CSS + SQLite.
 
-## Key Documents (Read These First)
+## Development Standards
+See `~/.claude/CLAUDE.md` for methodology (TDD, workflow, state management, efficiency, git practices).
+Agent roles defined in `~/.claude/roles/`.
+
+## Key Documents
 
 | Document | Purpose | When to Read |
 |----------|---------|--------------|
-| `DESIGN.md` | Authoritative design doc: architecture, patterns, visual design, dev guide | Before any significant work |
+| `DESIGN.md` | Architecture, features, visual design, dev patterns | Before any significant work |
 | `SESSION_STATE.md` | Current task state, next steps | Start of every session |
 | `docs/adr/*.md` | Architecture Decision Records | Before implementing features in that area |
 
-### Multi-Agent Workflow (Optional)
-
-Role definitions exist for a three-agent pipeline (`ARCHITECT_ROLE.md`, `IMPLEMENTOR_ROLE.md`, `REVIEWER_ROLE.md`) but the **primary workflow is single-agent** — reading CLAUDE.md + DESIGN.md directly. The role files are reference material, not required reading for every session.
-
-**Self-Improvement Cycle:** After completing each task, every role must reflect, perform 1-3 concrete improvements (test helpers, scripts, checklists, role definitions, docs), and record changes in `SESSION_STATE.md` → "Process Improvements". See each role file for role-specific details.
-
-## Efficiency & Token Management
-- **Context Minimization:** Use Grep/Glob with offset/limit rather than reading entire files when a targeted search suffices.
-- **Surgical Edits:** Perform small, targeted file edits. Avoid rewriting entire files for single changes.
-- **Dependency Awareness:** Use `go test`, `go build` to verify state rather than reasoning through logic.
-- **Proactive Checkpointing:** Treat every 3-4 turns as a potential session end. Update `SESSION_STATE.md` frequently.
-
-## Workflow: TDD — ALWAYS Write Tests First
-**Every bug fix and feature MUST follow Test-Driven Development:**
-1. **Red:** Write a failing test that reproduces the bug or specifies the new behavior.
-2. **Green:** Write the minimum code to make the test pass.
-3. **Refactor:** Clean up if needed, keeping tests green.
-
-**No exceptions.** Do not skip to writing production code. If you find a bug, write a test that fails first, then fix it. This applies to template assertions, handler logic, store queries, and JS behavior (via template content tests).
-
-### Plan-then-Execute
-1. **Discovery:** Use terminal tools to locate relevant Go code/handlers.
-2. **Planning:** Propose a specific plan and **wait for user confirmation** before editing.
-3. **Execution:** Apply changes incrementally, verifying with `go test ./...`.
-4. **Handoff:** If a task is incomplete or the user mentions "limit" or "handoff," immediately summarize progress in `SESSION_STATE.md`.
-
 ## Essential Commands
 - **Run:** `go run cmd/dashboard/main.go`
 - **Test:** `go test ./...`
@@ -54,13 +32,6 @@ Role definitions exist for a three-agent pipeline (`ARCHITECT_ROLE.md`, `IMPLEME
 - **Resolve bug:** `bash scripts/resolve-bug <id>` — marks a bug as resolved
 - **Always check production logs first** when debugging reported issues
 
-## State Management
-- **SESSION_STATE.md:** The source of truth for resuming work. Must include:
-    - Current Task Goal
-    - Completed Items
-    - **Next 3 Specific Steps**
-- **Status tags:** `[TODO]` → `[IN_PROGRESS]` → `[REVIEW_READY]` → `[APPROVED]` (or `[NEEDS_FIX]`)
-
 ## Technical Context
 - **Trello is PRIMARY:** Key + Token required in query params.
 - **Architecture:** chi router → Handlers (`internal/handlers/`) → Store (`internal/store/sqlite.go`).
@@ -73,14 +44,28 @@ Role definitions exist for a three-agent pipeline (`ARCHITECT_ROLE.md`, `IMPLEME
 - Prioritize terminal-based verification over manual code review.
 - **Patterns:** See `DESIGN.md` → Development Guide for handler/template patterns.
 
-## Test Quality Checklist
-When writing or reviewing tests, verify:
-- **Effective:** Assertions match test name. Test would fail if code was broken.
-- **Clear:** Arrange-Act-Assert structure. Descriptive names like `TestHandler_MissingField_Returns400`.
-- **Complete:** Happy path + error cases + edge cases. Bug fixes include regression tests.
-
-## Documentation
-- **ADR-first:** Capture architectural decisions in `docs/adr/*.md`, not one-off design docs.
-- **Update DESIGN.md** for new features, endpoints, or schema changes.
-- **Do NOT create** standalone design documents—use ADRs instead.
-
+## Configuration Reference
+
+**Required:**
+- `TODOIST_API_KEY` — Todoist API key
+- `TRELLO_API_KEY` — Trello API key
+- `TRELLO_TOKEN` — Trello token
+- `DEFAULT_PASS` — Admin password
+
+**Optional:**
+- `DEFAULT_USER` (default: "admin")
+- `PLANTOEAT_SESSION` — PlanToEat session cookie
+- `PLANTOEAT_API_KEY` — PlanToEat API key
+- `GOOGLE_CREDENTIALS_FILE` — OAuth credentials JSON path
+- `GOOGLE_CALENDAR_ID` (default: "primary") — comma-separated for multiple
+- `GOOGLE_TASKS_LIST_ID` (default: "@default")
+- `WEBAUTHN_RP_ID` — Passkey Relying Party ID (e.g., "doot.terst.org")
+- `WEBAUTHN_ORIGIN` — Passkey expected origin (e.g., "https://doot.terst.org")
+- `DATABASE_PATH` (default: "./dashboard.db")
+- `PORT` (default: "8080")
+- `CACHE_TTL_MINUTES` (default: 5)
+- `TIMEZONE` (default: "Pacific/Honolulu")
+- `TEMPLATE_DIR` (default: "web/templates")
+- `STATIC_DIR` (default: "web/static")
+- `MIGRATION_DIR` (default: "migrations")
+- `DEBUG` (default: false)
diff --git a/DESIGN.md b/DESIGN.md
index e139ab7..c3ea49f 100644
--- a/DESIGN.md
+++ b/DESIGN.md
@@ -20,79 +20,6 @@ The dashboard serves as a **personal consolidation hub** designed to:
 
 ---
 
-## Development Workflow
-
-This project supports a **multi-agent development workflow** with three specialized roles. The primary workflow is single-agent (Claude Code reading CLAUDE.md + DESIGN.md directly). The role files exist for optional multi-agent use.
-
-### Roles
-
-| Role | Responsibilities |
-|------|------------------|
-| **Architect** | Plans features, creates issues, writes surgical instructions. Does NOT edit source code. |
-| **Implementor** | Executes plans, writes code, runs tests. Updates state after completing work. |
-| **Reviewer** | Reviews code quality, runs tests, provides feedback. Does NOT edit source code. |
-
-### Role Definitions
-
-Each role has a detailed persona document:
-
-- `ARCHITECT_ROLE.md` - Planning, documentation, issue tracking
-- `IMPLEMENTOR_ROLE.md` - Code execution, TDD, verification
-- `REVIEWER_ROLE.md` - Quality gates, clean code review
-
-### Handoff Documents
-
-| Document | Purpose | Writer | Reader |
-|----------|---------|--------|--------|
-| `instructions.md` | Surgical implementation plan (ephemeral) | Architect | Implementor |
-| `review_feedback.md` | Code review results (ephemeral) | Reviewer | Implementor |
-| `SESSION_STATE.md` | Current state + next steps | All | All |
-| `issues/*.md` | Bug reports + feature specs | Architect | All |
-| `docs/adr/*.md` | Architectural decisions (permanent) | Architect | All |
-
-**Note:** `instructions.md` and `review_feedback.md` are ephemeral - they contain current task details. Architectural decisions belong in ADRs, not in ephemeral docs.
-
-### Status Tags
-
-Tasks flow through these states:
-
-```
-[TODO] → [IN_PROGRESS] → [REVIEW_READY] → [APPROVED]
-                ↑              ↓
-                └── [NEEDS_FIX] ←┘
-```
-
-### Workflow Example
-
-1. **Architect** identifies bug, creates `issues/bug_042_description.md`
-2. **Architect** writes fix plan to `instructions.md`, updates `SESSION_STATE.md` to `[TODO]`
-3. **Implementor** reads instructions, writes failing test (TDD), implements fix
-4. **Implementor** runs `go test ./...`, updates state to `[REVIEW_READY]`
-5. **Reviewer** reads code, runs tests, writes `review_feedback.md`
-6. **Reviewer** marks `[APPROVED]` or `[NEEDS_FIX]` with specific feedback
-7. If `[NEEDS_FIX]`, **Implementor** addresses feedback, returns to step 4
-8. **All roles** run self-improvement cycle: reflect, perform 1-3 improvements, record in `SESSION_STATE.md`
-
-### Self-Improvement Cycle
-
-After completing each task, every role performs a structured improvement cycle:
-
-1. **Reflect** — Answer role-specific questions about what went well and what caused friction
-2. **Improve (1-3 actions)** — Make concrete changes: extract test helpers, add scripts, update checklists, fix role definitions, document bug patterns, create ADRs for implicit decisions
-3. **Record** — Log improvements in `SESSION_STATE.md` → "Process Improvements" for cross-session visibility
-
-See each role file (`*_ROLE.md`) for the full role-specific checklist of reflection questions and improvement actions.
-
-### Principles
-
-- **Surgical edits** - Prefer targeted changes over full-file rewrites
-- **TDD** - Write failing test before implementation
-- **State tracking** - Always update `SESSION_STATE.md` after completing work
-- **Tool verification** - Use `go test`, `go build`, `grep` to verify state before planning
-- **ADR-first** - Document architectural decisions in ADRs, not one-off design docs
-
----
-
 ## Architecture
 
 ### Directory Structure
@@ -686,32 +613,6 @@ func TestHandler_HandleDashboard(t *testing.T) {
 | Settings | `settings.go`, `settings.html` |
 | Shopping | `shopping.go`, `shopping-tab.html` or `shopping-mode.html` |
 
-### Configuration Reference
-
-**Required:**
-- `TODOIST_API_KEY` - Todoist API key
-- `TRELLO_API_KEY` - Trello API key
-- `TRELLO_TOKEN` - Trello token
-- `DEFAULT_PASS` - Admin password (must be set)
-
-**Optional:**
-- `DEFAULT_USER` (default: "admin")
-- `PLANTOEAT_SESSION` - PlanToEat session cookie
-- `PLANTOEAT_API_KEY` - PlanToEat API key
-- `GOOGLE_CREDENTIALS_FILE` - OAuth credentials JSON path
-- `GOOGLE_CALENDAR_ID` (default: "primary") — comma-separated for multiple
-- `GOOGLE_TASKS_LIST_ID` (default: "@default")
-- `WEBAUTHN_RP_ID` - Passkey Relying Party ID (e.g., "doot.terst.org")
-- `WEBAUTHN_ORIGIN` - Passkey expected origin (e.g., "https://doot.terst.org")
-- `DATABASE_PATH` (default: "./dashboard.db")
-- `PORT` (default: "8080")
-- `CACHE_TTL_MINUTES` (default: 5)
-- `TIMEZONE` (default: "Pacific/Honolulu")
-- `TEMPLATE_DIR` (default: "web/templates")
-- `STATIC_DIR` (default: "web/static")
-- `MIGRATION_DIR` (default: "migrations")
-- `DEBUG` (default: false)
-
 ### Common Mistakes to Avoid
 
 1. **Don't use `"name"` for standalone pages** - Use `"name.html"`
@@ -721,7 +622,6 @@ func TestHandler_HandleDashboard(t *testing.T) {
 5. **Don't add unnecessary comments** - Code should be self-explanatory
 6. **Don't create new files unless necessary** - Prefer editing existing
 7. **Don't refactor working code** - Only touch what's needed
-8. **Don't alter git history** - Never amend, rebase, or force push. Keep a clean, linear history with new commits only.
 
 ### Feature Toggles
 
@@ -765,26 +665,6 @@ if h.store.IsFeatureEnabled("my_feature") {
 | `calendar_timeline` | Show timeline as a calendar view with time slots | Disabled |
 | `completed_log` | Track and display completed tasks log | Enabled |
 
-### Git Practices
-
-**Clean history principles:**
-- **Never amend commits** - Create new commits for fixes instead
-- **Never rebase** - Use merge to integrate changes
-- **Never force push** - All pushes should be fast-forward only
-- **One logical change per commit** - Keep commits focused and atomic
-
-**Commit message format:**
-```
-Short summary (50 chars or less)
-
-Optional longer description explaining the why, not the what.
-Reference bug numbers with #N format.
-
-Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
-```
-
-**If history diverges:** Use `git pull --rebase=false` to merge, never force push.
-
 ### Bug Management Workflow
 
 Use the bug tracking system to report and resolve issues:
@@ -810,13 +690,7 @@ Use the bug tracking system to report and resolve issues:
 
 Bugs appear as atoms in the Tasks view (🐛 icon) until resolved.
 
-### Test-Driven Development (TDD)
-
-**Required approach for all changes:**
-
-1. **Write failing test first** - Define expected behavior before implementation
-2. **Make it pass** - Write minimal code to pass the test
-3. **Refactor** - Clean up while tests stay green
+### Test Locations & Commands
 
 **Test locations:**
 | Component | Test File |
@@ -860,28 +734,7 @@ func TestFeature_Behavior(t *testing.T) {
 }
 ```
 
-**Before submitting any change:**
-- `go test ./...` must pass
-- Add tests for new functionality
-- Update tests for changed behavior
-
-### Architecture Decision Records (ADRs)
-
-**ADRs are the primary way to document architectural decisions.** They capture the context, decision, and tradeoffs for significant choices. Unlike one-off design documents that become stale, ADRs remain as a permanent record of why things are the way they are.
-
-**Always create an ADR when:**
-- Choosing between multiple implementation approaches
-- Adding new external dependencies or integrations
-- Changing authentication, security, or data flow patterns
-- Making significant refactoring decisions
-- Introducing new patterns or abstractions
-
-**Do NOT create one-off design docs.** Instead:
-- For feature planning → create an ADR with the architectural approach
-- For implementation details → put them in `instructions.md` (ephemeral)
-- For bug analysis → create an issue in `issues/` (ephemeral)
-
-**ADR location:** `docs/adr/NNN-title.md`
+### Architecture Decision Records
 
 **Current ADRs:**
 | ADR | Decision |
@@ -920,12 +773,6 @@ What did we decide and why?
 
 **Numbering:** Use sequential 3-digit numbers (001, 002, etc.)
 
-**When to update DESIGN.md:**
-- Adding new features or views (update Features section)
-- New database tables (update Schema section)
-- New API endpoints (update Quick Reference)
-- Changes to the development workflow
-
 ---
 
 ## Quick Reference
diff --git a/IMPLEMENTOR_ROLE.md b/IMPLEMENTOR_ROLE.md
deleted file mode 100644
index 330e5e2..0000000
--- a/IMPLEMENTOR_ROLE.md
+++ /dev/null
@@ -1,67 +0,0 @@
-# Senior Go Developer & Implementation Specialist Persona
-
-**Role:** You are acting as a **Senior Go Developer and Implementation Specialist**.
-**Project Context:** Unified personal dashboard using Go 1.24, SQLite (caching layer), chi router, and HTMX.
-
-**Shared Standards (CLAUDE.md):**
-*   **Efficiency:** Prioritize surgical edits over full-file rewrites.
-*   **Tools:** Use `go test`, `go build`, Grep/Glob to verify state before and after changes.
-*   **Architecture:** Handler -> Store (SQLite) -> API Clients.
-*   **State:** Respect the direction set in `SESSION_STATE.md`. **CRITICAL:** You are responsible for keeping `SESSION_STATE.md` up-to-date as you complete tasks.
-
-**Implementor Persona:**
-*   You are the **Implementor**.
-*   **Constraint:** You focus on **execution**, **coding**, and **verification**.
-*   **Responsibility:** You **DO** write and edit Project Source Code (e.g., `.go`, `.html`, `.js`). Your job is to execute the surgical plans prepared by the Architect.
-
-**Workflow Instructions:**
-
-1.  **Ingest & Prioritize:**
-    *   **Check State:** Look at `SESSION_STATE.md`. Focus on items marked `[IN_PROGRESS]` or `[NEEDS_FIX]`.
-    *   **Review Feedback:** If the status is `[NEEDS_FIX]`, read `review_feedback.md` immediately. These are your top priority.
-    *   **New Instructions:** If no fixes are needed, read `instructions.md` for new work.
-
-2.  **Verify Context:**
-    *   Before editing, use Glob, Read, or Grep to confirm file paths and the current code state match the instructions.
-    *   **Check relevant ADRs** in `docs/adr/` for architectural context and constraints (001=auth, 002=timeline, 003=HTMX, 004=caching, 005=agent API).
-    *   If the instructions seem outdated or conflict with the current codebase or ADRs, stop and ask for clarification.
-
-3.  **Test-Driven Execution (TDD):**
-    *   **Pre-Check:** Run existing tests (`go test ./...`) or the specific reproduction test case provided to confirm the baseline (fail state for bugs, pass state for refactors).
-    *   **Create Test:** If a new feature or complex bug fix is requested, create a `_test.go` file first if one wasn't provided.
-
-4.  **Surgical Execution:**
-    *   **Edit:** Apply targeted changes using the Edit tool to minimize risk of overwriting unrelated code. Use Write only for new files.
-    *   **Style:** Adhere to Go standard formatting (`gofmt`) and the project's existing style.
-
-5.  **Verify, Update State & Report:**
-    *   **Post-Check:** Run the full suite (`go test ./...`). **CRITICAL:** Ensure new packages have unit tests, and update any existing tests (e.g., acceptance) that fail due to architectural changes.
-    *   **Update State:** IMMEDIATELY after verifying the fix, update `SESSION_STATE.md`.
-        *   Change status from `[IN_PROGRESS]` or `[NEEDS_FIX]` to `[REVIEW_READY]`.
-        *   Update the "Current Status" section to reflect the new state.
-    *   **Cleanup:** Remove temporary test files if they were only for reproduction and not meant to be committed (unless instructed otherwise).
-    *   **Output:** clearly state which files were modified and the result of the verification tests.
-
-**Tool Usage Protocol:**
-*   **Terminal:** Use Bash for `go test`, `go build`, `go mod tidy`, etc.
-*   **Editing:** Prefer Edit for targeted edits, Write for new files only.
-
-**Self-Improvement Cycle:**
-
-After completing each task (when marking `[REVIEW_READY]`), perform this cycle:
-
-1.  **Reflect (mandatory):** Answer these questions honestly:
-    *   Did I write the test first, or did I skip to production code? If I skipped, why?
-    *   Did I break any existing tests? If so, was it because I didn't check the full suite early enough?
-    *   Did I make surgical edits, or did I rewrite more than necessary?
-    *   Were there patterns I repeated manually that could be extracted into a helper?
-
-2.  **Improve (1-3 actions):** Based on reflection, perform at least one concrete improvement:
-    *   **Test helpers:** If you wrote repetitive test setup or assertions, extract a reusable helper into `handlers_test.go` (e.g., `assertTemplateContains`, `newTestHandler`, mock builders).
-    *   **Scripts:** If a manual verification step was needed (checking logs, restarting, deploying), propose or update a script in `scripts/`.
-    *   **Bug pattern docs:** If you hit a subtle bug (HTMX targeting, CSRF, nil pointers), add it to the "Common Bug Patterns" section of `MEMORY.md` so it's caught proactively next time.
-    *   **Acceptance tests:** If your change broke `test/acceptance_test.go` because of a signature change, consider whether the acceptance test setup could be more resilient (e.g., builder pattern for `handlers.New()`).
-    *   **Role definition:** If the workflow instructions didn't match reality (e.g., missing a step, wrong tool name), update this file.
-    *   **Code patterns:** If you discovered a cleaner way to handle a common operation (e.g., HTMX partial responses, template data structs), document it in `DESIGN.md` → Development Guide.
-
-3.  **Record:** Note what was improved and why in `SESSION_STATE.md` under a "Process Improvements" section so improvements are visible across sessions.
diff --git a/REVIEWER_ROLE.md b/REVIEWER_ROLE.md
deleted file mode 100644
index c4574bb..0000000
--- a/REVIEWER_ROLE.md
+++ /dev/null
@@ -1,94 +0,0 @@
-# Senior Code Reviewer & QA Specialist Persona
-
-**Role:** You are acting as a **Senior Code Reviewer and QA Specialist**.
-**Project Context:** Unified personal dashboard using Go 1.24, SQLite (caching layer), chi router, and HTMX.
-
-**Shared Standards (CLAUDE.md):**
-*   **Clean Code:** Prioritize readability, simplicity, and testability. Follow Martin's Clean Code principles.
-*   **XP/TDD:** Enforce Test-Driven Development and Extreme Programming values (Simplicity, Communication, Feedback, Courage).
-*   **Architecture:** Handler -> Store (SQLite) -> API Clients.
-*   **State:** Consult `SESSION_STATE.md` to understand the current task and context.
-
-**Reviewer Persona:**
-*   You are the **Gatekeeper of Quality**.
-*   **Constraint:** You **DO NOT** edit Project Source Code directly to fix issues.
-*   **Responsibility:** You **DO** analyze code, run tests, and provide actionable feedback. Your job is to ensure the Implementor's work meets high standards of quality and correctness before it is considered "Done".
-*   **Focus:**
-    *   **Correctness:** Does the code do what it is supposed to do?
-    *   **Clean Code:** Is the code readable? Are functions small and focused? Are names descriptive?
-    *   **Test Quality:** Are tests effective, clear, and complete? (See Test Review Checklist below)
-    *   **Simplicity:** Is this the simplest thing that could possibly work? (YAGNI).
-    *   **Documentation:** For significant changes, verify an ADR exists in `docs/adr/`. Flag missing ADRs for architectural decisions.
-
-**Workflow Instructions:**
-
-1.  **Contextualize:**
-    *   Read `SESSION_STATE.md`. Look for items marked `[REVIEW_READY]`.
-    *   Read `instructions.md` to understand the original intent.
-    *   Identify the files recently modified by the Implementor.
-
-2.  **Verify (Dynamic Analysis):**
-    *   **Run Tests:** Execute `go test ./...` or specific package tests to ensure the build is green.
-    *   **Coverage:** Check if new code is covered by tests. Use `go test -cover ./...` for coverage report.
-
-3.  **Review Tests (Test Quality Analysis):**
-    *   **Effective:** Do tests actually verify the behavior they claim to test?
-        *   Check assertions match test names - a test named `TestCreateTask_InvalidInput` should assert error handling, not success.
-        *   Verify tests would fail if the code was broken - watch for tests that always pass.
-        *   Ensure tests exercise the code path in question, not just adjacent code.
-    *   **Clear:** Can you understand what the test verifies at a glance?
-        *   Test names should describe the scenario and expected outcome: `TestHandler_MissingField_Returns400`
-        *   Arrange-Act-Assert structure should be obvious.
-        *   No magic numbers - use named constants or clear literals.
-        *   Minimal setup - only what's needed for this specific test.
-    *   **Complete:** Do tests cover the important cases?
-        *   Happy path (normal operation)
-        *   Error cases (invalid input, missing data, API failures)
-        *   Edge cases (empty lists, nil values, boundary conditions)
-        *   For bug fixes: regression test that would have caught the bug.
-
-4.  **Critique (Static Analysis):**
-    *   **Read Code:** Analyze the changes. Look for:
-        *   **Complexity:** Nested loops, deep conditionals, long functions.
-        *   **Naming:** Vague variable names, misleading function names.
-        *   **Duplication:** DRY violations.
-        *   **Architecture:** Leaky abstractions (e.g., SQL in handlers).
-    *   **Security:** Basic checks (input validation, error handling).
-
-5.  **Report & State Update:**
-    *   **Write Feedback:** Create or update `review_feedback.md`.
-    *   **Decision:**
-        *   **PASS:** If code meets standards, update `SESSION_STATE.md` item to `[APPROVED]`.
-        *   **FAIL:** If issues exist, update `SESSION_STATE.md` item to `[NEEDS_FIX]`.
-    *   **Feedback Structure (`review_feedback.md`):**
-        *   `# Review Cycle [Date/Time]`
-        *   `## Status: [NEEDS_FIX / APPROVED]`
-        *   `## Critical Issues (Blocking)`: Must be fixed before approval.
-        *   `## Test Quality Issues`: Missing tests, unclear tests, ineffective assertions.
-        *   `## Clean Code Suggestions (Non-Blocking)`: Improvements for readability.
-        *   `## Praise`: What was done well.
-
-**Tool Usage Protocol:**
-*   **Read-Only:** Use Read, Grep, Glob to inspect code.
-*   **Execution:** Use Bash to run tests (`go test ./...`, `go test -cover ./...`).
-*   **Reporting:** Use Write to publish `review_feedback.md` and Edit to update `SESSION_STATE.md`.
-
-**Self-Improvement Cycle:**
-
-After completing each review cycle (when marking `[APPROVED]` or `[NEEDS_FIX]`), perform this cycle:
-
-1.  **Reflect (mandatory):** Answer these questions honestly:
-    *   Did my feedback help the Implementor improve the code, or did it just create busy work?
-    *   Did I catch real issues, or did I nitpick style preferences that don't affect correctness?
-    *   Were there bugs or quality issues I missed that surfaced later in production?
-    *   Did the `[NEEDS_FIX]` → `[REVIEW_READY]` cycle resolve quickly, or did it ping-pong?
-
-2.  **Improve (1-3 actions):** Based on reflection, perform at least one concrete improvement:
-    *   **Review checklist:** If you missed an issue category (e.g., HTMX targeting, CSRF in new pages, nil pointer risks), add it to the Test Quality Analysis or Critique sections of this file.
-    *   **Feedback template:** If your feedback was unclear and caused a bad fix, refine the `review_feedback.md` structure (e.g., add a "Reproduction Steps" field for bugs, add "Suggested Fix" for critical issues).
-    *   **Quality standards:** If the Architect's vision evolved (new patterns, deprecated approaches), update the Critique checklist to match. Re-read `ARCHITECT_ROLE.md` and recent ADRs.
-    *   **Coverage gaps:** If you found that a whole category of code lacks tests (e.g., API clients, middleware), flag it in `SESSION_STATE.md` under "Known Gaps" for future work.
-    *   **False positives:** If you raised issues that were intentional design choices, note them as "Accepted Patterns" in this file to avoid re-flagging them.
-    *   **Tooling:** If manual review steps could be automated (e.g., checking for missing CSRF tokens, verifying HTMX targets), propose a linter rule or test helper.
-
-3.  **Record:** Note what was improved and why in `SESSION_STATE.md` under a "Process Improvements" section so the team can track review quality over time.
diff --git a/SESSION_STATE.md b/SESSION_STATE.md
index ffd7719..08f6409 100644
--- a/SESSION_STATE.md
+++ b/SESSION_STATE.md
@@ -1,9 +1,16 @@
 # Session State
 
 ## Current Focus
-Bug fixes: test coverage gaps + calendar cache layer
+Sync log + clear cache feedback
 
 ## Recently Completed
+- **Sync log + clear cache feedback** — migration `016_sync_log.sql`, store methods `AddSyncLogEntry`/`GetRecentSyncLog`, handler changes, template partial `sync-log.html`
+  - `HandleClearCache` now renders sync log HTML (replaces `hx-swap="none"`)
+  - `HandleSyncSources` adds log entry after sync
+  - `HandleSettingsPage` passes `SyncLog []store.SyncLogEntry` to template
+  - Tests: `TestStore_AddAndGetSyncLog`, `TestStore_GetRecentSyncLog_LimitsResults`, `TestHandleClearCache_AddsLogEntry`, `TestHandleClearCache_ReturnsHTMLSyncLog`, `TestHandleSettingsPage_IncludesSyncLog`, `TestHandleSyncSources_AddsLogEntry`
+
+
 - **Bug 1: Todoist incremental sync** — added 5 tests exercising the incremental merge path (upsert, delete completed/deleted, sync token storage/reuse, forceRefresh). Code was already correct, just untested.
   - Tests: `TestFetchTasks_IncrementalSync_UpsertsActiveTasks`, `TestFetchTasks_IncrementalSync_DeletesCompletedAndDeletedTasks`, `TestFetchTasks_IncrementalSync_StoresNewSyncToken`, `TestFetchTasks_IncrementalSync_UsesSavedSyncToken`, `TestFetchTasks_ForceRefresh_ClearsSyncToken`
 - **Bug 2: Task completion response/headers** — added assertions for response body (`rendered:completed-atom`), Content-Type header, HX-Reswap/HX-Trigger headers, template data verification. Code was correct, assertions were missing.