Roman/ohm_streaming
1
0
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity
Files
20bcc75b9be8219c89d0332947bf2386a53a5bd9
ohm_streaming/.sisyphus/plans/watchlist-visual-redesign.md
T
root 20bcc75b9b chore: update watchlist features and fixes
2026-02-28 09:22:57 +00:00

45 KiB
Raw Blame History

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

# 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.

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

# 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
Reference in New Issue View Git Blame Copy Permalink