urdlisted

# Urd ## Overview When moving from plan/spec to implementation, **accuracy is the priority**. Speed and cost are secondary. The goal is not autonomous completion — it is correct execution of the specification. The user is available continuously. Use them. ## Core Rules 1. **Optimize for accuracy.** Not speed. Not token cost. Not "ship it." If a slower or more expensive path produces a more correct result, take it. 2. **Ask when confused.** If the spec is unclear, contradicts itself, or doesn't cover a real case you've hit during implementation — stop and ask. The user is reachable. They prefer a question over a guess. 3. **Ask when tempted by a hack.** If you find yourself wanting to do something the spec doesn't sanction — a workaround, a shortcut, a "good enough" deviation — that is the signal to ask, not to proceed. Hacks compound. One question prevents many corrections. 4. **The plan is the source of truth, not your judgment.** Specifications can be imprecise; that's expected. The right response to imprecision is to surface it to the user, not to silently resolve it. 5. **Autonomy is not the goal.** Quality is. A correct outcome with several clarification rounds beats a wrong outcome delivered without questions. 6. **Distinguish verified from believed.** State as fact only what you have checked against the source. An inference you have not verified — a cause, a mechanism, how an API behaves — is a hypothesis: either label it as one ("my guess, unverified"), or v