Failure Protocol Instructions

Silent failure is the most dangerous failure mode in agentic work. The agent encounters ambiguity, picks an interpretation, proceeds, and produces output that looks complete but has missed the mark. You do not know this happened. The fix is not better inference — the fix is explicit instructions for what to do when the task encounters ambiguity, conflict, or an error it cannot resolve.

## When to Stop and Ask

Stop and ask before proceeding in these situations:
- The task requires changes outside the scope you were given
- You encounter a merge conflict that requires a judgment call about which version is correct
- The test suite was passing before your changes and fails after — do not attempt to fix the tests without asking
- You identify a breaking change that affects the public API
- You are about to take an action that is irreversible (deletion, force-push, schema drop)

Do not attempt to resolve these situations through inference. Stop. Describe what you found. Ask for direction.

## When to Proceed Without Asking

You may proceed without confirmation for:
- TypeScript errors you introduced that you can fix without changing behavior
- Linting errors in code you modified
- Test failures caused by test setup, not by your changes (missing mocks, wrong test env)
- Formatting issues in files you edited

1. Define stop conditions explicitly List the specific situations that require stopping: out-of-scope changes, irreversible actions, test failures introduced by the agent, breaking changes. If the situation is not listed, the agent will use judgment — which means it will continue.
2. Define the stop action "Stop" needs a next step: describe what you found, ask for direction, wait for confirmation. An agent that stops without a next action creates a different problem — a session that stalls with no clear path.
3. Define proceed conditions equally explicitly Failure protocols work better when they include both stop and proceed conditions. When the agent knows what it can handle autonomously — TypeScript errors it introduced, linting issues, missing mocks — it does not need to ask about those, which reduces unnecessary interruptions.