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

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

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

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

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

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

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

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