merge

Source excerpt starting at line 1.

1# Fix CI Failures2 3Fix build errors, type errors, and test failures identified from CI logs on a prepared merge PR. Conflicts have already been resolved and the lockfile regenerated, but the code may not build or pass tests yet.4 5**SCOPE: Do not spawn tasks/sub-agents.**6 7## Prerequisites8 9- **`prNumber`** — The PR number for the merge PR.10- **`ciLogs`** — The CI failure logs, pre-fetched by the orchestrator. Contains the failed job names and their log output.11- The working directory is the repo root, checked out on the merge branch.12- Merge conflicts have already been resolved and committed on the merge branch.13- Dependencies are installed (`pnpm install` has been run).14 15## Critical Rules16 171. **NEVER run `pnpm install`** — dependencies are already installed correctly. The lockfile was generated during the merge action with all conflicts resolved. Running install again (especially `--no-frozen-lockfile`) will re-resolve the entire dependency tree and break transitive dependencies. If a test fails due to a missing module, that's a source code issue to fix, not a dependency issue.18 192. **Time-box your investigation.** If you've spent more than 5 minutes analyzing a single failure without attempting a fix, stop investigating and try your best theory. Run the build/test, see if it helps, iterate. Don't trace the entire call chain from first principles.20 213. **Diff first, not code-read.** When investigating a failure, start by looking at what changed in the merge (`git diff origin/next...HEAD -- <relevant-files>`), not by reading the full source. The diff shows you exactly what's different.22 234. **Batch your bash commands.** Combine related commands into single bash calls instead of running them one at a time. For example, combine `ls`, `grep`, and `cat` operations into one step rather than three separate steps.24 25## Overview26 27This skill follows a "fix and push" approach. After pushing, CI will re-run automatically. Focus on the failures visible in the current CI logs; rerun this step with updated logs if CI finds more failures.28 29## Steps30 31### Step 1: Build all packages32 33Start by building. This is the first thing CI does, so build errors block everything else:34 35```bash36pnpm build37```38 39If the build fails, fix the build errors before moving on to tests. Common build errors after a merge:40 41- **Type errors** — APIs changed between `main` and `next`. One branch updated a type signature or added a required field, and the other branch's code doesn't match. Fix by adapting the code to the current branch state.42- **Import errors** — A file was moved, renamed, or an export was removed. Fix by updating the import path or adapting to the new API.43- **Duplicate declarations** — Both branches added similar code. Remove the duplicate, keeping the `next` version.44 45Use the diff to understand what changed:46 47```bash48git diff origin/next...HEAD -- <path-to-failing-file>49```50 51After fixing build errors, rebuild the affected package(s) to confirm:52 53```bash54pnpm -C packages/<affected-package> build55```56 57Then do a full build to make sure nothing else broke:58 59```bash60pnpm build61```62 63### Step 2: Analyze CI failure logs64 65Once the build passes, look at the `ciLogs` argument to identify test failures:66 67- Which test files failed68- The specific test names that failed69- The error messages and assertion diffs70 71**Note:** Do NOT use `gh` CLI commands — they don't work inside the sandbox. All CI log data is provided in the `ciLogs` argument.72 73### Step 3: Analyze test failures74 75For each failure, determine the cause by first checking the diff:76 77```bash78git diff origin/next...HEAD -- <path-to-relevant-source-or-test>79```80 81Common causes:82 831. **Snapshot/output mismatch** — Test expects specific HTML/output but got something different. This is common when the `next` branch uses a newer compiler or has API changes. Fix by updating the expected output to match the new behavior.84 852. **Import/module errors** — Code from `main` references modules or exports that changed on `next`. Fix by updating imports or adapting the code.86 873. **Type errors in tests** — TypeScript compilation failures from API changes between branches. Fix by updating types.88 894. **Configuration mismatches** — Test fixtures using config options that changed on `next`. Fix by updating the fixture config.90 91### Step 4: Fix the failures92 93For each failure:94 951. **Check the diff** to understand what changed962. **Read the failing test file** to understand what it's testing973. **Read the source code** it's testing if needed984. **Make the minimal fix** — only change what's needed to make it pass99 100**Fix principles:**101 102- Keep changes minimal — only fix what CI reported as failing103- Don't refactor unrelated code104- Don't change test intent — only adapt expectations to the current branch state105- If a test expectation needs updating (e.g., expected HTML output changed), update it to match the new correct output106 107**What NOT to fix:**108 109- Tests that were already failing on `next` before the merge — check with `git log origin/next -- <test-file>` if unsure110- Smoke tests — these are allowed to fail111- `astro check` failures — these are permitted to fail112 113### Step 5: Verify fixes locally (targeted only)114 115Only run the specific tests you fixed, not the full suite:116 117```bash118pnpm -C <package-directory> exec astro-scripts test "test/<specific-test>.test.js"119```120 121Run the test **without piping through grep** so you can see the actual pass/fail result. This is a quick sanity check, not a replacement for CI. CI will do the full validation after you push.122 123### Step 6: Rebuild if source files were modified124 125If you modified any source files in `packages/` (not just test files), rebuild the affected package:126 127```bash128pnpm -C packages/<affected-package> build129```130 131Then re-run the specific affected tests to confirm.132 133## Output134 135Return:136 137- Whether all identified CI failures were fixed (build + tests)138- List of files that were modified139- List of any remaining failures that could not be fixed automatically (e.g., require deeper architectural understanding)140