technical-premortem

/technical-premortem — Technical pre-mortem

Skill advisory и read-only. Он не является workflow gate, не заменяет /review-feat-plan, /review-tasks-plan, /verify, /red-verify или /mb-doctor и не меняет task lifecycle, approvals, ownership или durable artifacts.

Finding не создаёт requirement и не расширяет accepted target. Если нужная mitigation меняет product behavior, design, task boundary, tier или proof contract, направь её существующему owning workflow.

<input_contract> Expected $ARGUMENTS: один TASK-NNN-TN-FT-NNN-WN либо однозначно названный implementation plan или planned change. Без аргумента используй текущий operator context только когда target однозначен.

Прочитай относящиеся к target task/plan, accepted specs, code, tests, configuration, migrations и доступный operational context. Восстанови:

• что меняется: files, modules, behavior, data/schema/config и contracts;
• кто зависит: callers, consumers, jobs, integrations и operational owners;
• что разделяется: state, cache, sessions, queues, storage и environment;
• intended outcome, compatibility constraints, proof path и accepted limits.

Если material scope, intended behavior или authoritative target не восстановимы, задай короткие точечные вопросы и остановись без verdict. Не выдумывай структуру, потребителей, production conditions или требования. </input_contract>

<failure_frame> Представь, что изменение уже смёржено и, где применимо, задеплоено. Проверь каждый относящийся к target путь провала:

1. Само не сработало — intended behavior не достигнут из-за логики, данных, edge case или неверного допущения.
2. Сломало соседнее — регрессировал consumer, contract, shared state или скрытая зависимость.
3. Ухудшило, не сломавшись явно — деградировали security, performance, reliability, operability, maintainability или architecture boundary.
4. Сработало, но навредило позже — harm проявился на реальных данных, под нагрузкой, при конкуренции, после deploy или rollback.

Не останавливайся на первом очевидном сценарии. Сначала найди конкретные candidate failures по применимым путям и surfaces, затем отфильтруй их по evidence, consequence и recoverability. Отклонённые speculative candidates в ответ не включай. </failure_frame>

<failure_surfaces> Используй только относящиеся к target surfaces, но не пропускай применимые:

• correctness и historical/null/partial data;
• callers, contracts, integrations, versions и shared state;
• migrations, irreversible writes, queues, caches и rollback residue;
• security, permissions, secrets и trust boundaries;
• dependency failure, retries, timeouts, idempotency и concurrency;
• production scale, latency, memory, deployment order и config drift;
• observability: как оператор или тест узнает о конкретном сбое;
• architecture/maintainability: какой accepted owner, boundary или invariant будет нарушен;
• agent-execution error: где исполнитель может двусмысленно прочитать target, выдумать API, затронуть лишнее, нарушить accepted boundary или предъявить нерелевантное evidence.

Agent-execution surface проверяется всегда; finding публикуется только при конкретном material механизме или decision-relevant blind spot. </failure_surfaces>

<risk_model> Классифицируй только findings, способные изменить решение или pre-flight:

• 🐅 Tiger — подтверждённый material risk: evidence связывает конкретный mechanism с наблюдаемым symptom и affected surface. Игнорирование способно сорвать accepted outcome. Укажи urgency merge_blocker, follow_up или observe.
• 🐯 Paper Tiger — сценарий выглядит опасно, но inspected evidence, ограниченный impact или дешёвая recoverability показывают, почему он не blocker. Включай его только когда явное понижение риска предотвращает ненужную сложность или влияет на verdict.
• 🐘 Elephant — существенное допущение, blind spot или отсутствие evidence, на котором зависит решение. Назови, какое решение от него зависит, какой evidence отсутствует и кто может закрыть неизвестность.