---
name: dnv-synthesis-acogood
title: Сборка документации кейса — справочник
description: Внутренний справочник по сборке рабочей документации кейса. Структура spec.md (шаблон, теги достоверности, as-of), генерация action-plan.md, ветвление initial vs renovación. Используй когда нужно собрать или обновить нормативную базу кейса и план действий.
author: acogood
author_url: https://github.com/acogood/spain-dnv-consultant/tree/main/.claude/skills/dnv-synthesis
license: MIT
version: 0.1.0
execution_mode: open
jurisdiction: es
practice: immigration
language: ru
---

# Сборка документации кейса — справочник

Когда нужно собрать нормативную базу кейса (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).

### Входы для сборки

1. `user/case-profile.json` — значения для `{{ПЛЕЙСХОЛДЕРОВ}}`.
2. `user/research-notes.md` — **живые находки** (с источниками и as-of),
   если есть. Если их нет — работай с курируемой базой и пометь, что живая
   проверка не проводилась.
3. `knowledge_base/sources/primary/*` — **дословные тексты** законов и
   Instrucción (BOE + inclusion.gob.es). **Единственный якорь тега `[норма]`.**
4. `knowledge_base/norms/*` — разбор норм + **as-of** даты. Шапка каждого
   файла называет статьи в `sources/primary/`, на которые он якорится.
   **При расхождении `norms/` ↔ `primary/` прав `primary/`** — зафиксируй
   расхождение в §11.
5. `knowledge_base/practice/digest.md` — практика (мнение). ⚠️ Пункт дайджеста
   **не знает, к какому кейсу применим**: прежде чем поднимать из него блокер,
   сверься с нормативной рамкой.
6. `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` добавь блок:

```markdown
> **Синтез от:** <дата>  ·  **Рисёрч от:** <дата research-notes | «не проводился»>
> **Практика:** <дайджест | дайджест + свежие slices>
> As-of норм-базы: <дата из norms/ (перепроверено вживую там, где помечено)>.
```

## Извлечение утверждений для верификации

Когда spec или план готовы и нужна проверка фактов — используй
`engine/scripts/extract_claims.py` для извлечения утверждений с тегами.
Каждое `[не подтверждено]` — кандидат в «список внешних проверок».

## Если данных не хватает

Если профиля нет или он неполон — собери недостающее в разговоре (справочник:
dnv-intake). Если живых находок нет — работай с курируемой базой и пометь
ограничение. Не останавливайся с требованием «сначала сделайте X».