3.6 KiB
status
| status |
|---|
| superseded |
Native OpenSpec lifecycle и repository gates
Обязательность описанной ниже процедуры заменена ADR 012. Текст сохраняет историческое решение; current policy — прямая работа по задаче.
Контекст
ADR 010 сохраняет rationale
выбора native OpenSpec и независимых repository gates. Его описание schema v3,
custom authority/planning verifiers и dispatcher относится к прежней реализации.
Текущая project-local schema wealth-ledger-sdd
имеет version 5 и граф Proposal → Delta Specs → Design → Tasks → Apply.
Native instructions и общие authorities уже определяют действующую процедуру;
optional entrypoints направляют к ней.
Отслеживаемый .cli-version существует и
содержит 1.10.0. Версия schema и CLI contract — разные сведения. Наличие этого
файла не доказывает запуск прежних verifiers; это решение не меняет CLI pin,
version contract, schema или требования к tooling.
Решение
Частично заменить ADR 010 в части прежней schema version и orchestration.
Canonical SDD store остаётся wealth-ledger-specs в specs/openspec.
Действующая процедура принадлежит существующим owners:
- Engineering governance — роли, отдельные approvals, Delivery Map, обязательность проверок и completion safeguards.
- OpenSpec lifecycle — native planning/apply, strict structural validation, semantic sync и completion procedure.
- Context discipline — выбор и повторная сверка inputs, fingerprints, recovery и evidence reuse.
Native OpenSpec получает structure и contextFiles текущего artifact или Apply. Каждый affected repository владеет своим gate через local AGENTS. Выполнение процедуры не зависит от custom verifier, dispatcher, skill или session adapter; optional entrypoints остаются navigation, без второго workflow engine.
Последствия
Агент и человек используют один актуальный lifecycle. Отдельный порядок команд в ADR не поддерживается: точные команды находятся у lifecycle и repository owners. Исходные альтернативы и rationale остаются в ADR 010; historical archives, audits и evidence сохраняют описание своего времени.
Structural success не подтверждает решение Change Owner, semantic compliance или независимый PASS. Approval bindings, полный применимый context/Design package, независимая Validation и отдельная Finalization сохраняются. Замена orchestration не ослабляет gates и не разрешает изменение незатронутых main-spec requirements о tooling.