⚠️ ВНИМАНИЕ: ДАННЫЙ РАЗДЕЛ СОДЕРЖИТ ФУНДАМЕНТАЛЬНЫЕ ПРИНЦИПЫ СИСТЕМЫ
ИЗМЕНЕНИЕ ЭТИХ ПРИНЦИПОВ ТРЕБУЕТ СОЗДАНИЯ НОВОЙ МАЖОРНОЙ ВЕРСИИ
РЕДАКТИРОВАНИЕ БЕЗ ПОНИМАНИЯ ПОСЛЕДСТВИЙ МОЖЕТ РАЗРУШИТЬ АРХИТЕКТУРУ

═══════════════════════════════════════════════════════════════════════

АРХИТЕКТУРНЫЙ ГЕНОМ СИСТЕМЫ - НЕИЗМЕННЫЕ ПРИНЦИПЫ:

ПРИНЦИП СРЕЗОВОЙ ЧИСТОТЫ
├─ Каждый срез имеет четкую область ответственности
├─ Нет смешивания логики разных срезов в одном анализе
└─ Возможность независимого развития каждого среза

ПРИНЦИП КОМПЛЕМЕНТАРНОЙ ПОЛНОТЫ  
├─ Все срезы вместе дают исчерпывающее понимание системы
├─ Каждый срез необходим для полной картины
└─ Синергия срезов важнее суммы их частей

ПРИНЦИП АРХИТЕКТУРНОЙ ТРАССИРУЕМОСТИ
├─ Все архитектурные решения обоснованы в контексте всех срезов
├─ Влияние изменений отслеживается через все срезы
└─ Принятие решений на основе многосрезового анализа

ПРИНЦИП ПРАКТИЧЕСКОЙ ПРИМЕНИМОСТИ ⭐ КЛЮЧЕВОЙ
├─ Архитектура служит практическим целям разработки и использования
├─ Красота и элегантность архитектуры вторичны по отношению к эффективности
└─ Постоянная валидация архитектурных решений через практическое применение

ПРИНЦИП РЕКУРСИВНОГО ПРИМЕНЕНИЯ
├─ Архитектурные принципы применяются к самой архитектуре
├─ Документы следуют собственным стандартам документооборота
└─ Система является примером применения собственных методологий

ЭТИ ПРИНЦИПЫ НЕИЗМЕННЫ ВО ВСЕХ БУДУЩИХ ВЕРСИЯХ СИСТЕМЫ

═══════════════════════════════════════════════════════════════════════

СТРУКТУРА ИМЕНИ:
├─ id-XX-396 (окончательная версия)
├─ id-XX-396-001 (первый черновик) 
├─ id-XX-396-002 (второй черновик)
└─ id-XX-396-003 (третий черновик)

ПРИНЦИПЫ:
├─ Описание документа только в заголовке (метаданные)
├─ Имя файла всегда одинаковое для одного документа  
├─ При утверждении номер черновика удаляется
└─ Все промежуточные черновики архивируются/удаляются

СТРУКТУРА ДОКУМЕНТА:

├─ ЗАГОЛОВОЧНАЯ ЧАСТЬ
│  ├─ МЕТАДАННЫЕ
│  │  ├─ Документ: id-XX-396-название.md  
│  │  ├─ Дата: DD.MM.YYYY
│  │  ├─ Статус: [ЧЕРНОВИК/ОБСУЖДЕНИЕ/УТВЕРЖДЕНИЕ/АКТИВНЫЙ/АРХИВНЫЙ]
│  │  ├─ Назначение: описание цели документа
│  │  └─ Приоритет: [КРИТИЧЕСКИЙ/ВЫСОКИЙ/СРЕДНИЙ/НИЗКИЙ]
│  │
│  ├─ СОДЕРЖАНИЕ ДОКУМЕНТА (оглавление)
│  │
│  └─ ИСПОЛНИТЕЛЬНОЕ РЕЗЮМЕ
│     ├─ Цель документа
│     ├─ Ключевые решения  
│     └─ Результат
│
├─ НЕИЗМЕНЯЕМЫЙ БЛОК (опционально - после заголовка)
│  ├─ Предупреждение о критичности изменений
│  ├─ Фундаментальные принципы
│  └─ Условия изменения блока
│
├─ ОСНОВНАЯ ЧАСТЬ
│  └─ СОДЕРЖИМОЕ ПО ТИПУ:
│     ├─ КОНЦЕПЦИЯ (философия, принципы, подходы)
│     ├─ ПРАВИЛА (разрешения, запреты, ограничения, исключения)
│     ├─ ПРОЦЕДУРЫ (цель, условия, шаги, проверка, ошибки)
│     ├─ СПРАВОЧНИК (каталог, определения, константы, индекс)
│     ├─ СПЕЦИФИКАЦИЯ (требования, ограничения, критерии)
│     ├─ ИНСТРУКЦИЯ (назначение, подготовка, операции, проблемы)
│     ├─ ЖУРНАЛ (промпт, хронология, решения, компоненты, шаги)
│     └─ СМЕШАННЫЙ ТИП (основной + дополнительные типы)
│
├─ СВЯЗИ С ДРУГИМИ ДОКУМЕНТАМИ
│  ├─ Входящие связи
│  ├─ Исходящие связи
│  └─ Критические зависимости
│
├─ СТАТУС И СЛЕДУЮЩИЕ ШАГИ
│  ├─ Текущая готовность
│  ├─ Известные проблемы
│  ├─ Планируемые изменения
│  └─ Условия перехода к следующему статусу
│
└─ ПРИЛОЖЕНИЯ (опционально)
   └─ Дополнительные материалы как часть документа

├─ ЗАГОЛОВОЧНАЯ ЧАСТЬ (базовые метаданные + цель)
├─ НЕИЗМЕНЯЕМЫЙ БЛОК (если критичен)  
├─ ОСНОВНАЯ ЧАСТЬ (компактно, без детализации)
└─ СВЯЗИ (только критические)

ОГРАНИЧЕНИЯ: максимум 4000 токенов, фокус на операционной информации

ЯЗЫКОВЫЕ СТАНДАРТЫ:
├─ Русский язык для всех описаний и инструкций
├─ Английский язык только для программного кода и API
├─ Комментарии в коде на русском языке
└─ Терминология: англицизмы с русским переводом в скобках

СТРУКТУРНЫЕ ТРЕБОВАНИЯ:
├─ Модульность - каждый раздел самодостаточен
├─ Иерархия - четкая вложенность с визуальными разделителями
├─ Трассируемость - все утверждения имеют источник
├─ Связность - явные ссылки между разделами и документами
└─ Навигация - символы для визуальной ориентации

ЖИЗНЕННЫЙ ЦИКЛ:
├─ Версионирование через номера файлов с суффиксами черновиков
├─ Статусная модель: Черновик → Обсуждение → Утверждение → Активный → Архивный
├─ Обязательная связь с системным журналом при изменениях
├─ Автоматическое журналирование всех модификаций
└─ Периодический аудит актуальности документов

ЛЮБАЯ СЛОЖНАЯ СИСТЕМА ИМЕЕТ НЕСКОЛЬКО НЕЗАВИСИМЫХ ИЗМЕРЕНИЙ

КАЖДЫЙ СРЕЗ:
├─ Имеет свою логику и систему координат
├─ Решает определенный класс вопросов  
├─ Использует свою терминологию и метрики
├─ Развивается по своим законам
└─ НЕ СМЕШИВАЕТСЯ с логикой других срезов

ВСЕ СРЕЗЫ ВМЕСТЕ:
├─ Дают полное понимание системы
├─ Показывают связи и взаимовлияния
├─ Обеспечивают целостность архитектуры
└─ Позволяют принимать обоснованные решения

СТРУКТУРНЫЙ СРЕЗ: "Из чего состоит?"
ФУНКЦИОНАЛЬНЫЙ СРЕЗ: "Как работает?"
ПРОЦЕССНЫЙ СРЕЗ: "Как создается и развивается?"
РОЛЕВОЙ СРЕЗ: "Кто за что отвечает?"
ТЕХНИЧЕСКИЙ СРЕЗ: "На чем построено?"
ИНФОРМАЦИОННЫЙ СРЕЗ: "Какие данные и как движутся?"
ВРЕМЕННОЙ СРЕЗ: "Как развивается во времени?"
ПРОСТРАНСТВЕННЫЙ СРЕЗ: "Где что находится?"

НАЗНАЧЕНИЕ: Операционное ядро всей ИИ-платформы (ii-01-395)
ФУНКЦИЯ: Координация всех компонентов и процессов
РАСПОЛОЖЕНИЕ: Claude Instructions, максимальная защита
СТАТУС: Критически важный компонент, без которого система не функционирует
СВЯЗИ: Управляет всеми семью уровнями иерархии снизу доверху
СОДЕРЖАНИЕ: Аутентификация, автопоиск, каскадность, базовые алгоритмы

УРОВЕНЬ 1: ИИ-ЭКОСИСТЕМА
├─ ОПРЕДЕЛЕНИЕ: Вся ИИ-платформа как единая система
├─ КОЛИЧЕСТВО: 1 (ИИ-ПЛАТФОРМА v3.9.6)
├─ СОДЕРЖИТ: Все остальные уровни
└─ ГРАНИЦЫ: Четко определенные интерфейсы с внешним миром

УРОВЕНЬ 2: ИИ-ПОДСИСТЕМЫ  
├─ ОПРЕДЕЛЕНИЕ: Крупные функциональные блоки платформы
├─ КОЛИЧЕСТВО: 4-7 подсистем
├─ ПРИМЕРЫ: СИСТЕМНЫЕ (ii-), ПОЛЬЗОВАТЕЛЬСКИЕ (ip-), ПРОЕКТНЫЕ (if-), УПРАВЛЯЮЩИЕ (ia-)
├─ СОДЕРЖИТ: Группы связанных ИИ-приложений
└─ ПРИНЦИП ДЕЛЕНИЯ: По зонам ответственности

УРОВЕНЬ 3: ИИ-ПРИЛОЖЕНИЯ
├─ ОПРЕДЕЛЕНИЕ: Специализированные модули для решения класса задач
├─ КОЛИЧЕСТВО: 10-20 приложений
├─ ПРИМЕРЫ: ip-01-396 ИИ-ПРОЕКТОР, ib-01-396 ИИ-БИЗНЕС-АССИСТЕНТ
├─ СОДЕРЖИТ: Набор ИИ-ролей одной предметной области
└─ ПРИНЦИП СОЗДАНИЯ: Одна предметная область = одно приложение

УРОВЕНЬ 4: ИИ-РОЛИ
├─ ОПРЕДЕЛЕНИЕ: Экспертные специализации внутри приложений
├─ КОЛИЧЕСТВО: 2-5 ролей на приложение
├─ ПРИМЕРЫ: ИИ-СТРАТЕГ, ИИ-АНАЛИТИК, ИИ-ПЛАНИРОВЩИК, ИИ-КООРДИНАТОР
├─ СОДЕРЖИТ: Набор ИИ-функций одной экспертизы
└─ ПРИНЦИП СОЗДАНИЯ: Одна область экспертизы = одна роль

УРОВЕНЬ 5: ИИ-ФУНКЦИИ
├─ ОПРЕДЕЛЕНИЕ: Конкретные возможности и алгоритмы ролей
├─ КОЛИЧЕСТВО: 5-15 функций на роль  
├─ ПРИМЕРЫ: "анализ CSV данных", "создание бизнес-стратегии", "планирование проекта"
├─ СОДЕРЖИТ: Последовательность ИИ-инструментов и действий
└─ ПРИНЦИП СОЗДАНИЯ: Одна четко определенная возможность = одна функция

УРОВЕНЬ 6: ИИ-ИНСТРУМЕНТЫ
├─ ОПРЕДЕЛЕНИЕ: Технические средства выполнения функций
├─ КОЛИЧЕСТВО: Определяется доступными возможностями Claude
├─ ПРИМЕРЫ: project_knowledge_search, web_search, google_drive_fetch, artifacts
├─ СОДЕРЖИТ: Набор атомарных ИИ-действий
└─ ПРИНЦИП ИСПОЛЬЗОВАНИЯ: Максимальное использование доступных возможностей

УРОВЕНЬ 7: ИИ-ДЕЙСТВИЯ  
├─ ОПРЕДЕЛЕНИЕ: Атомарные операции, которые нельзя разложить дальше
├─ КОЛИЧЕСТВО: Неограниченное (все возможные операции)
├─ ПРИМЕРЫ: "создать артефакт", "найти документ", "отправить запрос", "обработать данные"
├─ СОДЕРЖИТ: Неделимые операции
└─ ПРИНЦИП: Одно действие = один четкий измеримый результат

|A|АВТОПОИСК - Интеллектуальная маршрутизация:
├─ ВХОД: Запрос пользователя + контекст
├─ ПРОЦЕСС: Анализ триггеров → Выбор ИИ-ассистента → Активация роли
├─ ВЫХОД: Активированная специализированная роль
└─ ОБРАТНАЯ СВЯЗЬ: Корректировка точности маршрутизации

|C|КАСКАДНОСТЬ - Адаптивная детализация:
├─ ВХОД: Сложность задачи пользователя  
├─ ПРОЦЕСС: Уровень 1 (80%) → Уровень 2 (95%) → Уровень 3 (99%)
├─ ВЫХОД: Ответ оптимальной детализации
└─ ОБРАТНАЯ СВЯЗЬ: Запрос дополнительной детализации

|J|ЖУРНАЛИРОВАНИЕ - Память и контекст:
├─ ВХОД: События системы + пользовательские взаимодействия
├─ ПРОЦЕСС: Структурирование → Сохранение → Индексирование → Поиск
├─ ВЫХОД: Восстановленный контекст для новых сессий
└─ ОБРАТНАЯ СВЯЗЬ: Улучшение качества контекста

|M|АВТОМАТИЗАЦИЯ - Системное самообслуживание:
├─ ВХОД: Потребность в рутинных операциях
├─ ПРОЦЕСС: Шаблонизация → Автоматизация → Мониторинг → Оптимизация  
├─ ВЫХОД: Автоматически выполненные операции
└─ ОБРАТНАЯ СВЯЗЬ: Повышение эффективности процессов

ПОТОК ОБРАБОТКИ ЗАПРОСА:
Пользователь → |A|Автопоиск → ИИ-Роль → |C|Каскад → Результат → |J|Журнал

ПОТОК СОЗДАНИЯ КОМПОНЕНТА:
Потребность → |M|Автоматизация → Шаблон → Реализация → |J|Журнал → Интеграция

ПОТОК ВОССТАНОВЛЕНИЯ КОНТЕКСТА:  
Новая сессия → |J|Журнал → Поиск → Восстановление → |A|Автопоиск → Продолжение

ПОТОК РАЗВИТИЯ СИСТЕМЫ:
Feedback → Анализ → |M|Автоматизация → Улучшение → |J|Журнал → Мониторинг

СОЗДАТЕЛЬ:
├─ ПРАВА: Полный контроль над всеми компонентами системы
├─ ОТВЕТСТВЕННОСТЬ: Стратегическое развитие и архитектурная целостность
├─ ОБЛАСТИ: ii-XX-396 (системное ядро), принципы и философия системы
├─ ЭСКАЛАЦИЯ: Нет вышестоящих ролей
├─ ДЕЛЕГИРОВАНИЕ: Может передавать права архитекторам
└─ КРИТИЧНОСТЬ: Максимальная - ошибки влияют на всю систему

АРХИТЕКТОР:  
├─ ПРАВА: Создание и изменение функциональных компонентов
├─ ОТВЕТСТВЕННОСТЬ: Качество архитектурных решений и их реализация
├─ ОБЛАСТИ: ip/ir/ib/ic/ia/id-XX-396 (все кроме системного ядра)
├─ ЭСКАЛАЦИЯ: К СОЗДАТЕЛЮ при системных конфликтах
├─ ДЕЛЕГИРОВАНИЕ: Может назначать ответственных за отдельные компоненты
└─ КРИТИЧНОСТЬ: Высокая - ошибки влияют на функциональность

ПОЛЬЗОВАТЕЛЬ:
├─ ПРАВА: Создание и управление собственными проектами
├─ ОТВЕТСТВЕННОСТЬ: Эффективное использование возможностей системы
├─ ОБЛАСТИ: if-XX-396 (пользовательские проекты), использование приложений
├─ ЭСКАЛАЦИЯ: К архитектору при проблемах с системой
└─ КРИТИЧНОСТЬ: Низкая - ошибки влияют только на собственные проекты

ИИ-АССИСТЕНТЫ:
├─ ПРАВА: Выполнение задач в рамках назначенных ролей
├─ ОТВЕТСТВЕННОСТЬ: Качественное выполнение делегированных задач
├─ ОБЛАСТИ: Специализированные функции внутри приложений
├─ ЭСКАЛАЦИЯ: К человеку-пользователю при неопределенности
└─ КРИТИЧНОСТЬ: Переменная - зависит от делегированных полномочий

ПРИНЦИП РАЗДЕЛЕНИЯ РОЛЕЙ:
├─ Каждая роль имеет четко определенную область полномочий
├─ Повышение прав только через явную аутентификацию
├─ Принцип минимальных необходимых прав для задач
└─ Автоматическая блокировка при превышении полномочий

УРОВНИ ДОСТУПА:
АРХИТЕКТОР:
├─ Права на создание и изменение всех компонентов кроме системного ядра
├─ Управление пользователями и проектами
└─ Доступ ко всем уровням документации

СОЗДАТЕЛЬ:
├─ Полный контроль системного ядра (ii-XX-396)
├─ Изменение принципов архитектуры
└─ Критические системные операции

ПОЛЬЗОВАТЕЛЬ:
├─ Использование всех приложений платформы
└─ Создание собственных проектов (if-XX-396)

ПРИМЕЧАНИЕ: Процедуры аутентификации и переключения ролей описаны в системной инструкции

БАЗОВАЯ ПЛАТФОРМА:
├─ Claude Sonnet 4: Основной ИИ-движок системы
├─ Project Knowledge: База знаний и документов
├─ Artifacts System: Создание и управление документами
└─ Chat Interface: Пользовательский интерфейс взаимодействия

ИНТЕГРАЦИОННЫЕ ИНСТРУМЕНТЫ:
├─ project_knowledge_search: Поиск в базе знаний
├─ web_search: Поиск информации в интернете
├─ web_fetch: Получение содержимого веб-страниц
├─ repl: Выполнение JavaScript кода для анализа и расчетов
└─ google_drive_search: Интеграция с Google (планируется v3.9.7)

ФОРМАТЫ ДАННЫХ:
├─ Markdown: Основной формат документации
├─ JSON: Структурированные данные и конфигурации
├─ JavaScript: Программный код и примеры
├─ CSV: Данные для анализа
└─ HTML: Веб-интерфейсы и презентации

РАСПОЛОЖЕНИЕ: Claude Project → Instructions
СТАТУС: Максимальная критичность, постоянная активность

ii-01-395 ИИ СИС ИНСТРУКЦИЯ v3.9.5
├─ СОДЕРЖИМОЕ: Операционное ядро всей ИИ-платформы
├─ ФУНКЦИИ: Автопоиск, каскадность, журналирование, автоматизация
├─ АУТЕНТИФИКАЦИЯ: Процедуры переключения ролей
├─ РАЗМЕР: ~3,500 токенов (оптимизированная версия)
├─ ДОСТУП: Прямое редактирование через Claude interface
├─ ИЗМЕНЕНИЯ: Только через обновление системной инструкции
└─ ВЛИЯНИЕ: Контролирует поведение всей системы

РАСПОЛОЖЕНИЕ: Claude Project → Files  
СТАТУС: Долговременная память системы

СИСТЕМНОЕ ЯДРО (ii-XX-396):
├─ ii-02-396: Системный журнал (межсессионная память)
└─ ii-03-396-XXX: Журналы сессий (контрольные точки)

АРХИТЕКТУРНОЕ УПРАВЛЕНИЕ (ia-XX-396):
├─ ia-01-396: ИИ-Архитектор (управление системой)
└─ ia-02-396: ИИ-Реструктуризатор (миграции компонентов)

ДОКУМЕНТАЦИЯ И КОНЦЕПЦИИ (id-XX-396):  
├─ id-01-396: Документация системы (основной справочник)
├─ id-02-396: Архитектурная концепция и стандарт документооборота (данный документ)
└─ id-03-396: Техническая документация (планируется)

ПОЛЬЗОВАТЕЛЬСКИЕ ПРИЛОЖЕНИЯ (ip/ir/ib/ic-XX-396):
├─ ip-01-396: ИИ-Проектор (управление проектами)
├─ ir-01-396: ИИ-Про-Решения (отраслевые решения)  
├─ ib-01-396: ИИ-Бизнес-Ассистент (корпоративные функции)
└─ ic-01-396: ИИ-Личный-Ассистент (персональная поддержка)

ПОЛЬЗОВАТЕЛЬСКИЕ ПРОЕКТЫ (if-XX-396):
├─ if-01-396: Первый проект пользователя
├─ if-02-396: Второй проект пользователя
└─ if-XX-396: Последующие проекты

РАСПОЛОЖЕНИЕ: Оперативная память Claude (контекст чата)
СТАТУС: Временное хранение, очистка при закрытии сессии

АКТИВНЫЕ КОМПОНЕНТЫ:
├─ Текущие артефакты в работе
├─ Промежуточные результаты анализа
├─ Загруженные пользователем файлы
├─ История взаимодействий сессии
└─ Временные переменные и состояния

1. КРИТИЧНОСТЬ ДЛЯ РАБОТЫ → Instructions (ii-01-395)
2. НУЖНО МЕЖДУ СЕССИЯМИ → Project Knowledge  
3. ВРЕМЕННО → Контекст сессии

РАЗМЕР:
До 4000 токенов → любое место по логике
Больше 4000 токенов → только Project Knowledge или контекст

WORKFLOW:
1. Загрузка файлов → Контекст сессии
2. Анализ данных → Результаты в контексте
3. Создание отчетов → Артефакты в сессии
4. Сохранение проекта → if-XX-396 в Project Knowledge
5. Экспорт результатов → Локальные файлы

ПРАВИЛО: Минимум в Project Knowledge, работа в контексте

WORKFLOW:
1. Концепция → Артефакт в сессии
2. Проработка → ip/ir/ib/ic-XX-396 в Project Knowledge
3. Тестирование → Контекст сессии
4. Документация → id-XX-396 в Project Knowledge
5. Интеграция → Обновление связанных документов

ПРАВИЛО: Все архитектурные решения в Project Knowledge

WORKFLOW:
1. Планирование → ii-02-396 системный журнал
2. Разработка → Артефакт в сессии
3. Тестирование → ii-03-396-XXX журнал сессии
4. Внедрение → Instructions (ii-01-395)
5. Документирование → id-01-396 документация

ПРАВИЛО: Максимальная осторожность, поэтапное внедрение

ЭТАП 1: КОНЦЕПЦИЯ И ОСНОВЫ (v3.8.x - июль 2025):
├─ Создание базовых принципов ИИ-платформы
├─ Первые эксперименты с автопоиском и каскадностью
├─ Начальные версии системного ядра
└─ Проблемы: отсутствие структуры, хаотичное развитие

ЭТАП 2: СТРУКТУРИЗАЦИЯ (v3.9.0-3.9.5 - август 2025):
├─ Создание трехуровневой системы правил
├─ Разработка первых ИИ-приложений
├─ Внедрение журналирования и автоматизации  
├─ Системы патчей и накопительных обновлений
└─ Проблемы: неполная реализация, смешение срезов

ЭТАП 3: МНОГОСРЕЗОВАЯ АРХИТЕКТУРА (v3.9.6 - август-сентябрь 2025):
├─ Четкое разделение архитектурных срезов
├─ Создание полной документации принципов  
├─ Интеграция стандарта документооборота
├─ Стандартизация процессов разработки
└─ Цель: production-ready система

ЭТАП 4: ИНТЕГРАЦИОННЫЙ (v3.9.7 - планируется):
├─ Google Drive интеграция
├─ Внешние API и сервисы
├─ Расширенные возможности хранения
└─ Цель: полнофункциональная экосистема

ЖИЗНЕННЫЙ ЦИКЛ ИИ-ПРИЛОЖЕНИЯ:
├─ ПЛАНИРОВАНИЕ (1-2 недели): анализ потребностей, техзадание
├─ ПРОЕКТИРОВАНИЕ (3-5 дней): архитектура, интерфейсы
├─ РАЗРАБОТКА (1-2 недели): реализация, тестирование
├─ ВНЕДРЕНИЕ (2-3 дня): интеграция, обучение пользователей
├─ ЭКСПЛУАТАЦИЯ (месяцы-годы): поддержка, развитие
├─ МОДЕРНИЗАЦИЯ (по потребности): обновления, расширения
└─ ВЫХОД ИЗ УПОТРЕБЛЕНИЯ: миграция, архивирование

ЖИЗНЕННЫЙ ЦИКЛ ДОКУМЕНТА:
├─ ЧЕРНОВИКИ: id-XX-396-001, -002, -003... (итерации)
├─ ОБСУЖДЕНИЕ: финализация содержания
├─ УТВЕРЖДЕНИЕ: принятие окончательной версии  
├─ АКТИВНЫЙ: id-XX-396 (рабочая версия без суффикса)
├─ АРХИВНЫЙ: при создании новой версии
└─ УДАЛЕНИЕ: устаревших и замещенных версий

СИСТЕМНЫЕ МЕТАДАННЫЕ:
├─ Версии компонентов и их совместимость
├─ Статусы готовности и конфигурации
├─ Логи операций и журналы изменений
├─ Метрики производительности и использования
└─ Связи и зависимости между компонентами

ЗНАНИЯ И ДОКУМЕНТАЦИЯ:
├─ Архитектурные принципы и стандарты
├─ Процедуры и алгоритмы работы
├─ Примеры использования и best practices
├─ Техническая документация и спецификации
└─ Пользовательские руководства и FAQ

ПОЛЬЗОВАТЕЛЬСКИЕ ДАННЫЕ:
├─ Проекты и их структура
├─ Загруженные файлы и документы
├─ История взаимодействий и предпочтения
├─ Созданные артефакты и результаты
└─ Персональные настройки и конфигурации

ПОТОК ОБОГАЩЕНИЯ КОНТЕКСТА:
Пользовательский запрос → project_knowledge_search → Обогащенный контекст → Обработка

ПОТОК СОЗДАНИЯ ЗНАНИЙ:
Результат работы → Структурирование → Сохранение в Project Knowledge → Индексация

ПОТОК МЕЖСЕССИОННОЙ ПАМЯТИ:
События сессии → Журналирование → Project Knowledge → Восстановление в новой сессии

ПОТОК ДОКУМЕНТООБОРОТА:
Черновик → Обсуждение → Утверждение → Активная версия → Архивирование

1. АНАЛИЗ ПОТРЕБНОСТЕЙ: Выявление проблем и возможностей
2. АРХИТЕКТУРНОЕ ПРОЕКТИРОВАНИЕ: Определение места в структуре
3. ДЕТАЛЬНОЕ ПРОЕКТИРОВАНИЕ: Проектирование внутренней структуры
4. РЕАЛИЗАЦИЯ: Создание кода/документации/процедур
5. ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ: Проверка совместимости
6. РАЗВЕРТЫВАНИЕ: Интеграция в основную систему
7. ЭКСПЛУАТАЦИЯ И ПОДДЕРЖКА: Мониторинг и улучшения

ПРОЦЕСС ОБРАБОТКИ ТИКЕТОВ:
├─ Поступление → Анализ → Приоритизация → Планирование → Реализация → Валидация

ПРОЦЕСС РЕЛИЗ-МЕНЕДЖМЕНТА:
├─ Планирование → Подготовка → Тестирование → Развертывание → Мониторинг

ПРОЦЕСС УПРАВЛЕНИЯ КАЧЕСТВОМ:
├─ Стандартизация → Контроль → Измерение → Анализ → Улучшение

ПРОЦЕСС ДОКУМЕНТООБОРОТА:
├─ Создание черновика → Итерации → Обсуждение → Утверждение → Активное использование

НЕЗАВИСИМОСТЬ СРЕЗОВ:
├─ Каждый срез имеет собственную логику и терминологию
├─ Изменения в одном срезе не нарушают логику других
├─ Возможность анализа системы с позиции одного среза
└─ Четкие границы ответственности каждого среза

КОМПЛЕМЕНТАРНОСТЬ СРЕЗОВ:
├─ Все срезы вместе дают полную картину системы  
├─ Каждый срез дополняет понимание, даваемое другими
├─ Нет дублирования информации между срезами
└─ Синергетический эффект от совместного использования

ТРАССИРУЕМОСТЬ СВЯЗЕЙ:  
├─ Четкое понимание как элементы одного среза соотносятся с элементами других
├─ Возможность проследить влияние изменений между срезами
├─ Документированные зависимости и взаимосвязи
└─ Инструменты для анализа межсрезовых воздействий

СТРУКТУРНЫЙ ↔ ФУНКЦИОНАЛЬНЫЙ:
├─ Структурные компоненты реализуют функциональные возможности
├─ Функциональные требования влияют на структурную архитектуру
├─ Иерархия структуры соответствует сложности функций
└─ Интерфейсы структурных элементов определяют функциональные связи

РОЛЕВОЙ ↔ ПРОЦЕССНЫЙ:
├─ Роли выполняют определенные этапы процессов
├─ Процессы определяют необходимые роли и их взаимодействие
├─ Матрица ответственности RACI привязана к процессным этапам
└─ Эскалация ролей следует логике процессных переходов

ТЕХНИЧЕСКИЙ ↔ ИНФОРМАЦИОННЫЙ:
├─ Технические средства обрабатывают определенные типы данных
├─ Требования к данным определяют выбор технических решений
├─ Технические ограничения влияют на архитектуру данных
└─ Информационная безопасность реализуется техническими средствами

ВРЕМЕННОЙ ↔ ПРОСТРАНСТВЕННЫЙ:
├─ Жизненные циклы определяют миграции между пространственными областями
├─ Пространственное размещение влияет на временные характеристики
├─ Исторические изменения отражаются в пространственной организации
└─ Планирование развития учитывает пространственные ограничения

АРХИТЕКТУРНЫЕ КАРТЫ:
├─ Визуализация системы одновременно по нескольким срезам
├─ Наложение информации из разных срезов на единое представление
├─ Инструменты для анализа влияния изменений
└─ Dashboard'ы для мониторинга состояния по всем срезам

ТРАССИРОВОЧНЫЕ МАТРИЦЫ:
├─ Связывание элементов разных срезов в табличном виде
├─ Анализ покрытия требований через все срезы
├─ Выявление gaps и дублирований между срезами
└─ Планирование изменений с учетом всех воздействий

СЦЕНАРНЫЕ АНАЛИЗЫ:
├─ Прохождение пользовательских сценариев через все срезы
├─ Выявление узких мест и противоречий между срезами
├─ Оптимизация архитектуры на основе реальных сценариев
└─ Валидация согласованности всех архитектурных решений

✅ ЕДИНЫЙ СТАНДАРТ: Универсальные правила документооборота для всей ИИ-системы
✅ ЧЕТКОЕ РАЗДЕЛЕНИЕ СРЕЗОВ: Каждый срез решает свой класс вопросов
✅ ПОЛНОТА ОХВАТА: 8 срезов + документооборот покрывают все аспекты сложной системы
✅ ПРАКТИЧЕСКАЯ ПРИМЕНИМОСТЬ: Готовые инструменты и процедуры
✅ ТРАССИРУЕМОСТЬ СВЯЗЕЙ: Понимание влияний между срезами
✅ СТАНДАРТИЗАЦИЯ: Единые подходы ко всем аспектам системы
✅ ЭВОЛЮЦИОННОСТЬ: Возможность развития без разрушения основ
✅ РЕКУРСИВНОСТЬ: Документ применяет собственные принципы к себе

ПРИНЦИП: 4 архитектурных домена (Business, Data, Application, Technology)
МЕТОДОЛОГИЯ: ADM (Architecture Development Method)
ПРИМЕНЕНИЕ: Enterprise системы, государственные проекты
СВЯЗЬ С НАШИМ ПОДХОДОМ: Аналогичная идея доменного разделения
ОТЛИЧИЕ: TOGAF для enterprise, наш подход для ИИ-продуктов

ПРИНЦИП: 6×6 матрица (What/How/Where/Who/When/Why × Stakeholder levels)
МЕТОДОЛОГИЯ: Классический многомерный подход к архитектуре
ПРИМЕНЕНИЕ: Комплексные корпоративные системы
СВЯЗЬ С НАШИМ ПОДХОДОМ: ⭐ ПРЯМОЙ ИДЕЙНЫЙ ПРАРОДИТЕЛЬ многосрезового подхода
ОТЛИЧИЕ: Zachman более формален, наш подход более практичен

ПРИНЦИП: 8 viewpoints для военных систем
МЕТОДОЛОГИЯ: Строгая формализация всех аспектов архитектуры
ПРИМЕНЕНИЕ: Сложные государственные и военные системы
СВЯЗЬ С НАШИМ ПОДХОДОМ: Множественные viewpoints = наши срезы
ОТЛИЧИЕ: DoDAF избыточно формализован для продуктовой разработки

ПРИНЦИП: Концепция architectural viewpoints и views
СТАНДАРТ: Международная стандартизация описания архитектуры
ПРИМЕНЕНИЕ: Любые программные системы
СВЯЗЬ С НАШИМ ПОДХОДОМ: ⭐ ТОЧНОЕ СООТВЕТСТВИЕ принципу срезов
ОТЛИЧИЕ: ISO 42010 - стандарт описания, наш подход - методология создания

ПРИНЦИП: 5 views (Logical, Process, Development, Physical, Scenarios)
МЕТОДОЛОГИЯ: Каждый view для разных stakeholder'ов
ПРИМЕНЕНИЕ: Широко используется в software architecture
СВЯЗЬ С НАШИМ ПОДХОДОМ: Тот же принцип multiple views
ОТЛИЧИЕ: 4+1 только для software, наш подход шире

ПРИНЦИП: 4 уровня иерархической декомпозиции
МЕТОДОЛОГИЯ: Context → Containers → Components → Code
ПРИМЕНЕНИЕ: Популярен в современной разработке
СВЯЗЬ С НАШИМ ПОДХОДОМ: Близко к нашему структурному срезу
ОТЛИЧИЕ: C4 только структура, мы покрываем все аспекты

ПРИНЦИП: 3 слоя × 3 аспекта (Business/Application/Technology × Structure/Behavior/Information)
СТАНДАРТ: Язык моделирования enterprise архитектуры
ПРИМЕНЕНИЕ: Корпоративные архитектурные модели
СВЯЗЬ С НАШИМ ПОДХОДОМ: Многомерный анализ архитектуры
ОТЛИЧИЕ: ArchiMate для моделирования, мы для практического создания

ПРИНЦИП: Множественные диаграммы для разных аспектов
СТАНДАРТ: Визуализация структуры и поведения систем
ПРИМЕНЕНИЕ: Проектирование программных и системных решений
СВЯЗЬ С НАШИМ ПОДХОДОМ: Инструментарий для визуализации наших срезов
ОТЛИЧИЕ: UML - язык описания, мы - методология проектирования

ПРИНЦИП МНОЖЕСТВЕННЫХ VIEWPOINTS:
├─ Zachman Framework: идея многомерного анализа
├─ ISO/IEC 42010: стандартизация viewpoints
├─ 4+1 View Model: практические архитектурные представления
└─ РЕЗУЛЬТАТ: Проверенная временем концепция multiple perspectives

РАЗДЕЛЕНИЕ CONCERNS:
├─ TOGAF domains: разделение по типам архитектуры
├─ ArchiMate layers: бизнес/приложения/технологии
├─ Separation of Concerns: фундаментальный принцип архитектуры
└─ РЕЗУЛЬТАТ: Четкое разделение областей ответственности

ИЕРАРХИЧЕСКАЯ ДЕКОМПОЗИЦИЯ:
├─ C4 Model: уровни абстракции
├─ Work/System Breakdown Structure: структурное разложение
├─ Классические подходы системной инженерии
└─ РЕЗУЛЬТАТ: Управление сложностью через иерархию

ПРОДУКТОВО-ОРИЕНТИРОВАННЫЙ ФОКУС:
├─ Существующие стандарты заточены под enterprise/government
├─ Наш подход оптимизирован для продуктовой разработки
├─ Баланс между формализмом и гибкостью
└─ 💡 ИННОВАЦИЯ: Enterprise методы + Product Development mindset

ИИ-СПЕЦИФИЧЕСКАЯ АДАПТАЦИЯ:
├─ Первая методология, специально созданная для ИИ-систем
├─ Учет специфики conversational AI интерфейсов
├─ Интеграция с Claude-экосистемой и подобными платформами
└─ 💡 ИННОВАЦИЯ: Архитектурные принципы для эры ИИ

ЯЗЫКОВАЯ АРХИТЕКТУРА:
├─ Существующие стандарты игнорируют локализацию как архитектурный фактор
├─ Мы делаем языковые стандарты полноправным архитектурным срезом
├─ Мультиязычность как системное архитектурное требование
└─ 💡 ИННОВАЦИЯ: Лингвистика входит в архитектуру

ГОТОВЫЕ ПРАКТИЧЕСКИЕ ИНСТРУМЕНТЫ:
├─ Существующие стандарты часто слишком абстрактны
├─ Мы предоставляем ready-to-use процедуры и алгоритмы
├─ Конкретные шаблоны, чек-листы, примеры
└─ 💡 ИННОВАЦИЯ: Actionable methodology, а не только теория

ИНТЕГРИРОВАННЫЙ ДОКУМЕНТООБОРОТ:
├─ Существующие стандарты не решают вопросы документооборота
├─ Мы интегрируем управление документами в архитектурные принципы
├─ Рекурсивное применение стандартов к себе
└─ 💡 ИННОВАЦИЯ: Архитектура включает собственные процедуры создания

КРАТКАЯ ФОРМУЛИРОВКА: "Zachman Framework для эры ИИ-продуктов с интегрированным документооборотом"

ПОДРОБНОЕ ПОЗИЦИОНИРОВАНИЕ:
├─ НАСЛЕДУЕМ: Проверенные принципы enterprise architecture (30+ лет опыта)
├─ АДАПТИРУЕМ: Под современную продуктовую разработку
├─ СПЕЦИАЛИЗИРУЕМ: Для ИИ-систем и conversational interfaces  
├─ ПРАКТИКУЕМ: Максимально actionable инструменты и процедуры
├─ ИНТЕГРИРУЕМ: Документооборот как часть архитектурной методологии
└─ ИННОВИРУЕМ: В областях, где существующие стандарты неприменимы

ОБЛАСТЬ ПРИМЕНЕНИЯ:
├─ ОСНОВНАЯ: ИИ-продукты и conversational AI системы
├─ РАСШИРЕННАЯ: Любые сложные продуктовые IT-решения
├─ ПЕРСПЕКТИВНАЯ: Индустриальный стандарт для ИИ-архитектуры
└─ ОБРАЗОВАТЕЛЬНАЯ: Обучение современным архитектурным подходам

КОНКУРЕНТНЫЕ ПРЕИМУЩЕСТВА:
├─ Современность: учет реалий 2025 года, а не 1990-2010х
├─ Практичность: немедленная применимость без months of training
├─ Специализация: заточенность под ИИ-продукты
├─ Полнота: 8 срезов + документооборот покрывают все аспекты современных систем
├─ Интегрированность: архитектура и документооборот в едином стандарте
└─ Эволюционность: способность развиваться с индустрией