Версия: 0.1.0 (черновик)
Дата: 2025-11-10
Статус: 🔄 В разработке — проектируем саму себя
Эта система определяет КАК мы проектируем любой компонент платформы — от агентов до функций.
Принцип: Система проектирования сама себя проектирует первой, а потом проектирует всё остальное.
Вопросы:
- Что проектируем? (агент / функция / модуль / систему)
- Зачем это нужно?
- Какую проблему решает?
- Кто будет использовать?
Выход: Чёткое понимание ЧТО создаём и ЗАЧЕМ.
Вопросы:
- Что уже есть в платформе? (избегаем дублирования)
- Какие зависимости?
- С чем взаимодействует?
- Какие ограничения?
Инструменты:
- Cascade Search (L1-L7) — поиск существующих решений
- Чтение документации (platform/CLAUDE.md, PLATFORM_OVERVIEW.md)
- Анализ существующих компонентов
Выход: Карта контекста — что используем, с чем интегрируемся.
Применяем 8 срезов (из PLATFORM_MULTISLICE_ANALYSIS.md):
🏗️ СТРУКТУРНЫЙ — Из чего состоит?
- Компоненты
- Связи
- Зависимости
⚡ ФУНКЦИОНАЛЬНЫЙ — Что делает?
- Основные функции
- Входы/выходы
- Потоки данных
🔄 ПРОЦЕССНЫЙ — Как работает?
- Алгоритмы
- Последовательности
- Жизненный цикл
👥 РОЛЕВОЙ — Кто использует?
- Пользователи
- Права доступа
- Ответственность
🔧 ТЕХНИЧЕСКИЙ — На чём построено?
- Технологии
- API
- Паттерны
📊 ИНФОРМАЦИОННЫЙ — Какие данные?
- Модель данных
- Хранилища
- Потоки
⏰ ВРЕМЕННОЙ — Как развивается?
- Версионирование
- Roadmap
- Deprecation
🌍 ПРОСТРАНСТВЕННЫЙ — Где находится?
- Размещение
- Топология
- Масштабирование
Выход: Полное понимание через разные углы зрения.
Создаём документ:
{component}/DESIGN.md
Содержит:
- Цель и назначение
- Анализ по 8 срезам
- API / интерфейсы
- Примеры использования
- Ограничения
- Альтернативы (почему выбрали это)
Выход: Полная спецификация компонента.
Проверяем через диалог:
- Задаём вопросы
- Ищем противоречия
- Проверяем полноту
- Уточняем детали
Участники: Человек (вы) + Claude (я)
Выход: Согласованная спецификация.
Фиксируем:
- Git commit с DESIGN.md
- Обновление system-journal.md
- Версия (0.1.0 → 1.0.0)
- Статус: Черновик → Утверждено
Выход: Готовая спецификация для реализации.
Теперь применим эту систему к самой системе проектирования!
Что проектируем?
Систему проектирования компонентов платформы ЦИФРА.
Зачем нужна?
- Унифицировать процесс проектирования
- Избежать хаотичной разработки
- Обеспечить полноту анализа
- Создать документацию автоматически
Какую проблему решает?
Без системы проектирования каждый компонент проектируется по-своему, теряется контекст, забываются важные аспекты.
Кто использует?
- Я (Claude) — при проектировании агентов/функций
- Вы (Human) — для контроля и уточнений
- Будущие разработчики — для понимания процесса
Что уже есть?
- ✅ PLATFORM_MULTISLICE_ANALYSIS.md — методология 8 срезов
- ✅ DEVELOPMENT_SEQUENCE.md — план разработки
- ✅ platform/CLAUDE.md — правила платформы
- ✅ Архитектурная ДНК (4 принципа)
Зависимости:
- Методология 8 срезов (используем её!)
- Cascade Search (поиск существующих решений)
- Git (версионирование спецификаций)
С чем интегрируется?
- Процесс разработки (DESIGN → CODE → TEST)
- MetaAgent (в будущем будет проектировать автоматически)
- DocumentAgent (генерирует DESIGN.md)
Ограничения:
- Должна быть простой (не перегружать)
- Должна быть гибкой (не все срезы всегда нужны)
- Должна работать в диалоге (Human ↔ Claude)
Компоненты системы проектирования:
Система проектирования
│
├─ Процесс (6 этапов)
│ ├─ 1. Определение сущности
│ ├─ 2. Контекстный анализ
│ ├─ 3. Многосрезовый анализ
│ ├─ 4. Спецификация
│ ├─ 5. Валидация
│ └─ 6. Утверждение
│
├─ Шаблоны
│ ├─ DESIGN.md (спецификация)
│ ├─ QUESTIONS.md (вопросы для диалога)
│ └─ VALIDATION_CHECKLIST.md (проверка полноты)
│
└─ Инструменты
├─ Cascade Search (поиск существующего)
├─ Методология 8 срезов (анализ)
└─ Git (версионирование)
Связи:
- Процесс использует Шаблоны
- Этапы используют Инструменты
- Результат → Git → system-journal.md
Основные функции:
F1: Провести проектирование компонента
Вход: Название компонента, тип (агент/модуль/функция)
Процесс: 6 этапов (см. выше)
Выход: {component}/DESIGN.md
F2: Валидировать спецификацию
Вход: DESIGN.md (черновик)
Процесс: Чеклист вопросов, диалог
Выход: Список замечаний / OK
F3: Сгенерировать вопросы для диалога
Вход: Компонент, текущий этап
Процесс: Анализ через 8 срезов → генерация вопросов
Выход: Список вопросов для уточнения
Потоки данных:
User: "Спроектируй DocumentAgent"
↓
Claude: Применяет систему проектирования
↓
├─ Этап 1: Определяет что это агент документации
├─ Этап 2: Ищет существующие решения (Cascade Search)
├─ Этап 3: Анализ по 8 срезам
├─ Этап 4: Генерирует platform/agents/DocumentAgent/DESIGN.md
├─ Этап 5: Задаёт вопросы пользователю для уточнения
└─ Этап 6: User утверждает → Git commit
↓
Result: Готовая спецификация DocumentAgent
Жизненный цикл спецификации:
1. ЧЕРНОВИК (v0.1.0)
- Первая версия
- Статус: 🔄 В разработке
2. ВАЛИДАЦИЯ (v0.2.0 - v0.9.0)
- Итерации через диалог
- Уточнения, исправления
- Статус: 🔄 На валидации
3. УТВЕРЖДЕНО (v1.0.0)
- Все вопросы закрыты
- Готово к реализации
- Статус: ✅ Утверждено
4. РЕАЛИЗАЦИЯ
- Код пишется по спецификации
- Спецификация может уточняться (v1.1.0, v1.2.0)
5. DEPRECATED (при необходимости)
- Компонент устарел
- Статус: ⚠️ Устарело
Роли:
Human (Пользователь):
- Инициирует проектирование ("Давай спроектируем X")
- Отвечает на вопросы для уточнения
- Утверждает спецификацию
- Может вносить правки
Claude (Проектировщик):
- Применяет систему проектирования
- Проводит анализ по 8 срезам
- Генерирует DESIGN.md
- Задаёт вопросы для валидации
- Фиксирует результат в Git
MetaAgent (в будущем):
- Автоматически проектирует улучшения
- Анализирует существующие спецификации
- Предлагает оптимизации
Технологии:
Формат документов: Markdown (.md)
Версионирование: Git + Semantic Versioning
Хранение: /opt/claude-workspace/platform/
Шаблоны: Jinja2 (опционально для автогенерации)
Валидация: Python скрипты (опционально)
API системы проектирования:
# Псевдокод (будущая реализация)
class DesignSystem:
def design(self, component_name, component_type):
"""Провести проектирование компонента"""
# Этап 1: Определение
definition = self.define_entity(component_name, component_type)
# Этап 2: Контекст
context = self.analyze_context(component_name)
# Этап 3: Многосрезовый анализ
analysis = self.multislice_analysis(definition, context)
# Этап 4: Спецификация
spec = self.generate_specification(analysis)
# Этап 5: Валидация (через диалог)
validated_spec = self.validate_with_user(spec)
# Этап 6: Утверждение
self.approve_and_commit(validated_spec)
return validated_spec
Модель данных:
Сущность: СПЕЦИФИКАЦИЯ
Структура:
component_name: str
component_type: enum(agent, module, function, system)
version: semver
status: enum(draft, validation, approved, deprecated)
created_at: datetime
updated_at: datetime
# Содержание
definition: str (из Этапа 1)
context: dict (из Этапа 2)
analysis: dict (8 срезов из Этапа 3)
specification: str (Этап 4)
validation_log: list[Question] (Этап 5)
Файл:
- platform/{component}/DESIGN.md
- platform/{component}/DESIGN_HISTORY.md (версии)
Хранение:
platform/
├── design-system/
│ └── DESIGN.md (эта система сама себя описывает!)
│
└── agents/
├── DocumentAgent/
│ ├── DESIGN.md
│ └── DESIGN_HISTORY.md
└── CodeAgent/
├── DESIGN.md
└── DESIGN_HISTORY.md
История:
2025-11-10: Создана система проектирования (v0.1.0 черновик)
2025-11-10: Применена к самой себе (рекурсия!)
2025-11-10: Валидация через диалог (вы + я)
[БУДУЩЕЕ]: Утверждена (v1.0.0)
[БУДУЩЕЕ]: Использована для проектирования DocumentAgent
[БУДУЩЕЕ]: Использована для проектирования CodeAgent
...
Roadmap:
v0.1.0: Черновик (СЕЙЧАС)
v0.2.0: После первого раунда вопросов
v0.3.0: После уточнений
...
v1.0.0: Утверждено — готово к использованию
v1.1.0: Улучшения после использования на 1-м агенте
v2.0.0: Автоматизация (через MetaAgent)
Расположение:
/opt/claude-workspace/platform/DESIGN_SYSTEM.md (этот файл)
Будущие спецификации:
/opt/claude-workspace/platform/agents/{agent}/DESIGN.md
/opt/claude-workspace/platform/modules/{module}/DESIGN.md
Размер:
Текущий: ~15 KB (этот документ)
После проектирования всех агентов: ~100-200 KB
API системы проектирования:
# ВХОД
component_name: str (например, "DocumentAgent")
component_type: enum (agent / module / function / system)
# ПРОЦЕСС
1. Определение сущности (диалог с пользователем)
2. Контекстный анализ (Cascade Search + чтение docs)
3. Многосрезовый анализ (8 срезов)
4. Генерация DESIGN.md
5. Валидация (вопросы пользователю)
6. Утверждение (Git commit)
# ВЫХОД
{component}/DESIGN.md (версионированная спецификация)
Примеры использования:
ПРИМЕР 1: Проектирование агента
User: "Давай спроектируем DocumentAgent"
Claude:
1. Применяет систему проектирования
2. Этап 1: Определяет — это агент для генерации документации
3. Этап 2: Ищет существующие решения, зависимости
4. Этап 3: Анализ по 8 срезам
5. Этап 4: Генерирует platform/agents/DocumentAgent/DESIGN.md
6. Этап 5: Задаёт вопросы:
- Какие типы документов генерировать? (PROJECT.md / ROADMAP.md / ...)
- Откуда брать примеры? (существующие проекты?)
- Как обновлять существующие документы?
7. Этап 6: После ответов → утверждает → Git commit
Результат: ✅ Спецификация DocumentAgent готова к реализации
Вопросы к вам для валидации этой системы проектирования:
Q1: Согласны ли вы с 6 этапами процесса проектирования?
- Определение → Контекст → Анализ → Спецификация → Валидация → Утверждение
Q2: Какие этапы нужно добавить / убрать / изменить?
Q3: Нужен ли этап "Прототипирование" перед спецификацией?
- Или сразу из спецификации в код?
Q4: Нужно ли всегда использовать все 8 срезов?
- Или для простых компонентов можно меньше?
Q5: Какие срезы самые важные для агентов?
- Структурный, Функциональный, Технический — достаточно?
Q6: Как лучше организовать валидацию?
- Вариант А: Я задаю вопросы блоками (по 5-10 вопросов)
- Вариант Б: Вопросы по ходу каждого этапа
- Вариант В: Сначала полный черновик, потом все вопросы
Q7: Что делать при разногласиях?
- Если я предлагаю одно решение, а вы другое — как решаем?
Q8: Формат DESIGN.md подходит?
- Markdown с 8 срезами + примеры?
Q9: Нужна ли отдельная VALIDATION_LOG.md?
- Чтобы видеть историю вопросов и ответов?
Q10: Начинаем проектировать DocumentAgent после утверждения этой системы?
- Или сначала ещё что-то нужно доработать?
Ожидает ответов на вопросы Q1-Q10
После валидации:
- Обновлю этот документ
- Версия: 0.1.0 → 1.0.0
- Статус: Черновик → Утверждено
- Git commit
- Запись в system-journal.md
# {Component Name} — Спецификация
**Версия:** 0.1.0
**Дата:** YYYY-MM-DD
**Статус:** 🔄 Черновик
---
## ОПРЕДЕЛЕНИЕ
**Что:** [Название и тип компонента]
**Зачем:** [Назначение, проблема]
**Кто использует:** [Пользователи]
---
## КОНТЕКСТ
**Существующие решения:** [Что уже есть]
**Зависимости:** [От чего зависит]
**Интеграции:** [С чем взаимодействует]
**Ограничения:** [Что нельзя]
---
## АНАЛИЗ (8 срезов)
### 🏗️ СТРУКТУРНЫЙ
[Компоненты, связи, зависимости]
### ⚡ ФУНКЦИОНАЛЬНЫЙ
[Функции, входы/выходы, потоки данных]
### 🔄 ПРОЦЕССНЫЙ
[Алгоритмы, последовательности]
### 👥 РОЛЕВОЙ
[Роли, права доступа]
### 🔧 ТЕХНИЧЕСКИЙ
[Технологии, API, паттерны]
### 📊 ИНФОРМАЦИОННЫЙ
[Модель данных, хранилища]
### ⏰ ВРЕМЕННОЙ
[Версионирование, roadmap]
### 🌍 ПРОСТРАНСТВЕННЫЙ
[Размещение, топология]
---
## СПЕЦИФИКАЦИЯ
**API:**
[Интерфейсы, методы]
**Примеры использования:**
[Конкретные примеры]
---
## ВАЛИДАЦИЯ
**Вопросы:** [Список вопросов для уточнения]
**Ответы:** [Ответы из диалога]
---
## УТВЕРЖДЕНИЕ
**Дата:** [После валидации]
**Версия:** 1.0.0
**Статус:** ✅ Утверждено
СЕЙЧАС:
1. Вы отвечаете на Q1-Q10
2. Я обновляю этот документ
3. Утверждаем систему проектирования (v1.0.0)
ПОТОМ:
4. Применяем к DocumentAgent
5. Применяем к CodeAgent
6. Применяем к GitAgent
...
Версия: 0.1.0 (черновик)
Дата: 2025-11-10
Ожидает валидации