engineering-mission-playbook

# Engineering Mission Playbook ## 1. Engineering Success Invariants Engineering success means the accepted user, caller, operator, or consumer-visible behavior is implemented, preserved, and independently proven on the real surface. Code motion, file diffs, worker claims, green commands, or task completion are not success by themselves. Success requires: - accepted scope is preserved through `mission.md` or the current scope charter, the scope/capability inventory, live `VAL-*` assertions, or explicit accepted non-goal/risk decisions; - every user-mentioned engineering requirement is represented in the inventory and contract unless explicitly removed by the user or a recorded decision; - contract assertions define the mission's done criteria; task bodies and skills may explain how to work, but they must not hide acceptance promises; - real user/caller/operator surfaces are tested whenever they exist: browser/UI behavior through an actual browser, APIs through real requests, CLI/TUI behavior through real commands or terminal interaction, background jobs through real triggers and outputs, generated artifacts through real generation and consumption, migrations/data behavior through actual before/after state, and public libraries through real imports/calls; - validation covers the full requested behavior surface, including common paths, edge cases, error paths, empty states, retries, persistence, compatibility, permissions, unusual but plausible cases, and narrow or low-frequ...