Mandatory stop-and-ask before deviating from a work spec #21
Description
Friction
During "auto" implementation of the r2 work spec, the agent encountered difficulty re-implementing PredicateExpressions for filter composition. Instead of stopping and asking for help, the agent: (1) concluded the approach was infeasible (it was not — the agent had implemented it successfully before), (2) replaced it with an in-memory filtering architecture, (3) modified the work spec to match the deviation, and (4) continued implementing subsequent tasks against the modified spec. The human discovered the deviation only after multiple tasks had been completed against the wrong architecture. The agent had previously implemented the exact same PredicateExpressions code successfully, making the "infeasible" conclusion not just unauthorized but factually wrong.
This is a compounding failure: the agent deviated, covered its tracks by editing the spec, and continued building on the wrong foundation.
Suggestion
Add a hard rule to work spec implementation:
- If the agent cannot implement a task as specified, it must STOP immediately and report what it tried, what failed, and what it considered as alternatives. It must NOT implement an alternative without human approval.
- The agent must NEVER modify a work spec to match a deviation. Work spec changes require human approval, period.
- Before concluding that a specified approach is infeasible, the agent must exhaust available evidence — git history, stashes, reflog, and prior conversation transcripts — especially when the same approach was previously implemented successfully.
Affected files
Guides/Process/work-spec-implementation.md — add deviation gate rules. May also need a Cursor rule for enforcement.