steelmorgan/source-of-truth

Политика источников правды (Source of Truth) — метод

Во full-cycle артефакты образуют иерархию источников правды. Нижний уровень уточняет верхний, но НЕ отменяет его. При конфликте приоритет всегда у более высокого уровня. Проверка выполняется по всей цепочке сверху вниз, пока не найдено первое сломанное звено. Этот навык — детальная процедура; инвариант-триггер «конфликт → проверь цепочку сверху вниз» зафиксирован в правиле framework/rules/source-of-truth/SKILL.md.

Иерархия источников правды

| Уровень | Артефакт | Назначение | |---------|----------|------------| | 1 | Бизнес-цель задачи + явные ответы пользователя | Определяют intent и допустимый результат | | 2 | Утверждённая спецификация + acceptance criteria | Фиксируют контракт задачи | | 3 | Technical design + task-breakdown.json | Определяют способ реализации и декомпозицию | | 4 | BDD / acceptance scenarios | Формализуют наблюдаемое поведение | | 5 | Unit / integration tests | Проверяют поведение на исполнимом уровне | | 6 | Код | Реализует поведение |

Если в конкретной задаче какой-то уровень отсутствует по правилам процесса, источником правды является ближайший утверждённый уровень выше текущего.

MUST

• Каждый нижний уровень MUST быть трассируем к верхнему уровню
• Нижний уровень MUST NOT молча переопределять поведение, зафиксированное выше
• При конфликте нижнего и верхнего уровней агент MUST считать нижний уровень подозрительным, пока не проверит цепочку
• Пользовательский ответ уровня 1 имеет высший приоритет, но после такого изменения downstream-артефакты MUST быть обновлены и заново проверены
• Видимая ошибка на нижнем уровне НЕ доказывает, что причина находится там же
• Первый уровень, который перестаёт быть обоснован верхним уровнем, считается корневой причиной
• Если корневая причина находится вне зоны ответственности агента, агент MUST остановиться, зафиксировать вывод в контексте и вернуть управление оркестратору

Сквозная проверка цепочки

При любом конфликте, падении теста, расхождении поведения или споре между артефактами агент MUST проверять цепочку сверху вниз:

1. Бизнес-цель и ответы пользователя ясны, актуальны и не противоречат друг другу
2. Спецификация корректно отражает бизнес-цель
3. Technical design и task breakdown корректно отражают спецификацию
4. BDD / acceptance scenarios корректно отражают спецификацию и design
5. Unit / integration tests корректно отражают scenarios и спецификацию
6. Код корректно отражает design, tests и спецификацию

Запрещено перепрыгивать через уровни и делать бинарный вывод вида «виноват тест» или «виноват код» без проверки верхних уровней.

Классификация первого сломанного звена

| Где впервые обнаружено расхождение | Классификация | |------------------------------------|---------------| | Уровень 1-2 | Проблема требований / спецификации | | Уровень 3 | Проблема technical design / decomposition | | Уровень 4 | Проблема acceptance / BDD scenarios | | Уровень 5 | Проблема тестов | | Уровень 6 | Проблема реализации |

Фиксировать нужно не только симптом, но и первое сломанное звено цепочки.

Что это правило добавляет

• Определяет, какой артефакт является авторитетным при конфликте
• Задаёт единый алгоритм диагностики для ВСЕХ агентов
• Разделяет два вопроса: «что истинно?» и «кто имеет право это менять?»

Принцип, границы и арбитраж

• Это правило — общий принцип для всех агентов: порядок приоритета артефактов и способ поиска корневой причины
• Промпты сабагентов задают границы ответственности: кто что МОЖЕТ и НЕ МОЖЕТ изменять
• Оркестратор выполняет арбитраж и маршрутизацию: кому возвращать задачу после обнаружения первого сломанного звена

Иными словами: данное правило определяет источник правды, промпты агентов определяют право на изменение, orchestrator определяет маршрут возврата.

Следствия для ролей

• Analyst работает от уровня 1 к уровню 2 и не подменяет требования дизайном
• Architect работает от уровня 2 к уровню 3 и не меняет контракт задачи
• Scenario-Author формализует уровень 4 по уровням 2-3 и не расширяет поведение сверх них
• Developer-Tests пишет уровень 5 по уровням 2-4 и не подгоняет тесты под реализацию
• Developer-Code реализует уровень 6 по уровням 2-5 и не исправляет тесты или сценарии
• Tester проверяет уровни 4-6 относительно уровней 1-3, но исправляет только тестовые артефакты
• Reviewer может анализировать любой уровень цепочки, но не изменяет артефакты
• Orchestrator маршрутизирует задачу по первому сломанному звену, а не по одному симптому

Типовые применения

• Упал unit-тест: это НЕ автоматически баг в коде. Сначала проверить, что тест следует спецификации и сценариям
• Tester видит implementation_error только после проверки, что тест и ожидаемое поведение согласованы с верхними уровнями
• Developer-Code подозревает ошибку в тесте: НЕ правит тест, а фиксирует конфликт и останавливается
• Конфликт между кодом и technical design: код должен быть приведён к design, либо design должен быть официально обновлён через процесс

---

depends_on:

• framework/rules/sdd-policy/SKILL.md
• framework/rules/tdd-policy/SKILL.md

---