docs: record SDD audit remediation

audits/2026-08-26-wealth-ledger-sdd/README.md

@@ -0,0 +1,26 @@
+# Multi-source assessment схемы WealthLedger SDD
+
+Дата фиксации snapshot: 2026-08-26.
+
+Этот каталог — неизменяемый source snapshot пяти независимых внешних
+модельных оценок schema `wealth-ledger-sdd`. Отчёты содержат claims и
+рекомендации внешних моделей, но не являются authority проекта и не заменяют
+OpenSpec requirements, engineering governance, ADR или проверенное as-built
+состояние. Принятые решения и текущая remediation находятся только в
+[live registry](../../development/audit-remediation.md).
+
+Исходные файлы перенесены byte-for-byte из unversioned workspace folder
+`sdd-audit`. До удаления исходной папки для каждого файла были сопоставлены
+byte count, `cmp` и SHA-256; все пять сравнений прошли.
+
+| Source report | Bytes | SHA-256 |
+| --- | ---: | --- |
+| [DeepSeek](deepseek-result.md) | 19,319 | `2d50f4c195507ceb079d69489c03f1ea8a81185e2594dd51ff6a293ab8198db8` |
+| [Gemini](gemini-result.md) | 10,371 | `af95a4c208c993621a6c15102a1e26684eee6c2966b166f6ba23b600d0e33696` |
+| [Kimi](kimi-result.md) | 23,100 | `31d423903cde2d7c1feb711cc625c77864964bb66cfd0cacb734c5c6bbdddd17` |
+| [Qwen](qwen-result.md) | 11,035 | `1b6582efe55b7044d2bebc9c1a146df1963e4103c5517c259ccf617d6d2b4f14` |
+| [Z.AI](zai-result.md) | 8,391 | `0bdb7785087c8d1b6fe532d578804aa498bfc90935623d79c1003cd1899d5bad` |
+
+Суммарный размер raw evidence: 72,216 bytes. Snapshot files не редактируются
+при изменении triage или remediation status; новый аудит создаёт новый каталог
+и обновляет тот же live registry.

audits/2026-08-26-wealth-ledger-sdd/deepseek-result.md

@@ -0,0 +1,178 @@
+# Анализ схемы Spec‑Driven Development (openspec) для pet‑проектов
+
+## 1. Введение
+
+Данный документ содержит оценку пользовательской схемы `schema.yaml`, предназначенной для организации процесса **Spec‑Driven Development (SDD)** с использованием фреймворка `openspec`. Схема описывает жизненный цикл изменения: от формулирования намерения (`proposal`) до реализации (`tasks`) и выполнения (`apply`). Анализ выполнен на основе предоставленных артефактов (`proposal.md`, `spec.md`, `design.md`, `tasks.md`) и самой схемы.
+
+**Общая оценка:** схема **качественная, продуманная и функциональная**. Она соответствует лучшим практикам SDD, обеспечивает чёткое разделение уровней абстракции и поддерживает эволюционное развитие спецификаций. Однако присутствуют области, которые можно улучшить для повышения удобства работы, автоматизации и снижения когнитивной нагрузки на AI‑агента.
+
+---
+
+## 2. Сильные стороны схемы
+
+- **Чёткое разделение артефактов**  
+  Каждый артефакт решает свою задачу:
+    - `proposal` — *почему* и *что* (бизнес‑намерение);
+    - `specs` — *какое наблюдаемое поведение* (контракт);
+    - `design` — *как архитектурно* (решения);
+    - `tasks` — *что конкретно сделать* (реализация).
+      Это предотвращает смешивание уровней и упрощает коммуникацию между участниками.
+
+- **Поведенческий фокус в спецификациях**  
+  Требования формулируются с использованием `SHALL/MUST` и сопровождаются сценариями в формате **WHEN‑THEN**, что делает их проверяемыми и независимыми от реализации.
+
+- **Поддержка дельт**  
+  Операции `ADDED`, `MODIFIED`, `REMOVED` и `RENAMED` позволяют аккуратно эволюционировать существующие возможности, сохраняя историю изменений.
+
+- **Учёт архитектурных решений**  
+  В `design` присутствуют обязательные разделы: `Delivery Map` (привязка к областям), `Contract Gate Decision` (для API), `Solution Assessment` (для сравнения готовых решений). Это способствует принятию обоснованных технических решений.
+
+- **Практичные задачи**  
+  `tasks` разбиты на выполнимые шаги с указанием верификации (команды, наблюдаемые результаты). Задачи привязаны к областям из Delivery Map, что обеспечивает покрытие всех affected‑зон.
+
+- **Интеграция с `openspec`**  
+  Использование `store`, `planningHome.root`, флага `skip_specs` и явной инструкции по архивации показывает глубокое понимание инструмента и его особенностей.
+
+---
+
+## 3. Замечания и области для улучшения
+
+### 3.1. Избыточная детализация инструкций
+Инструкции для каждого артефакта содержат много пояснений (повторяющиеся правила, подробное описание `planningHome.root`, форматирования). Это усложняет восприятие AI и увеличивает вероятность ошибок при генерации.
+
+**Риск:** AI может пропустить важное правило из‑за большого объёма текста.
+
+### 3.2. Отсутствие машинной валидации формата
+Хотя инструкции описывают правильный синтаксис (например, ровно 4 `#` для сценариев), нет автоматической проверки на этапе генерации. AI может случайно отклониться от ожидаемого формата, и ошибка обнаружится только при валидации `openspec validate`.
+
+**Риск:** увеличение итераций на исправление.
+
+### 3.3. Недостаточная поддержка многокомпонентных изменений
+В схеме не указано, как обрабатывать изменения, затрагивающие **несколько репозиториев** (например, синхронизация API‑контрактов между бэкендом и фронтендом). Упоминается только `Delivery Map` с областями, но нет явных разделов для координации версий, порядка деплоя или обратной совместимости.
+
+**Риск:** несогласованность при параллельной разработке.
+
+### 3.4. Размытые критерии для `Solution Assessment`
+Требуется включать этот раздел, когда изменение вводит или существенно заменяет "дорогостоящее необратимое решение". Однако триггеры перечислены в скобках (auth, storage, external integration и т.п.), но они не формализованы. AI может пропустить необходимость анализа, если не распознает ситуацию.
+
+**Риск:** принятие неоптимальных технических решений без сравнения альтернатив.
+
+### 3.5. Отсутствие явного этапа утверждения спецификаций
+После создания `specs` нет артефакта или флага, обозначающего их утверждение владельцем (например, `status: draft | approved`). В `proposal` требуется утверждение, но для `specs` – нет. Это может привести к тому, что `design` будет писаться по неутверждённым требованиям.
+
+**Риск:** переделки при изменении требований на поздних этапах.
+
+### 3.6. Избыточность при модификации требований
+Инструкция требует копировать **полное** содержание существующего требования (включая все сценарии) в секцию `MODIFIED`. Это увеличивает объём дельты и риск рассинхронизации (например, если в исходном требовании позже появится изменение, а дельта этого не отразит). Хотя такой подход безопасен для архивации, он громоздкий.
+
+**Риск:** ошибки копирования и потери изменений.
+
+### 3.7. Отсутствие примеров для сложных сценариев
+В инструкции приведён только простой пример для нового требования. Нет примеров для `MODIFIED` (с полным копированием), для `RENAMED`, для `design` с заполненным `Solution Assessment` или для `tasks` с перекрёстными зависимостями.
+
+**Риск:** AI может неправильно интерпретировать формат, особенно для модификаций.
+
+### 3.8. Неполное описание процесса `apply`
+В секции `apply` указано "работать с pending tasks и отмечать выполненные", но не описаны завершающие шаги: проверка всех задач, запуск тестов, обновление документации, создание коммита/PR, архивация изменения в `openspec` store. Это оставляет пространство для неполного завершения.
+
+**Риск:** незавершённые изменения, потерянные артефакты.
+
+### 3.9. Слабая трассируемость между артефактами
+Хотя в `tasks` сказано "ссылаться на specs и design", нет явного механизма привязки задач к конкретным требованиям или архитектурным решениям. Например, не указано, какая задача реализует какой requirement.
+
+**Риск:** сложно проверить полноту покрытия и проследить impact изменения.
+
+---
+
+## 4. Предложения по улучшению
+
+### 4.1. Упростить инструкции, вынеся общие правила в отдельный файл
+- Создать `_rules.md` (или `.openspec-rules.md`) в корне проекта, где описать:
+    - общие требования к форматированию;
+    - правила работы с `planningHome.root`;
+    - пояснения по `skip_specs` и дельта‑операциям.
+- В `schema.yaml` для каждого артефакта оставить только **специфичные** для него инструкции, ссылаясь на общие правила.
+
+**Плюсы:** уменьшение объёма инструкций, снижение когнитивной нагрузки на AI, централизованное обновление правил.
+
+### 4.2. Добавить машинную валидацию формата при генерации
+- Интегрировать проверку сгенерированных файлов через `openspec validate --strict` (или внешний валидатор) перед сохранением.
+- В инструкции добавить шаг: "После генерации выполни `openspec validate <change> --strict` и исправь ошибки".
+
+**Плюсы:** автоматическое обнаружение синтаксических ошибок, сокращение циклов доработки.
+
+### 4.3. Явно определить процесс для кросс‑репозиторных изменений
+- В `design` добавить раздел **Cross‑repo Dependencies**, где перечислять:
+    - затронутые репозитории и их версии;
+    - необходимый порядок деплоя;
+    - требования к обратной совместимости (если применимо).
+- При необходимости создать отдельный артефакт `integration-plan.md`, который включается в change.
+
+**Плюсы:** синхронизация разработки, снижение риска несовместимости.
+
+### 4.4. Формализовать критерии для включения `Solution Assessment`
+- Сделать раздел обязательным для всех изменений, кроме тех, что помечены как `trivial` (например, исправление опечаток, рефакторинг без изменения поведения).
+- В инструкции перечислить **конкретные области**, требующие анализа, в виде чек‑листа:
+    - [ ] Аутентификация/авторизация
+    - [ ] Хранилище данных (схема, миграции)
+    - [ ] Внешние интеграции (новые API, сторонние сервисы)
+    - [ ] Кэширование
+    - [ ] Конкурентность
+    - [ ] Наблюдаемость (логи, метрики, трейсинг)
+    - [ ] Инфраструктура (новые компоненты, изменение конфигурации)
+- Если ни один пункт не затронут, раздел можно пропустить с пометкой `N/A` и кратким обоснованием.
+
+**Плюсы:** единообразие, предотвращение пропусков.
+
+### 4.5. Добавить этап утверждения спецификаций
+- Ввести артефакт `approval.md` или поле `status` в начале каждого `spec.md` (например, `## Status: Draft | Approved`).
+- В цепочке зависимостей указать, что `design` может начинаться только после того, как все дельта‑спецификации помечены как `Approved` (владельцем продукта или техническим лидом).
+- Это можно реализовать через ручную проверку или через CI‑шаг, требующий комментария.
+
+**Плюсы:** прозрачность, снижение риска переделок.
+
+### 4.6. Оптимизировать модификацию требований (альтернатива копированию)
+- Вместо полного копирования разрешить указывать **изменения** в формате diff (например, с использованием маркеров `<<<` / `>>>` или просто явное описание изменений).
+- При архивации автоматически применять эти изменения к базовому `spec.md` с помощью скрипта слияния.
+- Однако это требует более сложной обработки. Если такой возможности нет, то сохранить текущий подход, но добавить рекомендацию использовать **внешние инструменты** для поиска и копирования (например, `openspec show`).
+
+**Плюсы:** уменьшение дублирования, снижение ошибок.
+
+### 4.7. Добавить примеры для всех типов дельт и сложных ситуаций
+- В инструкцию или в отдельный файл `_examples.md` включить примеры:
+    - **MODIFIED** с полным копированием существующего требования и его изменением.
+    - **RENAMED** с указанием FROM/TO.
+    - **REMOVED** с Reason и Migration.
+    - **design** с заполненным `Solution Assessment` (например, выбор между готовым и кастомным решением).
+    - **tasks** с перекрёстными зависимостями между репозиториями.
+
+**Плюсы:** уменьшение неоднозначности для AI, повышение качества генерируемых артефактов.
+
+### 4.8. Дополнить процесс `apply` завершающими шагами
+- В секцию `apply` добавить:
+    - После завершения всех задач: запустить полный набор тестов (CI‑пайплайн).
+    - Проверить, что все артефакты соответствуют актуальному состоянию кода.
+    - Создать коммит с изменениями в коде и обновлёнными спецификациями.
+    - Выполнить `openspec archive <change>` для переноса дельт в основной `specs` store.
+    - Удалить директорию изменения или обновить статус в системе отслеживания задач.
+
+**Плюсы:** гарантированное завершение, предотвращение потери изменений.
+
+### 4.9. Ввести трассируемость через мета‑данные в задачах
+- Добавить в каждую задачу поля (в виде комментариев или меток), например:
+    - `implements: <requirement-id>` – ссылка на конкретное требование.
+    - `related-to: <decision-id>` – ссылка на решение в design.
+- Это можно сделать через формат: `- [ ] 1.1 Implement export feature (implements: export-data, related: design#cache-decision)`
+- Или вынести в отдельную колонку, если используется система управления задачами.
+
+**Плюсы:** прослеживаемость, упрощение ревью и аудита.
+
+---
+
+## 5. Заключение
+
+Предоставленная схема является **надёжной и работоспособной** основой для SDD в pet‑проектах и даже в небольших командах. Она грамотно использует возможности `openspec` и обеспечивает дисциплину в разработке. Предложенные улучшения направлены на **снижение когнитивной нагрузки, повышение автоматизации и устранение потенциальных пробелов** при работе с несколькими репозиториями и сложными изменениями.
+
+Рекомендуется внедрять улучшения поэтапно, начиная с наиболее критичных (например, добавление валидации и формализация `Solution Assessment`), а затем дорабатывать процесс по мере накопления опыта.
+
+Данный анализ может быть использован как руководство по дальнейшему развитию вашей SDD‑системы.

audits/2026-08-26-wealth-ledger-sdd/gemini-result.md

@@ -0,0 +1,117 @@
+# Анализ схемы Spec-Driven Development (wealth-ledger-sdd) и рекомендации по улучшению
+
+## 1. Общий обзор и контекст
+
+Представленная схема **wealth-ledger-sdd** реализует Spec-Driven Development (SDD) поверх фреймворка `openspec`. Конфигурация рассчитана на работу AI-агента из общей корневoй директории, объединяющей несколько отдельных репозиториев, с хранением спецификаций в изолированном хранилище (`openspec store`).
+
+Пайплайн планирования состоит из 4 последовательных этапов:
+1. **Proposal** (`proposal.md`) — продуктовое и бизнес-обоснование («Зачем» и «Что меняется на верхнем уровне»).
+2. **Specs** (`specs/**/*.md`) — контракты наблюдаемого поведения системы («ЧТО система делает»).
+3. **Design** (`design.md`) — техническая архитектура и решения по реализации («КАК сделать»).
+4. **Tasks** (`tasks.md`) — атомарный чек-лист задач для выполнения («ЧТО СДЕЛАТЬ конкретно»).
+
+---
+
+## 2. Анализ сильных сторон (Strengths)
+
+* **Строгая синтаксическая дисциплина для LLM:**
+  Инструкции к артефакту `specs` содержат четкие предохранители против специфических багов генерации Markdown у AI-моделей (например, строго 4 хештега `#### Scenario:` и нормативные глаголы `SHALL`/`MUST`). Это гарантирует предсказуемый парсинг артефактов со стороны OpenSpec CLI.
+* **Изоляция планирования от продуктового кода:**
+  Использование переменной `planningHome.root` гарантирует корректную работу с `wealth-ledger-specs` store. Репозитории сервисов не засоряются промежуточными черновиками и файлами планирования.
+* **Защита от избыточной работы (Build-vs-Buy Control):**
+  Обязательный раздел `Solution Assessment` в `design.md` предотвращает попытки AI «изобретать велосипед» при добавлении авторизации, кеширования, интеграций или инфраструктурных утилит.
+* **Прагматичная стратегия тестирования:**
+  Инструкция к `tasks.md` явно задает зоны, где тесты обязательны (финансы, безопасность, персистентность, публичные контракты), и запрещает избыточные unit-тесты для DTO, тонких адаптеров и декларативных структур.
+* **Четкое разделение ответственности между этапами:**
+  Запрет на упоминание технологий в `proposal.md` предотвращает преждевременное принятие архитектурных решений до согласования целей бизнеса.
+
+---
+
+## 3. Анализ узких мест и рисков в мультирепозиторной среде
+
+* **Неопределенность адресации файлов в мультирепо (File Path Ambiguity):**
+  В текущих шаблонах `tasks.md` и `design.md` отсутствуют явные требования указывать имя репозитория. В рабочей директории с десятком сервисов задача вида `Modify user.service.ts` приведет к ошибкам адресации или поиску файла по всем подпапкам.
+* **Размытый фокус затронутых репозиториев на старте:**
+  В `proposal.md` есть секция `Impact`, но нет явного списка целевых сервисов. Агент может не рассчитать требуемый контекст и пропустить смежный сервис на этапе проектирования контрактов.
+* **Высокий оверхед на мелкие изменения (Fast-Track overhead):**
+  Полный 4-этапный цикл избыточен для локального рефакторинга или точечного багфикса. Хотя параметр `skip_specs: true` предусмотрен, генерация `design.md` и `proposal.md` для однострочных правок влечет лишние затраты токенов и времени.
+* **Риск раздувания контекстного окна (Context Window Bloat):**
+  Запуск AI-агента из единого корня открывает ему доступ ко всему коду всех проектов. Без явных ограничений в промпте и конфигурации агент может считывать лишние репозитории, исчерпывая лимит контекста.
+
+---
+
+## 4. Предложения по улучшению (Improvement Proposals)
+
+### 4.1. Внедрение явной мультирепозиторной адресации
+
+#### А. Секция Target Repositories в `proposal.md`
+Добавьте в шаблон `proposal.md` секцию, фиксирующую список затронутых репозиториев:
+
+```markdown
+## Target Repositories
+
+<!-- Укажите репозитории, в которые будут вноситься изменения -->
+- `<repo-name>`: <роль репозитория в данном изменении>
+```
+
+#### Б. Строгий формат задач в `tasks.md`
+Обновите инструкцию артефакта `tasks` в `schema.yaml`, обязывая AI указывать путь к репозиторию:
+
+```yaml
+# В инструкции tasks в schema.yaml:
+- Каждая задача MUST указывать целевой репозиторий в формате: `- [ ] X.Y [<repo-folder>] <action>`
+```
+
+Пример сгенерированной задачи:
+```markdown
+- [ ] 1.1 [auth-service] Add standard JWT validation middleware and verify auth test suite passes
+- [ ] 1.2 [frontend-app] Update API client DTO types to align with new contract
+```
+
+---
+
+### 4.2. Организация Fast-Track сценария для точечных правок
+
+Для оптимизации работы над некрупными задачами рекомендуется предусмотреть ускоренный пайплайн.
+
+1. **Если изменение не меняет внешнее поведение:**
+   В `.openspec.yaml` устанавливается `skip_specs: true`.
+2. **Сокращенный Design:**
+   В инструкцию `design` добавьте правило: если `Delivery Map` затрагивает только 1 репозиторий и `runtime-openapi` равен `N/A`, разделы `Solution Assessment` и `Migration Plan` можно опускать.
+
+---
+
+### 4.3. Усиление Contract Gate Decision
+
+В мультирепозиторном окружении изменение контракта API в одном сервисе сразу требует обновления клиента в другом. Уточните таблицу `Contract Gate Decision` в `design.md`:
+
+```markdown
+### Contract Gate Decision
+
+| Gate | Status | Affected Repositories | Reason |
+| --- | --- | --- | --- |
+| runtime-openapi | `required` / `N/A` | `backend-api`, `frontend-web` | <!-- причины --> |
+| internal-proto | `required` / `N/A` | `billing-service`, `orders-service` | <!-- причины --> |
+```
+
+---
+
+### 4.4. Оптимизация контекста AI-агента
+
+При запуске агента из общего корня настройте файл `.aiignore` (или `.cursorignore` / `.windsurfignore` в зависимости от используемого CLI/IDE) в корневой папке:
+
+1. Исключите тяжелые бинарники, папки сборки и зависимости (`**/node_modules`, `**/dist`, `**/target`, `**/.git`).
+2. Запретите агенту просматривать репозитории, не указанные в `Target Repositories` для текущей задачи.
+
+---
+
+## 5. Итоговая оценка качества схемы
+
+| Критерий | Оценка (1-5) | Комментарий |
+| --- | --- | --- |
+| **LLM-friendly (предсказуемость)** | **5/5** | Отличные предохранители против сбоев синтаксиса и парсинга Markdown. |
+| **Архитектурная строгость** | **5/5** | Баланс между бизнес-целями, specs и архитектурным проектированием. |
+| **Мультирепозиторная адаптация** | **3.5/5** | Требует добавления явных указателей путей репозиториев в `tasks` и `proposal`. |
+| **Эффективность по скорости/токенам** | **4/5** | Отлично для фич, требует Fast-Track сценария для мелких правок. |
+
+**Вердикт:** Схема находится на очень высоком уровне разработки. После внесения точечных правок по мультирепозиторной адресации и фильтрации контекста она станет эталонной для мультисервисной Spec-Driven разработки.

audits/2026-08-26-wealth-ledger-sdd/kimi-result.md

@@ -0,0 +1,530 @@
+# Анализ openspec SDD-схемы: wealth-ledger-sdd
+
+> **Версия схемы:** 1  
+> **Автор анализа:** AI-ассистент  
+> **Дата:** 2026-08-25
+
+---
+
+## 1. Общая оценка
+
+**B+ / «Готова к использованию, есть куда расти»**
+
+Схема представляет собой зрелый, хорошо структурированный Spec-Driven Development workflow для pet-проектов с multi-repo архитектурой и выделенным specs-store. Pipeline `proposal → specs → design → tasks` с жёстким разделением ответственности между фазами — это правильный фундамент. Схема явно ориентирована на работу с AI-агентом: чёткие prompts, машиночитаемые форматы, парсимый прогресс.
+
+---
+
+## 2. Что сделано сильно
+
+### 2.1. Чёткое разделение ответственности между фазами
+
+Каждая фаза имеет строгое назначение:
+
+| Фаза | Ответственность | Что исключено |
+|------|----------------|---------------|
+| **Proposal** | «Почему» и «что» — намерение, проблема, scope | Технологии, библиотеки, API, имена файлов |
+| **Specs** | Behavior contract — наблюдаемое поведение | Внутренние классы/функции, шаги реализации |
+| **Design** | Архитектурные решения и rationale | Построчная инструкция, список правок |
+| **Tasks** | Конкретные действия с verification | Архитектурные обоснования |
+
+Это защищает от классической ошибки: выбор технологий на этапе «намерения».
+
+### 2.2. Delta-операции в specs
+
+Поддержка четырёх операций — **ADDED**, **MODIFIED**, **REMOVED**, **RENAMED** — делает specs пригодными для эволюции, а не только для greenfield-разработки. Особенно сильно:
+
+- **MODIFIED** требует полного копирования блока requirement — защита от потери деталей при архивации в openspec.
+- **REMOVED** требует **Reason** и **Migration** — забота о обратной совместимости.
+
+### 2.3. Строгие правила формата specs
+
+- **SHALL/MUST** для нормативных требований (исключение `should/may`)
+- **#### Scenario** с ровно 4 хэшами — с учётом silent fail это критически важное правило
+- **WHEN/THEN** структура — проверяемые сценарии
+- **Обязательный `Purpose`** для новых capability (50+ символов под strict-валидацию)
+
+Это делает specs одновременно человекочитаемыми и пригодными для валидации.
+
+### 2.4. Contract Gate Decision в Design
+
+Выделенное внимание к `runtime-openapi` — признак зрелого подхода. В multi-repo setup, где API-контракты разделяют frontend и backend, это предотвращает рассинхронизацию сторон контракта.
+
+### 2.5. Правильная работа с Open Questions
+
+Критерий «если вопрос меняет specs, подход или tasks — решай сейчас, не откладывай» — это ловушка, в которую попадают многие шаблоны. Ты её явно обозначил.
+
+### 2.6. Tasks с обязательным verification
+
+Каждая задача должна иметь **planned verification action** — команда, проверка наблюдаемого поведения или delivered artifact. Это DoD на уровне отдельной задачи.
+
+Также хорошо сформулировано исключение: «Не требуй отдельный unit test только из-за изменения файла». DTO без логики, thin adapters, declarative structures проверяются существующим integration gate.
+
+### 2.7. Apply phase с отслеживанием прогресса
+
+Парсинг checkbox'ов (`- [ ]`) для отслеживания — прагматичное решение для AI-агента. Нет необходимости в сложном state machine.
+
+### 2.8. Интеграция с openspec store
+
+Схема корректно учитывает store-aware пути (`planningHome.root`), не предполагает repo-relative структуру. Это критично для multi-repo setup с выделенным specs-репозиторием.
+
+---
+
+## 3. Области для улучшения
+
+### 3.1. Нет review gates между фазами
+
+В `schema.yaml` есть `requires` (specs требует proposal), но нет явного **checkpoint'а утверждения**.
+
+**Риск:** AI-агент может сгенерировать Design до реального review specs. В pet-проектах, где «владелец продукта» — это сам разработчик, риск ещё выше: нет естественного барьера «кто-то другой должен посмотреть».
+
+**Проявление:**
+- Design создаётся с непроверенными предположениями
+- Tasks строятся на неверных specs
+- Regression: приходится переписывать несколько фаз
+
+### 3.2. Нет traceability между specs и tasks
+
+Нет механизма проверки, что каждый requirement из specs покрыт задачей в tasks.md. Сейчас это держится в голове разработчика (или AI-агента).
+
+**Риск:**
+- Пропущенные requirements
+- «Лишние» задачи, не связанные с specs
+- Невозможность аудита completeness change'а
+
+### 3.3. Spec.md template неполный
+
+В `spec.md` template есть только `## ADDED Requirements`. Но в instruction к specs описаны 4 операции. Для **MODIFIED** и **REMOVED** шаблоны сложнее — их стоит добавить в template с примерами.
+
+**Риск:** AI-агент или разработчик может неправильно оформить MODIFIED (например, внести частичные изменения вместо полного блока), что приведёт к потере деталей при архивации.
+
+### 3.4. Нет «Definition of Done» для change целиком
+
+Когда change считается завершённым? Когда все tasks checked? А кто проверяет, что реализация соответствует specs?
+
+**Риск:**
+- Change считается «готовым», но specs не покрыты
+- Нет единого артефакта, который можно было бы archive'ить как evidence
+
+### 3.5. Нет управления зависимостями между changes
+
+В multi-repo setup с shared specs store рано или поздно появится change B, который блокируется change A. Сейчас это не выразимо в схеме.
+
+**Риск:**
+- Параллельная работа над конфликтующими changes
+- Merge-конфликты в specs-store
+- Нарушение порядка архивации
+
+### 3.6. Нет приоритизации и sizing'а в tasks
+
+Даже минимальная маркировка `S/M/L` помогает AI-агенту планировать сессии и разработчику — оценивать объём.
+
+### 3.7. Нет явного механизма для «тёплого» отката
+
+Если change реализован, но вызывает regression — как откатить? Схема описывает forward-only flow.
+
+**Риск:**
+- Data migration без rollback-стратегии
+- Breaking changes в public API без deprecation period
+- Security-изменения, которые сложно отменить
+
+### 3.8. Apply phase — неясность с «context files»
+
+В multi-repo setup «read context files» требует понимания, какие именно файлы релевантны. Сейчас это оставлено на усмотрение AI.
+
+**Риск:**
+- AI читает лишние файлы — контекст переполняется
+- AI пропускает релевантные файлы — решения принимаются на неполных данных
+
+---
+
+## 4. Предложения по улучшению
+
+### 4.1. Добавить review gate между specs и design
+
+**Формат:** Новый артефакт или секция в существующих файлах.
+
+**Вариант A — отдельный артефакт `review.md`:**
+
+```yaml
+# schema.yaml
+- id: review
+  generates: review.md
+  description: Checkpoint before design — verify specs completeness and correctness
+  template: review.md
+  requires: [specs]
+```
+
+**Содержимое `review.md`:**
+
+```markdown
+## Specs Review Checklist
+
+- [ ] Каждый capability из Proposal имеет соответствующий spec-файл
+- [ ] Все requirements используют SHALL/MUST (нет should/may)
+- [ ] Каждый requirement имеет хотя бы один scenario
+- [ ] Все scenarios используют ровно 4 уровня заголовков (`####`)
+- [ ] Для MODIFIED requirements скопирован полный блок (не частично)
+- [ ] Для REMOVED requirements указаны Reason и Migration
+- [ ] В specs отсутствуют технические детали (имена классов, библиотеки)
+- [ ] New capabilities имеют секцию `## Purpose` (50+ символов)
+- [ ] `skip_specs: true` установлен только при отсутствии behavior changes
+
+## Review Decision
+
+- [ ] **APPROVED** — переходим к Design
+- [ ] **REJECTED** — возврат к Specs, причина:
+```
+
+**Вариант B — inline в `schema.yaml`:**
+
+Добавить в `design` артефакт поле `prerequisites`:
+
+```yaml
+- id: design
+  generates: design.md
+  # ...
+  prerequisites:
+    - type: review
+      artifact: specs
+      checklist: review.md
+```
+
+**Рекомендация:** Вариант A — проще для AI-агента (явный файл, явный checklist).
+
+---
+
+### 4.2. Добавить traceability: specs → tasks
+
+**Формат:** Convention в tasks.md + опциональный артефакт `traceability.md`.
+
+**Convention в tasks.md:**
+
+```markdown
+## 2. Core Implementation
+
+- [ ] 2.1 Implement user export  
+  **Spec:** `specs/data-export/spec.md#requirement-user-can-export-data`  
+  **Verification:** `npm test data-export`
+
+- [ ] 2.2 Add CSV formatting utilities  
+  **Spec:** `specs/data-export/spec.md#requirement-export-format`  
+  **Verification:** unit tests cover quoting and delimiters
+```
+
+**Автоматический артефакт `traceability.md`** (генерируется AI-агентом после tasks):
+
+```markdown
+## Traceability Matrix
+
+| Spec Requirement | Task | Status |
+|------------------|------|--------|
+| data-export#user-can-export-data | 2.1 | ⬜ |
+| data-export#export-format | 2.2 | ⬜ |
+
+## Orphan Tasks (no spec link)
+- 3.1 Update README — **INFO:** docs-only, no spec required
+
+## Uncovered Requirements
+- data-export#error-handling — **WARNING:** no task linked
+```
+
+**Рекомендация:** Начать с convention (ручная ссылка в tasks), затем добавить автоматическую генерацию traceability.md.
+
+---
+
+### 4.3. Дополнить spec.md template примерами для всех delta-операций
+
+**Текущий template** (`spec.md`) содержит только `## ADDED Requirements`.
+
+**Предлагаемый полный template:**
+
+```markdown
+## Purpose
+<!-- New capabilities only: 50+ characters. Delete for existing capabilities. -->
+
+## ADDED Requirements
+
+### Requirement: <!-- requirement name -->
+<!-- requirement text using SHALL/MUST -->
+
+#### Scenario: <!-- scenario name -->
+- **WHEN** <!-- condition -->
+- **THEN** <!-- expected outcome -->
+
+## MODIFIED Requirements
+
+### Requirement: <!-- exact existing requirement name -->
+<!-- FULL updated requirement text -->
+
+#### Scenario: <!-- updated scenario name -->
+- **WHEN** <!-- updated condition -->
+- **THEN** <!-- updated expected outcome -->
+
+## REMOVED Requirements
+
+### Requirement: <!-- requirement name -->
+**Reason:** <!-- why removed -->
+**Migration:** <!-- how to migrate -->
+
+## RENAMED Requirements
+
+### Requirement: <!-- old name -->
+**FROM:** <!-- old exact name -->
+**TO:** <!-- new exact name -->
+```
+
+**Почему это важно:** AI-агент, следуя template, будет генерировать корректные MODIFIED-блоки. Без примера риск частичного копирования высок.
+
+---
+
+### 4.4. Добавить Definition of Done для change целиком
+
+**Новый артефакт `done.md`:**
+
+```yaml
+# schema.yaml
+- id: done
+  generates: done.md
+  description: Completion evidence and verification summary
+  template: done.md
+  requires: [tasks]
+```
+
+**Содержимое `done.md`:**
+
+```markdown
+## Completion Evidence
+
+### Specs Coverage
+- [ ] All requirements from delta specs have corresponding tasks
+- [ ] All tasks are completed and verified
+- [ ] Traceability matrix has no uncovered requirements
+
+### Verification Summary
+| Area | Gate | Status | Evidence |
+|------|------|--------|----------|
+| Backend | `npm test` | ✅ | All tests pass |
+| Frontend | `npm run build` | ✅ | Build succeeds |
+| API Contract | `runtime-openapi` | ✅ | Schema matches implementation |
+
+### Regression Check
+- [ ] Existing specs не нарушены (`openspec validate`)
+- [ ] Existing tests не сломаны
+
+### Archive Ready
+- [ ] All artifacts saved in canonical store
+- [ ] `.openspec.yaml` обновлён
+```
+
+**Альтернатива:** Добавить как секцию в `tasks.md` в конце, но отдельный артефакт лучше для AI-агента (явный финальный checkpoint).
+
+---
+
+### 4.5. Добавить управление зависимостями между changes
+
+**Добавить в proposal.md template:**
+
+```markdown
+## Dependencies
+
+### Blocked By
+<!-- Changes that must be completed before this one -->
+- [ ] `change-id-1`: <!-- reason -->
+
+### Blocks
+<!-- Changes that cannot start until this one is done -->
+- `change-id-2`: <!-- reason -->
+
+### Related
+<!-- Changes that are related but not blocking -->
+- `change-id-3`: <!-- reason -->
+```
+
+**В `schema.yaml` добавить валидацию:**
+
+```yaml
+validation:
+  dependencies:
+    check_store: true  # проверять, что blocked-by changes завершены
+```
+
+---
+
+### 4.6. Добавить sizing в tasks
+
+**Convention в tasks.md:**
+
+```markdown
+## 2. Core Implementation
+
+- [ ] 2.1 Implement user export  
+  **Size:** M (2-4 часа)  
+  **Spec:** `specs/data-export#user-can-export-data`  
+  **Verification:** `npm test data-export`
+```
+
+**Размеры:**
+- **S** — до 1 часа (config change, DTO, простой adapter)
+- **M** — 2-4 часа (новая feature, refactoring с тестами)
+- **L** — 1-2 дня (сложная интеграция, data migration)
+- **XL** — требует декомпозиции
+
+**Польза:** AI-агент может планировать сессии (не брать L-задачу в конце дня), разработчик — оценивать объём change.
+
+---
+
+### 4.7. Усилить rollback-стратегию
+
+**Добавить в design.md template обязательную секцию:**
+
+```markdown
+## Rollback Plan
+
+<!-- Обязательно, если change затрагивает: data migration, public API, auth/security -->
+
+### Rollback Trigger
+<!-- При каких условиях откатываем -->
+
+### Rollback Steps
+1. <!-- конкретный шаг -->
+2. <!-- конкретный шаг -->
+
+### Data Safety
+<!-- Что происходит с данными, созданными после деплоя -->
+
+### Rollback Verification
+<!-- Как проверить, что откат успешен -->
+```
+
+**В `schema.yaml` добавить условие:**
+
+```yaml
+- id: design
+  # ...
+  required_sections:
+    - Rollback Plan  # если change трогает migration/api/auth
+```
+
+---
+
+### 4.8. Добавить context mapping для multi-repo
+
+**Новый артефакт `context.yaml` (в корне change или в repo):**
+
+```yaml
+# .openspec/context.yaml
+repositories:
+  - name: backend
+    path: ../backend
+    relevant_paths:
+      - src/api/**
+      - src/domain/**
+      - src/infrastructure/**
+    ignore_paths:
+      - src/api/__tests__/**
+
+  - name: frontend
+    path: ../frontend
+    relevant_paths:
+      - src/components/**
+      - src/services/**
+
+  - name: specs-store
+    path: ../wealth-ledger-specs
+    relevant_paths:
+      - openspec/specs/**
+      - openspec/changes/**
+```
+
+**Интеграция в schema.yaml:**
+
+```yaml
+apply:
+  requires: [tasks]
+  tracks: tasks.md
+  context_source: .openspec/context.yaml
+  instruction: |
+    Read context files according to context.yaml mapping.
+    Prioritize files matching relevant_paths of affected repositories.
+```
+
+**Польза:** AI-агент знает, какие файлы читать, а не сканирует всё подряд. Экономия токенов и точность контекста.
+
+---
+
+### 4.9. Добавить convention для commit messages
+
+При архивации change в specs-store и реализации в code repos полезна связь через commit messages.
+
+**Convention:**
+
+```
+[openspec:<change-id>] <type>: <description>
+
+Refs: specs/<change-id>/proposal.md
+```
+
+Примеры:
+```
+[openspec:wl-42] feat: add CSV export for user data
+
+Refs: specs/wl-42/proposal.md
+```
+
+```
+[openspec:wl-42] spec: update export format requirements
+
+Refs: specs/wl-42/specs/data-export/spec.md
+```
+
+**Польза:** Git history связывает код с specs. При `git blame` можно найти обоснование изменения.
+
+---
+
+## 5. Итоговая таблица оценок
+
+| Критерий | Оценка | Комментарий |
+|----------|--------|-------------|
+| **Разделение concerns** | A | Отлично, 4 фазы с чёткими границами |
+| **Проверяемость specs** | A | WHEN/THEN, SHALL/MUST, 4-level headers |
+| **Защита от деградации** | B+ | Хорошие правила, но нет review gates |
+| **Traceability** | C+ | Нет связи specs→tasks, нет completeness check |
+| **Полнота workflow** | B | Нет DoD, rollback, cross-change deps |
+| **AI-агент friendliness** | A | Чёткие prompts, парсимый формат, чёткие границы |
+| **Интеграция с openspec** | A− | Хорошо, но store-aware пути требуют ручного контекста |
+| **Multi-repo поддержка** | B | Есть store, но нет context mapping и cross-repo deps |
+| **Эволюционность** | B+ | Delta-ops хороши, но нет dependency management |
+| **Документированность** | A | Подробные instructions в schema.yaml |
+
+---
+
+## 6. Топ-3 приоритета для доработки
+
+### 🥇 Приоритет 1: Добавить review gate между specs и design
+**Почему:** Самый дешёвый способ предотвратить каскадные ошибки. Без него AI-агент может построить Design на неверных specs, и переделывать придётся всё.
+**Сложность:** Низкая (новый template-файл + одна строка в schema.yaml)
+**ROI:** Очень высокий
+
+### 🥈 Приоритет 2: Дополнить spec.md template примерами MODIFIED/REMOVED/RENAMED
+**Почему:** Сейчас это «незаявленная функциональность» — AI-агент может генерировать неверный формат. При архивации в openspec это приведёт к потере деталей.
+**Сложность:** Очень низкая (расширить template)
+**ROI:** Высокий
+
+### 🥉 Приоритет 3: Добавить traceability (convention specs→tasks)
+**Почему:** Гарантирует, что ни один requirement не потерян. Для pet-проекта — это главный способ держать качество без полноценного QA.
+**Сложность:** Средняя (convention + опциональная автоматизация)
+**ROI:** Высокий
+
+---
+
+## 7. Заключение
+
+Схема **wealth-ledger-sdd** — это продуманный, прагматичный SDD-фреймворк, явно выросший из реальных потребностей multi-repo pet-проекта. Основные сильные стороны — разделение concerns, проверяемость specs и ориентация на AI-агента.
+
+Главные риски — отсутствие review gates и traceability — не критичны для pet-проекта, но станут болевыми точками при росте сложности или переходе к командной работе. Три предложенных приоритета (review gate, полный spec template, traceability) решают 80% рисков при минимальных затратах.
+
+Схема готова к использованию «как есть» и имеет чёткий путь эволюции.
+
+---
+
+*Анализ подготовлен на основе файлов: schema.yaml, proposal.md, spec.md, design.md, tasks.md*

audits/2026-08-26-wealth-ledger-sdd/qwen-result.md

@@ -0,0 +1,118 @@
+# Анализ и оценка кастомной схемы OpenSpec SDD (`wealth-ledger-sdd`)
+
+## Общее резюме
+Ваша кастомная схема `wealth-ledger-sdd` — это **великолепный, глубоко проработанный артефакт**. Видно, что вы прошли через реальные боли работы с AI-агентами в парадигме SDD (Spec-Driven Development) и решили их не на уровне "магии промптов", а на уровне строгой архитектуры и контрактов.
+
+Особенно впечатляет то, как вы учли специфику работы LLM: защита от галлюцинаций, предотвращение смешения слоев абстракции и жесткие требования к форматированию.
+
+**Общая оценка: 9.5 / 10**
+
+Вы создали **Enterprise-grade SDD фреймворк для AI-агентов**. То, как вы проработали edge-cases (форматирование хэшей, копирование блоков, разделение store и repo) — это уровень senior-архитектора, который уже "набил шишки" в продакшене.
+
+---
+
+## 🌟 Сильные стороны (Что сделано блестяще)
+
+### 1. Защита от типичных галлюцинаций и ошибок LLM
+* **Правило `#### Scenario`:** Вы явно указали, что сценарии должны использовать ровно 4 хэша, иначе валидация упадет. Это спасает от молчаливых ошибок парсинга.
+* **Правило `MODIFIED Requirements`:** Требование копировать *весь* блок требования, а не переписывать его частично, решает огромную проблему LLM, которые любят "терять" контекст или сценарии при модификации.
+* **Запрет на технологии в Proposal:** Жесткое ограничение "MUST NOT включать технологии... Эти решения появляются только после Delta Specs". Это не дает AI-агенту преждевременно скатиться в написание кода или выбор фреймворков.
+
+### 2. Идеальная трассируемость (Traceability)
+Секция `Capabilities` в `proposal.md` — это **сердце вашей схемы**. Она создает жесткий контракт между "Зачем/Что" (Proposal) и "Как себя ведет" (Specs). AI не сможет написать спецификацию для фичи, которая не была заявлена в намерениях.
+
+### 3. Учет вашей архитектуры (Multi-repo + Store)
+Инструкции в `specs` и `apply` явно оперируют понятием `<planningHome.root>` и каноническими путями. Это критически важно для вашего сценария с отдельным репозиторием под спеки и `openspec store`. Вы заранее решили проблему того, куда агент должен писать файлы, исключая путаницу между рабочими директориями.
+
+### 4. Разделение "Что" (Specs) и "Как" (Design)
+* `specs` описывают только наблюдаемое поведение (контракт).
+* `design` описывает архитектуру, Delivery Map и риски.
+  Это классический SDD, но реализованный так, что AI физически не может смешать их в одну кучу из-за разных шаблонов и инструкций.
+
+### 5. Верификация в `tasks.md`
+Требование указывать `planned verification action` для каждой задачи — это киллер-фича. AI-агенты часто пишут задачи в стиле "Сделать Х", а потом не знают, как проверить, что Х сделано. Ваша схема заставляет его сразу думать о тестах или командах проверки.
+
+---
+
+## ⚠️ Точки роста и потенциальные проблемы
+
+Несмотря на высочайшее качество, схема имеет несколько мест, которые могут стать "бутылочным горлышком" или избыточными в контексте пет-проектов.
+
+### 1. Избыточность (Over-engineering) для пет-проектов
+В `design.md` есть секции: `Solution Assessment`, `Contract Gate Decision`, `Migration Plan`.
+* **Проблема:** Для небольших фич в пет-проектах AI будет тратить огромное количество токенов, генерируя заглушки вроде "N/A, так как это не затрагивает API" или выдумывая несуществующие риски миграции. Это замедляет работу и засоряет контекст.
+
+### 2. Отсутствие явного цикла итераций (Feedback Loop)
+Схема линейна: `proposal` → `specs` → `design` → `tasks` → `apply`.
+* **Проблема:** Что если на этапе `design` архитектор (или AI) поймет, что требования из `specs` технически невозможны или слишком дороги? Или что если во время `apply` выяснится, что `specs` были неполными?
+
+### 3. Обработка блокеров в фазе `apply`
+В `apply` написано: *"Pause if you hit blockers or need clarification."*
+* **Проблема:** AI-агент может просто остановиться и вывести текст в консоль, но как вам (владельцу) отследить этот блокер? Как агент поймет, что он должен делать дальше?
+
+### 4. Токенозатратность инструкций
+Инструкции в `schema.yaml` очень подробные. Это отлично для точности, но при передаче в системный промпт или контекст LLM они могут съедать тысячи токенов на каждый вызов.
+
+---
+
+## 💡 Предложения по улучшению
+
+Ниже приведены конкретные правки, которые можно внести в `schema.yaml` и шаблоны, чтобы сделать схему еще более устойчивой и экономичной.
+
+### 1. Сделайте энтерпрайз-секции в `design.md` условными
+Чтобы AI не тратил токены на отписки, добавьте в `instruction` для `design` следующее правило:
+
+```text
+Include `Solution Assessment` ONLY if the change introduces auth, storage, 
+or external integrations. Include `Migration Plan` ONLY if it breaks backward 
+compatibility. Include `Contract Gate Decision` ONLY if both API contract 
+sides change. Otherwise, omit these sections entirely or mark them as N/A 
+with a single word reason to save context.
+```
+
+### 2. Введите механизм артефактов для блокеров и ревизий
+Добавьте в `apply` и `design` правила создания явных артефактов вместо простого "паузы":
+
+```text
+In `apply`: If blocked, DO NOT guess or just pause. Create a `blocker.md` 
+in the change directory detailing the exact error, the task that failed, 
+and proposed solutions. Then halt execution.
+
+In `design` or `apply`: If a spec-level behavior change is required because 
+the original specs were technically impossible or incomplete, STOP. Generate 
+a `revision-request.md` explaining why specs must change, and pause for 
+owner approval before modifying specs.
+```
+
+### 3. Уточните правила тестирования в `tasks.md`
+Вы написали: "Автоматические тесты обязательны для security/privacy...". Сделайте это правило более предсказуемым для AI:
+
+```text
+If a task modifies existing logic, it MUST include a regression test. 
+If it adds new logic, it MUST include a happy-path test. 
+Do not write tests for DTOs without logic, declarative structures, 
+or thin adapters unless they contain branching or transformation.
+```
+
+### 4. Добавьте "Definition of Done" для фазы `apply`
+Чтобы агент четко понимал, когда он закончил работу, добавьте в конец `instruction` для `apply`:
+
+```text
+The `apply` phase is complete ONLY when all tasks in `tasks.md` are marked 
+`[x]`, all planned verification actions have passed, and a brief 
+`Completion Summary` (listing executed verifications and final state) 
+is appended to the bottom of `tasks.md`.
+```
+
+### 5. Оптимизация токенов (Advanced)
+Если вы используете это через API, попробуйте вынести общие правила (например, "никогда не пиши код в specs", "используй SHALL/MUST") в отдельный базовый системный промпт (System Prompt), а в `schema.yaml` оставьте только уникальные для каждого артефакта дельты и специфичные правила форматирования.
+
+---
+
+## Заключение
+
+Ваш подход с выделенным репозиторием под спеки и `openspec store` в связке с этой кастомной схемой — это **передовой край (bleeding edge)** использования AI для разработки.
+
+Единственное, за чем нужно следить по мере развития пет-проектов — это **баланс между строгостью и оверхедом**. Если вы заметите, что AI-агент начинает "уставать" (генерировать отписки в `N/A` секциях или терять нить из-за объема контекста), просто примените советы из раздела "Предложения по улучшению", чтобы сделать схему более гибкой.
+
+Отличная работа!

audits/2026-08-26-wealth-ledger-sdd/zai-result.md

@@ -0,0 +1,85 @@
+# Анализ SDD-схемы WealthLedger (OpenSpec)
+
+## Общая оценка
+
+Схема представляет собой **зрелый, продакшн-готовный пайплайн** управления AI-ассистентом. Конфигурация решает главную проблему применения LLM в разработке — преждевременное погружение в имплементацию и галлюцинации. Выстроен идеальный конвейер: от бизнес-намерения (Proposal) через поведенческий контракт (Specs) к архитектуре (Design) и чеклисту (Tasks), с жесткой защитой границ каждого этапа.
+
+---
+
+## Сильные стороны (Уровень "A+")
+
+### 1. Защита от смешивания уровней (Level Slippage)
+Директивы вида `MUST NOT включать технологии...` в Proposal и `Не включай в specs: Internal class/function names` — золотой стандарт промпт-инжиниринга для SDD. LLM обожают смешивать *Why*, *What* и *How*. В данной схеме уровни изолированы максимально жестко.
+
+### 2. Глубокое понимание квирков OpenSpec
+Конфигурация написана человеком, который реально дебажил поведение агента с фреймворком:
+- Требование ровно 4 решеток (`####`) для сценариев (критично для парсинга).
+- Грамотная работа с `planningHome.root` вместо хардкода путей (правильный подход для работы со store).
+- Разделение логики для `## Purpose` (добавляется только для новых capability, запрещается для дельт).
+- Корректная обработка флага `skip_specs: true`.
+
+### 3. Эвристика "Solution Assessment"
+Ограничение триггеров для создания раздела (auth, security, storage, observability и т.д.) — отличное архитектурное решение. Оно не дает ИИ писать бесполезные простыни текста для тривиальных фич, но принуждает к глубокому анализу там, где цена ошибки высока.
+
+### 4. Анти-галлюцинации в фазе Apply
+Правило `MUST NOT записывать ещё не наблюдённые результаты как выполненные` спасает от классической ошибки агентов, когда они ставят галочку `- [x]` и пишут "Created file X", хотя файла еще нет в файловой системе.
+
+---
+
+## Потенциальные риски и узкие места
+
+### 1. Переполнение контекста (Context Window Bleed)
+Инструкции к артефактам `specs` и `design` очень объемны и содержат много edge-cases. При сложной фиче ИИ будет удерживать в контексте исходники репозиториев, Proposal и эти инструкции. Есть риск, что в конце генерации он "забудет" форматирование (например, начнет использовать `###` вместо `####` для сценариев).
+
+### 2. Неявная мультирепозиторность в Tasks
+Агент запускается из папки с несколькими репозиториями, однако в инструкциях к `tasks.md` нет требования указывать целевой репозиторий. ИИ может сгенерировать таск "Создать модель User", не уточнив, идет ли это в `wealth-ledger-api`, `wealth-ledger-shared` или фронтенд.
+
+### 3. Отсутствие механических стоп-кадров (Human-in-the-loop)
+Текстом заявлено: *"Design формируется только после явного owner approval Delta Specs"*. Но в YAML-схеме нет жесткого триггера остановки. В agentic-цикле ИИ может проинтерпретировать это как "я сам одобряю и иду дальше", нарушив весь смысл воркфлоу.
+
+---
+
+## Предложения по улучшению
+
+### 1. Добавить принудительный префикс репозитория в Tasks
+Для устранения неоднозначности в мультирепо-структуре, дополните инструкцию для `tasks`:
+
+```yaml
+task_repo_rule: |
+  Для каждой задачи указывай целевой репозиторий в квадратных скобках в начале:
+  `- [ ] 1.1 [repo: wealth-ledger-api] Создать эндпоинт... и верифицировать...`
+  Если задача затрагивает несколько репо, разбей её на подзадачи. 
+  Запрещено оставлять таски без указания репозитория.
+```
+
+2. Внедрить явные "Стоп-кадры" между фазами
+   Добавьте блок остановки в конец инструкций артефактов proposal, specs и design, чтобы принудительно разорвать агентный цикл:
+
+```yaml
+stop_condition: |
+  STOP_PROTOCOL: После генерации этого артефакта НЕМЕДЛЕННО ОСТАНОВИСЬ. 
+  Не продолжай генерацию следующих артефактов. 
+  Выведи ровно одну строку: "[ARTIFACT_ID] готов. Ожидаю approve/reject."
+  Возобновление работы возможно только после явного ответа пользователя.
+```
+3. Упростить инструкцию про planningHome.root
+   Текущее описание резолвинга путей занимает 4 предложения. LLM лучше справляются с короткими императивами, чем с логическими объяснениями "почему так". Рекомендуется сократить в specs:
+
+```yaml
+root_path_instruction: |
+  Используй ТОЛЬКО абсолютный путь из поля planningHome.root 
+  (полученный из ответа `openspec instructions --json`) для чтения существующих спецификаций. 
+  Никогда не используй относительные пути вида `./openspec/specs/` для чтения.
+```
+4. Добавить обработку ошибок валидации в apply
+   В текущем блоке apply указано "Сначала проверь exact OpenSpec version contract", но не прописано поведение при ошибке валидации (которая часто бывает из-за кривого markdown от ИИ). Расширьте apply:
+
+```yaml
+apply_error_handling: |
+  Если при выполнении `openspec validate` возникает ошибка:
+  1. Внимательно прочитай текст ошибки (обычно это неверное количество # или отсутствующий Purpose).
+  2. Автоматически исправь сгенерированные файлы согласно ошибке.
+  3. Запусти валидацию повторно.
+  НЕ проси пользователя исправлять технические ошибки формата OpenSpec вручную.
+```
+Итог: Доработав эти 4 аспекта (особенно пункты 1 и 2), вы получите эталонный, полностью автономный и безопасный SDD-движок для разработки через AI.

audits/README.md

@@ -7,3 +7,4 @@
 - [Аудит 13.08.2026](audit-13-08-2026.md)
 - [Аудит 20.08.2026](audit-20-08-2026.md)
 - [Аудит 24.08.2026](audit-24-08-2026.md)
+- [Multi-source assessment WealthLedger SDD 26.08.2026](2026-08-26-wealth-ledger-sdd/README.md)