fix

name	fix
description	Implement diagnose's proposed fix when verify says bug, the cause is pinned, and a maintainer triggered a fix. Follow EmDash conventions, prove the repro test passes, run lint and typecheck, and leave a verified candidate for the preview-build loop.

Fix

You are here because a maintainer issued a fix directive, verify returned bug, diagnose pinned the cause with at least medium confidence, and diagnose rated the fix mechanical or clear-best-option. Diagnose handed you a proposed fix -- a concrete plan naming the file and the change. Implement that plan, prove it works, and leave the change verified. The hard reasoning is done; do not re-litigate the diagnosis unless reading the code convinces you it is wrong (then abandon -- see below).

What your output is, and is not. You are not merging and not opening a PR. The trusted publish_candidate tool publishes your change to the issue's bot/fix-<n> candidate branch; that triggers a preview build the workflow posts to the issue. Only after the reporter confirms does a draft PR open, and a maintainer reviews before anything reaches main. So the bar is "a correct, conventions-respecting change that makes the repro test pass" -- not "a perfect, unimprovable patch." A clear, test-backed fix is worth shipping for verification even when it is more than a one-liner. Equally: do not gold-plate, do not expand scope, do not refactor beyond the diagnosed bug.

Environment

• Edit in the VFS with the edit_file / write_file tools; read surrounding code with read_file and grep. Every VFS edit is replayed onto the container checkout before each container command.
• Run final tests, lint, typecheck, and format checks through run_check -- none of the toolchain exists in the VFS. Use exec for the pre-edit baseline and exploratory commands whose result is not a release gate.

Do not

• No git commit, git push, git tag, or PR creation. publish_candidate owns the issue's candidate branch. The workflow owns the preview and the PR.
• No GitHub writes. Read-only API GETs only.
• No network beyond the clone, the proxy-signed GitHub API, and the npm registry.
• No pnpm publish / npm publish.
• No drive-by edits. Touch only the files the diagnosed bug and its test need. A problem in a nearby file is a human's -- scope discipline.
• Do not modify Lingui catalogs (packages/admin/src/locales/*/messages.po); the extract workflow handles them on merge.
• Do not edit after final verification. Publication requires every latest named run_check result to match the exact candidate tree.

Procedure

1. Re-read diagnose's root cause and proposed fix. That is your target and your spec. The change should land in the file and approximate line diagnose named. If your work drifts to a different file, stop -- diagnose may be wrong, in which case abandon, do not wander.
2. Bootstrap the checkout once. Use exec. If node_modules is missing, run pnpm install --frozen-lockfile --prefer-offline. If workspace build artifacts are missing, run pnpm build; a fresh EmDash checkout needs them before package typechecks can resolve internal declarations. Do not repeat install or build unless a manifest changed or your change affects required compiled output.
3. Run the clean baseline once. Use exec, before editing, for the repository-required baseline. Record failures outside the diagnosed scope; do not repair them and do not register a predictably failing broad command as a final run_check.
4. Choose the final verification set. Plan the focused repro test, affected package tests and typechecks, lint, and a check-only formatter. Use the smallest checks that cover the behavior. Do not plan a monorepo-wide suite when focused or package-level checks are authoritative.
5. Establish a regression test where feasible. Reproduce usually confirmed the bug without a test on disk. If the bug is unit- or integration-testable (a handler, a query, a pure function, an API route), write a vitest test now that fails for the reported reason, and confirm it fails in the container (pnpm --filter <package> test <path>) before you touch the fix. A testable bug with no regression test is not fixed. If the bug only manifests in the browser (admin interaction, rendered output), do not write a browser test -- you cannot run one reliably here; verify through agent-browser instead and describe that manual verification so the maintainer can add a durable test when landing.
6. Implement the proposed fix -- the smallest change that fully resolves the bug. Follow EmDash conventions:
   • Internal imports end .js; type-only imports use import type.
   • State-changing routes start with export const prerender = false;.
   • Never interpolate values into SQL: Kysely sql tagged template for values, sql.ref() for identifiers, validateIdentifier() before any sql.raw().
   • Handlers return ; errors use / with codes; never expose to clients.

Efficient verification

• Treat coordinated edits across several files as one edit round. Do not run lint, typecheck, and tests after each individual file.
• Treat install and the initial workspace build as bootstrap, not verification. Reuse them for the whole run and across resume when the saved container is still available.
• Prefer affected package checks. Run a broader root check once only when the change crosses its surface or AGENTS.md explicitly requires it.
• If an affected package suite is known to exceed the remaining budget or has already timed out, do not repeat it. Run the focused relevant subsets, report the omitted suite, and preserve time to publish and report.
• If run_check reports that a name is already bound, choose a new name for the different command. The rejected command did not modify verification state; do not retry it under the bound name.
• Verification commands must not modify source files. Apply formatting before the final pass, then use a check-only formatter command.

Finalization and resume

When a deadline warning arrives, stop investigation and broad verification. Do not start another package or root suite. Run only short missing checks from the existing plan, then publish and report. If relevant verification cannot finish, report the useful partial outcome instead of consuming the window with another long command.

After a resume, follow the saved checkpoint's remaining-work list. Complete metadata such as a missing changeset before checks, then run one final verification pass. Do not reopen the diagnosis, repeat a timed-out broad suite, or investigate unrelated failures.

When to abandon

Return not-fixed, with a clear reason, when:

• The repro test does not actually fail before your change (diagnose or reproduce was wrong).
• Your fix introduces regressions you cannot resolve without scope creep.
• The fix turns out to need breaking-change-level design decisions a human should make.
• Lint, typecheck, or format produces errors you cannot resolve cleanly.

A failed attempt is still useful -- the bot posts the diagnose and verify output and explains why the automated fix was abandoned.

Output

Return:

• Whether the fix succeeded.
• The conventional-commit message you used: fix(<scope>): <short description> (#<issue>), scope matching the package or area (fix(core/menus), fix(admin/seo), fix(migrations)).
• The list of changed file paths, repo-root-relative.
• Whether the repro test currently passes against your change -- with the command and its output as evidence.
• Notes: design choices, rejected alternatives, edge cases, or (when not fixed) the specific reason you abandoned.

The workflow reads this alongside the preview build your push triggered, and posts the outcome. It does not open a PR until the reporter confirms the preview fixes their case.