risk-first

Implement the work in the spec, tickets, or request you were given.

1. Hunt the risks

Before you write code, identify risks in the change: a spec line that admits multiple readings, or a plausible mistake at a place where code goes subtly wrong: a boundary, an ordering or tie, absent versus empty, time and zone, identity, a repeat, a partial failure. Keep the hunt proportional to the change; a simple edit can have no risks.

For each risk, write down:

• the competing readings, each with the spec line it rests on, or the mistake and the requirement it would violate;
• the oracle that settles it. Checks expose ambiguity; they cannot decide intent. The oracle is a spec line, an acceptance criterion, an ADR, a seam profile, a worked example, or a run of the project's verification skill. With no oracle, take one reading as a stated assumption. When the readings lead to materially different work, ask the user. As a subagent, stop before writing code and report the question with its competing readings to your caller;
• one concrete input and its literal result from the oracle or stated assumption, as the intended behavior.

Done when every identified risk has an intended behavior supported by an oracle or stated assumption, and no unresolved ambiguity would materially change the work.

2. Build and verify

For a bug fix, attempt to reproduce the existing failure before the fix. If reproduction is blocked, state the missing conditions and use the available evidence to guide the fix.