# Watchlist JavaScript Bug Fix - Architectural Refactor ## TL;DR > **Quick Summary**: Fix critical JavaScript errors causing watchlist infinite loading, broken search, and navigation traps through complete architectural refactor of script loading and code cleanup. > > **Deliverables**: > - Fixed downloads.js duplicate variable declarations > - Eliminated duplicate API_BASE declarations > - Removed duplicate script loading in watchlist.html > - Added "Retour à l'accueil" navigation button > - Audited all JS files for similar issues > - Verified backend watchlist API functionality > > **Estimated Effort**: Medium > **Parallel Execution**: YES - 4 waves > **Critical Path**: downloads.js fix → script cleanup → navigation button → QA verification --- ## Context ### Original Request User reported watchlist completely broken: infinite loading, non-functional search, navigation stuck on watchlist page with no way to return to home. Multiple JavaScript errors in console preventing proper initialization. ### Interview Summary **Key Discussions**: - User confirmed home page is `/web` - Chose to remove duplicate script from watchlist.html (keep in base.html globally) - Chose to remove duplicate API_BASE from watchlist/main.js (use api.js only) - Selected "Architectural Refactor" scope - complete overhaul, not minimal fix **Research Findings**: - downloads.js has duplicate variable declarations (lines 64-67 and 69-76) - API_BASE declared in both api.js and watchlist/main.js - watchlist/main.js loaded twice (base.html + watchlist.html) - No navigation button from watchlist to home page - JavaScript errors prevent proper initialization causing infinite loading ### Metis Review **Identified Gaps** (addressed): - Need to audit ALL JS files for similar duplication patterns (not just reported ones) - Need clear separation between global scripts and page-specific scripts - Must verify backend API endpoints work correctly - Need browser console verification steps as acceptance criteria - Must ensure existing routes (/web, /watchlist) continue to work after refactor --- ## Work Objectives ### Core Objective Eliminate all JavaScript errors causing watchlist failures through comprehensive architectural refactor of script loading and code cleanup, add proper navigation from watchlist to home, and verify complete functionality. ### Concrete Deliverables - Fixed `static/js/downloads.js` - no duplicate variable declarations - Fixed `static/js/watchlist/main.js` - no duplicate API_BASE - Fixed `templates/watchlist.html` - no duplicate script loading - Added navigation button in `templates/watchlist.html` to return to `/web` - Audited all JS files for duplication and scope issues - Verified `/api/watchlist/*` endpoints work correctly with curl ### Definition of Done - [ ] Browser console shows 0 JavaScript errors on both `/web` and `/watchlist` - [ ] Watchlist loads successfully (< 3 seconds) with no infinite loading spinner - [ ] "Retour à l'accueil" button navigates to `/web` - [ ] Watchlist search functionality works - [ ] All API endpoints return valid responses (200/400/401, not 500) ### Must Have - Fix all 6 JavaScript errors reported - Add navigation button to return to `/web` - Verify backend watchlist API works - Audit all JS files for similar issues ### Must NOT Have (Guardrails) - **DO NOT change `/web` or `/watchlist` routes** - existing URLs must work - **DO NOT break authentication flow** - JWT tokens must work on both pages - **DO NOT create new frameworks** - use existing Vanilla JS patterns - **DO NOT modify backend API endpoints** - only verify they work - **DO NOT introduce new pages** - only fix existing functionality - **DO NOT fix favicon.ico** - separate issue, out of scope --- ## Verification Strategy > **ZERO HUMAN INTERVENTION** — ALL verification is agent-executed. No exceptions. ### Test Decision - **Infrastructure exists**: YES (pytest) - **Automated tests**: NO (focus on browser console verification for UI bugs) - **Framework**: None for this refactor - use browser console + curl for API tests - **Rationale**: This is UI-focused bug fix, not new feature development ### 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 browser console verification + Playwright (dev-browser skill) for interactions - **API/Backend**: Use Bash (curl) — Send requests, assert status + response fields --- ## Execution Strategy ### Parallel Execution Waves ``` Wave 1 (Start Immediately - Foundation Fixes): ├── Task 1: Fix downloads.js duplicate variables [quick] ├── Task 2: Fix watchlist/main.js duplicate API_BASE [quick] ├── Task 3: Remove duplicate script from watchlist.html [quick] ├── Task 4: Audit all JS files for duplication patterns [quick] └── Task 5: Verify backend watchlist API endpoints [quick] Wave 2 (After Wave 1 - UI/Navigation): ├── Task 6: Add navigation button to watchlist.html [visual-engineering] └── Task 7: Style navigation button matching existing UI [visual-engineering] Wave 3 (After Wave 2 - Integration): ├── Task 8: Test watchlist loading and search functionality [unspecified-high] └── Task 9: Test navigation from watchlist to home [unspecified-high] Wave 4 (After Wave 3 - Verification): ├── Task 10: Browser console error verification (all pages) [quick] ├── Task 11: API endpoint integration tests [quick] └── Task 12: Git cleanup and commit [git] Critical Path: Task 1 → Task 2 → Task 3 → Task 6 → Task 8 → Task 10 Parallel Speedup: ~60% faster than sequential Max Concurrent: 5 (Wave 1) ``` ### Dependency Matrix - **1**: — — 4, 5 (independent) - **2**: — — 4, 5 (independent) - **3**: — — 4, 5 (independent) - **4**: 1, 2, 3 — 8, 10 - **5**: — — 11 - **6**: 3 — 7, 8, 9 - **7**: 6 — 8, 9 - **8**: 4, 6, 7 — 10 - **9**: 6, 7 — 10 - **10**: 1, 2, 3, 4, 8 — 12 - **11**: 5 — 12 - **12**: 10, 11 — None ### Agent Dispatch Summary - **1**: **5** — T1-T3 (quick), T4 (quick), T5 (quick) - **2**: **2** — T6-T7 (visual-engineering) - **3**: **2** — T8-T9 (unspecified-high) - **4**: **3** — T10-T11 (quick), T12 (git) --- ## TODOs - [x] 1. Fix downloads.js Duplicate Variable Declarations **What to do**: - Read `static/js/downloads.js` to identify duplicate declarations (lines 64-76) - Remove lines 69-76 which duplicate the variable declarations from lines 64-67 - Verify the function `filterDownloads()` has only one set of declarations for `statusFilter`, `sortBy`, `groupBy`, `searchTerm` - Ensure the fix preserves the logic (the duplicate code does the same thing) **Must NOT do**: - Remove lines 64-67 (these are the correct declarations) - Change the filter logic or behavior - Modify other functions in downloads.js **Recommended Agent Profile**: > Select category + skills based on task domain. Justify each choice. - **Category**: `quick` - Reason: Simple fix with clear scope - remove duplicate code block - **Skills**: [] - No specific skills needed - straightforward JavaScript file edit **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 1 (with Tasks 2, 3, 4, 5) - **Blocks**: Task 8, 10 - **Blocked By**: None (can start immediately) **References** (CRITICAL - Be Exhaustive): **Pattern References** (existing code to follow): - `static/js/downloads.js:64-76` - The function with duplicate declarations **Acceptance Criteria**: > **AGENT-EXECUTABLE VERIFICATION ONLY** — No human action permitted. ```bash # Verify exactly one declaration of each variable grep -c "const sortBy" static/js/downloads.js Expected: 1 grep -c "const groupBy" static/js/downloads.js Expected: 1 grep -c "const searchTerm" static/js/downloads.js Expected: 1 grep -c "const statusFilter" static/js/downloads.js Expected: 1 ``` **QA Scenarios (MANDATORY — task is INCOMPLETE without these):** ``` Scenario: downloads.js parses without syntax errors Tool: Bash (node) Preconditions: None Steps: 1. Run: node -c static/js/downloads.js Expected Result: Exit code 0 (syntax valid) Failure Indicators: Exit code 1 with syntax error Evidence: .sisyphus/evidence/task-1-syntax-check.txt Scenario: loadDownloads function is defined and accessible Tool: Bash (node) Preconditions: None Steps: 1. Create test script: echo "const fs = require('fs'); eval(fs.readFileSync('static/js/downloads.js', 'utf8')); console.log(typeof loadDownloads);" > /tmp/test-downloads.js 2. Run: node /tmp/test-downloads.js Expected Result: Output: "function" Failure Indicators: Output: "undefined" or syntax error Evidence: .sisyphus/evidence/task-1-function-accessible.txt ``` **Commit**: YES - Message: `fix(js): Remove duplicate variable declarations in downloads.js` - Files: `static/js/downloads.js` - [x] 2. Fix watchlist/main.js Duplicate API_BASE Declaration **What to do**: - Read `static/js/watchlist/main.js` to locate line 3 with `const API_BASE = '/api';` - Remove line 3 (duplicate declaration) - Verify the file no longer contains any API_BASE declaration - Confirm api.js is loaded before watchlist/main.js in base.html (check base.html line 2 loads api.js, line 21 loads watchlist/main.js) **Must NOT do**: - Add API_BASE back with different syntax (var instead of const) - Change the value of API_BASE ('/api' should remain) - Modify api.js **Recommended Agent Profile**: - **Category**: `quick` - Reason: Simple line removal - DRY principle fix - **Skills**: [] - No special skills needed **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 1 (with Tasks 1, 3, 4, 5) - **Blocks**: Task 10 - **Blocked By**: None (can start immediately) **References**: **Pattern References**: - `static/js/api.js:2` - Correct API_BASE declaration - `static/js/watchlist/main.js:3` - Duplicate to remove - `templates/base.html:2` - api.js loaded globally - `templates/base.html:21` - watchlist/main.js loaded globally **Acceptance Criteria**: ```bash # Verify no API_BASE in watchlist/main.js grep -c "API_BASE" static/js/watchlist/main.js Expected: 0 # Verify api.js still has API_BASE grep -c "API_BASE" static/js/api.js Expected: 1 ``` **QA Scenarios (MANDATORY):** ``` Scenario: watchlist/main.js parses without duplicate const errors Tool: Bash (node) Preconditions: None Steps: 1. Run: node -c static/js/watchlist/main.js Expected Result: Exit code 0 (syntax valid) Failure Indicators: SyntaxError: Identifier 'API_BASE' has already been declared Evidence: .sisyphus/evidence/task-2-syntax-check.txt ``` **Commit**: YES - Message: `fix(js): Remove duplicate API_BASE declaration from watchlist/main.js` - Files: `static/js/watchlist/main.js` - [x] 3. Remove Duplicate Script Loading from watchlist.html **What to do**: - Read `templates/watchlist.html` to locate line 530 with `` - Remove this script tag (it's already loaded by base.html line 21) - Verify the file no longer contains any reference to watchlist/main.js - Confirm base.html still loads watchlist/main.js globally (base.html line 21) **Must NOT do**: - Remove watchlist/main.js from base.html (keep it global) - Add other scripts to watchlist.html - Modify script loading order in base.html **Recommended Agent Profile**: - **Category**: `quick` - Reason: Simple HTML tag removal - eliminate duplicate loading - **Skills**: [] - No special skills needed **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 1 (with Tasks 1, 2, 4, 5) - **Blocks**: Task 6, 8 - **Blocked By**: None (can start immediately) **References**: **Pattern References**: - `templates/base.html:21` - Correct global loading of watchlist/main.js - `templates/watchlist.html:530` - Duplicate to remove **Acceptance Criteria**: ```bash # Verify no watchlist/main.js in watchlist.html grep -c "watchlist/main.js" templates/watchlist.html Expected: 0 # Verify base.html still loads it grep -c "watchlist/main.js" templates/base.html Expected: 1 ``` **QA Scenarios (MANDATORY):** ``` Scenario: watchlist.html loads watchlist/main.js exactly once Tool: Bash (grep) Preconditions: None Steps: 1. Search for all script tags loading watchlist/main.js in watchlist.html 2. Search for all script tags in base.html Expected Result: 0 occurrences in watchlist.html, 1 in base.html Failure Indicators: >0 occurrences in watchlist.html Evidence: .sisyphus/evidence/task-3-script-count.txt ``` **Commit**: YES - Message: `fix(html): Remove duplicate script loading from watchlist.html` - Files: `templates/watchlist.html` - [x] 4. Audit All JS Files for Duplication Patterns **What to do**: - List all JavaScript files in `static/js/` directory (recursive) - For each JS file, search for duplicate: - const declarations of same variable name - let declarations of same variable in same scope - var declarations of same variable in same scope - Function definitions with same name - Create audit report listing all duplication issues found - For any critical duplications (causing syntax errors), create separate fix tasks - For minor duplications (non-breaking), document for future cleanup - Focus on: api.js, utils.js, auth.js, main.js, tabs.js, anime.js, series-search.js, downloads.js, watchlist/main.js, anime-details.js, recommendations.js **Must NOT do**: - Fix non-critical duplications without explicit approval - Modify working code (only document issues) - Change architecture patterns unless duplications are critical bugs **Recommended Agent Profile**: - **Category**: `quick` - Reason: Audit task with grep-based analysis - **Skills**: [] - grep and file listing sufficient **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 1 (with Tasks 1, 2, 3, 5) - **Blocks**: None (report only) - **Blocked By**: None (can start immediately) **References**: **Pattern References**: - `static/js/downloads.js` - Example of duplication already fixed - `static/js/watchlist/main.js` - Example of duplication already fixed **Acceptance Criteria**: ```bash # Audit report exists test -f .sisyphus/evidence/task-4-js-audit.txt Expected: PASS ``` **QA Scenarios (MANDATORY):** ``` Scenario: All JS files checked for duplicate declarations Tool: Bash (grep + find) Preconditions: None Steps: 1. Find all .js files in static/js/ 2. For each file, check for duplicate const/let/var declarations using pattern 3. Check for duplicate function definitions 4. Generate report with file:line:duplication_type format Expected Result: Report generated with all duplications listed Failure Indicators: No report generated, or report incomplete Evidence: .sisyphus/evidence/task-4-js-audit.txt ``` **Commit**: NO - This is an audit task - no code changes - [x] 5. Verify Backend Watchlist API Endpoints **What to do**: - Start the FastAPI server if not running: `uvicorn main:app --host 0.0.0.0 --port 3000` - Test all watchlist API endpoints with curl: - GET `/api/watchlist` - List watchlist items - POST `/api/watchlist` - Add item to watchlist - GET `/api/watchlist/{id}` - Get specific item - PUT `/api/watchlist/{id}` - Update item - DELETE `/api/watchlist/{id}` - Delete item - GET `/api/watchlist/stats` - Get statistics - For each endpoint, record: HTTP status code, response time, response structure - Check for 500 errors (backend bugs) - Verify authentication is working (401/403 for unauthenticated, 200 for authenticated) - Note any endpoints returning unexpected errors **Must NOT do**: - Modify backend code - Fix any API bugs found (only document them) - Create new endpoints **Recommended Agent Profile**: - **Category**: `quick` - Reason: API verification with curl - **Skills**: [] - curl sufficient for API testing **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 1 (with Tasks 1, 2, 3, 4) - **Blocks**: Task 11 - **Blocked By**: None (can start immediately) **References**: **Pattern References**: - `app/routes/watchlist.py` - Backend watchlist routes - `main.py` - FastAPI app setup **Acceptance Criteria**: ```bash # Server is running curl -s http://localhost:3000/health | grep -q "status" Expected: PASS ``` **QA Scenarios (MANDATORY):** ``` Scenario: GET /api/watchlist returns 401 (requires auth) or 200 (with token) Tool: Bash (curl) Preconditions: Server running on port 3000 Steps: 1. Run: curl -i -s http://localhost:3000/api/watchlist 2. Check HTTP status code in response headers Expected Result: 401 (Unauthorized) OR 200 (OK if token provided) Failure Indicators: 500 (Internal Server Error), connection refused Evidence: .sisyphus/evidence/task-5-get-watchlist.txt Scenario: Watchlist endpoints respond with proper JSON structure Tool: Bash (curl) Preconditions: Server running Steps: 1. Test GET /api/watchlist (authenticated) 2. Test GET /api/watchlist/stats (authenticated) 3. Verify responses are valid JSON Expected Result: 200 OK with valid JSON array or object Failure Indicators: Invalid JSON, 500 error, malformed response Evidence: .sisyphus/evidence/task-5-api-structure.txt ``` **Commit**: NO - This is verification only - no code changes - [x] 6. Add Navigation Button to Return to /web in watchlist.html **What to do**: - Read `templates/watchlist.html` to locate the header section - Add a "Retour à l'accueil" button in the header area (before main content) - Button should use `onclick="window.location.href = '/web'"` or similar - Style the button to match existing UI (use existing button classes) - Position button prominently but not obtrusively (top right or near title) - Ensure button works on both desktop and mobile (touch-friendly, minimum 44x44px) **Must NOT do**: - Use `window.history.back()` (user wants /web specifically) - Create a new page or route - Modify existing navigation in index.html - Break the visual consistency of watchlist page **Recommended Agent Profile**: - **Category**: `visual-engineering` - Reason: UI component addition requiring HTML + CSS styling - **Skills**: [] - No special skills needed - HTML button with existing styles **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 2 (with Task 7) - **Blocks**: Task 8, 9 - **Blocked By**: Task 3 (duplicate script must be removed first) **References**: **Pattern References** (existing code to follow): - `templates/components/header.html` - Existing navigation pattern and button styles - `templates/watchlist.html` - Target file where button should be added - `static/css/style.css` or inline styles - Existing button classes to use **Acceptance Criteria**: ```bash # Verify navigation button exists in watchlist.html grep -c "Retour à l'accueil" templates/watchlist.html Expected: >= 1 # Verify button points to /web grep -o "href.*'/web'" templates/watchlist.html | head -1 Expected: href='/web' or similar ``` **QA Scenarios (MANDATORY):** ``` Scenario: Navigation button is visible on watchlist page Tool: dev-browser (playwright) Preconditions: Server running on port 3000 Steps: 1. Navigate to http://localhost:3000/watchlist 2. Wait for page to load completely (timeout 10s) 3. Check for element with text "Retour à l'accueil" Expected Result: Button is visible in DOM with correct text Failure Indicators: Button not found, button not visible, incorrect text Evidence: .sisyphus/evidence/task-6-button-visible.png Scenario: Clicking navigation button redirects to /web Tool: dev-browser (playwright) Preconditions: On watchlist page Steps: 1. Click button with text "Retour à l'accueil" 2. Wait for navigation to complete (timeout 5s) 3. Check current URL Expected Result: URL changes to /web, home page loads Failure Indicators: URL does not change, 404 error, page doesn't load Evidence: .sisyphus/evidence/task-6-redirect-to-home.png ``` **Commit**: NO - Groups with Task 7 - [ ] 7. Style Navigation Button Matching Existing UI **What to do**: - Read existing CSS for button classes in `static/css/style.css` or inline styles in templates - Identify primary button style used in the application (btn-primary, btn-secondary, etc.) - Apply appropriate class to the navigation button added in Task 6 - Ensure button has proper hover states, transitions, and active states matching other buttons - Test button appearance on dark background (watchlist uses dark theme) - Add padding/margin for proper spacing and alignment - Ensure button is accessible (adequate contrast, focus state) **Must NOT do**: - Create new button classes (reuse existing) - Change existing button styles - Break responsive design on mobile **Recommended Agent Profile**: - **Category**: `visual-engineering` - Reason: CSS styling for visual consistency - **Skills**: [] - No special skills needed - apply existing classes **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 2 (with Task 6) - **Blocks**: Task 8, 9 - **Blocked By**: Task 6 (button must exist before styling) **References**: **Pattern References**: - `static/css/style.css` - Existing button class definitions - `templates/components/header.html` - Example of button styling - `templates/index.html` - Example of button usage in main page **Acceptance Criteria**: ```bash # Verify button has appropriate class grep -A1 "Retour à l'accueil" templates/watchlist.html | grep -q "class=.*btn" Expected: PASS ``` **QA Scenarios (MANDATORY):** ``` Scenario: Navigation button matches existing button styles Tool: dev-browser (playwright) Preconditions: On watchlist page with navigation button Steps: 1. Take screenshot of navigation button 2. Take screenshot of other buttons on page (e.g., "Ajouter" button) 3. Compare visual appearance (color, padding, font, border radius) Expected Result: Navigation button visually consistent with other buttons Failure Indicators: Button looks different/broken, colors don't match theme Evidence: .sisyphus/evidence/task-7-button-styles.png Scenario: Button has hover and focus states Tool: dev-browser (playwright) Preconditions: On watchlist page Steps: 1. Hover over navigation button, verify visual change 2. Tab to button, verify focus indicator appears 3. Click button, verify active state if applicable Expected Result: Hover, focus, and active states work correctly Failure Indicators: No hover effect, no focus indicator, stuck state Evidence: .sisyphus/evidence/task-7-button-states.png ``` **Commit**: YES - Message: `feat(ui): Add navigation button to return to /web from watchlist` - Files: `templates/watchlist.html` - [ ] 8. Test Watchlist Loading and Search Functionality **What to do**: - Start the FastAPI server: `uvicorn main:app --host 0.0.0.0 --port 3000` - Open browser and navigate to `/watchlist` - Verify watchlist loads without infinite loading spinner - Check that content appears within 3 seconds - Test search functionality: - Enter search query in watchlist search input - Click search button - Verify results appear or "no results" message shows - Verify no JavaScript errors in browser console - Test on both authenticated and unauthenticated states (if applicable) **Must NOT do**: - Modify backend code - Fix bugs found during testing (only document) - Change search behavior **Recommended Agent Profile**: - **Category**: `unspecified-high` - Reason: Integration testing with browser verification - **Skills**: [`dev-browser`] - dev-browser: Use Playwright for browser automation and console checking **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 3 (with Task 9) - **Blocks**: Task 10 - **Blocked By**: Task 1, 2, 3, 4, 6, 7 (all fixes must be applied first) **References**: **Pattern References**: - `static/js/watchlist/main.js` - Watchlist search implementation - `templates/watchlist.html` - Watchlist UI structure **Acceptance Criteria**: ```bash # Watchlist page loads successfully curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/watchlist Expected: 200 ``` **QA Scenarios (MANDATORY):** ``` Scenario: Watchlist loads successfully without infinite loading Tool: dev-browser (playwright) Preconditions: Server running, user may need auth token Steps: 1. Navigate to http://localhost:3000/watchlist 2. Wait max 5 seconds for page to load 3. Check if "Chargement de la watchlist..." text is present 4. Check if actual watchlist content appears (cards, items, etc.) Expected Result: Loading text disappears within 3s, actual content appears Failure Indicators: Loading spinner continues indefinitely, timeout errors, 500 errors Evidence: .sisyphus/evidence/task-8-watchlist-loads.png Scenario: Watchlist search works correctly Tool: dev-browser (playwright) Preconditions: On watchlist page with content Steps: 1. Locate search input field 2. Type search query (e.g., "Naruto") 3. Click search button or press Enter 4. Wait max 2 seconds for results 5. Check if results appear or "no results" message shows Expected Result: Search results appear within 2s, results filter correctly, no console errors Failure Indicators: No results appear, results don't match query, console errors, timeout Evidence: .sisyphus/evidence/task-8-search-works.png Scenario: Browser console shows 0 JavaScript errors on watchlist Tool: dev-browser (playwright console API) Preconditions: On watchlist page Steps: 1. Open browser DevTools Console tab 2. Check for any red error messages 3. Count errors (should be 0) Expected Result: 0 JavaScript errors in console Failure Indicators: Any error messages (red text) in console Evidence: .sisyphus/evidence/task-8-console-errors.txt ``` **Commit**: NO - This is testing - no code changes - [ ] 9. Test Navigation from Watchlist to Home **What to do**: - Navigate to `/watchlist` page in browser - Locate the "Retour à l'accueil" button added in Task 6 - Click the button - Verify navigation redirects to `/web` - Verify home page loads completely - Check browser console for errors after navigation - Test that navigation works from different watchlist states (empty, with items, after search) - Verify browser history is updated correctly **Must NOT do**: - Modify navigation logic - Fix bugs found during testing (only document) - Change /web route behavior **Recommended Agent Profile**: - **Category**: `unspecified-high` - Reason: Integration testing of navigation flow - **Skills**: [`dev-browser`] - dev-browser: Use Playwright for navigation testing **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 3 (with Task 8) - **Blocks**: Task 10 - **Blocked By**: Task 6, 7 (navigation button must exist first) **References**: **Pattern References**: - `templates/watchlist.html` - Navigation button location - `templates/index.html` - Home page structure **Acceptance Criteria**: ```bash # Home page loads successfully curl -s -o /dev/null -w "%{http_code}" http://localhost:3000/web Expected: 200 ``` **QA Scenarios (MANDATORY):** ``` Scenario: Clicking navigation button redirects to /web Tool: dev-browser (playwright) Preconditions: On watchlist page with navigation button Steps: 1. Locate button with text "Retour à l'accueil" 2. Click button 3. Wait max 5 seconds for navigation 4. Check current URL in browser 5. Verify home page content is visible Expected Result: URL changes to /web or /, home page loads completely, no errors Failure Indicators: URL doesn't change, 404 error, broken page, console errors Evidence: .sisyphus/evidence/task-9-nav-to-home.png Scenario: Navigation works from different watchlist states Tool: dev-browser (playwright) Preconditions: Server running Steps: 1. Test from empty watchlist state 2. Test from watchlist with items 3. Test after performing search 4. Test after opening item details 5. For each state, click navigation button and verify it works Expected Result: Navigation works from all states, no broken scenarios Failure Indicators: Navigation fails in certain states, inconsistent behavior Evidence: .sisyphus/evidence/task-9-nav-all-states.png ``` **Commit**: NO - This is testing - no code changes - [ ] 10. Browser Console Error Verification (All Pages) **What to do**: - Start FastAPI server: `uvicorn main:app --host 0.0.0.0 --port 3000` - Open browser DevTools on `/web` page - Check Console tab for any JavaScript errors - Navigate to `/watchlist` page - Check Console tab for any JavaScript errors - Test navigation from watchlist to home - Check Console tab for any JavaScript errors after navigation - Verify 0 errors on all pages and after all interactions - Note any warnings (non-critical) separately from errors **Must NOT do**: - Fix any errors found (only document) - Ignore errors - they must be fixed by previous tasks - Clear browser cache before testing (test real user scenario) **Recommended Agent Profile**: - **Category**: `quick` - Reason: Console verification task - **Skills**: [`dev-browser`] - dev-browser: Use Playwright to access browser console **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 4 (with Tasks 11, 12) - **Blocks**: Task 12 - **Blocked By**: Task 1, 2, 3, 8, 9 (all fixes and tests must be complete) **References**: **Pattern References**: - `static/js/downloads.js` - Fixed for duplicate variables - `static/js/watchlist/main.js` - Fixed for duplicate API_BASE - `templates/watchlist.html` - Fixed for duplicate script loading **Acceptance Criteria**: ```bash # No duplicate declarations in downloads.js grep -c "const sortBy" static/js/downloads.js Expected: 1 # No API_BASE in watchlist/main.js grep -c "API_BASE" static/js/watchlist/main.js Expected: 0 ``` **QA Scenarios (MANDATORY):** ``` Scenario: Browser console shows 0 errors on /web page Tool: dev-browser (playwright) Preconditions: Server running Steps: 1. Navigate to http://localhost:3000/web 2. Open DevTools Console tab 3. Check for red error messages 4. Count total errors Expected Result: 0 JavaScript errors Failure Indicators: Any error messages in console Evidence: .sisyphus/evidence/task-10-console-home.txt Scenario: Browser console shows 0 errors on /watchlist page Tool: dev-browser (playwright) Preconditions: Server running Steps: 1. Navigate to http://localhost:3000/watchlist 2. Open DevTools Console tab 3. Check for red error messages 4. Count total errors Expected Result: 0 JavaScript errors Failure Indicators: Any error messages in console Evidence: .sisyphus/evidence/task-10-console-watchlist.txt Scenario: No errors after navigating watchlist to home Tool: dev-browser (playwright) Preconditions: On watchlist page Steps: 1. Click "Retour à l'accueil" button 2. Wait for navigation to complete 3. Check Console tab for new errors Expected Result: 0 new errors after navigation Failure Indicators: Any error messages appear after navigation Evidence: .sisyphus/evidence/task-10-console-nav.txt ``` **Commit**: NO - This is verification - no code changes - [ ] 11. API Endpoint Integration Tests **What to do**: - Verify all watchlist API endpoints work correctly with curl - Test each endpoint with proper authentication (JWT token) - Test error handling (missing token, invalid token, invalid data) - Verify response structure matches expected format - Test edge cases (empty watchlist, non-existent ID, duplicate adds) - Document any endpoints returning unexpected responses - Verify `/health` endpoint returns 200 **Must NOT do**: - Modify backend code - Fix any API bugs found (only document) - Add new endpoints **Recommended Agent Profile**: - **Category**: `quick` - Reason: API testing with curl - **Skills**: [] - curl sufficient for API verification **Parallelization**: - **Can Run In Parallel**: YES - **Parallel Group**: Wave 4 (with Tasks 10, 12) - **Blocks**: Task 12 - **Blocked By**: Task 5 (initial API verification should have been done) **References**: **Pattern References**: - `app/routes/watchlist.py` - Watchlist API routes - `app/auth.py` - JWT authentication implementation **Acceptance Criteria**: ```bash # Health endpoint works curl -s http://localhost:3000/health | grep -q "ok" Expected: PASS ``` **QA Scenarios (MANDATORY):** ``` Scenario: GET /api/watchlist with auth returns 200 Tool: Bash (curl) Preconditions: Server running, valid JWT token available Steps: 1. Get auth token (or use existing) 2. Run: curl -i -H "Authorization: Bearer TOKEN" http://localhost:3000/api/watchlist 3. Check HTTP status code 4. Verify response is valid JSON Expected Result: 200 OK with valid JSON array Failure Indicators: 401/403, 500 error, invalid JSON Evidence: .sisyphus/evidence/task-11-api-get-watchlist.txt Scenario: POST /api/watchlist with valid data returns 201 Tool: Bash (curl) Preconditions: Server running, authenticated Steps: 1. Prepare JSON payload with valid watchlist item data 2. Run: curl -i -X POST -H "Content-Type: application/json" -H "Authorization: Bearer TOKEN" -d PAYLOAD http://localhost:3000/api/watchlist 3. Check HTTP status code Expected Result: 201 Created with valid JSON response Failure Indicators: 400 Bad Request, 401 Unauthorized, 500 error Evidence: .sisyphus/evidence/task-11-api-post-watchlist.txt Scenario: DELETE /api/watchlist/{id} with valid ID returns 204 Tool: Bash (curl) Preconditions: Server running, authenticated, item exists Steps: 1. Get valid watchlist item ID from GET request 2. Run: curl -i -X DELETE -H "Authorization: Bearer TOKEN" http://localhost:3000/api/watchlist/{id} 3. Check HTTP status code Expected Result: 204 No Content (success) Failure Indicators: 404 Not Found, 401 Unauthorized, 500 error Evidence: .sisyphus/evidence/task-11-api-delete-watchlist.txt ``` **Commit**: NO - This is verification - no code changes - [ ] 12. Git Cleanup and Commit **What to do**: - Review all changes made during this refactor - Group related commits if needed (or keep separate for clarity) - Verify all modified files are included in commit: - `static/js/downloads.js` (Task 1) - `static/js/watchlist/main.js` (Task 2) - `templates/watchlist.html` (Task 3 and Tasks 6, 7) - Create descriptive commit messages following project conventions - Verify no unintended files were modified - Check git status for untracked files (should be only evidence files) - Run tests one final time before committing - Push changes if needed (or prepare for manual push) **Must NOT do**: - Commit files that weren't modified - Commit evidence files (.sisyphus/evidence/) - Commit with unclear messages - Include debugging code or console.logs **Recommended Agent Profile**: - **Category**: `git` - Reason: Git operations for commit cleanup - **Skills**: [`git-master`] - git-master: Git operations, commit message formatting, history management **Parallelization**: - **Can Run In Parallel**: NO - **Parallel Group**: Final task in Wave 4 - **Blocks**: None - **Blocked By**: Task 10, 11 (all verifications must complete) **References**: **Pattern References**: - Git log for recent commit messages (check format) - Project documentation for commit conventions (if exists) **Acceptance Criteria**: ```bash # Git status is clean (except evidence files) git status --porcelain | grep -v "^.sisyphus/evidence" Expected: Empty or only evidence files ``` **QA Scenarios (MANDATORY):** ``` Scenario: Git commits are properly formatted Tool: Bash (git) Preconditions: All fixes applied, tested Steps: 1. Run: git log -1 --pretty=format:"%s" 2. Verify commit message follows convention: type(scope): description 3. Verify message is descriptive and clear Expected Result: Commit messages follow project conventions Failure Indicators: Vague messages, wrong format, merge commits Evidence: .sisyphus/evidence/task-12-git-log.txt Scenario: All modified files are committed Tool: Bash (git) Preconditions: Ready to commit Steps: 1. Run: git status 2. Verify downloads.js, watchlist/main.js, watchlist.html are listed as modified 3. Verify no other unexpected files are modified 4. Run: git diff --stat Expected Result: Only expected files modified, changes match plan Failure Indicators: Unexpected files modified, missing files, unrelated changes Evidence: .sisyphus/evidence/task-12-git-status.txt ``` **Commit**: YES (This task IS the commit action) - Groups all previous tasks into final commits - [ ] F1. **Plan Compliance Audit** — `oracle` Read the plan end-to-end. For each "Must Have": verify implementation exists. For each "Must NOT Have": search codebase for forbidden patterns. 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. **Code Quality Review** — `unspecified-high` Check all changed files for: duplicate variable declarations, duplicate const declarations, syntax errors, console errors. Verify no new bugs introduced. Output: `Syntax [PASS/FAIL] | Duplicates [0/N] | Files [N clean/N issues] | VERDICT` - [ ] F3. **Real Manual QA** — `unspecified-high` (+ `dev-browser` skill) Start from clean state. Navigate to `/web` and `/watchlist`. Verify watchlist loads successfully, search works, navigation button returns to home. Check browser console for 0 errors. Test all watchlist features (add, remove, search, stats). Output: `Console Errors [0/N] | Watchlist Load [PASS/FAIL] | Search [PASS/FAIL] | Navigation [PASS/FAIL] | VERDICT` --- ## Commit Strategy - **1**: `fix(js): Remove duplicate variable declarations in downloads.js` - Files: `static/js/downloads.js` - **2**: `fix(js): Remove duplicate API_BASE declaration from watchlist/main.js` - Files: `static/js/watchlist/main.js` - **3**: `fix(html): Remove duplicate script loading from watchlist.html` - Files: `templates/watchlist.html` - **4**: `feat(ui): Add navigation button to return to /web from watchlist` - Files: `templates/watchlist.html` --- ## Success Criteria ### Verification Commands ```bash # Check downloads.js has no duplicate declarations grep -n "const sortBy" static/js/downloads.js | wc -l # Expected: 1 # Check watchlist/main.js has no API_BASE grep -c "API_BASE" static/js/watchlist/main.js # Expected: 0 # Check watchlist.html doesn't load watchlist/main.js locally grep -c "watchlist/main.js" templates/watchlist.html # Expected: 0 # Verify navigation button exists in watchlist.html grep -c "Retour à l'accueil" templates/watchlist.html # Expected: >= 1 # Test backend API endpoints curl -s http://localhost:3000/health # Expected: {"status": "ok"} ``` ### Final Checklist - [ ] All "Must Have" present (fixes applied, navigation button added) - [ ] All "Must NOT Have" absent (no new frameworks, no route changes) - [ ] Browser console shows 0 JavaScript errors - [ ] Watchlist loads in < 3 seconds with no infinite loading - [ ] Search functionality works - [ ] Navigation button returns to `/web` - [ ] Backend API endpoints respond correctly