fix-cilisted

Fix the failure CI actually reported, not the one you assume it hit. The log line that failed the job is evidence; everything else is guessing. Pull it first, reproduce it locally second, and only then change code. ## Step 1: Get the real failure ```bash # What failed, and on which commit gh run list --limit 10 gh run view <run-id> --log-failed 2>&1 | tail -80 ``` Read the failed step's output completely. Identify: the failing step name, the exact error, and whether the failure is in *your change* or in the pipeline itself (setup step, cache, runner image, flaky network). If several jobs failed, find the first failure in dependency order; downstream jobs often fail as a consequence. If the run belongs to a PR, also check which check is required and whether the failure is new to this branch: ```bash gh pr checks <pr-number> git log --oneline origin/main..HEAD ``` ## Step 2: Reproduce locally Run the failing step's actual command from the workflow file, not your usual local equivalent: ```bash # Read the workflow to get the exact command and environment cat .github/workflows/<workflow>.yml ``` - **Reproduces locally:** it is a code problem. Debug it normally (the `systematic-debugging` skill applies) and fix the root cause. - **Passes locally, fails in CI:** the difference is environmental. Compare in this order: dependency install mode (`--frozen-lockfile` vs a loose local install), Node/tool versions (CI pins one; check yours), OS differences (case-sensitive paths, l