В опытной стадии — версия v0.5.0 (Jan 2026), используется командой, интерфейс и поведение могут меняться.
Плагин для Claude Code, реализующий spec-driven development — поддержание согласованности между бизнес-спецификацией, технической спецификацией и кодом через формализованные команды каскадирования.
Канонический источник методологии: /home/i/vault/SDD.md. Сам плагин: /home/i/.claude/plugins/cache/local-dev/cascade/.
Что решает
Когда бизнес-спека, техническая спека и код живут в разных местах и редактируются независимо — они расходятся. Cascade фиксирует поток изменений:
- Когда меняется бизнес-спека — нужно проанализировать, что это значит для технической спеки и потенциально для кода.
- Когда меняется код — нужно отразить это вверх в технической и бизнес-спеке (если изменение значимо).
Три уровня спецификаций
Бизнес-спека Техническая спека Код / Промпт
ЧТО → КАК → Реализация
Бизнес-спека — что нужно сделать. Цели, user stories, функциональные / нефункциональные требования, бизнес-правила, acceptance criteria. Без архитектурных решений и имён классов / функций.
Техническая спека — как это сделать. Архитектурные решения для каждого требования, API контракты, модели данных, промпты (Input / Output / Algorithm & Details), Mermaid-диаграммы. Принцип: каждое требование из бизнес-спеки имеет конкретный дизайн.
Код — реализация дизайна. Сервисы (TS / Go / Python / …), инфра (Terraform, K8s), промпты в Langfuse.
Команды плагина
| Команда | Описание |
|---|---|
/init | Инициализация проекта |
/down | Каскад вниз: бизнес → техническая → код. Анализ git diff верхнего уровня → предложение изменений на нижнем. |
/up | Каскад вверх: код → техническая (reverse engineering). |
/check | Валидация соответствия specs ↔ code. |
Workflow
Google Docs <— gdocs-sync —> specs/business/*.md
│
│ /down
▼
specs/technical/*.md
│
│ /down
▼
src/**
Команда редактирует бизнес-спеку в Google Docs (с возможностью комментариев). gdocs-sync pull приносит изменения в repo как specs/business/*.md. Дальше /down смотрит git-diff бизнес-спеки и предлагает изменения в технической спеке. Аналогично от технической к коду.
Конфигурация (.claude/cascade.yaml)
specs:
business: specs/business
technical: specs/technical
code:
paths: [src, apps]
langfuse:
host: ${LANGFUSE_HOST}
label: ${LANGFUSE_LABEL}Монорепо
Группирует изменения по приложениям:
monorepo/
├── apps/
│ ├── api/ → specs/api/
│ └── web/ → specs/web/
└── packages/
└── shared/ → specs/shared/
Status и реальность использования
Плагин работающий, методология целостная, но широкого внедрения в команду BloodGPT не получило. Главные слабые места:
- Синхронизация Google Docs ↔ repo через MCP — те же нюансы, которые убили Итерацию 3 (см. knowledge-management). Каждое автообновление превращается в ручную настройку.
- Слой технических спек требует постоянной поддержки — на практике часто пропускался.
- Дисциплина три-уровневого редактирования не закрепилась как командная практика.
На Apr 2026 текущий подход — markdown-wiki в wiki/bloodgpt/ без формального каскадирования (см. knowledge-management). Cascade остаётся как доступный инструмент для проектов, где трёх-уровневая структура оправдана.
Открытые вопросы
- Стоит ли реанимировать Cascade для конкретных частей продукта (например, FHIR Gravity middleware где спека имеет смысл вести отдельно от реализации).
- Возможна ли версия Cascade без Google Docs — сразу markdown-в-git с CriticMarkup для комментариев.
- Как соотнести три-уровневый каскад с принципом «один файл может содержать спецификацию + обсуждение + реализованное-но-обсуждаемое» (см. open вопрос в knowledge-management).
Связано
- knowledge-management — общий обзор подхода к управлению знаниями (Cascade — Итерация 2)
- CLAUDE.md — wiki conventions
- уроки — methodology lessons