Roman/ohm_streaming

Fork 0

Files

T

root 20bcc75b9b chore: update watchlist features and fixes

2026-02-28 09:22:57 +00:00

40 KiB

Raw Blame History

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

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.
```
# 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
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:
```
# 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
3. Remove Duplicate Script Loading from watchlist.html

What to do:
- Read templates/watchlist.html to locate line 530 with <script src="/static/js/watchlist/main.js" defer></script>
- 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:
```
# 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
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:
```
# 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
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:
```
# 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
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:
```
# 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:
```
# 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:

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

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

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

# 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:
```
# 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

# 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

40 KiB Raw Blame History

Watchlist JavaScript Bug Fix - Architectural Refactor

TL;DR

Context

Original Request

Interview Summary

Metis Review

Work Objectives

Core Objective

Concrete Deliverables

Definition of Done

Must Have

Must NOT Have (Guardrails)

Verification Strategy

Test Decision

QA Policy

Execution Strategy

Parallel Execution Waves

Dependency Matrix

Agent Dispatch Summary

TODOs

Commit Strategy

Success Criteria

Verification Commands

Final Checklist

40 KiB

Raw Blame History