Цикл жизни артефакта · теория
Lifecycle · от draft до terminal
Артефакт - не статичный документ, который пишется один раз и забывается. Он эволюционирует: draft становится validated planом, активное решение через год заменяется лучшим, бенчмарк устаревает и требует пересмотра. Без управления жизненным циклом - зомби-документы, устаревшие спеки, которым никто не доверяет, но никто не удаляет. Lifecycle даёт каждому артефакту явный статус и явные правила перехода - так что вы всегда знаете: это current? validated? replaced? нужно ли ему ещё доверять?
01 · Пять состояний · что означает каждое
Каждый артефакт всегда находится в одном из пяти состояний
Паспорт сам по себе - это draft: документ есть, но без визы пересечь границу нельзя. Активная виза - это active. Виза с истёкшим сроком - stale: не invalid, но требует переоформления. Аннулированная виза - superseded или deprecated в зависимости от причины: заменили на новую (supersede) или просто закрыли страну для въезда (deprecate).
Система журналирования фиксирует это явно - у каждого артефакта в frontmatter поле status:
строго одно из пяти значений. Никаких «не помним», никаких «вроде закрыли».
→ deprecated
→ stale
→ deprecated (reopen)
Из superseded и deprecated нет
выхода. Это не «временно убрали, потом вернём» - это точка истории.
Если решение нужно вернуть (например, выбирали JWT → переходили на sessions → опять
нужен JWT) - создаётся новый артефакт ADR-003, который supersede'ит
ADR-002. Старый ADR-001 остаётся superseded - это сохраняет
реальный timeline решений.
02 · Шесть переходов · какой когда
Не «как переименовать» - а «какой transition отражает реальность»
Каждый переход - это семантическое утверждение, а не просто смена строки в frontmatter. Выбор не «как мне удобнее назвать», а «что на самом деле произошло с решением».
valid_until истёк - артефакт автоматически становится stale
active → stale
Не команда, а сигнал: пора пересмотреть
PRD, RFC, ADR, Epic, Spec требуют проверки перед активацией - 30+ правил на тип артефакта (MUST-секции, отсутствие implementation leakage, information density, measurability, traceability). Note и Problem могут активироваться без validation gate - они быстрые captures, и формальные правила здесь только мешали бы фиксировать сигнал.
03 · Stale · самое опасное состояние
Stale не значит «неверно». Stale значит «никто не проверил, что всё ещё верно»
Большинство команд игнорируют stale - и это самая опасная ошибка. Когда дата
valid_until у артефакта истекает, он автоматически становится stale. Это не
«он сломался» - это сигнал, что контекст мог измениться, а решение
зафиксировано на старых данных.
Вы создали ADR полгода назад: выбрали LanceDB, потому что у него тогда был лучший
Rust SDK. Поставили valid_until: 180 дней. Сейчас он stale. Может быть,
LanceDB всё ещё лучший вариант - а может быть, появился более зрелый конкурент.
Статус stale заставляет вас явно переоценить, вместо тихого допущения «оно ещё работает».
Без stale-состояния это решение продолжало бы быть active, R_eff его evidence считался бы по 6-месячному бенчмарку, и вы бы спокойно жили в иллюзии «всё проверено и работает». Через год команда упирается в проблему, начинает гадать «почему мы выбрали LanceDB», и выясняется, что evidence давно нерелевантен.
renew - всё ещё лучший выбор. reopen - нужен новый разбор.Когда evidence становится stale, его оценка падает до 0.1 (а не до 0 - «решение было, контекст мог измениться»). Это значит, что R_eff = min(scores) у всего связанного артефакта тоже падает до 0.1 - тихий сигнал, который виден в health-дашборде системы. Игнорировать его = молчаливо принимать риск.
Полный цикл на одном артефакте · ADR-001
Vault choice - LanceDB как embedded DB. Артефакт проживает все возможные состояния за 18 месяцев.
ADR-001 создан · статус draft
Frontmatter: status: draft, depth: deep, valid_until не установлен. 3 гипотезы из ADI (FAISS / LanceDB / pgvector), evidence пока пустое.
Validation pass → артефакт активирован
3 quality gates прошли, evidence линкован (бенчмарк CL2), R_eff = 0.7. status: active, valid_until: 2026-12-01. Файл immutable.
valid_until истёк · автоматический переход в stale
Контекст не меняли, ничего не делали - но valid_until прошёл. status: stale выставлен системой. Health-дашборд показывает: «1 stale artifact, R_eff degraded».
Re-evaluation → продлено до 2027-06-30
Перезамерили на новой версии LanceDB. Те же тренды - выбор валиден. Renew продлевает valid_until, статус возвращается в active, evidence актуализируется.
Появился лучший вариант → ADR-002 заменяет ADR-001
В индустрии появился sqlite-vec с лучшим API. ADR-002 (новое решение) создан, активирован. ADR-001 помечается как superseded, ADR-002 ссылается на ADR-001 как на источник lineage. ADR-001 уходит в terminal.