# Watchlist Visual Redesign - Integrate as Tab on /web

## TL;DR

> **Quick Summary**: Refactor standalone `/watchlist` page to integrate as 5th tab on `/web` page, maintaining all existing features (scheduler, filters, settings) while using exact same visual design.
>
> **Deliverables**:
> - `components/watchlist_section.html` - New component with watchlist content
> - Updated `index.html` - Include watchlist tab structure
> - Updated `tabs.js` - Load watchlist content instead of redirecting
> - Updated `main.js` - Add watchlist case to button activation logic
> - Updated `style.css` - Move watchlist inline styles (190 lines)
> - Updated `watchlist-ui.js` - Extract settings modal HTML to function
> - Updated `main.py` - Redirect `/watchlist` → `/web#watchlist`
>
> **Estimated Effort**: Medium
> **Parallel Execution**: NO - sequential (due to dependencies)
> **Critical Path**: Task 1 → Task 4 → Task 6 → Task 7 → Task 9

---

## Context

### Original Request
User wants `/watchlist` page to have exact same visual base as `/web` page, so users don't see any difference between pages except content.

### Interview Summary
**Key Discussions**:
- **Approach decision**: User chose "Onglet sur /web (Recommandé)" - integrate watchlist as 5th tab on /web page
- **Design constraint**: No visual difference between /web and watchlist except content
- **Functional requirement**: Keep all existing watchlist features (scheduler, filters, settings modal)

**Research Findings**:
- `/web` uses `base.html` + `components/header.html` with clean structure
- `/watchlist` is standalone HTML with 190 lines of inline CSS, 310 lines of inline JavaScript
- Header already has watchlist button (components/header.html lines 47-52)
- tabs.js currently redirects to `/watchlist` instead of loading content (line 390)
- main.js button activation logic missing watchlist case (lines 220-235)
- watchlist.js and watchlist-ui.js already loaded in base.html (lines 21-22)

### Metis Review
**Identified Gaps** (addressed in plan):
- **Gap 1**: Missing `switchTab()` case in main.js → Task 4
- **Gap 2**: No `window.watchlistTabLoaded` flag → Task 1
- **Gap 3**: Watchlist has duplicate tab navigation (lines 214-220) → Task 8 (remove)
- **Gap 4**: Settings modal is inline HTML (lines 421-527) → Task 3 (extract to function)
- **Gap 5**: 30-second interval management needs logic → Task 6 (clear/restart on tab switch)
- **Gap 6**: DOM ID conflicts need verification → Task 2 (pre-check)
- **Gap 7**: Filter tabs use `.filter-tab` class, need CSS conflict check → Task 2 (pre-check)

---

## Work Objectives

### Core Objective
Integrate watchlist as seamless tab on /web page with identical visual design and all existing functionality preserved.

### Concrete Deliverables
- `components/watchlist_section.html` - New template component
- Modified `index.html` - Include watchlist tab div
- Modified `tabs.js` - Load watchlist content, not redirect
- Modified `main.js` - Add watchlist button activation case
- Modified `style.css` - Add watchlist-specific styles (190 lines)
- Modified `watchlist-ui.js` - Extract settings modal to function
- Modified `main.py` - Add `/watchlist` redirect endpoint

### Definition of Done
```bash
# Navigate to /web#watchlist
# Verify: Watchlist tab is active (highlighted)
# Verify: Same header/nav as other tabs
# Verify: Scheduler panel displays correctly
# Verify: Filter tabs (All/Active/Paused/Completed) work
# Verify: Settings modal opens/closes correctly
# Verify: 30-second status refresh works
# Verify: Switching away clears interval, switching back restarts
```

### Must Have
- Exact same visual design as /web (colors, fonts, spacing, layout)
- All watchlist features work (scheduler, filters, settings, list display)
- No duplicate navigation (watchlist's own tab bar removed)
- 30-second interval management (clear on tab switch away, restart when active)
- Filter tabs function identically to original
- Settings modal functional (save, toggle switches, close)
- `/watchlist` URL redirects to `/web#watchlist`

### Must NOT Have (Guardrails)
- No functional changes to watchlist behavior
- No breaking changes to existing features
- No duplicate tab navigation (watchlist's own tabs removed)
- No visual differences between /web and watchlist
- No modifications to `/web` page design (only structure changes for integration)
- No DOM ID conflicts with existing tabs
- No CSS class conflicts between `.tab` and `.filter-tab`
- No infinite interval loops (must clear when switching away)

---

## Verification Strategy (MANDATORY)

> **ZERO HUMAN INTERVENTION** — ALL verification is agent-executed. No exceptions.
> Acceptance criteria requiring "user manually tests/confirms" are FORBIDDEN.

### Test Decision
- **Infrastructure exists**: YES (pytest for backend, browser testing for frontend)
- **Automated tests**: Tests-after (manual verification via browser)
- **Framework**: Playwright for UI verification

### QA Policy
Every task MUST include agent-executed QA scenarios (see TODO template below).
Evidence saved to `.sisyphus/evidence/task-{N}-{scenario-slug}.{ext}`.

- **Frontend/UI**: Use Playwright (playwright skill) — Navigate, interact, assert DOM, screenshot
- **API/Backend**: Use Bash (curl) — Verify redirect endpoint works
- **Integration**: Use Playwright — Test full tab switching workflow

---

## Execution Strategy

### Parallel Execution Waves

> Sequential execution required due to dependencies between tasks.
> Most tasks depend on previous waves completing.

```
Wave 1 (Start Immediately - Pre-implementation checks):
├── Task 1: Add watchlistTabLoaded flag to tabs.js [quick]
├── Task 2: Pre-check for DOM/CSS conflicts [quick]
└── Task 3: Extract settings modal HTML to function [quick]

Wave 2 (After Wave 1 - JavaScript modifications):
├── Task 4: Add watchlist case to main.js switchTab() [quick]
└── Task 5: Remove watchlist redirect from tabs.js [quick]

Wave 3 (After Wave 2 - Create component):
├── Task 6: Create components/watchlist_section.html [visual-engineering]
└── Task 7: Move watchlist inline CSS to style.css [quick]

Wave 4 (After Wave 3 - Integrate):
├── Task 8: Add watchlist tab div to index.html [quick]
└── Task 9: Add watchlist loading logic to tabs.js [quick]

Wave 5 (After Wave 4 - Backend):
├── Task 10: Add /watchlist redirect endpoint to main.py [quick]

Wave 6 (After Wave 5 - Final verification):
├── Task 11: End-to-end testing (Playwright) [unspecified-high]
└── Task 12: Git cleanup [git]
```

### Dependency Matrix

- **1, 2, 3**: — — 4, 5, 6
- **4, 5**: 1, 2, 3 — 9
- **6**: 3 — 7, 8
- **7**: 6 — (independent, just CSS)
- **8, 9**: 4, 5 — 10
- **10**: 8, 9 — 11
- **11**: 1-10 — 12

> Sequential flow: Pre-checks → JS changes → Component creation → Integration → Backend → Testing

### Agent Dispatch Summary

- **1-3**: **3** — T1 → `quick`, T2 → `quick`, T3 → `quick`
- **4-5**: **2** — T4 → `quick`, T5 → `quick`
- **6-7**: **2** — T6 → `visual-engineering`, T7 → `quick`
- **8-9**: **2** — T8 → `quick`, T9 → `quick`
- **10**: **1** — T10 → `quick`
- **11**: **1** — T11 → `unspecified-high` (+ playwright skill)
- **12**: **1** — T12 → `git`

---

## TODOs

> Implementation + Test = ONE Task. Never separate.
> EVERY task MUST have: Recommended Agent Profile + Parallelization info + QA Scenarios.
> **A task WITHOUT QA Scenarios is INCOMPLETE. No exceptions.**

---

- [x] 1. Add watchlistTabLoaded flag to tabs.js

  **What to do**:
  - Open `static/js/tabs.js`
  - Find where loading flags are initialized (around line 360 in DOMContentLoaded)
  - Add `window.watchlistTabLoaded = false;` after other tab loaded flags
  - Ensure flag is set to `true` when watchlist content loads (in tabs.js switchTab override)

  **Must NOT do**:
  - Don't create duplicate flag if already exists (verify first)
  - Don't change existing `animeTabLoaded`, `seriesTabLoaded`, `providersTabLoaded` behavior

  **Recommended Agent Profile**:
  > Select category + skills based on task domain. Justify each choice.
  - **Category**: `quick`
    - Reason: Simple flag addition, clear pattern to follow
  - **Skills**: []
    - No special skills needed - straightforward code modification

  **Parallelization**:
  - **Can Run In Parallel**: NO
  - **Parallel Group**: Sequential
  - **Blocks**: Task 4, Task 5
  - **Blocked By**: None (can start immediately)

  **References** (CRITICAL - Be Exhaustive):

  > The executor has NO context from your interview. References are their ONLY guide.
  > Each reference must answer: "What should I look at and WHY?"

  **Pattern References** (existing code to follow):
  - `static/js/tabs.js:360-395` - Loading flags initialization pattern (animeTabLoaded, seriesTabLoaded)
  - `static/js/tabs.js:388-391` - Where watchlistTabLoaded flag should be set to true

  **API/Type References** (contracts to implement against):
  - N/A (JavaScript flag, no API)

  **Test References** (testing patterns to follow):
  - N/A (simple flag, no tests needed)

  **External References** (libraries and frameworks):
  - N/A

  **WHY Each Reference Matters** (explain the relevance):
  - `tabs.js:360-395` - Shows exact pattern where `animeTabLoaded = false` is initialized, watch for similar pattern to add `watchlistTabLoaded`
  - `tabs.js:388-391` - This is where watchlist currently redirects to /watchlist, needs to set flag instead after loading

  **Acceptance Criteria**:

  > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted.
  > Every criterion MUST be verifiable by running a command or using a tool.

  - [ ] `grep "watchlistTabLoaded" static/js/tabs.js` → returns 2 matches (initialization + setting to true)
  - [ ] Flag initialized to `false` with other loading flags
  - [ ] Flag set to `true` after watchlist content loads

  **QA Scenarios (MANDATORY - task is INCOMPLETE without these):**

  > **This is NOT optional. A task without QA scenarios WILL BE REJECTED.**
  >
  > Write scenario tests that verify the ACTUAL BEHAVIOR of what you built.
  > Minimum: 1 happy path + 1 failure/edge case per task.
  > Each scenario = exact tool + exact steps + exact assertions + evidence path.
  >
  > **The executing agent MUST run these scenarios after implementation.**
  > **The orchestrator WILL verify evidence files exist before marking task complete.**

  ```
  Scenario: Flag initialization and usage
    Tool: Bash (grep)
    Preconditions: tabs.js file exists
    Steps:
      1. grep -n "watchlistTabLoaded" static/js/tabs.js
      2. Verify 2 matches found (initialization + setting to true)
      3. Check line numbers are correct (near other tab loaded flags)
    Expected Result: Exactly 2 matches, both properly positioned
    Failure Indicators: Only 1 match, flag not initialized, or flag in wrong location
    Evidence: .sisyphus/evidence/task-1-flag-init.txt
  ```

  ```
  Scenario: Verify flag follows existing pattern
    Tool: Read
    Preconditions: tabs.js modified
    Steps:
      1. Read static/js/tabs.js lines 360-400
      2. Verify watchlistTabLoaded = false is after animeTabLoaded, seriesTabLoaded, providersTabLoaded
      3. Verify watchlistTabLoaded = true is in switchTab watchlist case
    Expected Result: Flag follows exact same pattern as other tabs
    Failure Indicators: Flag in different section, wrong initialization value, missing setter
    Evidence: .sisyphus/evidence/task-1-flag-pattern.txt
  ```

  **Evidence to Capture**:
  - [ ] task-1-flag-init.txt - Grep output showing 2 matches
  - [ ] task-1-flag-pattern.txt - Context around flag initialization

  **Commit**: NO (groups with Task 2, 3)
  - Message: `feat: add watchlistTabLoaded flag to tabs.js`
  - Files: `static/js/tabs.js`
  - Pre-commit: N/A

---

- [x] 2. Pre-check for DOM/CSS conflicts

  **What to do**:
  - Check for DOM ID conflicts between watchlist and existing tabs
  - Run `grep -r "id=\"watchlistContainer\|id=\"schedulerStatus\" templates/`
  - Run `grep -r "id=\"settingsModal\|id=\"nextRunInfo\" templates/`
  - Run `grep -r "id=\"startSchedulerBtn\|id=\"stopSchedulerBtn\" templates/`
  - Check for CSS class conflicts between `.filter-tab` and existing `.tab` styles
  - Run `grep "filter-tab" static/css/style.css`
  - Document any conflicts found and decide mitigation strategy (rename IDs, use unique prefixes)

  **Must NOT do**:
  - Don't modify any files yet (this is a check-only task)
  - Don't proceed to implementation if conflicts found without documenting

  **Recommended Agent Profile**:
  > Select category + skills based on task domain. Justify each choice.
  - **Category**: `quick`
    - Reason: Simple grep checks, fast verification
  - **Skills**: []
    - No special skills needed

  **Parallelization**:
  - **Can Run In Parallel**: NO
  - **Parallel Group**: Sequential
  - **Blocks**: Task 3, Task 6, Task 7
  - **Blocked By**: None (can start immediately)

  **References** (CRITICAL - Be Exhaustive):

  > The executor has NO context from your interview. References are their ONLY guide.
  > Each reference must answer: "What should I look at and WHY?"

  **Pattern References** (existing code to follow):
  - `templates/watchlist.html:265` - ID `watchlistContainer`
  - `templates/watchlist.html:233` - ID `schedulerStatus`
  - `templates/watchlist.html:237` - ID `nextRunInfo`
  - `templates/watchlist.html:240` - ID `startSchedulerBtn`
  - `templates/watchlist.html:243` - ID `stopSchedulerBtn`
  - `templates/watchlist.html:422` - ID `settingsModal`
  - `templates/watchlist.html:130-148` - `.filter-tab` CSS class

  **API/Type References** (contracts to implement against):
  - N/A

  **Test References** (testing patterns to follow):
  - N/A

  **External References** (libraries and frameworks):
  - N/A

  **WHY Each Reference Matters** (explain the relevance):
  - All ID references - These are the specific IDs that could conflict with existing tabs
  - `.filter-tab` - This CSS class could conflict with existing `.tab` styles

  **Acceptance Criteria**:

  > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted.
  > Every criterion MUST be verifiable by running a command or using a tool.

  - [ ] All watchlist IDs checked against existing templates (grep results saved)
  - [ ] `.filter-tab` CSS class checked against style.css
  - [ ] Conflicts documented (if any found)
  - [ ] No conflicts found OR mitigation strategy documented

  **QA Scenarios (MANDATORY - task is INCOMPLETE without these):**

  ```
  Scenario: Check for DOM ID conflicts
    Tool: Bash (grep)
    Preconditions: templates directory exists
    Steps:
      1. grep -r "id=\"watchlistContainer\|id=\"schedulerStatus\" templates/
      2. grep -r "id=\"settingsModal\|id=\"nextRunInfo\" templates/
      3. grep -r "id=\"startSchedulerBtn\|id=\"stopSchedulerBtn\" templates/
    Expected Result: Each ID appears exactly 1 time (only in watchlist.html)
    Failure Indicators: Any ID appears in multiple files → conflict exists
    Evidence: .sisyphus/evidence/task-2-dom-conflicts.txt
  ```

  ```
  Scenario: Check for CSS class conflicts
    Tool: Bash (grep)
    Preconditions: style.css exists
    Steps:
      1. grep -n "filter-tab" static/css/style.css
      2. grep -n "\\.tab\s" static/css/style.css | head -10
      3. Verify no overlapping definitions between .filter-tab and .tab
    Expected Result: .filter-tab either doesn't exist in style.css OR has unique definitions
    Failure Indicators: .filter-tab conflicts with .tab styles
    Evidence: .sisyphus/evidence/task-2-css-conflicts.txt
  ```

  **Evidence to Capture**:
  - [ ] task-2-dom-conflicts.txt - Grep results for ID conflicts
  - [ ] task-2-css-conflicts.txt - Grep results for CSS conflicts

  **Commit**: NO (groups with Task 1, 3)
  - Message: `test: pre-check DOM/CSS conflicts for watchlist integration`
  - Files: N/A (check-only task)
  - Pre-commit: N/A

---

- [x] 3. Extract settings modal HTML to function

  **What to do**:
  - Open `static/js/watchlist-ui.js`
  - Create new function `createSettingsModal(settings)` that generates modal HTML
  - Extract modal HTML from `templates/watchlist.html` lines 421-527
  - Replace inline HTML in `handleOpenSettings()` with call to `createSettingsModal()`
  - Keep all modal styles (switch, slider) inline with the function or in style.css
  - Ensure modal close function `closeSettingsModal()` still works with new HTML structure

  **Must NOT do**:
  - Don't break existing modal functionality (open, close, save)
  - Don't remove any settings fields (check_interval, auto_download_enabled, etc.)
  - Don't change modal styling (keep exact same visual appearance)

  **Recommended Agent Profile**:
  > Select category + skills based on task domain. Justify each choice.
  - **Category**: `quick`
    - Reason: Simple HTML extraction to function, no complexity
  - **Skills**: []
    - No special skills needed

  **Parallelization**:
  - **Can Run In Parallel**: NO
  - **Parallel Group**: Sequential
  - **Blocks**: Task 6
  - **Blocked By**: None (can start immediately)

  **References** (CRITICAL - Be Exhaustive):

  > The executor has NO context from your interview. References are their ONLY guide.
  > Each reference must answer: "What should I look at and WHY?"

  **Pattern References** (existing code to follow):
  - `templates/watchlist.html:421-527` - Inline modal HTML to extract
  - `templates/watchlist.html:416-538` - `handleOpenSettings()` function using inline HTML
  - `templates/watchlist.html:486-526` - Modal styles (switch, slider) inline in modal HTML

  **API/Type References** (contracts to implement against):
  - N/A

  **Test References** (testing patterns to follow):
  - N/A

  **External References** (libraries and frameworks):
  - N/A

  **WHY Each Reference Matters** (explain the relevance):
  - Lines 421-527 - This is the exact modal HTML that needs to be extracted to a function
  - Lines 486-526 - Modal styles must be preserved when extracting to function

  **Acceptance Criteria**:

  > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted.
  > Every criterion MUST be verifiable by running a command or using a tool.

  - [ ] `createSettingsModal(settings)` function exists in watchlist-ui.js
  - [ ] `handleOpenSettings()` calls `createSettingsModal()` instead of inline HTML
  - [ ] Modal contains all 4 settings fields (check_interval, auto_download_enabled, max_concurrent, notify_on_new_episodes)
  - [ ] Modal styles preserved (switch, slider look identical)

  **QA Scenarios (MANDATORY - task is INCOMPLETE without these):**

  ```
  Scenario: Modal opens correctly
    Tool: Playwright
    Preconditions: /web#watchlist loaded
    Steps:
      1. Navigate to http://localhost:3000/web#watchlist
      2. Click "⚙️ Paramètres" button
      3. Verify modal appears with correct styling
      4. Verify all 4 settings fields visible
      5. Take screenshot
    Expected Result: Modal opens, styled correctly, all fields present
    Failure Indicators: Modal doesn't open, styling broken, fields missing
    Evidence: .sisyphus/evidence/task-3-modal-open.png
  ```

  ```
  Scenario: Modal saves settings
    Tool: Playwright
    Preconditions: Settings modal open
    Steps:
      1. Change "Fréquence de vérification" to 12 hours
      2. Toggle "Téléchargement automatique" ON
      3. Click "💾 Enregistrer" button
      4. Verify modal closes
      5. Re-open settings modal
      6. Verify values persisted
    Expected Result: Settings saved and persisted correctly
    Failure Indicators: Values not saved, modal doesn't close, errors in console
    Evidence: .sisyphus/evidence/task-3-modal-save.txt
  ```

  **Evidence to Capture**:
  - [ ] task-3-modal-open.png - Screenshot of modal open
  - [ ] task-3-modal-save.txt - Test results showing save functionality

  **Commit**: YES (with Tasks 1, 2)
  - Message: `feat: prepare watchlist integration foundation (flags, conflict check, modal extraction)`
  - Files: static/js/tabs.js, static/js/watchlist-ui.js
  - Pre-commit: N/A

---

- [x] 4. Add watchlist case to main.js switchTab()

  **What to do**:
  - Open `static/js/main.js`
  - Find button activation logic (around lines 220-235 based on Metis analysis)
  - Add watchlist case to handle button highlighting when switching tabs
  - Follow same pattern as existing cases (home, anime, series, providers)
  - Ensure `btn.classList.add('active')` is called for watchlist tab button

  **Must NOT do**:
  - Don't break existing tab switching logic
  - Don't modify other tab cases (home, anime, series, providers)

  **Recommended Agent Profile**:
  > Select category + skills based on task domain. Justify each choice.
  - **Category**: `quick`
    - Reason: Simple case addition, follows existing pattern
  - **Skills**: []
    - No special skills needed

  **Parallelization**:
  - **Can Run In Parallel**: NO
  - **Parallel Group**: Sequential
  - **Blocks**: Task 5
  - **Blocked By**: Task 1 (watchlistTabLoaded flag needed for complete context)

  **References** (CRITICAL - Be Exhaustive):

  > The executor has NO context from your interview. References are their ONLY guide.
  > Each reference must answer: "What should I look at and WHY?"

  **Pattern References** (existing code to follow):
  - `static/js/main.js:220-235` - Button activation logic with cases for home, anime, series, providers

  **API/Type References** (contracts to implement against):
  - N/A

  **Test References** (testing patterns to follow):
  - N/A

  **External References** (libraries and frameworks):
  - N/A

  **WHY Each Reference Matters** (explain the relevance):
  - Lines 220-235 - This is where watchlist case needs to be added to highlight watchlist button correctly

  **Acceptance Criteria**:

  > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted.
  > Every criterion MUST be verifiable by running a command or using a tool.

  - [ ] Watchlist case added to button activation logic
  - [ ] Case follows same pattern as existing tab cases
  - [ ] `grep "watchlist" static/js/main.js` shows watchlist handling

  **QA Scenarios (MANDATORY - task is INCOMPLETE without these):**

  ```
  Scenario: Watchlist button highlights correctly
    Tool: Playwright
    Preconditions: /web page loaded
    Steps:
      1. Navigate to http://localhost:3000/web
      2. Click Watchlist tab button
      3. Verify watchlist button has 'active' class
      4. Take screenshot
    Expected Result: Watchlist button highlighted as active
    Failure Indicators: Button not highlighted, wrong button active
    Evidence: .sisyphus/evidence/task-4-button-active.png
  ```

  **Evidence to Capture**:
  - [ ] task-4-button-active.png - Screenshot showing watchlist button active


  **Commit**: NO (groups with Task 5)
  - Message: `feat: add watchlist case to main.js tab switching`
  - Files: `static/js/main.js`
  - Pre-commit: N/A

---


- [x] 5. Remove watchlist redirect from tabs.js

  **What to do**:
  - Open `static/js/tabs.js`
  - Find watchlist case that redirects to `/watchlist` (around line 388-391)
  - Replace redirect logic with content loading logic
  - Add code to load watchlist content instead of redirecting
  - Set `window.watchlistTabLoaded = true` after content loads
  - Follow same pattern as anime, series, providers tabs (load content only once)

  **Must NOT do**:
  - Don't remove the watchlist case entirely (modify to load content instead)
  - Don't change how other tabs load content

  **Recommended Agent Profile**:
  > Select category + skills based on task domain. Justify each choice.
  - **Category**: `quick`
    - Reason: Replace redirect with content loading, follows existing pattern
  - **Skills**: []
    - No special skills needed

  **Parallelization**:
  - **Can Run In Parallel**: NO
  - **Parallel Group**: Sequential
  - **Blocks**: Task 9
  - **Blocked By**: Task 1 (watchlistTabLoaded flag needed)

  **References** (CRITICAL - Be Exhaustive):

  > The executor has NO context from your interview. References are their ONLY guide.
  > Each reference must answer: "What should I look at and WHY?"

  **Pattern References** (existing code to follow):
  - `static/js/tabs.js:372-387` - Content loading patterns for anime, series, providers tabs
  - `static/js/tabs.js:388-391` - Current watchlist redirect to remove

  **API/Type References** (contracts to implement against):
  - N/A

  **Test References** (testing patterns to follow):
  - N/A

  **External References** (libraries and frameworks):
  - N/A

  **WHY Each Reference Matters** (explain the relevance):
  - Lines 372-387 - These show the pattern for loading tab content that watchlist should follow
  - Lines 388-391 - This is the redirect logic that must be replaced with content loading

  **Acceptance Criteria**:

  > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted.
  > Every criterion MUST be verifiable by running a command or using a tool.

  - [ ] Watchlist case no longer redirects to `/watchlist`
  - [ ] Watchlist case loads content instead
  - [ ] `window.location.href = '/watchlist'` removed from watchlist case

  **QA Scenarios (MANDATORY - task is INCOMPLETE without these):**

  ```
  Scenario: Clicking watchlist tab doesn't redirect
    Tool: Playwright
    Preconditions: /web page loaded, watchlist_section.html exists
    Steps:
      1. Navigate to http://localhost:3000/web
      2. Click Watchlist tab button
      3. Verify URL stays as /web#watchlist (not /watchlist)
      4. Verify watchlist content loads in same page
    Expected Result: No redirect, content loads in place
    Failure Indicators: Redirect to /watchlist occurs, content doesn't load
    Evidence: .sisyphus/evidence/task-5-no-redirect.txt
  ```

  **Evidence to Capture**:
  - [ ] task-5-no-redirect.txt - Test results showing no redirect

  **Commit**: YES (with Task 4)
  - Message: `refactor: update tab switching for watchlist (load content instead of redirect)`
  - Files: `static/js/tabs.js`
  - Pre-commit: N/A

---

- [x] 6. Create components/watchlist_section.html

  **What to do**:
  - Create new file `templates/components/watchlist_section.html`
  - Extract main watchlist content from `templates/watchlist.html` (lines 223-267)
  - Remove duplicate tab navigation (lines 214-220) from watchlist content
  - Remove duplicate header (lines 200-206) from watchlist content
  - Include scheduler status section, filter tabs, watchlist container
  - Use same structure as other tab sections (`.section-header` pattern)
  - Ensure all IDs match what watchlist.js/watchlist-ui.js expects
  - Add appropriate comments for maintainability

  **Must NOT do**:
  - Don't keep duplicate navigation (header tabs already exist)
  - Don't change any ID names that watchlist.js depends on
  - Don't remove any watchlist features (scheduler, filters, container)
  - Don't change existing watchlist functionality

  **Recommended Agent Profile**:
  > Select category + skills based on task domain. Justify each choice.
  - **Category**: `visual-engineering`
    - Reason: HTML template creation, visual structure alignment
  - **Skills**: []
    - No special skills needed

  **Parallelization**:
  - **Can Run In Parallel**: NO
  - **Parallel Group**: Sequential
  - **Blocks**: Task 7, Task 8
  - **Blocked By**: Task 3 (modal extraction needed first)

  **References** (CRITICAL - Be Exhaustive):

  > The executor has NO context from your interview. References are their ONLY guide.
  > Each reference must answer: "What should I look at and WHY?"

  **Pattern References** (existing code to follow):
  - `templates/watchlist.html:223-267` - Main watchlist content to extract
  - `templates/index.html:12-52` - Tab content structure pattern (.section-header, content div)
  - `templates/components/header.html:47-52` - Watchlist tab button structure (for reference)

  **API/Type References** (contracts to implement against):
  - N/A

  **Test References** (testing patterns to follow):
  - N/A

  **External References** (libraries and frameworks):
  - N/A

  **WHY Each Reference Matters** (explain the relevance):
  - Lines 223-267 - This is the core watchlist content that needs to be extracted
  - Lines 12-52 - This shows how tab sections should be structured for consistency

  **Acceptance Criteria**:

  > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted.
  > Every criterion MUST be verifiable by running a command or using a tool.

  - [ ] `templates/components/watchlist_section.html` file exists
  - [ ] Contains scheduler status section (with all buttons: Start, Stop, Check All, Settings)
  - [ ] Contains filter tabs (All, Active, Paused, Completed)
  - [ ] Contains watchlist container div
  - [ ] No duplicate navigation (header tabs removed)
  - [ ] All IDs preserved from original (watchlistContainer, schedulerStatus, etc.)

  **QA Scenarios (MANDATORY - task is INCOMPLETE without these):**

  ```
  Scenario: Watchlist section renders correctly
    Tool: Playwright
    Preconditions: /web#watchlist loaded, watchlist_section.html included in index.html
    Steps:
      1. Navigate to http://localhost:3000/web#watchlist
      2. Verify scheduler status panel displays
      3. Verify filter tabs display
      4. Verify watchlist container exists
      5. Take screenshot
    Expected Result: All watchlist components render correctly
    Failure Indicators: Missing components, layout broken, IDs incorrect
    Evidence: .sisyphus/evidence/task-6-render.png
  ```

  **Evidence to Capture**:
  - [ ] task-6-render.png - Screenshot of watchlist section rendering

  **Commit**: NO (groups with Task 7)
  - Message: `feat: create watchlist section component`
  - Files: `templates/components/watchlist_section.html`
  - Pre-commit: N/A

---

- [x] 7. Move watchlist inline CSS to style.css

  **What to do**:
  - Open `templates/watchlist.html` lines 8-197 (inline styles)
  - Extract all watchlist-specific CSS (watchlist-header, scheduler-status, filter-tabs, etc.)
  - Append extracted CSS to `static/css/style.css`
  - Use unique prefixes to avoid conflicts (`.watchlist-` prefix recommended)
  - Ensure no CSS class names conflict with existing `.tab` classes
  - Remove inline styles from watchlist.html after extraction

  **Must NOT do**:
  - Don't change any CSS behavior or visual appearance
  - Don't remove any watchlist-specific styles
  - Don't break existing styles in style.css

  **Recommended Agent Profile**:
  > Select category + skills based on task domain. Justify each choice.
  - **Category**: `quick`
    - Reason: CSS extraction and migration, straightforward
  - **Skills**: []
    - No special skills needed

  **Parallelization**:
  - **Can Run In Parallel**: NO
  - **Parallel Group**: Sequential
  - **Blocks**: Task 8
  - **Blocked By**: Task 6 (watchlist_section.html needed to verify styles)

  **References** (CRITICAL - Be Exhaustive):

  > The executor has NO context from your interview. References are their ONLY guide.
  > Each reference must answer: "What should I look at and WHY?"

  **Pattern References** (existing code to follow):
  - `templates/watchlist.html:8-197` - Inline CSS to extract
  - `static/css/style.css` - Where to append extracted styles

  **API/Type References** (contracts to implement against):
  - N/A

  **Test References** (testing patterns to follow):
  - N/A

  **External References** (libraries and frameworks):
  - N/A

  **WHY Each Reference Matters** (explain the relevance):
  - Lines 8-197 - This is the complete inline CSS that needs to be moved to style.css

  **Acceptance Criteria**:

  > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted.
  > Every criterion MUST be verifiable by running a command or using a tool.

  - [ ] Watchlist CSS added to `static/css/style.css`
  - [ ] CSS uses `.watchlist-` prefix for classes to avoid conflicts
  - [ ] `grep "watchlist-" static/css/style.css` returns watchlist styles
  - [ ] Inline styles removed from watchlist.html (or kept only for modal)

  **QA Scenarios (MANDATORY - task is INCOMPLETE without these):**

  ```
  Scenario: Watchlist styles apply correctly
    Tool: Playwright
    Preconditions: /web#watchlist loaded
    Steps:
      1. Navigate to http://localhost:3000/web#watchlist
      2. Verify watchlist header displays with correct colors
      3. Verify scheduler status panel styles match original
      4. Verify filter tabs styles match original
      5. Take screenshot
    Expected Result: All visual styles match original watchlist page
    Failure Indicators: Styles broken, colors wrong, layout issues
    Evidence: .sisyphus/evidence/task-7-styles.png
  ```

  **Evidence to Capture**:
  - [ ] task-7-styles.png - Screenshot showing watchlist styles

  **Commit**: YES (with Task 6)
  - Message: `feat: add watchlist styles to style.css`
  - Files: `static/css/style.css`
  - Pre-commit: N/A

---

- [x] 8. Add watchlist tab div to index.html

  **What to do**:
  - Open `templates/index.html`
  - Find where tab sections are defined (after existing tabs)
  - Add new tab div: `<div id="tab-watchlist" class="tab-content">`
  - Include watchlist section component: `{% include "components/watchlist_section.html" %}`
  - Place it after existing tab sections (tab-providers)
  - Follow same structure as other tab divs

  **Must NOT do**:
  - Don't break existing tab structure
  - Don't modify other tab sections

  **Recommended Agent Profile**:
  > Select category + skills based on task domain. Justify each choice.
  - **Category**: `quick`
    - Reason: Simple include addition to existing template
  - **Skills**: []
    - No special skills needed

  **Parallelization**:
  - **Can Run In Parallel**: NO
  - **Parallel Group**: Sequential
  - **Blocks**: Task 9, Task 10
  - **Blocked By**: Task 6 (watchlist_section.html must exist)

  **References** (CRITICAL - Be Exhaustive):

  > The executor has NO context from your interview. References are their ONLY guide.
  > Each reference must answer: "What should I look at and WHY?"

  **Pattern References** (existing code to follow):
  - `templates/index.html:12-52` - Where tab sections are defined (tab-home, tab-anime, tab-series, tab-providers)
  - `templates/index.html:9` - Example of include usage (home_section.html)

  **API/Type References** (contracts to implement against):
  - N/A

  **Test References** (testing patterns to follow):
  - N/A

  **External References** (libraries and frameworks):
  - N/A

  **WHY Each Reference Matters** (explain the relevance):
  - Lines 12-52 - This shows the exact structure and placement where watchlist tab div should be added
  - Line 9 - This shows how to use {% include %} syntax for components

  **Acceptance Criteria**:

  > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted.
  > Every criterion MUST be verifiable by running a command or using a tool.

  - [ ] `<div id="tab-watchlist" class="tab-content">` added to index.html
  - [ ] `{% include "components/watchlist_section.html" %}` inside tab-watchlist div
  - [ ] Placement after tab-providers section

  **QA Scenarios (MANDATORY - task is INCOMPLETE without these):**

  ```
  Scenario: Watchlist tab displays when active
    Tool: Playwright
    Preconditions: /web page loaded
    Steps:
      1. Navigate to http://localhost:3000/web
      2. Click Watchlist tab button
      3. Verify tab-watchlist div is visible
      4. Verify watchlist section content displays
      5. Take screenshot
    Expected Result: Watchlist tab section appears with all content
    Failure Indicators: Tab doesn't display, content missing, wrong content shown
    Evidence: .sisyphus/evidence/task-8-tab-display.png
  ```

  **Evidence to Capture**:
  - [ ] task-8-tab-display.png - Screenshot of watchlist tab display

  **Commit**: YES (with Task 9)
  - Message: `feat: integrate watchlist into main page`
  - Files: `templates/index.html`
  - Pre-commit: N/A

---

- [x] 9. Add watchlist loading logic to tabs.js

  **What to do**:
  - Open `static/js/tabs.js`
  - Find watchlist case in switchTab override (already modified in Task 5)
  - Add call to `displayWatchlist()` function when watchlist tab opens
  - Ensure function exists in watchlist.js (it should from original page)
  - Add `window.watchlistTabLoaded = true` after successful load
  - Implement 30-second interval management:
    - Clear interval when switching away from watchlist
    - Start interval when watchlist tab becomes active
    - Use `clearInterval()` to stop refresh when not visible
  - Follow same pattern as other tabs (animeTabLoaded flag check)

  **Must NOT do**:
  - Don't create infinite interval loops
  - Don't forget to clear interval when switching tabs
  - Don't break existing interval logic in watchlist.html

  **Recommended Agent Profile**:
  > Select category + skills based on task domain. Justify each choice.
  - **Category**: `quick`
    - Reason: JavaScript logic for content loading and interval management
  - **Skills**: []
    - No special skills needed

  **Parallelization**:
  - **Can Run In Parallel**: NO
  - **Parallel Group**: Sequential
  - **Blocks**: Task 10
  - **Blocked By**: Task 5 (redirect removed), Task 8 (tab structure exists)

  **References** (CRITICAL - Be Exhaustive):

  > The executor has NO context from your interview. References are their ONLY guide.
  > Each reference must answer: "What should I look at and WHY?"

  **Pattern References** (existing code to follow):
  - `static/js/tabs.js:372-387` - Content loading patterns for anime, series, providers tabs
  - `static/js/watchlist-ui.js` - Should contain `displayWatchlist()` function
  - `templates/watchlist.html:282-286` - Where `displayWatchlist()` is called on page load
  - `templates/watchlist.html:586` - 30-second interval (`setInterval(loadSchedulerStatus, 30000)`)

  **API/Type References** (contracts to implement against):
  - N/A

  **Test References** (testing patterns to follow):
  - N/A

  **External References** (libraries and frameworks):
  - N/A

  **WHY Each Reference Matters** (explain the relevance):
  - Lines 372-387 - These show how to load tab content that watchlist should follow
  - Line 586 - This is the interval that needs management when switching tabs

  **Acceptance Criteria**:

  > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted.
  > Every criterion MUST be verifiable by running a command or using a tool.

  - [ ] `displayWatchlist()` called when watchlist tab opens
  - [ ] Interval cleared when switching away from watchlist tab
  - [ ] Interval restarted when watchlist tab becomes active
  - [ ] `watchlistTabLoaded` set to `true` after load

  **QA Scenarios (MANDATORY - task is INCOMPLETE without these):**

  ```
  Scenario: Interval management works correctly
    Tool: Playwright
    Preconditions: /web#watchlist loaded
    Steps:
      1. Navigate to http://localhost:3000/web#watchlist
      2. Click Anime tab
      3. Wait 35 seconds
      4. Switch back to Watchlist tab
      5. Verify scheduler status refreshed
    Expected Result: Interval cleared on tab switch away, restarted when returning
    Failure Indicators: Interval continues running when not visible, interval doesn't restart
    Evidence: .sisyphus/evidence/task-9-interval.txt
  ```

  ```
  Scenario: Watchlist content loads correctly
    Tool: Playwright
    Preconditions: /web page loaded
    Steps:
      1. Navigate to http://localhost:3000/web
      2. Click Watchlist tab button
      3. Verify scheduler status displays
      4. Verify filter tabs display
      5. Verify watchlist items load (or empty message)
      6. Take screenshot
    Expected Result: All watchlist content loads and displays correctly
    Failure Indicators: Content doesn't load, errors in console, missing sections
    Evidence: .sisyphus/evidence/task-9-content-load.png
  ```

  **Evidence to Capture**:
  - [ ] task-9-interval.txt - Test results showing interval management
  - [ ] task-9-content-load.png - Screenshot of content load

  **Commit**: YES (with Task 8)
  - Message: `feat: integrate watchlist into main page`
  - Files: `templates/index.html`, `static/js/tabs.js`
  - Pre-commit: N/A

---

- [x] 10. Add /watchlist redirect endpoint to main.py

  **What to do**:
  - Open `main.py`
  - Find FastAPI app and route definitions
  - Add new route `@app.get("/watchlist")`
  - Return redirect to `/web#watchlist`
  - Use `RedirectResponse` from fastapi
  - Preserve backward compatibility (old bookmarks still work)

  **Must NOT do**:
  - Don't modify existing routes
  - Don't break existing /web route

  **Recommended Agent Profile**:
  > Select category + skills based on task domain. Justify each choice.
  - **Category**: `quick`
    - Reason: Simple FastAPI route addition
  - **Skills**: []
    - No special skills needed

  **Parallelization**:
  - **Can Run In Parallel**: NO
  - **Parallel Group**: Sequential
  - **Blocks**: Task 11
  - **Blocked By**: Task 8, Task 9 (watchlist tab fully integrated first)

  **References** (CRITICAL - Be Exhaustive):

  > The executor has NO context from your interview. References are their ONLY guide.
  > Each reference must answer: "What should I look at and WHY?"

  **Pattern References** (existing code to follow):
  - `main.py` - Where other routes are defined (look for @app.get decorators)

  **API/Type References** (contracts to implement against):
  - FastAPI `RedirectResponse` - Use this for redirect

  **Test References** (testing patterns to follow):
  - N/A

  **External References** (libraries and frameworks):
  - N/A

  **WHY Each Reference Matters** (explain the relevance):
  - Look for @app.get decorators to understand routing pattern

  **Acceptance Criteria**:

  > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted.
  > Every criterion MUST be verifiable by running a command or using a tool.

  - [ ] `@app.get("/watchlist")` route added to main.py
  - [ ] Returns `RedirectResponse("/web#watchlist")`
  - [ ] Route works when accessed

  **QA Scenarios (MANDATORY - task is INCOMPLETE without these):**

  ```
  Scenario: /watchlist endpoint redirects correctly
    Tool: Bash (curl)
    Preconditions: Server running
    Steps:
      1. curl -I http://localhost:3000/watchlist
      2. Check for HTTP 302 or 307 redirect status
      3. Check Location header contains /web#watchlist
    Expected Result: Redirect to /web#watchlist with correct status code
    Failure Indicators: No redirect, wrong status code, wrong location
    Evidence: .sisyphus/evidence/task-10-redirect.txt
  ```

  **Evidence to Capture**:
  - [ ] task-10-redirect.txt - Curl output showing redirect

  **Commit**: YES (standalone)
  - Message: `feat: add /watchlist redirect endpoint`
  - Files: `main.py`
  - Pre-commit: N/A

---


## Final Verification Wave (MANDATORY — after ALL implementation tasks)

> 2 review tasks run in SEQUENTIAL (dependent on each other). ALL must APPROVE. Rejection → fix → re-run.

- [ ] F1. **Plan Compliance Audit** — `oracle`
  Read the plan end-to-end. For each "Must Have": verify implementation exists (read file, curl endpoint, run command). For each "Must NOT Have": search codebase for forbidden patterns — reject with file:line if found. Check evidence files exist in .sisyphus/evidence/. Compare deliverables against plan.
  Output: `Must Have [N/N] | Must NOT Have [N/N] | Tasks [N/N] | VERDICT: APPROVE/REJECT`

- [ ] F2. **Real Manual QA** — `unspecified-high` (+ `playwright` skill)
  Start from clean state. Execute EVERY QA scenario from EVERY task — follow exact steps, capture evidence. Test cross-task integration: navigate to /web, click watchlist tab, verify all features (scheduler, filters, settings). Test tab switching: switch to other tabs and back, verify interval management. Test filter functionality: click All/Active/Paused/Completed, verify items filtered correctly. Test settings modal: open, toggle switches, save, verify persistence. Save to `.sisyphus/evidence/final-qa/`.
  Output: `Scenarios [N/N pass] | Integration [N/N] | Edge Cases [N tested] | VERDICT`

---

## Commit Strategy

- **1-3**: `feat: prepare watchlist integration foundation` — static/js/tabs.js, static/js/watchlist-ui.js
- **4-5**: `refactor: update tab switching for watchlist` — static/js/tabs.js, static/js/main.js
- **6-7**: `feat: create watchlist section component` — templates/components/watchlist_section.html, static/css/style.css
- **8-9**: `feat: integrate watchlist into main page` — templates/index.html, static/js/tabs.js
- **10**: `feat: add watchlist redirect endpoint` — main.py
- **11-12**: `test: end-to-end verification` — .sisyphus/evidence/

---

## Success Criteria

### Verification Commands
```bash
# Navigate to /web#watchlist in browser
# Verify visual consistency with other tabs

# Check for DOM ID conflicts (should be none)
grep -r "id=\"watchlistContainer\|id=\"schedulerStatus\"" templates/ | wc -l  # Should be 1

# Check for CSS conflicts (should be none)
grep "filter-tab" static/css/style.css | head -3

# Verify redirect endpoint works
curl -I http://localhost:3000/watchlist  # Should return 302 to /web#watchlist
```

### Final Checklist
- [ ] All "Must Have" present
- [ ] All "Must NOT Have" absent
- [ ] No duplicate navigation tabs
- [ ] Interval management works correctly
- [ ] Filter tabs functional
- [ ] Settings modal functional
- [ ] Visual design identical to /web
- [ ] All QA scenarios pass