architect/standards/arch-intake-operation.md

type: standard
layer: arch
object: intake
aspect: operation
form: text
title: "Операция РАЗБОР"
status: active
version: 1.0.0
date: 2026-04-11
knowledge_level: У1
parent: arch-document-system.md
deps:
- arch-document-system.md
- arch-project-structure.md
- arch-project-lifecycle.md
- arch-document-format.md


Операция РАЗБОР

Стандарт описывает операцию РАЗБОР — анализ входящих данных (файлов, описаний, ссылок) и автоматическое создание первичных документов проекта. РАЗБОР — отдельная операция, не привязанная к конкретной фазе жизненного цикла. Может запускаться в любой момент.


1. НАЗНАЧЕНИЕ

РАЗБОР решает задачу: превратить сырые входные данные в структурированные документы платформы.

Без РАЗБОРА: оператор вручную заполняет десятки полей.
С РАЗБОРОМ: AI анализирует источники → заполняет шаблоны → предлагает список исследований.

Триггеры

Сигнал оператора Что делать
"разбери [файл/ссылку/описание]" РАЗБОР в существующем проекте
"создай проект + [файлы/описание]" РАЗБОР + создание проекта
"что тут есть?" про набор файлов РАЗБОР без создания документов
Явное "запусти разбор" Полный протокол РАЗБОР

2. ИСТОЧНИКИ

Что принимает РАЗБОР:

Тип Примеры Метод чтения
Файлы документов .md, .txt, .pdf, .docx Read / Agent(pdf)
Таблицы данных .csv, .xlsx Bash(head), анализ структуры
Код .py, .js, .sql Read + анализ зависимостей
Ссылки URL на сайт / документ WebFetch
Описание в чате текст от оператора прямой анализ
Архивы .zip, .tar.gz Bash(unzip -l) — инвентаризация

3. АЛГОРИТМ РАЗБОРА

Фаза 1 — ИНВЕНТАРИЗАЦИЯ

1. Получить список всех входных файлов
2. Классифицировать по типам (документы / данные / код / конфиги)
3. Определить объём (количество, размер)
4. Составить MANIFEST  что есть, чего нет

Вывод: краткий список "что нашёл" → оператор подтверждает продолжение.

Фаза 2 — АНАЛИЗ

1. Прочитать ключевые файлы (не все  выбрать важные)
2. Извлечь: цель проекта, участники, технологии, данные, ограничения
3. Определить тип проекта (biz / it / sys)
4. Если IT-проект: определить стек
5. Выявить неясности  список вопросов

Фаза 3 — ЗАПОЛНЕНИЕ ДОКУМЕНТОВ

Заполнить шаблоны проекта из projector/templates/:

Шаблон Что заполнить
index.yaml id, type, status, layer, описание
design/DESIGN.md цель, участники, ограничения
management/TODO.md первичный список задач

Принцип заполнения:
- Поле известно точно → заполнить значением
- Поле неизвестно → TBD: [вопрос к оператору]
- Поле неприменимо → N/A

Фаза 4 — СПИСОК ИССЛЕДОВАНИЙ

Сформировать список: что надо выяснить до начала работы.

## Исследования (до старта)

| # | Вопрос | Зачем | Источник |
|---|--------|-------|---------|
| 1 | ... | ... | оператор / документ / веб |

Типовые вопросы:
- Кто стейкхолдер? Кто пользователь?
- Какие интеграции нужны?
- Есть ли существующие данные / система?
- Каковы ограничения (бюджет, срок, технологии)?

Фаза 5 — ПОДТВЕРЖДЕНИЕ

Показать оператору:
1. MANIFEST (что нашли)
2. Заполненные документы (краткий вид)
3. Список исследований
4. Список TBD-полей

Вопрос: "Всё верно? Записываем?"


4. ВЫВОД РАЗБОРА

Структура результата

📋 РАЗБОР: {название}

НАШЁЛ:
  - {N} файлов: {типы}
  - Тип проекта: {biz/it/sys}
  - Стек: {если IT}

СОЗДАМ:
  - projects/{org}/{name}/index.yaml
  - projects/{org}/{name}/design/DESIGN.md
  - projects/{org}/{name}/management/TODO.md

ИССЛЕДОВАНИЯ (до старта):
  1. ...
  2. ...

НЕЯСНО (TBD):
  - Поле X: {вопрос}

Записываем?

5. ПРАВИЛА РАЗБОРА

✅  Сначала инвентаризация — потом анализ (не читать всё подряд)
✅  TBD вместо выдумывания значений
✅  Список исследований — обязателен
✅  Подтверждение оператора перед записью (Шаг 5)
❌  Не заполнять поля без источника (только TBD)
❌  Не читать файлы размером >10MB без предупреждения
❌  Не начинать реализацию в процессе РАЗБОРА

6. СВЯЗЬ С ЖИЗНЕННЫМ ЦИКЛОМ

РАЗБОР — отдельная операция. В жизненном цикле проекта вызывается из фазы 0.7:

Фаза 0.7 AI-РАЗБОР → запускает операцию РАЗБОР →
  результат: документы проекта заполнены
Фаза 1 ИДЕЯ → работает с уже заполненными документами

Но РАЗБОР может запускаться в любой момент (не только в фазе 0.7):
- при поступлении новых данных в существующий проект
- при необходимости ревизии документов
- по явному запросу оператора


7. СВЯЗАННЫЕ ДОКУМЕНТЫ