CI Prep

<!-- agent-pmo:2efd847 -->

CI Prep

Prepare the current state for CI. If CI is already failing, fetch and analyze the logs first.

Arguments

• --failing — Indicates a GitHub Actions run is already failing. When present, you MUST execute Step 1 before doing anything else.
• Any other argument is treated as a job name to focus on (but all failures are still reported).

If --failing is NOT passed, skip directly to Step 2.

Step 1 — Fetch failed CI logs (only when --failing)

You MUST do this before any other work.

BRANCH=$(git branch --show-current)
PR_JSON=$(gh pr list --head "$BRANCH" --state open --json number,title,url --limit 1)

If the JSON array is empty, stop immediately:

No open PR found for branch $BRANCH. Create a PR first.

Otherwise fetch the logs:

PR_NUMBER=$(echo "$PR_JSON" | jq -r '.[0].number')
gh pr checks "$PR_NUMBER"
RUN_ID=$(gh run list --branch "$BRANCH" --limit 1 --json databaseId --jq '.[0].databaseId')
gh run view "$RUN_ID"
gh run view "$RUN_ID" --log-failed

Read every line of --log-failed output. For each failure note the exact file, line, and error message. If a job name argument was provided, prioritize that job but still report all failures.

Step 2 — Analyze the CI workflow

1. Read every .github/workflows/ci*.yml completely — the PR pipeline is split into reusable workflows ([DIST-CI-LAYOUT]), so ci.yml alone only shows the orchestration:
   • ci.yml — orchestrator: detect-changes, dependency review, manifest validation, one uses: job per leg
   • ci-lint.yml — Rust / Zed / .NET / VS Code lint + format gates
   • ci-test-rust.yml — sharded Rust e2e suite, coverage gate, version contract
   • ci-test-dotnet.yml — sidecar tests (Ubuntu) + win32 named-pipe transport
   • ci-test-vsix.yml — full VS Code suite + coverage gate (Ubuntu)
   • ci-test-vsix-windows.yml — VS Code feature chunks on Windows ([DIST-CI-WIN-VSIX])
2. Parse every job and every step, then extract the ordered list of commands the CI actually runs.
3. Note any environment variables, matrix strategies, or conditional steps that affect execution. In particular the Windows VS Code matrix expands from src/editors/vscode/test-chunks.json — enumerate the chunks with node tools/vsix/vsix-test-chunks.mjs matrix and run each locally as make _test-vsix-win CHUNK=<name>.

Do NOT assume the steps are make lint, make test, make build. The actual CI may run different commands, in a different order. Extract what the CI actually does.

Step 3 — Run each CI step locally, in order

Before making changes, coordinate with other agents via TMC:

1. Check TMC status for active agents and locked files
2. Do NOT edit files locked by other agents
3. Lock files before editing them
4. Broadcast what you are doing

Work through failures in this priority order:

1. Formatting — run auto-formatters first to clear noise
2. Compilation errors — must compile before lint/test
3. Lint violations — fix the code pattern
4. Runtime / test failures — fix source code to satisfy the test

For each command extracted from the CI workflow:

1. Run the command exactly as CI would run it (adjusting only for local environment differences like not needing actions/checkout).
2. If the step fails, stop and fix the issues before continuing to the next step.
3. After fixing, re-run the same step to confirm it passes.
4. Move to the next step only after the current one succeeds.

Fix Rules

• Rust clippy violations: Fix the code. Never add #[allow(clippy::...)] without an extraordinary justification.
• Rust fmt: Run cargo fmt to auto-fix, then verify with cargo fmt --check.
• TypeScript prettier: Run cd src/editors/vscode && npx prettier@3 --write 'src/**/*.ts' to auto-fix.
• TypeScript ESLint: Fix lint errors in the source. Never add // eslint-disable.
• TypeScript tsc: Fix type errors. Never use any to silence a type error.
• .NET csharpier: Run dotnet csharpier src/sidecars/ to auto-fix.
• .NET build warnings: Fix the actual warning in the source code.