architect/_archive/2025-11-26-cleanup/cifra/archive/2025-11-10-restructure-v2/DESIGN_SYSTEM.md

Система проектирования платформы ЦИФРА

Версия: 0.1.0 (черновик)
Дата: 2025-11-10
Статус: 🔄 В разработке — проектируем саму себя


🎯 НАЗНАЧЕНИЕ

Эта система определяет КАК мы проектируем любой компонент платформы — от агентов до функций.

Принцип: Система проектирования сама себя проектирует первой, а потом проектирует всё остальное.


📋 ПРОЦЕСС ПРОЕКТИРОВАНИЯ

ЭТАП 1: ОПРЕДЕЛЕНИЕ СУЩНОСТИ

Вопросы:
- Что проектируем? (агент / функция / модуль / систему)
- Зачем это нужно?
- Какую проблему решает?
- Кто будет использовать?

Выход: Чёткое понимание ЧТО создаём и ЗАЧЕМ.


ЭТАП 2: КОНТЕКСТНЫЙ АНАЛИЗ

Вопросы:
- Что уже есть в платформе? (избегаем дублирования)
- Какие зависимости?
- С чем взаимодействует?
- Какие ограничения?

Инструменты:
- Cascade Search (L1-L7) — поиск существующих решений
- Чтение документации (platform/CLAUDE.md, PLATFORM_OVERVIEW.md)
- Анализ существующих компонентов

Выход: Карта контекста — что используем, с чем интегрируемся.


ЭТАП 3: МНОГОСРЕЗОВЫЙ АНАЛИЗ

Применяем 8 срезов (из PLATFORM_MULTISLICE_ANALYSIS.md):

  1. 🏗️ СТРУКТУРНЫЙ — Из чего состоит?
    - Компоненты
    - Связи
    - Зависимости

  2. ФУНКЦИОНАЛЬНЫЙ — Что делает?
    - Основные функции
    - Входы/выходы
    - Потоки данных

  3. 🔄 ПРОЦЕССНЫЙ — Как работает?
    - Алгоритмы
    - Последовательности
    - Жизненный цикл

  4. 👥 РОЛЕВОЙ — Кто использует?
    - Пользователи
    - Права доступа
    - Ответственность

  5. 🔧 ТЕХНИЧЕСКИЙ — На чём построено?
    - Технологии
    - API
    - Паттерны

  6. 📊 ИНФОРМАЦИОННЫЙ — Какие данные?
    - Модель данных
    - Хранилища
    - Потоки

  7. ВРЕМЕННОЙ — Как развивается?
    - Версионирование
    - Roadmap
    - Deprecation

  8. 🌍 ПРОСТРАНСТВЕННЫЙ — Где находится?
    - Размещение
    - Топология
    - Масштабирование

Выход: Полное понимание через разные углы зрения.


ЭТАП 4: СПЕЦИФИКАЦИЯ

Создаём документ:

{component}/DESIGN.md

Содержит:
- Цель и назначение
- Анализ по 8 срезам
- API / интерфейсы
- Примеры использования
- Ограничения
- Альтернативы (почему выбрали это)

Выход: Полная спецификация компонента.


ЭТАП 5: ВАЛИДАЦИЯ

Проверяем через диалог:
- Задаём вопросы
- Ищем противоречия
- Проверяем полноту
- Уточняем детали

Участники: Человек (вы) + Claude (я)

Выход: Согласованная спецификация.


ЭТАП 6: УТВЕРЖДЕНИЕ

Фиксируем:
- Git commit с DESIGN.md
- Обновление system-journal.md
- Версия (0.1.0 → 1.0.0)
- Статус: Черновик → Утверждено

Выход: Готовая спецификация для реализации.


🔄 ПРИМЕНЕНИЕ К САМОЙ СЕБЕ

Теперь применим эту систему к самой системе проектирования!


📄 ПРОЕКТ: СИСТЕМА ПРОЕКТИРОВАНИЯ

ЭТАП 1: ОПРЕДЕЛЕНИЕ СУЩНОСТИ

Что проектируем?
Систему проектирования компонентов платформы ЦИФРА.

Зачем нужна?
- Унифицировать процесс проектирования
- Избежать хаотичной разработки
- Обеспечить полноту анализа
- Создать документацию автоматически

Какую проблему решает?
Без системы проектирования каждый компонент проектируется по-своему, теряется контекст, забываются важные аспекты.

Кто использует?
- Я (Claude) — при проектировании агентов/функций
- Вы (Human) — для контроля и уточнений
- Будущие разработчики — для понимания процесса


ЭТАП 2: КОНТЕКСТНЫЙ АНАЛИЗ

Что уже есть?
- ✅ 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)


ЭТАП 3: МНОГОСРЕЗОВЫЙ АНАЛИЗ

🏗️ СТРУКТУРНЫЙ

Компоненты системы проектирования:

Система проектирования
│
├─ Процесс (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

ЭТАП 4: СПЕЦИФИКАЦИЯ

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 готова к реализации

ЭТАП 5: ВАЛИДАЦИЯ (СЕЙЧАС!)

Вопросы к вам для валидации этой системы проектирования:

Блок 1: Процесс

Q1: Согласны ли вы с 6 этапами процесса проектирования?
- Определение → Контекст → Анализ → Спецификация → Валидация → Утверждение

Q2: Какие этапы нужно добавить / убрать / изменить?

Q3: Нужен ли этап "Прототипирование" перед спецификацией?
- Или сразу из спецификации в код?

Блок 2: Многосрезовый анализ

Q4: Нужно ли всегда использовать все 8 срезов?
- Или для простых компонентов можно меньше?

Q5: Какие срезы самые важные для агентов?
- Структурный, Функциональный, Технический — достаточно?

Блок 3: Диалог и валидация

Q6: Как лучше организовать валидацию?
- Вариант А: Я задаю вопросы блоками (по 5-10 вопросов)
- Вариант Б: Вопросы по ходу каждого этапа
- Вариант В: Сначала полный черновик, потом все вопросы

Q7: Что делать при разногласиях?
- Если я предлагаю одно решение, а вы другое — как решаем?

Блок 4: Формат документации

Q8: Формат DESIGN.md подходит?
- Markdown с 8 срезами + примеры?

Q9: Нужна ли отдельная VALIDATION_LOG.md?
- Чтобы видеть историю вопросов и ответов?

Блок 5: Применение

Q10: Начинаем проектировать DocumentAgent после утверждения этой системы?
- Или сначала ещё что-то нужно доработать?


ЭТАП 6: УТВЕРЖДЕНИЕ

Ожидает ответов на вопросы Q1-Q10

После валидации:
- Обновлю этот документ
- Версия: 0.1.0 → 1.0.0
- Статус: Черновик → Утверждено
- Git commit
- Запись в system-journal.md


📋 ШАБЛОНЫ

Шаблон DESIGN.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
Ожидает валидации