---
name: vdv
description: "ВДВ-скилл — генератор и аудитор описания стадийного процесса по 6 принципам Вход·Действие·Выход. Используй для построения описания нового процесса (/vdv build) или проверки готового описания (/vdv audit)."
argument-hint: "[build | audit] [описание процесса или деятельности]"
version: 1.0.0
layer: L1
status: active
browser_safe: true
service_clause: DP.SC.052
triggers:
  slash: [/vdv, /vdv build, /vdv audit]
  phrases: ["проверь процесс по ВДВ", "построй описание процесса", "аудит стадийного процесса"]
tests: ./test_cases.md
routing:
  executor: sonnet
  deterministic: false
agents: single
interaction: multi-step
gates_required: []
gates_enforced: []
gates_rationale: "операционный скилл; WP Gate применим только при создании нового РП, не для операционных вызовов"
---

# ВДВ-скилл (Вход·Действие·Выход)

> **Service Clause:** DP.SC.052  
> Источник принципов: PD.METHOD.008 §174-230 (каскад v9 стратегирования как эталонный тест-кейс)

Выполни: $ARGUMENTS

---

## When to use

ВДВ-скилл — генератор и аудитор описания стадийного процесса по 6 принципам Вход·Действие·Выход. Используй для построения описания нового процесса (/vdv build) или проверки готового описания (/vdv audit).

## Принципы ВДВ (эталон проверки)

Шесть инвариантов, по которым работают оба режима:

| # | Принцип | Формулировка | Тест нарушения |
|---|---------|--------------|----------------|
| 1 | **Триада на каждой стадии** | У стадии есть Вход, Действие, Выход. Нет одного — неполно. | Одно из трёх полей отсутствует или пусто |
| 2 | **Сцепление выход→вход** | Выход стадии должен стать входом одной из следующих. | Выход стадии N не появляется во Входе ни одной последующей стадии (и не помечен «внешний» / «обещание контура») |
| 3 | **Инвариант входа** | Вход = выходы предыдущих + стабильные документы + «план для сравнения». Артефакт без производителя и без пометки «внешний» — сигнал пропущенной стадии. | Во Входе стадии N стоит артефакт, которого нет в Выходе ни одной предыдущей стадии и нет пометки `(внешний)` |
| 4 | **Двусторонняя трассируемость** | У каждого артефакта есть производитель и потребитель. Без потребителя — лишний. Без производителя и без «внешний» — пропущенная стадия. | Артефакт в Выходе без потребителя во Входах следующих стадий (и не является обещанием контура) |
| 5 | **Carry-over** | Незавершённое переносится во Вход следующей итерации того же контура. | Повторяемый процесс (ритм > 1 итерации): вход первой стадии не включает `carry-over от предыдущей итерации` |
| 6 | **Антипустышка** | Стадия имеет прямую или косвенную трассировку к обещанию контура. Убрать стадию → нарушится ли обещание? Если нет — кандидат-пустышка. | Проверка: убери стадию — нарушится ли обещание контура? Нет → ❌ кандидат-пустышка. Стадия не трассируется ни напрямую (выход = обещание), ни косвенно (цепочка выходов ведёт к обещанию) |

> **Особые случаи принципа 5:** одноитерационный процесс (однократный, без цикла) — принцип 5 неприменим, ставь ⏸ с пояснением.  
> **Особые случаи принципа 6:** обещание контура неизвестно — ⚠️ + запрос уточнения.

---

## Algorithm

## Режим `/vdv build` — Генерация

### Алгоритм (подход C)

### Шаг 1. Понять деятельность

Прочитать описание деятельности из $ARGUMENTS. Если описание слишком краткое (<1 предложения или нет ни одного результата/выхода) — запросить уточнение:

> «Опишите деятельность подробнее: что происходит, какой основной результат, есть ли повторяющийся ритм?»

### Шаг 2. Выделить стадии (быстрый черновик)

Из описания вывести предположительный набор стадий. Правила:
- Каждая стадия = одно смысловое действие с проверяемым артефактом на выходе
- Первая стадия: входы помечай как `(внешний)` если они не производятся внутри процесса
- Ритм указывать если известен из контекста, иначе `—`
- Формат: compact markdown-таблица, колонки строго в порядке: `# | Стадия | Ритм | Вход | Действие | Выход`

### Шаг 3. Self-audit принципы 1-4

Сразу после черновика прогнать принципы 1-4 по построенной таблице. Показать:

```
Предварительный аудит (принципы 1-4):
П1 (триада): ✅ / ⚠️ / ❌ — <что нашёл>
П2 (сцепление): ✅ / ⚠️ / ❌ — <что нашёл>
П3 (инвариант входа): ✅ / ⚠️ / ❌ — <что нашёл>
П4 (трассируемость): ✅ / ⚠️ / ❌ — <что нашёл>
П5 (carry-over): ⏸ проверится после утверждения структуры
П6 (антипустышка): ⏸ проверится после утверждения обещания контура
```

### Шаг 4. Inline трассируемость

После таблицы ВДВ вывести компактный блок:

```
| Артефакт | Произведён на стадии | Потребляется на стадиях |
|----------|----------------------|------------------------|
| Название | N. Стадия           | M. Стадия / → обещание контура / → carry-over (следующая итерация) |
```

Висячие артефакты (без потребителя внутри контура) помечать:
- `→ обещание контура` — терминальный выход, является обещанием
- `→ carry-over (следующая итерация)` — уходит в следующий цикл процесса (П5)
- `→ ❌ потребитель не найден` — нарушение П4

### Шаг 5. Уточнение и финальный аудит

После правок пользователя — запустить полный аудит (шаги 1-5 режима audit) включая принципы 5-6.

---

## Режим `/vdv audit` — Аудит

### Алгоритм

### Шаг 1. Получить описание

Входной текст из $ARGUMENTS — таблица стадий или текстовое описание. Если не содержит явной структуры стадий — спросить: «Выделите стадии или передайте таблицу с колонками Вход/Действие/Выход».

### Шаг 2. Вывести обещание контура

Найти все выходы, не являющиеся входом ни одной последующей стадии = кандидаты на обещание контура. Показать:

> «Я вижу обещание контура как: `<список терминальных выходов>`. Это верно?»

При несогласии — уточнить у пользователя. При нескольких терминальных выходах — попросить выбрать или подтвердить все.

### Шаг 3. Прогнать 6 принципов

Для каждой стадии и каждого артефакта проверить все 6 принципов. Формат вердикта:

```
## Аудит процесса: <название>

### Принцип 1: Триада на каждой стадии
✅ Все стадии имеют триаду / ❌ Нарушения:
- Стадия N «<название>»: отсутствует <Вход | Действие | Выход>
  Фикс: <конкретное предложение>

### Принцип 2: Сцепление выход→вход
...

### Принцип 3: Инвариант входа
...

### Принцип 4: Двусторонняя трассируемость
...

### Принцип 5: Carry-over
✅ / ⚠️ / ❌ / ⏸ <пояснение>

### Принцип 6: Антипустышка
Обещание контура: <что принято>
✅ / ⚠️ / ❌ — <для каждой стадии с ❌: трассировка к обещанию не найдена>
  Фикс: <убрать стадию или явно связать с обещанием>

---
Итог: ✅ <N принципов OK> | ⚠️ <M предупреждений> | ❌ <K нарушений>
```

### Шаг 4. Опционально: предложить исправление

Если есть ❌ — предложить исправленную таблицу стадий с применёнными фиксами.

---

## Справка `/vdv`

```
ВДВ-скилл (Вход·Действие·Выход) — WP-413, DP.SC.052

Режимы:
  /vdv build <описание деятельности>  — построить описание процесса
  /vdv audit <описание стадий>         — проверить по 6 принципам ВДВ

6 принципов: триада · сцепление · инвариант входа · трассируемость · carry-over · антипустышка

Эталонный тест-кейс: каскад стратегирования v9 (PD.METHOD.008 §185-189)
Тест-кейсы разработки: test_cases.md
```

<!-- USER-SPACE -->
<!-- /USER-SPACE -->

---
description: "Dev-time regression suite для /vdv. Запускается при создании/обновлении скилла, не при вызове пользователем."
version: 1.0.0
wp: WP-413
usage: |
  Субагент читает этот файл, прогоняет каждый тест через режим аудита /vdv,
  сравнивает с expected_violations. Тест PASS = найденные нарушения совпадают с expected.
---

# Тест-кейсы /vdv

## TC-01: Нарушение принципа 1 — стадия без явного входа

```yaml
id: TC-01
mode: audit
name: "Сбор данных без источника"
description: "Стадия без явного Входа (поле пустое или отсутствует)"
input: |
  | # | Стадия       | Ритм   | Вход | Действие         | Выход            |
  |---|--------------|--------|------|------------------|------------------|
  | 1 | Сбор данных  | еженед | —    | Собрать таблицу  | Таблица данных   |
  | 2 | Анализ       | еженед | Таблица данных | Проанализировать | Отчёт |
  | 3 | Отправка     | еженед | Отчёт | Отправить руководителю | Письмо |

expected_violations:
  - principle: 1
    stage: 1
    field: "Вход"
    reason: "Вход стадии 1 пустой (—). Триада неполна."
  - principle: 3
    stage: 1
    reason: "Артефакты 'Таблица данных' не имеют источника. Если это внешний вход — пометить (внешний)."

expected_verdict: "❌"
expected_ok_principles: [2, 5, 6]
# П4 не включён в OK: стадия 1 не потребляет никаких артефактов (Вход пуст),
# поэтому нарушение П3 (нет источника) не вызывает нарушения П4 автоматически.
# Но аудитор ДОЛЖЕН отметить, что «Таблица данных» имеет производителя (стадия 1)
# и потребителя (стадия 2) — П4 для выходных артефактов OK.
# П4 для входных артефактов: Вход пуст → нечего трассировать → П4 по входу неприменим.
# Итог: П4 = ОК (потребитель и производитель для «Таблица данных» есть), не включать в expected_violations.
expected_ok_principles_include_4: true
explanation: |
  Классический антипаттерн: первая стадия начинается «из воздуха».
  П4 специфика: 'Таблица данных' имеет производителя (стадия 1) и потребителя (стадия 2) — П4 OK.
  Нарушение в П1 (пустой вход) и П3 (нет источника для входа), но не в П4 (артефакт сцеплён).
  Корректный фикс: добавить во Вход стадии 1 источник данных с пометкой (внешний).
```

---

## TC-02: Нарушение принципа 2 — разрыв в сцеплении

```yaml
id: TC-02
mode: audit
name: "Разрыв в цепочке выход→вход"
description: "Выход стадии N не появляется ни в одном последующем Входе"
input: |
  | # | Стадия              | Ритм   | Вход                         | Действие               | Выход              |
  |---|---------------------|--------|------------------------------|------------------------|--------------------|
  | 1 | Постановка задачи   | разово | Запрос пользователя (внешний)| Сформулировать задачу  | Карточка задачи    |
  | 2 | Исследование        | разово | Запрос пользователя (внешний)| Изучить контекст       | Исследовательский отчёт |
  | 3 | Реализация          | разово | Карточка задачи              | Написать код           | PR                 |
  | 4 | Деплой              | разово | PR                           | Задеплоить             | Деплой в проде     |

expected_violations:
  - principle: 2
    stage: 2
    reason: "Выход стадии 2 'Исследовательский отчёт' не является входом ни одной следующей стадии."
  - principle: 4
    stage: 2
    reason: "Артефакт 'Исследовательский отчёт' — нет потребителя во входах стадий 3 и 4."

expected_verdict: "❌"
expected_ok_principles: [1, 3, 5, 6]
explanation: |
  Стадия 2 «Исследование» производит артефакт, который никуда не идёт — типичная пустышка
  (хотя здесь нарушается принцип 2, а не 6).
  Фикс: добавить «Исследовательский отчёт» во Вход стадии 3, либо удалить стадию 2 если её результат не влияет на реализацию.
```

---

## TC-03: Нарушение принципов 3 и 4 — артефакт без производителя

```yaml
id: TC-03
mode: audit
name: "Артефакт во входе без производителя"
description: "Вход стадии содержит артефакт, который ни одна предыдущая стадия не производит и нет пометки (внешний)"
input: |
  | # | Стадия              | Ритм    | Вход                                    | Действие                     | Выход                  |
  |---|---------------------|---------|-----------------------------------------|------------------------------|------------------------|
  | 1 | Day Open            | ежедневно | Вчерашний DayPlan · Коммиты за вчера  | Планировать день             | DayPlan               |
  | 2 | Исполнение          | ежедневно | DayPlan · Кэш активных РП             | Работать по РП               | Коммиты · Заметки      |
  | 3 | Day Close           | ежедневно | DayPlan · Коммиты · WeekPlan           | Закрыть день                 | DayReport              |

expected_violations:
  - principle: 3
    stage: 2
    artifact: "Кэш активных РП"
    reason: "Артефакт 'Кэш активных РП' во Входе стадии 2 не производится стадией 1 и не помечен (внешний)."
  - principle: 3
    stage: 3
    artifact: "WeekPlan"
    reason: "Артефакт 'WeekPlan' во Входе стадии 3 не производится стадиями 1-2 и не помечен (внешний)."
  - principle: 4
    stage: 3
    artifact: "WeekPlan"
    reason: "WeekPlan используется (потребляется) стадией 3, но производитель внутри этого процесса не определён."

expected_verdict: "⚠️"
expected_ok_principles: [1, 2, 5, 6]
explanation: |
  Вход содержит стабильные документы ('WeekPlan', 'Кэш активных РП'), 
  которые производятся другим процессом (Сессия стратегирования).
  Фикс: пометить как (внешний): «WeekPlan (внешний)», «Кэш активных РП (внешний)».
  После фикса принципы 3 и 4 = ✅, процесс ОК.
```

---

## TC-PASS: Эталонный процесс — каскад v9 (упрощённый фрагмент)

```yaml
id: TC-PASS
mode: audit
name: "Фрагмент каскада стратегирования v9 — должен пройти без нарушений"
description: "Стадии 3-5 каскада v9 (Day Open / Исполнение / Day Close). Тест: аудит не должен находить ❌."
input: |
  | # | Стадия        | Ритм       | Вход                                                        | Действие            | Выход                      |
  |---|---------------|------------|-------------------------------------------------------------|---------------------|----------------------------|
  | 3 | Day Open      | ежедневно  | Plan W{N} (внешний) · DayReport предыдущего дня (carry-over) · Коммиты за вчера (внешний) | Планировать день | DayPlan |
  | 4 | Исполнение    | в течение дня | DayPlan · Кэш активных РП (внешний)                     | Работать по РП      | Коммиты · Заметки          |
  | 5 | Day Close     | ежедневно  | DayPlan · Коммиты · Заметки · Plan W{N} (внешний)          | Закрыть день        | DayReport                  |

promise: "DayReport"
expected_violations: []
expected_verdict: "✅"
explanation: |
  Стадии 3-5 правильно сцеплены:
  - DayPlan: произведён стадией 3 → потреблён стадией 4 и 5
  - Коммиты: произведены стадией 4 → потреблены стадией 5
  - Заметки: произведены стадией 4 → потреблены стадией 5
  - DayReport: произведён стадией 5 → carry-over во Вход стадии 3 следующего дня (принцип 5)
  - Внешние входы помечены (внешний) → принцип 3 OK
  - Обещание контура задано явно как DayReport → П6 проверяется детерминированно
  Примечание: при dev-time прогоне поле `promise` подставляется автоматически,
  имитируя подтверждение пользователем (интерактивный шаг вывода обещания пропускается).
```

---

## TC-BUILD-01: Режим генерации — проверка self-audit и маркеров ⏸

```yaml
id: TC-BUILD-01
mode: build
name: "Генерация: пайплайн обработки заметок"
description: "Проверяет что build-режим: строит черновик, показывает self-audit П1-П4, явно маркирует П5-П6 как ⏸"
input: |
  Деятельность: сбор мимолётных заметок в течение дня, их разбор в конце недели и перевод в Pack-знания

expected_output_contains:
  - "| # | Стадия"
  - "Вход"
  - "Действие"
  - "Выход"
  - "Предварительный аудит"
  - "П5"
  - "⏸"
  - "П6"
  - "⏸"
expected_output_not_contains:
  - "П5 (carry-over): ✅"
  - "П5 (carry-over): ❌"
  - "П6 (антипустышка): ✅"
  - "П6 (антипустышка): ❌"

explanation: |
  Режим build должен:
  1. Построить таблицу стадий из описания деятельности
  2. Немедленно прогнать П1-П4 по черновику
  3. Явно пометить П5 и П6 как ⏸ (не пропускать молча, не ставить ✅/❌)
  Тест проверяет именно этот инвариант — принципы 5-6 отложены, не пропущены.
```