pre-mortemlisted

# Pre-Mortem: Adversarial Failure Analysis `verification-before-completion` asks "does it work now?" This skill asks "when will it break, and will we know?" ## Surface List Fires on these surfaces (auto-triggers deep analysis): | Surface | Examples | |---------|---------| | Scheduled tasks | cron, systemd, @reboot | | Hooks / daemons | stop hooks, background processes | | Persistent writes | config, state, databases | | Auth / permissions | credentials, access control | | Infrastructure | services, ports, network | | Data mutations | schema changes, migrations, bulk writes | | Architecture decisions | new modules, service boundaries, data models | | Third-party integrations | APIs, webhooks | | Dependency changes | upgrades, downgrades, version pins | | Deployment | push, release, merge to main | | GitHub actions | gh pr create, gh issue create, gh issue new, push to remote | Non-consequential work gets a minimum stamp and NO TOKEN: `PRE-MORTEM · [action] · CLEAR — no consequential surfaces detected. No clearance token issued.` If the edit-surface-guard fires during what you assessed as non-consequential work, that is a signal the action IS consequential. Re-run pre-mortem on the actual action with full analysis. ## Surface Classification — determines required dimensions **Default rule: when in doubt, classify as Infrastructure.** | Classification | What qualifies | Dimensions required | |---|---|---| | **Infrastructure** | Any edit to: cron/systemd/@reboot entries;