| name | dnv-synthesis |
| description | Внутренний справочник по сборке рабочей документации кейса. Структура spec.md (шаблон, теги достоверности, as-of), генерация action-plan.md, ветвление initial vs renovación. Используй когда нужно собрать или обновить нормативную базу кейса и план действий. |
Сборка документации кейса — справочник
Когда нужно собрать нормативную базу кейса (spec) или составить план действий
(action-plan) — используй этот справочник. Оба документа живут в user/
(gitignored) и являются внутренними рабочими документами, не юридической
консультацией.
Приватность (КРИТИЧНО)
Значения профиля идут только в файлы user/ (gitignored). Не дублируй
NIE/имена/суммы/адрес в CLAUDE.md, память или любой коммитимый файл.
Action-plan.md — первичный артефакт
Для сценариев «первичная подача» и «продление» главный результат —
пошаговый план действий (user/action-plan.md). Структура и формат
карточек описаны в CLAUDE.md §«Как строить план». Здесь — дополнительные
заметки по сборке:
- Таймлайн от целевой даты назад. Фазы не фиксированы: у кого-то 3 недели
до подачи, у кого-то полгода. Структуру фаз определяй под конкретный кейс.
- Каждая карточка = одно действие с правовым контекстом, спецификой кейса,
пререквизитами, пошаговым гайдом, дедлайном и ответственным.
- Теги достоверности на каждом факте (см. ниже).
- Живые значения (SMI, суммы tasa, состав пакета) — из живых источников
с пометкой «(проверить вживую)», не из устаревшей базы как факт.
- План — живой документ. По мере разговора обновляй: карточка выполнена →
[x] + дата; обнаружена проблема → новая карточка; изменились сроки →
пересчёт фаз.
Spec.md — рабочий документ с нормативной базой
user/spec.md — внутренний рабочий документ, собирающий нормативную базу
конкретного кейса. Строится по шаблону templates/spec_renewal.template.md
(секции 0–12).
Входы для сборки
user/case-profile.json — значения для {{ПЛЕЙСХОЛДЕРОВ}}.
user/research-notes.md — живые находки (с источниками и as-of),
если есть. Если их нет — работай с курируемой базой и пометь, что живая
проверка не проводилась.
knowledge_base/sources/primary/* — дословные тексты законов и
Instrucción (BOE + inclusion.gob.es). Единственный якорь тега [норма].
knowledge_base/norms/* — разбор норм + as-of даты. Шапка каждого
файла называет статьи в sources/primary/, на которые он якорится.
При расхождении norms/ ↔ primary/ прав primary/ — зафиксируй
расхождение в §11.
knowledge_base/practice/digest.md — практика (мнение). ⚠️ Пункт дайджеста
не знает, к какому кейсу применим: прежде чем поднимать из него блокер,
сверься с нормативной рамкой.
knowledge_base/norms/solicitud-inicial.md — при case.process_type == initial читать обязательно: маршрут, законность пребывания, кто подписывает
без NIE, обязательство по Seguridad Social, риск extinción.
Ветвление initial vs renovación в шаблоне
- Раздел «2-bis. Маршрут первичной подачи» заполняется только при
initial;
при renovación он удаляется целиком, а заполняется «Окно подачи».
- При
initial раздел «Окно подачи» удаляется, потому что у первичной подачи
окна нет.
Правила заполнения
-
Плейсхолдеры {{...}} — подставь из профиля. Нет значения → оставь
[ТРЕБУЕТСЯ: …], не выдумывай (особенно REGAGE/expediente — их нет до
подачи; §0 остаётся «не подано»).
-
Каждое утверждение — с тегом достоверности:
[норма] · [официальное разъяснение] · [практика — консультант] ·
[практика — Telegram] · [не подтверждено]
-
Тег [норма] проверяем: утверждение без дословного текста в
sources/primary/ (или живом BOE) этот тег нести не может — максимум
[официальное разъяснение]. Не повышай уровень «потому что звучит как закон».
-
Пороги/процедурное — бери живые значения из research-notes (с годом
- источником); если их нет или они
[не подтверждено] — сохрани пометку
«(проверить вживую)», не подставляй устаревшее из базы как факт.
-
Приоритет источников при конфликте: живой [норма] (BOE) >
sources/primary/ (дословный текст) > norms/ (разбор) >
[официальное разъяснение] > [практика]. Расхождения фиксируй в
§11 «Расхождения».
-
Практика (§4.7, §2 уточнения) — из дайджеста, с явным «Telegram = мнение».
Шапка достоверности
В начало user/spec.md добавь блок:
> **Синтез от:** <дата> · **Рисёрч от:** <дата research-notes | «не проводился»>
> **Практика:** <дайджест | дайджест + свежие slices>
> As-of норм-базы: <дата из norms/ (перепроверено вживую там, где помечено)>.
Извлечение утверждений для верификации
Когда spec или план готовы и нужна проверка фактов — используй
engine/scripts/extract_claims.py для извлечения утверждений с тегами.
Каждое [не подтверждено] — кандидат в «список внешних проверок».
Если данных не хватает
Если профиля нет или он неполон — собери недостающее в разговоре (справочник:
dnv-intake). Если живых находок нет — работай с курируемой базой и пометь
ограничение. Не останавливайся с требованием «сначала сделайте X».