frontend-mix-fix-validation

name	frontend-mix-fix-validation
description	Address validation failures recorded by the frontend-mix-validate step. Failures that survived two repair attempts need real judgment - switch to a strong reasoning model with /model. Reads validation-issues.md, fixes each failure at the source, re-runs the validation suite, writes resolution-summary.md. Use when frontend-mix-validate wrote validation-issues.md instead of validation-summary.md.
argument-hint	<validation-issues.md path> <plan.md path>

Frontend-Mix · Fix Validation

You are the escalation step for validation failures the prior pass couldn't fix in two attempts. Strong reasoning is what's needed here - select a strong reasoning model with /model before you start.

What to do

1. Read the validation-issues markdown (first path the user gave you - your work list) end-to-end with the view tool.

2. Read the plan markdown (second path) and extract everything under ## SECTION B - Integration Scope. This is what was supposed to be wired up.

3. The validation-issues filename carries your run-name. Strip the directory and the -validation-issues.md suffix. You'll use it to name your output file.

4. For each failure listed in the issues file, open the source file(s) it blames with view before forming a fix. Do not assume - verify.

5. If either path is missing or doesn't resolve, ask the user for the missing path. Do not work from memory.

Address each failure

For every failure in the issues file:

1. Diagnose at the source. Read the actual offending file end-to-end. If the error says "X has no property Y", figure out whether the right fix is adding Y to X's type or stopping the access to Y, based on what the plan says should be true.
2. Apply a real fix. Edit the source code, not the validation config.
3. Re-run the specific failing command to confirm the fix worked. If a fix breaks a different check, address that too.

Banned shortcuts (these are bugs, not solutions)

• Adding // @ts-ignore, // eslint-disable, or any to silence checks
• Deleting failing tests
• Removing strict mode or loosening tsconfig / eslint config
• Skipping validation steps you can't fix
• Pretending a failure is "flaky"

Genuine blockers

If a failure truly cannot be fixed without changing the plan (e.g. a missing third-party API key, a Clerk feature requiring a paid plan, a breaking change in an upstream library), record it as an OPEN ISSUE in the resolution file with the exact blocker. Do not silently skip.

Re-run the full validation suite once

After all individual fixes, run install → typecheck → lint → build → tests once end-to-end. Record the final state of each step.

Output

Write to .agents/artifacts/<run-name>-resolution-summary.md. Create the .agents/artifacts/ directory if it doesn't exist.

Contents:

• Each original failure from the issues file
• The fix applied (file:line + what changed) OR "OPEN ISSUE: "
• Final state of bun run build and tests
• A status line at the end: "READY TO DEPLOY" if everything is now clean, else "NOT READY: "

After fixing

Tell the user the absolute path to <run-name>-resolution-summary.md and the next step:

If status is READY TO DEPLOY:
  Next: ask Copilot to run the frontend-mix-smoke step with the integration-summary
  path and the resolution-summary path.

If status is NOT READY:
  Surface the open issues to the user and stop. Do not deploy a broken build.