Этот шаблон нужен для новых platform modules, а также для support/capability crates, которые хотят соответствовать текущему documentation contract RusToK.
Нормативный путь для module-level documentation такой:
- корневой
README.mdрядом с кодом; - локальный
docs/README.md; - локальный
docs/implementation-plan.md; - при необходимости
rustok-module.toml.
Не создавайте отдельный central doc для каждого модуля в docs/modules/. Central docs должны ссылаться на локальную документацию, а не дублировать её.
Для нового path-модуля ожидается следующий набор:
crates/rustok-<slug>/
Cargo.toml
README.md
rustok-module.toml
docs/
README.md
implementation-plan.md
Для support/capability crate rustok-module.toml не обязателен, если crate не входит в modules.toml.
Корневой README должен быть на английском и содержать этот каркас:
# rustok-<slug>
## Purpose
One short paragraph explaining what this crate owns.
## Responsibilities
- Responsibility 1
- Responsibility 2
- Responsibility 3
## Entry points
- `MainType`
- `MainService`
- `controllers::routes`
## Interactions
- Interaction with `apps/server`
- Interaction with other modules/crates
- Notes about UI packages or runtime wiring
## Docs
- [Module docs](./docs/README.md)
- [Platform docs index](../../docs/index.md)Правила:
- один файл — один язык;
README.mdне заменяет локальные docs;Docssection обязателен;- названия разделов должны совпадать с contract-формой:
## Purpose## Responsibilities## Entry points## Interactions
Локальный docs README пишется на русском и описывает живой модульный контракт.
Минимальный каркас:
# <Название модуля>
## Назначение
Кратко: что модуль делает и почему он существует.
## Зона ответственности
- Чем модуль владеет
- Чем модуль сознательно не владеет
## Интеграция
- GraphQL / REST / фоновые задачи / UI-поверхности
- host wiring и runtime boundaries
- зависимости на другие модули и crate-ы
- особенно важные кросс-модульные контракты
## Проверка
- `cargo xtask module validate <slug>`
- `cargo xtask module test <slug>`
- другие точечные команды при необходимости
## Связанные документы
- `implementation-plan.md`
- central docs
- соседние host/module docsДопустимы дополнительные разделы, если они реально нужны модулю:
## Настройки и конфигурация## Health и observability## Ограничения## UI contract
Но минимальные разделы выше должны оставаться на месте.
Этот файл фиксирует живой план доведения модуля до целевого состояния, а не подробную историю работ.
Минимальный каркас:
# План развития <модуля>
## Область работ
Коротко: на чём сосредоточен текущий план.
## Текущее состояние
Коротко: что уже стабилизировано и какие инварианты модуль уже держит.
## Этапы
### 1. Ближайший срез
- ...
## Проверка
- `cargo xtask module validate <slug>`
- `cargo xtask module test <slug>`
## Правила обновления
1. При изменении runtime/module contract сначала обновлять этот файл.
2. При изменении public surface синхронизировать `README.md` и `docs/README.md`.
3. При изменении manifest metadata синхронизировать `rustok-module.toml`.Допустимы дополнительные разделы:
## Риски и открытые вопросы## Приоритеты## Критерии готовности
Но ## Область работ, ## Текущее состояние, ## Этапы, ## Проверка и ## Правила обновления должны присутствовать как минимальный стандарт.
Для path-модуля из modules.toml локальный manifest обязателен.
Минимальный каркас:
[module]
slug = "<slug>"
name = "<Name>"
version = "0.1.0"
description = "At least one publish-ready sentence."
ownership = "first_party"
trust_level = "verified"
ui_classification = "dual_surface"
[crate]
entry_type = "<PascalSlug>Module"Для core-модуля, который добавляется в modules.toml с required = true, используется trust_level = "core".
Если crate реализует RusToKModule, entry_type обязателен и должен совпадать с реальным runtime entry type в src/lib.rs.
Если crate не реализует RusToKModule и используется как capability-only слой, entry_type можно не указывать.
Дальше по необходимости добавляются:
[provides.graphql][provides.http][provides.admin_ui][provides.storefront_ui][settings][marketplace]
Подробный contract-слой описан в docs/modules/manifest.md.
Для нового или существенно изменённого platform module:
cargo xtask module validate <slug>
cargo xtask module test <slug>Если меняется состав modules.toml, добавляется:
cargo xtask validate-manifestМинимальный Windows verification path описан в docs/verification/README.md.
- не писать root
README.mdна русском; - не хранить единственную документацию модуля только в
docs/modules/; - не добавлять path-модуль в
modules.tomlбезrustok-module.toml; - не считать подпапки
admin/иstorefront/доказательством интеграции без manifest wiring; - не превращать local docs в исторический changelog, если нужен живой contract.