Vdv

---
name: vdv
description: "ВДВ-скилл — генератор и аудитор описания стадийного процесса по 6 принципам Вход·Действие·Выход. Используй для построения описания нового процесса (/vdv build) или проверки готового описания (/vdv audit)."
argument-hint: "[build | audit] [описание процесса или деятельности]"
version: 1.0.0
layer: L1
status: active
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 -->