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-frequency behaviors that are still part of the accepted scope;
• automated test coverage must include relevant unit, integration, regression, fixture/golden, end-to-end, and system-level checks when those layers exist or are needed to prove the assertion;
• for porting, parity, compatibility, or drop-in replacement missions, the target must pass the relevant original/source test suite, golden corpus, differential command/API checks, and compatibility examples for the accepted source version, unless a specific divergence is explicitly accepted and recorded;
• task topology groups implementation effort without changing assertion granularity, ownership clarity, evidence requirements, or verdict clarity;
• many atomic assertions may map to fewer coherent work tasks when implementation boundaries are shared;
• every live assertion has exactly one active owning work task that completes it, not merely contributes to it;
• validators prove assertions independently through the surface and evidence required by each assertion;
• Needs and Evidence fields are binding: unmet prerequisites, missing evidence, skipped assigned targets, wrong validation surface, or incomplete source-suite parity means blocked or failed, not passed;
• automated tests, source inspection, worker-authored specs, and green commands are supporting evidence unless the assertion names them as the oracle;
• gates and closure claims seal only evidence-backed assertions or explicit accepted-risk/scope decisions.