vdv · v1.0.0 · 2026-09-04 · sha256 df3b912afef44ebf
vdv v1.0.0A
Immutable. This exact content is served forever at /api/v1/blob/df3b912afef44ebf.
--- 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 -->