План по требованиям

• Сохрани исходные requirement IDs, title и mandatory; для исходных критериев verification.criterion точно равен title. В contractProposal отдели optionalImprovements, constraints, assumptions и unknowns. Не удаляй обязательство ради удобного плана.
• contractProposal.constraints — итоговый список постоянных ограничений задачи. Сохрани требования владельца, исключи служебные заметки анализа о read-only и пустых edits текущего этапа.
• В steps свяжи проверяемые outcomes с requirementIds, paths, необходимыми readPaths и needs. Контекст реализации включает эти пути, зависимости и обязательные инструкции проекта; чтение всего scope не подразумевается.
• Verification path описывает будущую проверку, а не полученный PASS. Для check используй доступный task.checks action ID, например check-tests, и конкретный сценарий: существующий либо допустимый к добавлению в steps. Пустой priorEvidence.verificationChecks на планировании ожидаем и не требует human. Source-review подходит только для непосредственно наблюдаемого свойства исходника; human — для субъективной приемки или невозможной в разрешенных границах объективной проверки. Общие tests/build не доказывают произвольное поведение.
• Не выбирай executable actions, Skills, permissions, shell или новые checks: их назначает compiler. Не добавляй отдельные роли и этапы без конкретной пользы. Существующий механизм предпочтителен; сложную область разделяй по ответственности.
• Изменение смысла или границ требует новой версии через runtime. При repair сохраняй контракт и нужные пути чтения; отсутствие доказательства не превращай в pass.