AY Fix
Prove the cause, then make the smallest authorized repair that prevents recurrence.
Approval contract
- Read the full request and investigate discoverable facts before asking the user.
- Treat review, diagnosis, explanation, and planning as read-only unless the user also requests change.
- Treat a precise instruction as approval when target, observable result, and acceptance boundary are clear.
- A broad outcome authorizes investigation, not file or artifact changes based on choices the agent must invent.
- For a materially underspecified change, present one recommended proposal and wait for approval.
- After approval, execute autonomously inside the approved boundary; do not ask about ordinary implementation details.
- Reopen approval only when new evidence changes behavior, architecture, data contracts, dependencies, scope, risk, cost, rollback, or external actions.
- Perform external actions only when the request or approved proposal includes them. Confirm the exact target before an irreversible action.
- Preserve unrelated and user-authored work. Verify the real requested outcome before claiming completion.
Diagnose
- Capture the exact symptom, expected behavior, environment, and failure layer.
- Reproduce through the closest available path, or name the missing reproduction condition.
- Trace backward from the bad output to the earliest incorrect state. Read recent changes and working examples when relevant.
- Form competing hypotheses and run the smallest discriminating check. Instrument boundaries when observation is missing.
- Confirm the cause. A plausible smell, correlation, or vanished symptom is not proof.
After a failed hypothesis, collect new evidence before trying another. Do not edit repeatedly in place of diagnosis.
Decide the repair boundary
If the user asked only to diagnose, stop with the confirmed cause or next discriminating check.
If the user asked to fix, proceed without another checkpoint only when the root-cause repair is unique, local, reversible, and preserves intended behavior. Present a repair proposal first when alternatives change product behavior, architecture, data contracts, dependencies, scope, external state, or material risk.
Repair and prove
Fix the cause at the narrowest responsible boundary, not its downstream symptom. Add a regression check when a stable behavior seam exists; do not invent hollow tests for untestable surfaces.
Re-run the original reproduction, regression check, and relevant neighbors. Separate environment, harness, source, build, package, deployment, and real-runtime evidence. If the cause remains unproven, say so.
Report the cause, discriminating evidence, repair, proof, and remaining uncertainty.
1---2name: ay-fix3description: Diagnose and repair bugs, regressions, crashes, hangs, test failures, incorrect behavior, and unexpected slowness through evidence and root cause. Use when something broke or the user asks to diagnose, 修bug, repair, or implement a proven fix; keep diagnosis read-only unless repair is requested. Let a dedicated diagnosis-only workflow lead a diagnosis-only request when available. Do not use for planned improvements without a failure symptom.4---56# AY Fix78Prove the cause, then make the smallest authorized repair that prevents recurrence.910## Approval contract1112<!-- ay-contract:start -->13- Read the full request and investigate discoverable facts before asking the user.14- Treat review, diagnosis, explanation, and planning as read-only unless the user also requests change.15- Treat a precise instruction as approval when target, observable result, and acceptance boundary are clear.16- A broad outcome authorizes investigation, not file or artifact changes based on choices the agent must invent.17- For a materially underspecified change, present one recommended proposal and wait for approval.18- After approval, execute autonomously inside the approved boundary; do not ask about ordinary implementation details.19- Reopen approval only when new evidence changes behavior, architecture, data contracts, dependencies, scope, risk, cost, rollback, or external actions.20- Perform external actions only when the request or approved proposal includes them. Confirm the exact target before an irreversible action.21- Preserve unrelated and user-authored work. Verify the real requested outcome before claiming completion.22<!-- ay-contract:end -->2324## Diagnose25261. Capture the exact symptom, expected behavior, environment, and failure layer.272. Reproduce through the closest available path, or name the missing reproduction condition.283. Trace backward from the bad output to the earliest incorrect state. Read recent changes and working examples when relevant.294. Form competing hypotheses and run the smallest discriminating check. Instrument boundaries when observation is missing.305. Confirm the cause. A plausible smell, correlation, or vanished symptom is not proof.3132After a failed hypothesis, collect new evidence before trying another. Do not edit repeatedly in place of diagnosis.3334## Decide the repair boundary3536If the user asked only to diagnose, stop with the confirmed cause or next discriminating check.3738If the user asked to fix, proceed without another checkpoint only when the root-cause repair is unique, local, reversible, and preserves intended behavior. Present a repair proposal first when alternatives change product behavior, architecture, data contracts, dependencies, scope, external state, or material risk.3940## Repair and prove4142Fix the cause at the narrowest responsible boundary, not its downstream symptom. Add a regression check when a stable behavior seam exists; do not invent hollow tests for untestable surfaces.4344Re-run the original reproduction, regression check, and relevant neighbors. Separate environment, harness, source, build, package, deployment, and real-runtime evidence. If the cause remains unproven, say so.4546Report the cause, discriminating evidence, repair, proof, and remaining uncertainty.
ALVIN-YANG