architect/standards/arch-document-format.md

type: standard
layer: arch
object: document
aspect: format
title: "Формат документа платформы"
status: active
version: 1.1.0
date: 2026-04-15
knowledge_level: У1
form: text
parent: arch-platform-structure.md
deps: []


Формат документа платформы

Стандарт описывает как физически оформить любой .md документ платформы: frontmatter, структура, markdown, иерархия.

Это первый стандарт — написан в bootstrap-формате. Все последующие документы пишутся по нему.


1. FRONTMATTER

Метаданные документа. Располагается в самом начале файла.

1.1. Обязательные поля

---
type:    standard          # тип документа (см. §2.3)
title:   "Название"        # человекочитаемый заголовок
status:  active            # текущий статус (см. §2.4)
date:    YYYY-MM-DD        # дата создания или последнего изменения
---

1.2. Поля формулы именования

layer:   arch              # слой платформы: arch|project|domain|infra|system|service
object:  document          # что описывает файл
aspect:  format            # одна из 10 категорий

Эти поля дублируют имя файла и позволяют искать документы по метаданным без опоры на путь.

1.3. Рекомендуемые поля

version:         1.0.0     # SemVer — для стандартов и концепций
knowledge_level: У1        # У0|У1|У2|У3|У4
form:            text      # сущность документа: text | table | schema | code
owner:           architect # кто отвечает

1.4. Поля связей

parent:      ../MASTER.md      # родительский документ (один)
deps:                          # зависимости (список)
  - path/to/doc-a.md
  - path/to/doc-b.md

1.5. Поля блокировки

locked:      true              # true = только @keeper.agent может изменить
lock_reason: "У0 LOCKED  фундамент платформы"

При locked: true — AI-агенты (кроме @keeper.agent) обязаны отказать в изменении.
Разблокировка — через явный запрос оператора к @keeper.agent.

1.6. Опциональные поля

id:          ADR-001           # для decisions и tickets
priority:    HIGH              # для tickets: LOW|MEDIUM|HIGH|CRITICAL
derived_from: path/to.md       # от какого документа дериватив
part_of:     path/to.md        # частью чего является
phase:       3                 # фаза Проектора (0–15)
tags:        [api, security]
audience:    [architect, coder]

1.5. Значения полей

type:

concept      — видение, как понимаем предмет
standard     — правило, как должно быть сделано
decision     — ADR, почему решили именно так
pattern      — рецепт, типовое решение задачи
template     — заготовка для заполнения
research     — активное изучение внешних систем
analysis     — осмысление: выводы, закономерности
practice     — накопленный опыт, статистика
plan         — что и когда делать
instruction  — как делать шаг за шагом
ticket       — задача / баг / технический долг

status:

draft        — черновик, не действует
active       — действует, является истиной
deprecated   — устарело, есть замена (поле replaced_by: обязательно)
archived     — убран в архив, не используется

suspended    — заморожено временно (опционально)
cancelled    — отменено, не будет завершено (опционально)

form:

text         — нарратив, объяснение, рассуждение
table        — справочник, список с атрибутами
schema       — диаграмма, структура, граф
code         — готовый код, конфиг, шаблон

2. СТРУКТУРА ДОКУМЕНТА

2.1. Основные правила

Шаблон:

---
frontmatter
---

# Заголовок

Краткое описание (1–3 предложения).

---

## 1. ПЕРВЫЙ РАЗДЕЛ

...

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

- [Файл](./path.md) — что описывает

2.2. Рекомендуемая структура по типу

СТАНДАРТ:

## ЗАЧЕМ          — проблема / цель
## ПРАВИЛА        — жёсткие требования
## ПРИМЕРЫ        — как применять
## ИСКЛЮЧЕНИЯ     — когда можно нарушить

ADR (архитектурное решение):

## Контекст       — какая проблема, почему возникла
## Решение        — что решили делать
## Альтернативы   — что рассматривали, почему отказались
## Последствия    — что изменится, плюсы / минусы

ПЛАН:

## Цель           — чего хотим достичь
## Scope          — что входит, что нет
## Фазы           — последовательность шагов
## Риски          — что может пойти не так

ТИКЕТ:

## Описание           — что не так / что нужно
## Критерии готовности — когда считать выполненным
## Откат              — как вернуть назад

КОНЦЕПЦИЯ:

## ОПРЕДЕЛЕНИЕ    — что это такое
## ЗАЧЕМ          — почему существует
## КАК УСТРОЕНО   — структура / принципы
## ПРИМЕРЫ        — конкретные случаи

2.3. Размер документа

ОПТИМАЛЬНО       — до 500 строк (🟢)
РЕКОМЕНДУЕТСЯ ДРОБИТЬ — 500–800 строк (🟡)
ОБЯЗАТЕЛЬНО ДРОБИТЬ  — более 800 строк (🔴)

Дробить: если разные части документа используются независимо друг от друга — выносить в отдельные файлы с parent: в frontmatter.


3. MARKDOWN

3.1. Диалект

GFM (GitHub Flavored Markdown) — база
  + Pandoc extensions          — frontmatter, footnotes, definition lists, fenced divs
  + Custom transclusion        — компиляция документов
Компонент Зачем
GFM Таблицы, чеклисты, code blocks, совместимость с GitHub
YAML frontmatter Метаданные документов
Footnotes Сноски для теоретических документов
Definition lists Терминология и глоссарии
Fenced divs Блоки предупреждений и примеров

3.2. Правила оформления

Списки: только через -

✅ - пункт
❌ * пункт
❌ + пункт

Горизонтальная линия: только через ---

✅ ---
❌ ***
❌ ___

Ссылки: только относительные внутри репозитория

✅ [Стандарт](./format-file-types.md)
✅ [Секция](#название-раздела)
✅ [Родитель](../MASTER.md)
❌ [Стандарт](/opt/claude-workspace/standards/file.md)

Код: всегда указывать язык

✅ ```python
✅ ```bash
✅ ```yaml
✅ ```text   ← для псевдокода
❌ ``` (без языка)

Заголовки:

✅ H1 → H2 → H3
❌ H1 → H3 (пропуск уровня)
❌ Два H1 в одном документе

3.3. Fenced divs

::: warning
**Внимание:** критически важное предупреждение.
:::

::: note
Примечание для читателя.
:::

::: example
Пример применения.
:::

4. ИЕРАРХИЧЕСКИЕ ДОКУМЕНТЫ

4.1. MASTER / DETAIL / SUBDETAIL

Для больших тем — трёхуровневая иерархия:

MASTER.md                    ← обзор (до 300 строк)
  └── DETAIL_1.md            ← детали раздела
        └── SUBDETAIL_1.1.md ← реализация

Связь через поле parent: во frontmatter и ссылку в тексте:

---
parent: ../MASTER.md
---

4.2. Transclusion

Директива <!-- INCLUDE: path --> собирает иерархию в один файл при компиляции.

## Детали структуры

[→ Читать отдельно](./details/STRUCTURE.md)

<!-- INCLUDE: ./details/STRUCTURE.md -->

При обычном просмотре — видна ссылка.
При компиляции — вставляется содержимое файла (без его frontmatter).

python3 tools/md-compile.py INPUT.md OUTPUT.md

5. ЖИЗНЕННЫЙ ЦИКЛ ДОКУМЕНТА

5.1. Схема переходов

draft → active → deprecated → archived
                ↘ suspended (временно)
                ↘ cancelled (отменено)

Основной путь: draft → active → deprecated → archived.

5.2. Правила каждого статуса

Статус Кто изменяет Что разрешено Что запрещено
draft любой редактировать, удалить ссылаться как на источник истины
active architect (+ keeper для locked) читать, ссылаться, minor fix удалять, переименовывать без ADR
deprecated architect читать, ссылаться как "устаревшее" создавать новые ссылки без предупреждения
suspended architect читать, возобновить (→ draft) применять
cancelled operator архивировать восстанавливать
archived только @keeper.agent читать, ссылаться на историю изменять содержимое

5.3. Обязательные действия при переходе

draft → active:
- Заполнить frontmatter: type, title, layer, object, aspect, form, status, date
- Пройти чеклист §6
- Добавить в INDEX.md папки
- Обновить ссылки в зависимых документах

active → deprecated:
- Указать поле superseded_by: с путём к замене
- Добавить notice в начало документа:
```

УСТАРЕЛО: заменён новым файлом
```
- Обновить все ссылки на этот документ

deprecated → archived:
- Переместить в _archive/YYYY-MM-DD/
- Убрать из INDEX.md (оставить только в примечании если нужна история)

5.4. Специальные правила

LOCKED документы (locked: true):
- Изменение статуса — только через @keeper.agent
- Переход active→deprecated требует ADR

Версионирование при изменении:
- Bugfix / опечатки → patch (1.0.0 → 1.0.1), дата не меняется
- Уточнение / добавление → minor (1.0.0 → 1.1.0), обновить date
- Структурное изменение → major (1.0.0 → 2.0.0) = фактически новый документ


6. ЧЕКЛИСТ СОЗДАНИЯ


7. ТИПЫ ФАЙЛОВ ПЛАТФОРМЫ

7.1. Три зоны хранения

export WORKSPACE=/opt/claude-workspace    # КОД (git)
export DATASPACE=/mnt/beget-s3            # ДАННЫЕ (S3)
export MEDIASPACE=$DATASPACE/media        # МЕДИА (S3)
Зона Что Git
WORKSPACE Код, документация, конфиги Да
DATASPACE Таблицы, БД, JSON >1MB, бэкапы Нет
MEDIASPACE Изображения, видео, аудио, PDF Нет

7.2. 11 классов файлов

Класс Типы Где Git
CODE .py .js .ts .php .go .sh WORKSPACE Да
DOCUMENTATION .md .ai.md .txt .rst WORKSPACE Да
CONFIGURATION .yaml .json .toml .ini WORKSPACE Да
DATA .csv <100KB WORKSPACE Да
DATA .csv >100KB, .xlsx, .xls DATASPACE Нет
IMAGES .svg (любой), .png <50KB, .ico <20KB WORKSPACE Да
IMAGES .jpg, .png >50KB, .gif, .webp MEDIASPACE Нет
VIDEO .mp4 .avi .mov .webm MEDIASPACE Нет
AUDIO .mp3 .wav MEDIASPACE Нет
DOCUMENTS .pdf .docx .doc .rtf MEDIASPACE Нет
WEB .html .css .less .scss .woff2 .ttf WORKSPACE Да
TEMPLATES .twig .tpl .j2 WORKSPACE Да
DATABASES .sql (схемы) WORKSPACE Да
DATABASES .db .sqlite DATASPACE Нет

7.3. Жёсткие правила по изображениям

.jpg → ТОЛЬКО $MEDIASPACE (NO EXCEPTIONS)
.png → $WORKSPACE если < 50KB, иначе $MEDIASPACE
.svg → ТОЛЬКО $WORKSPACE (векторная графика)

7.4. Правила по размерам

Размер Где
< 50 KB WORKSPACE (git)
50 KB - 1 MB Только если критично важно
> 1 MB DATASPACE или MEDIASPACE. Запрещено в git

7.5. Белый список (разрешено в git)

CODE:   .py .js .ts .tsx .jsx .php .go .c .cpp .h .sh .bat .ps1
DOCS:   .md .ai.md .txt .rst
CONFIG: .yaml .yml .json .toml .ini .conf .xml .env.example
WEB:    .html .css .less .scss .svg .woff2 .ttf
TPL:    .twig .tpl .j2
SQL:    .sql
IMAGES: .svg (любой), .png (<50KB), .ico (<20KB)
MISC:   .gitignore .gitkeep .editorconfig Dockerfile Makefile LICENSE

7.6. Чёрный список (запрещено в git)

IMAGES:  .jpg .jpeg .gif .webp .png (>50KB)
MEDIA:   .mp4 .avi .mov .mp3 .wav
DOCS:    .pdf .docx .doc .rtf
DATA:    .xlsx .xls .ods .csv (>100KB)
DB:      .db .sqlite
CREDS:   .env .key .pem (приватные)
TEMP:    .pyc .log .tmp .cache
DEPS:    venv/ node_modules/ __pycache__/ .so .exe

8. ФОРМАТИРОВАНИЕ ДАННЫХ

8.1. Матрица применения

Формат Когда использовать Когда НЕ использовать
YAML Конфиги, метаданные, <100 записей Большие данные (>10K)
JSON API, логи, 100-10K записей Конфиги (читабельность)
CSV Табличные данные, 1K-100K записей Вложенные структуры
Excel Обмен с бизнесом, отчёты Автоматизация, версионирование
SQLite >10K записей, реляционные данные Конфиги, метаданные

8.2. YAML

Правила:
- Отступы: 2 пробела
- Ключи: snake_case
- Строки без кавычек если нет спецсимволов
- Двойные кавычки "text" если есть :, #, -, @

defaults: &defaults
  timeout: 30
  retries: 3

production:
  <<: *defaults
  host: prod.example.com

Валидация:

python3 -c "import yaml; yaml.safe_load(open('file.yaml'))"

8.3. JSON

Правила:
- Отступы: 2 пробела
- Кавычки: только двойные "
- Trailing comma: ЗАПРЕЩЕНА
- Ключи: snake_case (внутри платформы), camelCase (внешние API)

Валидация:

jq empty file.json
python3 -m json.tool file.json

8.4. CSV

Правила:
- Первая строка: обязательно заголовки (snake_case)
- Разделитель: запятая ,
- Кодировка: UTF-8 (UTF-8 with BOM для Excel)
- Кавычки: двойные " если значение содержит запятую или перенос

8.5. Excel (XLSX)

Использовать для обмена с бизнесом. НЕ для хранения данных и версионирования.

8.6. Даты и время

Формат: ISO 8601: YYYY-MM-DDTHH:MM:SSZ

created_at: 2026-02-19T10:30:00Z          # UTC
updated_at: 2026-02-19T13:30:00+03:00     # Moscow time

НЕ использовать: 19.02.2026, 19/02/26, Unix timestamp


9. INDEX.md — ПРАВИЛА

9.1. Обязательность

Каждый проект обязан иметь INDEX.md — оглавление с аннотациями. Добавляется в INDEX.md папки при переходе testing → active.

9.2. Структура INDEX.md

# Project Name -- Оглавление

**Тип:** {business|saas|infrastructure}
**Статус:** {design|development|production}

[<- Назад к Parent Project](../INDEX.md)

## ОСНОВНЫЕ ДОКУМЕНТЫ

| Документ | Описание |
|----------|----------|
| [PROJECT.md](PROJECT.md) | Полное описание |

## О ПРОЕКТЕ

{1-2 абзаца}

## СВЯЗИ

- **Родительский:** [Parent](../INDEX.md)

[<- Назад к Parent Project](../INDEX.md)

9.3. Правила навигации

Уровень Формат
Внутри проекта [doc](file.md)
Родительский [Parent](../INDEX.md)
Соседний проект [Proj](../proj/INDEX.md)
Внешний ресурс [Docs](http://...)

9.4. Изоляция

Проект НЕ ДОЛЖЕН ссылаться напрямую на документы других проектов своего уровня — только на их INDEX.md. Исключение: родительские проекты могут ссылаться на любые документы дочерних.

9.5. Проверка

test -f INDEX.md && echo "INDEX.md OK" || echo "INDEX.md missing"
test -f PROJECT.md && echo "PROJECT.md OK" || echo "PROJECT.md missing"
test -f CLAUDE.md && echo "CLAUDE.md OK" || echo "CLAUDE.md missing"
grep -q "Назад" INDEX.md && echo "Navigation OK" || echo "No navigation"

10. ДОКУМЕНТАЦИЯ БИЗНЕС-ПРОЕКТОВ

10.1. Обязательные документы

project-name/
├── INDEX.md              ← Оглавление
├── CONCEPT.md            ← 1. Концепция и идея
├── ANALYSIS.md           ← 2. Анализ рынка
├── BUSINESS_MODEL.md     ← 3. Бизнес-модель
├── IMPLEMENTATION.md     ← 4. План реализации
├── PROJECT.md            ← Полное описание (сводка)
└── CLAUDE.md             ← Контекст для Claude

10.2. Структура по типам

CONCEPT.md:
- ПРОБЛЕМА: боль рынка, текущие решения и их недостатки
- РЕШЕНИЕ: предложение, UVP, ключевые преимущества
- ВИДЕНИЕ: миссия, vision (2-5 лет), целевая аудитория
- ПРОДУКТ: MVP, полная версия, развитие

ANALYSIS.md:
- РЫНОК: TAM/SAM/SOM, тренды, драйверы, барьеры
- КОНКУРЕНТЫ: прямые, непрямые, сравнительная таблица
- ЦЕЛЕВАЯ АУДИТОРИЯ: персоны, сегментация
- SWOT: Strengths, Weaknesses, Opportunities, Threats

BUSINESS_MODEL.md:
- БИЗНЕС-МОДЕЛЬ: тип, источники дохода, партнёры, активности
- МОНЕТИЗАЦИЯ: ценообразование, тарифы
- UNIT-ЭКОНОМИКА: CAC, LTV, LTV/CAC, payback, churn, ARPU
- ФИНАНСОВАЯ МОДЕЛЬ: прогноз выручки, расходы, break-even

IMPLEMENTATION.md:
- ЭТАПЫ: MVP (1-3 мес), Growth (4-6 мес), Scale (7-12 мес)
- ROADMAP: по кварталам
- РЕСУРСЫ: инвестиции, команда
- РИСКИ: вероятность, влияние, митигация

10.3. Последовательность создания

  1. Исследование → ANALYSIS.md
  2. Концепция → CONCEPT.md
  3. Бизнес-модель → BUSINESS_MODEL.md
  4. Реализация → IMPLEMENTATION.md
  5. Сборка → PROJECT.md + INDEX.md + CLAUDE.md

11. ГЛОССАРИЙ — ПРОТОКОЛ

11.1. Назначение

Каждый проект имеет GLOSSARY_STANDARD.md — единый справочник терминов, кодов и синонимов.

11.2. Когда добавлять термин

Ситуация Действие
Создание проекта Изучить тему → предложить термины → подтвердить → записать
Новый термин в диалоге Предложить определение → после "ок" → добавить
Уточнение существующего Обновить запись
Платформенный термин Добавить в глоссарий платформы

11.3. Протокол "новый термин"

1. Предложить: "Предлагаю добавить в глоссарий: [термин] -- [определение]. Ок?"
2. После подтверждения -- добавить в GLOSSARY_STANDARD.md
3. Если платформенный -- также обновить глоссарий платформы

11.4. Формат записи

### [Термин]
**Canonical:** единственное эталонное название
**Code:** машинный код в файлах/системах
**Synonyms:** варианты, SEO-формы, разговорные названия
**Docs:** ссылки на документы
**Note:** уточнение, контекст, примеры

12. УВЕДОМЛЕНИЯ

12.1. Формат

[ТИП]: [краткое описание]

[детали если нужны]

[действие если нужно]

12.2. Типы уведомлений

Тип Кому Когда
NEW_PROJECT PM Завершён INTAKE
NEW_TASK Исполнитель Назначена задача
TASK_DONE PM Задача выполнена
QUESTION PM Вопрос от исполнителя
CLIENT_MESSAGE AM Клиент написал
NEED_HUMAN AM Клиент просит человека
CLARIFY_RESPONSE PM Клиент ответил на вопрос
REVIEW_RESPONSE PM Клиент дал обратную связь

12.3. Визуальные маркеры

Маркер Назначение
⚠️ WARNING Критическое предупреждение, требует внимания
ℹ️ INFO Информационное сообщение
✅ SUCCESS Успешное завершение операции

13. ВОПРОСЫ И ВАРИАНТЫ

13.1. Принцип

ВСЕ вопросы в системе задаются ТОЛЬКО с нумерованными вариантами.

13.2. Формат вопроса

<Вопрос>?
  1) <Вариант 1>
  2) <Вариант 2>
  3) <Вариант 3>
  0) Отмена / Выход

Выбор [номер]:

13.3. Обязательные элементы

Элемент Требование
Вопрос Короткий, понятный, со знаком ?
Варианты Минимум 2, максимум 9
Нумерация 1, 2, 3... (НЕ a, b, c)
Отмена Всегда есть 0)
Промпт Выбор [номер]: или Выбор:

13.4. Запрещённые форматы

13.5. Где применяется

НЕ применяется к: параметрам командной строки (--flag), API, конфигам, логам.


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

Прямые потомки (child):
- arch-document-system.md — типы документов, уровни знания, именование
- arch-filesystem-structure.md — файловая система: $WORKSPACE / $DATASPACE

Источник обогащения:
- format/format-content.md — форматы контента: типы файлов, данные, глоссарий, уведомления