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