type: draft
domain: standards
status: draft
created: 2026-03-26
author: Claude (Архитектор)

Типология разработки в платформе

Любая разработка — это проект. Но тип объекта разработки определяет lifecycle, владельца и процесс.

Статус: черновик для обсуждения

Проблема

Сейчас в платформе нет чёткого разграничения между:
- разработкой знаний (стандарты, методология)
- разработкой систем управления (инструменты, процессоры)
- разработкой продуктов (фичи, сервисы)

Все три типа смешаны в architect/projects/ и обрабатываются одинаково.
Это неверно — у них разные lifecycle, риски и владельцы.

Три типа объектов разработки

1. ЗНАНИЯ (Knowledge)

Что производим: стандарты, методологию, теорию, паттерны, типологии.

Свойства:
- Медленно меняются (часть LOCKED навсегда)
- Изменение cascades DOWN — меняешь стандарт → нужно обновить всё что его использует
- Тестируются логикой и рецензией, не кодом
- Существуют как документы (.md)

Где живут: architect/theory/, architect/concept/, architect/standards/, architect/patterns/

Примеры системных проектов:
- naming-standard — стандарт именования файлов
- project-structure-standard — стандарт структуры папки

2. СИСТЕМЫ УПРАВЛЕНИЯ (Management Systems)

Что производим: инструменты, алгоритмы, процессоры, процессы, СУБД.

Свойства:
- Меняются умеренно (версионирование)
- Изменение локально — не cascades без явных зависимостей
- Тестируются в работе (работает/не работает)
- Существуют как код (.py, .sh) + документация

Где живут: system/, infra/, library/

Примеры системных проектов:
- project-processor — рекурсивный алгоритм исполнения
- custom-db — гибридный формат данных

3. ПРОДУКТЫ (Products)

Что производим: фичи, интерфейсы, интеграции, каталоги, сайты.

Свойства:
- Меняются часто (спринты, итерации)
- Изменение изолировано в проекте
- Тестируются функционально (user stories, тест-кейсы)
- Существуют как код + данные + деплой

Где живут: projects/org/

Примеры:
- pirotehnika — ERP + OZON интеграция
- lideravto — каталог запчастей на Drupal

Матрица характеристик

Характеристика	Знания	Системы	Продукты
Скорость изменений	Редко	Умеренно	Часто
Каскад изменений	DOWN (обязательно)	Явные зависимости	Изолированно
Тестирование	Логика + рецензия	Работа в проде	Функциональные тесты
Откат	Сложно (нарушает зависимости)	Версия назад	git revert
Владелец	Архитектор ▲	Архитектор ▲ + Оператор ●	Проектор ◆
Агент-исполнитель	Архитектор	Оператор + Кодер	Проектор + Кодер
Формат документа	`.md` (нормативный)	`.md` + `.py/.sh`	любой
Хранение	`architect/`	`system/`, `infra/`	`projects/org/`

Жизненный цикл каждого типа

Знания: Research → Draft → Review → Standard → LOCKED

[Research]     Исследовать область, собрать практику
    ↓
[Draft]        Написать черновик (_draft/)
    ↓
[Review]       Обсудить с оператором, проверить логику
    ↓
[Standard]     Зафиксировать в standards/ с версией
    ↓
[LOCKED]       Заморозить (только через RFC для изменений)

Особенность: нельзя менять стандарт без анализа каскада (что использует этот стандарт).

Системы управления: Concept → Spec → Build → Deploy → Operate

[Concept]      Описать что нужно (PROJECT.md)
    ↓
[Spec]         Написать спецификацию (.spec.yaml)
    ↓
[Build]        Разработать (Кодер)
    ↓
[Deploy]       Задеплоить (Оператор, L3)
    ↓
[Operate]      Мониторить, улучшать (v+1)

Особенность: версионирование обязательно — v1.0, v1.1, v2.0.

Продукты: Backlog → Sprint → Build → Release → Feedback

[Backlog]      Список фич и задач
    ↓
[Sprint]       Планирование итерации (ПМ 🔷)
    ↓
[Build]        Разработка (Кодер 💻)
    ↓
[Release]      Деплой на прод (Оператор ●, L3-L4)
    ↓
[Feedback]     Сбор метрик, следующий спринт

Системные проекты: разграничение внутри

Все системные проекты (architect/projects/) управляются одинаково (PROJECT.md, task.yaml, QUEUE.md). Но тип объекта влияет на процесс разработки внутри.

Предлагаемая структура

architect/projects/
├── knowledge/                    ← проекты разработки ЗНАНИЙ
│   ├── naming-standard/          ← разрабатываем стандарт
│   └── project-structure-standard/  ← разрабатываем стандарт
│
└── systems/                      ← проекты разработки СИСТЕМ
    ├── project-processor/        ← разрабатываем алгоритм-инструмент
    └── custom-db/                ← разрабатываем формат данных

Маркировка в PROJECT.md

# в frontmatter:
type: system-project
domain: standards     # ← knowledge
# или
domain: algorithms    # ← system
# или
domain: data          # ← system

Применение к агентам

Архитектор ▲

Работает с двумя типами:
- Знания → Research + Draft + Review + Standard
- Системы → Concept + Spec → передаёт Кодеру/Оператору

Архитектор НЕ пишет код систем — только концептуализирует и специфицирует.

Проектор ◆

Работает только с Продуктами:
- Backlog → Sprint → Build → Release
- Использует знания (читает стандарты) и системы (запускает processor)

Оператор ●

Работает с деплоем Систем:
- Deploy → Operate
- Принимает готовый код от Кодера, деплоит

Критерий разграничения: цель использования

Простой тест для любого объекта:

Какова цель?
    ├── ПРОЧИТАТЬ (человек или AI применяет) → ЗНАНИЕ
    │   Живёт в: architect/
    │
    └── ЗАПУСТИТЬ (система исполняет) → КОМПОНЕНТ ПЛАТФОРМЫ
        Живёт в: system/ library/ infra/

Примеры:

Объект	Цель	Тип
`naming-files.md`	Прочитать → применить при именовании	знание
`PROJECT_PROCESSOR_v8.md`	Прочитать → Claude следует алгоритму	знание
`business.ai.md`	Прочитать → Claude ведёт себя как специалист	знание
`system/monitor/`	Запустить → получить отчёт о здоровье	компонент
`system/scheduler/`	Запустить → выполнить задачу по расписанию	компонент
`library/connectors/telegram/`	Запустить → отправить сообщение	компонент

Карта компонентов платформы: кто владеет

Компоненты Архитектора ▲

Производит и владеет — инструменты управления самой платформой:

system/
├── agents/        ← AI-агенты (инструкции поведения)
├── core/          ← движок платформы (project-processor и пр.)
└── monitor/       ← мониторинг здоровья платформы

architect/
└── templates/     ← шаблоны для создания проектов

Компоненты Оператора ●

Производит и владеет — инфраструктура, деплой:

infra/
├── @proxy.service/     ← nginx, routing
├── @md-viewer.service/ ← docs.0kt.ru
└── @*.service/         ← все инфра-сервисы

system/
└── scheduler/          ← планировщик задач

Компоненты Проектора ◆

Производит — переиспользуемые строительные блоки (вырастают из проектов):

library/
├── connectors/    ← API коннекторы (ozon, telegram, ...)
│                     начинаются в projects/, вырастают в library/
└── services/      ← сервисы (session, file-share, ...)

Общие (используют все)

system/
├── elements/      ← атомы: email, http, file
└── components/    ← молекулы: scraper, generator

library/           ← всё что вышло из sandbox в stable

Путь компонента: проект → платформа

projects/org/{project}/data/connectors/  ← рождается здесь (sandbox)
    ↓ доказал ценность, переиспользуется
library/connectors/sandbox/              ← перемещается сюда
    ↓ стабилизировался, покрыт тестами
library/connectors/stable/               ← становится платформенным

Открытые вопросы

RFC процесс — нужен ли формальный процесс для изменения LOCKED стандартов? Сейчас: нет.
Нумерация папок — knowledge/ и systems/ внутри architect/projects/ или прямо в architect/?
Граница system/core vs library — где живёт project-processor как код? Сейчас: только как документ в system/agents/protocols/.

Следующие шаги

[ ] Обсудить и согласовать с оператором
[ ] Выбрать структуру для architect/projects/
[ ] Перенести этот документ в standards/ после согласования
[ ] Применить к ролям Архитектора и Проектора в CLAUDE.md