two-phase-doc-honesty-then-engineeringlisted

# Two-Phase Response: Doc-Honesty Inline, Engineering Dispatched ## Problem A state-drift catch (the documented plan says X is PENDING but reality is X is DONE; the docs promise Y but the code can't deliver Y for the named target user; the case study cites a number that's no longer reproducible) surfaces TWO different kinds of work: 1. **Documentation inaccuracy** — the docs misrepresent current state. Fixing this is a few edits to README / examples / case-study / SOP doc. Fast. Low blast radius. No authorization needed beyond standard commit discipline. 2. **Engineering gap** — the docs were obscuring a real code-level limitation. Fixing this requires actual implementation work, possibly a subagent dispatch, possibly meaningful cost, definitely PM authorization in a budget-conscious context. If you bundle (1) and (2) into one effort, you either: - Wait on (1) because (2) needs authorization that hasn't arrived yet, leaving the docs lying to readers for hours/days - Pre-emptively dispatch (2) without authorization, violating the spend / scope discipline - Skip (2) and ship (1) as if the doc-honesty pass "closed" the issue, which it didn't — it just made the lie visible If you bundle them, you also create one commit / one push / one PR / one review cycle where there should be two — confusing the audit trail of what changed and why. The two-phase pattern keeps the responses cleanly separated by their natural cadence. ## Trigger conditions Apply this pattern when ALL of