iskronify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Repo-boost

Приведи текущий репозиторий к агентскому стандарту iskron: плотный

AGENTS.md

(читается каждую сессию каждым харнессом),

REALITY.md

рядом (таблица носителей реальности, читается по поводу — при поведенческой заявке и в брифе

verifier

reviewer

CLAUDE.md

-указатель, ритуалы сессии хуками и гейт качества. Конфиг ты генерируешь из скелетов — пользователь шаблонов не вставляет.

Деливерабл — интерфейс доверия.

AGENTS.md

REALITY.md

— производные виды: проекция источников (код,

package.json

, CI, файловая система, граф) плюс тонкий слой авторского суждения, который больше нигде не живёт. Контракт двуглав: плотность (каждая строка меняет поведение) и точность (каждая производная строка перепроверена против источника в этом прогоне). Плотная ложная строка хуже многословной.

Скелеты:

references/agents-template.md

(

AGENTS.md

: YAML-фронтматтер и тело) и

references/reality-template.md

(

REALITY.md

) — слоты

<…>

и заметки

<!-- … -->

. Заполни слоты, выброси неприменимые опциональные строки, вычисти каждую заметку и угловую скобку. Скелеты — что произвести; этот файл — как.

Контракт:
25
. Шаг 7 штампует это число в каждый

AGENTS.md

. Увеличивай на единицу, только когда перемена здесь или в скелетах делает уже сгенерированный файл неверным (секция или файл добавлены, переименованы, изъяты; ритуал изменён; имя тула выпало), никогда ради формулировок. То же число стоит первым словом в

description

— нарочно: триггер срабатывает по описанию, а в контексте сессии сходятся только описания скиллов и штамп

AGENTS.md

; расхождение копий ловит

make validate

. Конфиг со штампом-датой или без штампа — ниже любого числа: прогони полную дугу (правило запуска держит шаг «Выравнивание» двери

iskron

) и назови контракт, из которого пришёл конфиг.

Строка
AGENTS.md
расходится со скиллом — назови вслух, молча не выбирай: в деле постановщику, без дела — человеку. Штамп ниже контракта установленного

iskronify

— прав скилл, прогони; равен — дефект шаблона, фидбэк стюарду поставки скиллов (feedback). Правило стоит и в скелете («Держи этот файл честным») — для агента, этот скилл не загрузившего.

Редакция установленной поставки сверяется здесь. Всякий прогон — и всякий вывод «инструкция скилла неверна» (туда шлют feedback и entry) — начинается сверкой бегущего с выпущенным:

cat ~/.claude/plugins/cache/*/*/*/.claude-plugin/plugin.json     # что у тебя бежит
gh release view --repo <репозиторий плагина> --json tagName      # что существует
node ~/.iskron-bridge/iskron-bridge.mjs --version                # какую сборку несёт копия моста

Отстал больше чем на патч — обнови поставку, перезапусти сессии харнесса и только потом гони дугу: конфиг из протухшего скилла наследует его дефекты. Число контракта этого не заменяет: оно движется с формой конфига, версия — с каждой отгрузкой.

Скелет инлайнит граф-агностичную дисциплину (Рабочие принципы, «Жизненный цикл сессии») в каждый

AGENTS.md

— сжато, по строке на правило, но инлайн, не указателем в граф или скилл: есть харнессы без хука старта, и файл обязан стоять сам.

将当前仓库对齐到 iskron 的 Agent 标准：紧凑的

AGENTS.md

（每个运行载体（harness）每次会话都会读取）、同目录下的

REALITY.md

（现实载体表，按需读取——在行为请求以及

verifier

reviewer

的任务简报中）、

CLAUDE.md

指针、基于钩子的会话仪式和质量门禁。配置由你从骨架模板生成——用户无需手动插入模板。

交付物是信任接口。

AGENTS.md

和

REALITY.md

属于派生产物：是对各类来源（代码、

package.json

、CI、文件系统、图谱）的投影，加上一层仅存在于此的少量主观判断。合约包含两个核心要求：紧凑性（每一行都会改变 Agent 行为）和准确性（每一行派生内容都在本次运行中与来源进行过交叉验证）。一行紧凑的错误内容比冗长的废话更糟糕。

骨架模板包括：

references/agents-template.md

（用于生成

AGENTS.md

：包含 YAML 前置元数据和正文）和

references/reality-template.md

（用于生成

REALITY.md

）——模板中包含

<…>

格式的插槽和

<!-- … -->

格式的注释。请填充插槽，删除不适用的可选行，清理所有注释和尖括号占位符。骨架模板定义要生成什么；本文件定义如何生成。

合约版本：
25
。第7步会将这个版本号戳记到每个

AGENTS.md

中。仅当本文件或骨架模板的变更导致已生成的文件失效时（例如新增、重命名、删除了章节或文件；仪式流程变更；工具名称移除），才将版本号加1，仅为措辞优化的话不要升级。

description

的第一个词也是同一个版本号——这是刻意设计的：触发逻辑根据描述匹配，而在会话上下文中只会比对技能描述和

AGENTS.md

的戳记；副本的不一致会被

make validate

捕获。如果配置的戳记是日期格式或没有戳记——视为版本低于任何数字版本：请运行完整流程（启动规则由 iskron 门户的「对齐」步骤管控），并说明配置对应的合约版本。

如果
AGENTS.md
的内容与技能不一致——请明确指出，不要默默选择适用版本：有任务的话告知任务发起人，没有任务的话告知人工。如果戳记版本低于已安装的

iskronify

合约版本——以技能为准，重新运行；如果版本相等——则是模板缺陷，请向技能交付管理员反馈（feedback）。骨架模板中也有这条规则（「保持文件真实可信」）——针对未加载本技能的 Agent 生效。

已安装的技能版本需在此处核验。 每次运行——以及每次得出「技能指令有误」的结论时（需提交 feedback 和 entry）——都要先比对当前运行版本和已发布版本：

cat ~/.claude/plugins/cache/*/*/*/.claude-plugin/plugin.json     # что у тебя бежит
gh release view --repo <репозиторий плагина> --json tagName      # что существует
node ~/.iskron-bridge/iskron-bridge.mjs --version                # какую сборку несёт копия моста

如果落后超过一个补丁版本——请先更新技能，重启运行载体的会话，之后再运行完整流程：过期技能生成的配置会继承其缺陷。合约版本号不能替代技能版本：合约版本随配置格式变更，而技能版本随每次发布更新。

骨架模板会将与图谱无关的通用规范（工作原则、「会话生命周期」）内联到每个

AGENTS.md

中——内容紧凑，每条规则占一行，但是内联内容，而非指向图谱或技能的指针：因为有些运行载体没有启动钩子，文件必须能够独立生效。

Аудит → классификация → действие

审计 → 分类 → 处理

Репозиторий — спектр, не «свежий или настроенный»; ловушка — «файл есть, значит, его факты верны». Аудируй каждую заботу против её источника и классифицируй:

absent — выведи из источника; авторский слот без проверяемого источника — в дело выравнивания, никогда не выдумывай.
stale — ре-спроецируй, перезаписав; записанное не тащи вперёд.
correct — оставь.

Опаснее всего почти-верный конфиг: устаревшие строки среди доверенных — проверочный проход идёт по всему артефакту (Шаг 7).

仓库的状态是连续的，而非「全新的」或「已配置的」二元状态；常见陷阱是「文件存在，所以里面的内容都是对的」。请针对每一项配置对照其来源进行审计，并分类为：

absent（缺失） — 从来源推导生成；无法通过可验证来源填充的主观插槽——归入对齐任务，绝对不要编造。
stale（过期） — 重新投影并覆盖；不要沿用旧有内容。
correct（正确） — 保留原样。

最危险的是几乎正确的配置：可信内容中夹杂着过期行——验证流程会检查整个产物（第7步）。

Источник истины по заботам

各配置项的真实来源

Забота	Источник истины	Как проверить
Версии, зависимости	`package.json` / `pyproject.toml` / `go.mod` / `Cargo.toml` + lockfile	прочитать
Команды build/test/lint/dev	scripts, `Makefile` / `Justfile` , CI-workflow	прочитать; `--help` /dry-run, где дёшево
Гейт качества	конфиг линтера, `tsconfig` , CI-yaml	прочитать
Раскладка: карта кода, ловушки среды	слот обложки «Раскладка»	слота нет — умолчание: один `AGENTS.md` , навигация по файлам — компактно в README компонента, готчи в графе; прогон README компонентов не пишет: пока README компонента нет, его карта — в «Структуре проекта» `AGENTS.md` , и первый, кто тронет компонент, переносит её в README. Отступление — раздел «Структура проекта» вместо README — только там, где README рядом с выходами запрещён (выходы уезжают потребителю); запрет действует на такие выходы, не на весь репо, и выводится из него самого. `GOTCHAS.md` в репо — чья-то раскладка: разреши по Шагу 1; пока источники её не разрешили — слот пустой, источник `не согласовано — дело №N` , файлы нетронуты
Структура проекта, path-алиасы	файловая система + конфиг бандлера; при раскладке «README компонента» — сами README	glob / list; таблица «компонент → README» сверяется существованием файлов
Nature, production statement, послабления	граф, код репо, слово агентов; принятые владельцем ограничения сохраняются	разрешить по порядку Шага 1; смена мандата или цены поломки без основания — принципиальный вопрос
Носители реальности ( `REALITY.md` )	граф, наблюдаемый кодом путь поставки, слово агентов	проверить достижимость канонического носителя; неизвестное — Ceiling, не выдуманный носитель
Проектные решения, why-клаузы, открытые вопросы	граф	`iskron_orient` / `iskron_search`
Состояние веток	git + форжа	`git status` / `log` ; CLI форжи
Готчи	авторское; дом — по слоту «Раскладка»	только sanity-check — не автовыводить, не переносить между домами
Блоки канонов графа	узел-правило с `attrs.prose_for_repos`	`iskron_search(realm=<граф>, q="", attrs_filter="prose_for_repos:**")` ; блок кладётся байт-в-байт на место из `attrs.prose_anchor` , ниже — только хвост репо; применимость — по `attrs.scope` , иначе по смыслу, сомнение — порядком Шага 1

Производные факты (верхние строки, блоки канонов) ре-проецируются каждый прогон; авторское суждение (готчи, why-клаузы, nature, носители) сохраняется, лишь сверяясь на здравость с кодом.

配置项	真实来源	验证方式
版本、依赖	`package.json` / `pyproject.toml` / `go.mod` / `Cargo.toml` + lockfile	读取文件
build/test/lint/dev 命令	scripts、 `Makefile` / `Justfile` 、CI 工作流	读取文件；成本低的话用 `--help` /dry-run 验证
质量门禁	linter 配置、 `tsconfig` 、CI 配置文件	读取文件
布局：代码地图、环境陷阱	「布局」前置元数据插槽	没有该插槽时的默认规则：仅一个 `AGENTS.md` ，文件导航紧凑地放在组件的 README 中，陷阱（gotcha）记录在图谱里；本流程不会写入组件 README：只要组件还没有 README，它的代码地图就放在 `AGENTS.md` 的「项目结构」中，第一个修改该组件的人负责将地图迁移到 README 中。例外情况：用「项目结构」章节替代 README——仅适用于 README 不能与交付产物放在一起的场景（交付物要直接发给用户）；该禁令仅针对这类交付物，而非整个仓库，且需从交付物本身推导得出。仓库中的 `GOTCHAS.md` 属于已有布局：按第1步规则验证；在来源验证通过前，插槽保持为空，来源标记为 `未对齐 — 任务#N` ，文件不做修改
项目结构、路径别名	文件系统 + 打包工具配置；采用「组件 README」布局时——以组件 README 为准	glob / 列目录；「组件 → README」对照表需验证文件是否存在
项目性质（Nature）、生产环境声明、放宽规则	图谱、仓库代码、Agent 确认信息；所有者已接受的限制需保留	按第1步的顺序验证；无依据地变更授权范围或故障成本属于原则性问题
现实载体（ `REALITY.md` ）	图谱、代码可观测的交付路径、Agent 确认信息	验证标准载体的可访问性；未知的归入 Ceiling（上限），不要编造载体
项目决策、why 说明、待解决问题	图谱	`iskron_orient` / `iskron_search`
分支状态	git + 代码托管平台	`git status` / `log` ；平台 CLI
陷阱（Gotcha）	主观判断；归属按「布局」插槽规则	仅做合理性检查——不要自动推导，不要在不同归属间迁移
图谱规范块	带有 `attrs.prose_for_repos` 属性的规则节点	`iskron_search(realm=<图谱>, q="", attrs_filter="prose_for_repos:**")` ；规范块需按 `attrs.prose_anchor` 指定的位置逐字节插入，之后仅追加仓库专属内容；适用性按 `attrs.scope` 判断，无 scope 则按语义判断，存疑时按第1步的顺序处理

派生事实（顶部行、规范块）每次运行都会重新投影；主观判断（陷阱、why 说明、项目性质、载体）会保留，仅对照代码做合理性校验。

Контракт выхода — плотность и точность

输出合约——紧凑性与准确性

Императив агенту: «ориентируйся до кода», не «агенту следует».
Каждая строка меняет то, что агент делает; иначе удали. Чек-лист, не эссе.
Без проектных обоснований и пересказа графа — линкуй.
```
(why: …)
```
— только для инварианта, который агент иначе нарушит.
Таблицы и буллеты, одна директива на буллет.
Секция, растёкшаяся в абзацы, несёт обоснование — перенеси в граф.

Вне объёма — механика оркестрации (цепочки гейтов, суб-агентная проверка пушей, model-routing, многополосная координация): её дом — скилл оркестрации или граф; срез делегирования проецируется ролевыми файлами (Шаг 6), не прозой.

Пример: ❌ «Мы стараемся аккуратно обращаться с состоянием, потому что стор — единственное место данных, иначе демо может выглядеть сломанным.» ✅ «Persona-scoped UI читает роль через

use-acting-context

; перепроверь рендер при смене персоны. (why: устаревшее чтение показывает данные чужой роли.)»

对 Agent 的指令用祈使句：比如「先定位到代码再操作」，而非「Agent 应该先定位到代码」。
每一行都要改变 Agent 的行为；否则就删掉。要检查清单，不要散文式描述。
不要包含项目背景说明和图谱内容复述——用链接代替。
```
(why: …)
```
仅用于说明 Agent 可能违反的不变量。
用表格和列表，每个列表项只包含一条指令。
如果某个章节散落成大段文字且包含背景说明——将其迁移到图谱中。

不在范围内：编排机制（门禁链、子 Agent 推送检查、模型路由、多通道协调）：这些属于编排技能或图谱的范畴；委托相关的内容通过角色文件投影（第6步），而非文字描述。

示例：❌ 「我们会小心处理状态，因为 store 是唯一的数据源，否则 demo 可能会显示异常。」 ✅ 「Persona-scoped UI 通过

use-acting-context

读取角色；切换角色时请重新验证渲染结果。(why: 过期的读取会显示其他角色的数据。)」

Процедура

流程

Идемпотентна: в зрелом репо прогоняй каждый self-check и действуй только по провалам; докладывай, что осталось.

本流程是幂等的：在成熟仓库中，运行所有自检项，仅针对失败项进行处理；最后报告剩余问题。

Два такта

两个阶段

Кто исполняет прогон. Граф прогона — контур, роль, атрибуты, дело выравнивания — ведёт сам агент: это ремесло графа («Сквозные нормы» двери

iskron

). Объёмную проекцию файлов (

AGENTS.md

, ролевые файлы, хуки) он может отдать субагенту роли

designer

— у того свой мост-спутник; нет субагентов, ролевого файла

designer

ещё нет (первый контакт, такт 1 до проекции, роли старше контракта) или спутник не поднялся — проецирует сам. Прогон обновляет

AGENTS.md

и производные сам, не ждёт присутствия или подтверждения человека. Дело выравнивания ведёт позвавший (ведущий);

designer

работает в своём дочернем деле из строки запуска и дела выравнивания не ведёт (п. 5). Человека будит и ожидание держит ведущий, не

designer

, и только по принципиальному вопросу, не разрешённому графом, кодом и коллегами:

designer

возвращает его вопросом в итоге. Вопросы прогона — порядком Шага 1 («Человек обычно не в треде»).

Такт 1 «встать» — без вопросов, до минуты, в любом репозитории. Первый такт при первом контакте, по слову «iskronify» или при найденном отставании конфига. Быстро разрешаемое — в файл с источником, остальное — дыркой в дело; затем такт 2 без ожидания человека.

Адреса. Граф и роль — из слова человека, строки окна с адресом места или существующего
```
AGENTS.md
```
. Граф не назван —
```
iskron_realm(action="list")
```
, сверь с записанным о репо и спроси коллег; не разрешилось, какой граф выбрать или создать, — принципиальный вопрос о границе проекта по Шагу 1, не угадывай имя. Создание —
```
iskron_realm(action="create")
```
по принятому выбору. Роль владельца — 主-роль человека твоих ключей (
```
iskron_me(action="kartas")
```
); перечень, где стоишь ты сам, — знак сбитой привязки: слот дыркой, вопрос — в деле выравнивания.
```
kartas
```
видит только привязанные роли: прежде чем заводить svatantra-роль (Шаг 2), ищи её в графе —
```
iskron_search(q="", node_type="karta", manifested_as="svatantra")
```
. Он отдаёт все 主-роли графа: роль владельца — та, чей
```
handle
```
в атрибутах совпал с handle из
```
iskron_me(action="whoami")
```
; такая есть — не заводи, не выбирается — один вопрос человеку сессии, какая из найденных его. Привязку роли владельца проверь по шагу «Сойдись или эскалируй» скилла standing.
Контур репозитория.
```
origin
```
→
```
хост/организация/репо
```
→
```
iskron_search(q="", node_type="holon", attrs_filter="repository:<значение>")
```
. Нет —
```
iskron_add_holon
```
(
```
contains
```
от корня графа или контура репозиториев) с
```
attrs.repository
```
и
```
open_room
```
дела выравнивания. Один репозиторий — один контур.
Роль на репо.
```
iskron_search(q="", node_type="karta", steward_of=<контур>)
```
; нет —
```
iskron_add_karta
```
(
```
manifested_as=adhikarin
```
, мотивация — дистиллят того, что репо шипит) и
```
steward
```
к контуру. Одна роль на репозиторий.
Обложка и файлы. Слоты — YAML-фронтматтер в начале
```
AGENTS.md
```
по скелету и Шагу 7. Из графа и кода — «выведено»; из записанного ответа — «согласовано: кто», в том числе агент соседнего контура. Не разрешённое — пустое значение и источник «не согласовано — дело №N»; авторский слот не становится дыркой только потому, что человек отсутствует. «Жизненный цикл сессии» инлайнится из скелета.
```
REALITY.md
```
— таблицей разрешённых носителей; пока их нет, заголовок скелета и строка: «Носители ещё не установлены; дело выравнивания №N. До их установления поведенческие заявки не принимаются.» Таблица Reality в
```
AGENTS.md
```
уже есть — переносится в
```
REALITY.md
```
по Шагу 7.
Дело выравнивания на контуре из п. 2 ведёт позвавший (ведущий): открытое уже есть (
```
iskron_case(action="at", node=<контур>)
```
) — ведёт его; нет — открывает
```
open_room
```
у записи контура или
```
iskron_update
```
существующего, зачином до 64 знаков: «Выравнивание <репо> под контракт N». Прежде первой записи — назовись и войди (
```
iskron_case(action="join")
```
); стояние на вахту не нужно. Исполняешь сам — ведущий ты: назовись
```
iskron_channel(action="register", realm, karta=<роль на репо>, name=<выведенное имя>)
```
. Проекцию файлов исполняет субагент
```
designer
```
— ведущий заводит ему дочернее дело (
```
open_room
```
с
```
parent_room
```
— дело выравнивания) и ставит его №N в строку запуска;
```
designer
```
встаёт спутником (
```
iskron_stand
```
с
```
satellite_of
```
места позвавшего, как в
```
delegation.md
```
),
```
register
```
под выведенным именем не зовёт (имя — позвавшего), вопросы слотов говорит словом в дочернем деле, в граф не пишет, дела выравнивания не ведёт и выходит концом поручения (
```
iskron_case(action="leave")
```
). Неразрешённый, ждущий слот можно держать строкой «слот: <имя>» (
```
partial
```
— на ком, чего ждёт) — по желанию; разрешённый — значение и источник во фронтматтер, без строки; вопрос — словом в деле. Вопросы прогона — порядком Шага 1 («Человек обычно не в треде»). Первое слово: «есть вопросы по проекту, за который я отвечаю, — ответьте или скажите, кто может ответить». Анкету, вопросы прогона, план и ход выравнивания в граф не пиши; в граф такт пишет только структуру (контур с
```
repository
```
, роль) и готчи правилами (Шаг 7).
Хук старта и сторож памяти — из Шага 4 только
```
SessionStart
```
и memory-guard; стаб
```
MEMORY.md
```
(Шаг 5) — только над пустой или отсутствующей директорией памяти. Непустая — эвакуация по Шагу 5 в такте 2; до неё строка скелета о заморозке не утверждает завершения, а ссылается на строку дела выравнивания. Остальные хуки — такт 2. Указатель
```
CLAUDE.md
```
— Шаг 7.
Стояние — не здесь: его занимает старт двери
```
iskron
```
, только на вахту. Отчёт — слово в деле выравнивания: что разрешено, что открыто; такт по слову другого дела — слово-отчёт там, называющее дело выравнивания; затем эстафета Шага 7. Такт по слову дела — поручение, и его исход по наблюдённому говоришь словом в том деле.

Такт 2 «доделать» — сам, не блокируя. Продолжи после такта 1; каждый следующий старт (шаг «Выравнивание» двери

iskron

) читает сводку дела из ключа «Согласование» фронтматтера —

iskron_case(action="read")

; писать — назвавшись и войдя, как в п. 5. Слоты разрешай графом, кодом и словом коллег по Шагу 1. Впиши значение и источник во фронтматтер без переспроса; строка ожидания «слот: …», если слот её держал, снимается тем же ходом (

ok

), разрешённому без ожидания строка не заводится. Ответ агента подписывается его именем, не именем владельца; повторного подтверждения человеком не требует. Полная дуга (Шаги 1, 3, 4, 6, гейт, хуки, ролевые агенты) идёт без человека; неразрешённый слот держит только зависимую часть. Все слоты разрешены — «Согласование» = «пусто», предложи закрыть (

propose_close

, свидетельство — слоты фронтматтера со значениями и источниками), если ведущий ты; иначе слово ведущему.

谁来执行流程。 运行的图谱逻辑——边界、角色、属性、对齐任务——由 Agent 自身主导：这属于图谱的职责（iskron 门户的「跨域规范」）。文件的批量投影（

AGENTS.md

、角色文件、钩子）可以委托给

designer

角色的子 Agent——它有自己的卫星桥接器；如果没有子 Agent、

designer

角色文件还不存在（首次接触、第一阶段投影前、角色早于合约）或者卫星桥接器未启动——则由 Agent 自行投影。流程会自动更新

AGENTS.md

及派生文件，无需等待人工到场或确认。对齐任务由发起者（主导方）负责；

designer

在自己的子任务中按启动指令工作，不负责对齐任务（第5点）。只有主导方（而非

designer

）会在遇到原则性问题时唤醒人工并等待回复——这些问题无法通过图谱、代码和同事解决：

designer

会在最终结果中将其作为问题返回。流程中的问题按第1步的规则处理（「人工通常不在线程中」）。

第一阶段「启动」—— 无需提问，1分钟内完成，适用于任何仓库。 首次接触时、收到「iskronify」指令时或发现配置过期时执行第一阶段。能快速验证的内容直接写入文件并标注来源，其余的作为缺口记入任务；之后无需等待人工，直接进入第二阶段。

地址确认。 图谱和角色——从人工指令、窗口中的位置地址行或已有的
```
AGENTS.md
```
中获取。如果未指定图谱——运行
```
iskron_realm(action="list")
```
，与仓库的已有记录比对，并询问同事；如果仍无法确定选择或创建哪个图谱——属于第1步规定的项目边界原则性问题，不要猜测图谱名称。如需创建——按确认的选择执行
```
iskron_realm(action="create")
```
。所有者角色是你密钥对应用户的主角色（
```
iskron_me(action="kartas")
```
）；如果列表中出现你自己的角色——说明绑定异常：插槽留空，问题记入对齐任务。
```
kartas
```
仅能看到已绑定的角色：在创建 svatantra 角色（第2步）之前，先在图谱中搜索——
```
iskron_search(q="", node_type="karta", manifested_as="svatantra")
```
。它会返回图谱中的所有主角色：所有者角色是其属性中的
```
handle
```
与
```
iskron_me(action="whoami")
```
返回的 handle 一致的那个；如果存在就不要创建，如果无法确定——就问会话中的人工一个问题：找到的角色中哪个是他的。所有者角色的绑定请按 standing 技能的「对齐或升级」步骤验证。
仓库边界。 从
```
origin
```
提取
```
主机/组织/仓库
```
→ 执行
```
iskron_search(q="", node_type="holon", attrs_filter="repository:<值>")
```
。如果不存在——执行
```
iskron_add_holon
```
（作为图谱根节点或仓库边界的
```
contains
```
子节点），设置
```
attrs.repository
```
并为对齐任务创建
```
open_room
```
。一个仓库对应一个边界。
仓库角色。 执行
```
iskron_search(q="", node_type="karta", steward_of=<边界>)
```
；如果不存在——执行
```
iskron_add_karta
```
（
```
manifested_as=adhikarin
```
，动机为仓库核心价值的提炼）并设置为边界的
```
steward
```
。一个仓库对应一个角色。
封面与文件。 插槽——按骨架模板和第7步要求填充
```
AGENTS.md
```
开头的 YAML 前置元数据。从图谱和代码推导的标记为「推导得出」；从已记录的回复得到的标记为「已确认：确认人」，包括相邻边界的 Agent 确认的内容。未验证通过的——值为空，来源标记为「未对齐 — 任务#N」；主观插槽不会仅仅因为人工不在场就变成缺口。「会话生命周期」从骨架模板内联到文件中。
```
REALITY.md
```
是已确认的载体列表；如果还没有载体，保留骨架模板的标题和一行说明：「载体尚未确认；对齐任务#N。在载体确认前，不接受行为请求。」如果
```
AGENTS.md
```
中已经有 Reality 表格——按第7步迁移到
```
REALITY.md
```
中。
对齐任务 由第2步中边界的发起者（主导方）负责：如果已有开放任务（
```
iskron_case(action="at", node=<边界>)
```
）——就负责该任务；如果没有——在边界记录上创建
```
open_room
```
或
```
iskron_update
```
现有任务，任务简介不超过64字符：「将 <仓库> 对齐到合约版本N」。在第一条记录之前——请先表明身份并加入任务（
```
iskron_case(action="join")
```
）；无需值守。如果你自行执行——你就是主导方：通过
```
iskron_channel(action="register", realm, karta=<仓库角色>, name=<推导的名称>)
```
注册身份。文件投影由
```
designer
```
子 Agent 执行——主导方为其创建子任务（
```
open_room
```
的
```
parent_room
```
设为对齐任务），并在启动指令中注明子任务编号#N；
```
designer
```
作为卫星加入（执行带
```
satellite_of
```
的
```
iskron_stand
```
，指向发起者的位置，如
```
delegation.md
```
中所述），无需以推导的名称调用
```
register
```
（名称用发起者的），插槽相关问题在子任务中以消息形式提出，不写入图谱，不负责对齐任务，在委托结束时退出（
```
iskron_case(action="leave")
```
）。未解决的待处理插槽可以用「插槽：<名称>」的形式记录（
```
partial
```
字段说明负责人和待办事项）——可选；已解决的——将值和来源写入前置元数据，删除该行；问题以消息形式发送到任务中。流程中的问题按第1步的规则处理（「人工通常不在线程中」）。第一句话：「我负责的项目有几个问题，请解答或者告知谁能解答。」不要将问卷、流程问题、计划和对齐进度写入图谱；本阶段仅向图谱写入结构信息（带
```
repository
```
属性的边界、角色）和规则形式的陷阱（第7步）。
启动钩子和内存守卫 —— 从第4步中仅配置
```
SessionStart
```
和 memory-guard；
```
MEMORY.md
```
占位文件（第5步）——仅在内存目录为空或不存在时创建。如果内存目录非空——在第二阶段按第5步进行迁移；在此之前，骨架模板中关于冻结的行不会声明完成，而是引用对齐任务的对应行。其余钩子在第二阶段配置。
```
CLAUDE.md
```
指针在第7步配置。
值守 —— 不在本阶段：由 iskron 门户的启动流程负责，仅在值守时执行。

报告以消息形式发送到对齐任务中：说明哪些已解决，哪些仍开放；如果本阶段是由其他任务的消息触发的——就在该任务中发送回复报告，并提及对齐任务；然后转交第7步的接力。如果本阶段是由任务消息触发的委托——则将观察到的结果以消息形式回复到该任务中。

第二阶段「完善」—— 自动执行，不阻塞。 在第一阶段之后继续；每次后续启动（iskron 门户的「对齐」步骤）都会从前置元数据的「对齐状态」键读取任务摘要——

iskron_case(action="read")

；写入时需先表明身份并加入，如第5点所述。按第1步的规则，通过图谱、代码和同事的消息验证插槽。无需反复确认，直接将值和来源写入前置元数据；如果之前有「插槽：…」的等待行，同一操作中即可移除（

ok

），无需等待的已解决插槽不会创建该行。Agent 的回复用其自己的名称签名，而非所有者的名称；无需人工二次确认。完整流程（第1、3、4、6步、质量门禁、钩子、角色 Agent）无需人工参与；未解决的插槽仅阻塞依赖它的部分。所有插槽都解决后——「对齐状态」设为「无」，如果你是主导方，提议关闭任务（

propose_close

，证明材料为带值和来源的前置元数据插槽）；否则告知主导方。

Шаг 1 — Разреши слоты (такт 2)

第1步 — 验证插槽（第二阶段）

Не выбирай дефолты молча. Прочти граф, код репо и старый конфиг; чего они не разрешили — спроси у агентов соседних контуров в деле выравнивания. Запиши во фронтматтер значение и источник: Nature (не

production

— что ослаблено и почему), имя графа, «Стек», гейт (Шаг 3). Принятые авторские ограничения сохраняй; переспрос человеку нужен только для принципиального остатка.

Переход со старой анкеты. «Согласование» или дырка называет узел (

#N

), не дело, — форма прежнего контракта. Прочти узел (

iskron_look

): ответы с именем ответившего — в слоты «согласовано: кто»; открытые — строками «слот: <имя>» в дело выравнивания, пустое значение и источник

не согласовано — дело №N

во фронтматтер; узел-анкету отпусти (

visarjana

, reasoning «перенесён в дело №N»), чужой — слово автору.

Также согласуй:

Кто владеет направлением — svatantra-роль владельца (主), создаётся в Шаге 2; принципиальные вопросы слотов — ей через ведущего в деле выравнивания, не анкетой в графе.
Общее изменяемое состояние build/test (база, фиксированный порт, dev-сервер, глобальный кэш, облачная песочница): есть — зафиксируй по-полосную изоляцию готчей (агенты гоняют ветки конкурентно в отдельных worktree).
Реальность →
```
REALITY.md
```
. Установи из графа, кода и ответов коллег: куда приземляется изменение, какие эффекты производит, какие наблюдаемы и какой командой / URL / запросом, что агент достаёт сам, что требует пользователя. Дожимай до канонического носителя каждого класса: собранный артефакт, не исходники; живой эндпоинт, не хендлер; чистая установка, не тёплый кэш. Класс без достижимого наблюдения — в Ceiling с причиной; вывод о носителе не равен наблюдению поведения. Датированные замеры (сроки, версии, «наблюдено тогда-то») — узлами в граф, в
```
REALITY.md
```
— только нужное для наблюдения. В
```
AGENTS.md
```
— раздел «Reality» указателем: прочти
```
REALITY.md
```
прежде поведенческой заявки, первая строка таблицы названа, Ceiling — там. (Как таблица работает при закрытиях — скилл vahta, §3 «Работа и эстафета», абзац о
```
reality-audit
```
перед закрытием.)
Кросс-проектная память — умолчание шаблона: значение из скелета, источник
```
выведено: умолчание шаблона
```
, без вопроса человеку. Личный граф
```
@<handle>/mind
```
есть у каждого, о нём не спрашивай: нет — заведи граф и роль по minding; маршрутизация и сообщение memory-guard всегда несут его ветку. Поведение агента настраивают только коммитящиеся файлы рабочего дерева (AGENTS.md, файл хуков) и граф проекта — никогда глобальный файл инструкций (
```
~/.claude/CLAUDE.md
```
,
```
~/.config/opencode/AGENTS.md
```
…), память харнесса, пользовательские хуки; о глобальном файле не спрашивай и не заводи. Установка поставки — доставка, не настройка. Предпочтение, влияющее на процесс и результат, — в AGENTS.md или граф проекта; личное — в
```
@<handle>/mind
```
.
Фидбэк-рефлексия — рефлексировать ли опыт о методе в конце сессии или на мерже и записывать стоящее в граф работы (контур инструмента, адресом стюарду, после проверки на дубли, случаем). Умолчание шаблона — да, источник
```
выведено: умолчание шаблона
```
, без вопроса человеку: регион feedback-reflection скелета остаётся, хук мержа несёт такт. Нет — только по записанному слову (
```
согласовано: кто
```
): удали регион целиком.
Сосуществование с workflow-набором — только когда найден коэрсивный набор (его скиллы в списке или его директория в кэше плагинов; сегодня superpowers): (1) полный interop (рекомендуется) — подсекция из
```
references/superpowers-interop.md
```
+ spec-write-хук; (2) только проза; (3) пропустить — назови риск: дизайн-сессии набора не осядут в граф.

Человек обычно не в треде. Прогон сам обновляет

AGENTS.md

и производные; присутствие человека не условие. Везде выше и ниже «согласуй», «спроси», «подтверди» для слота означают этот порядок:

Сделай всё, что от ответа не зависит: аудит, выводимое, гейт, хуки.
Сперва граф и код, затем братья — агенты соседних контуров. Неразрешённое — в одном деле выравнивания, вопросом
```
ask
```
по двери iskron, «Ожидание от делателя»; строка «слот: <имя>» — по желанию, на отдельном от карточки ключе («Ключ вопроса не перекрывай строкой работы» там же), не узел и не дело на слот. Позови знающих коллег
```
iskron_case(action="invite")
```
; поручение —
```
say
```
с
```
to
```
на место по «Разовая задача — слово в деле» двери. Их
```
answer
```
прими
```
ack
```
, ответ — в слот с их именем. Факт из графа или кода впиши как «выведено», без строки дела; неочевидное основание — словом в деле.
Только принципиальный остаток — человеку через ведущего дела. Смена мандата, принятого ограничения, цены поломки, выбор или создание графа (граница проекта, такт 1, п. 1) либо неразрешимый конфликт источников — принципиальное; отсутствие ответа или сведений само по себе — нет. Прежде эскалации назови, что проверено в графе и коде, кого спросил и почему это требует решения владельца.
```
designer
```
возвращает такой вопрос в отчёте; ведущий говорит его словом в деле (строка «слот: …» — по желанию). Позвавший будит человека и держит ожидание:
```
invite
```
его места; места нет — его роли с контуром (
```
karta=<роль владельца>
```
,
```
holon=<контур репо>
```
). Нет доступного места — вопрос остаётся в деле у ведущего; остальная работа продолжается.
Дырка, не догадка: значение слота
```
''
```
, его источник
```
'не согласовано — дело №N'
```
;
```
Согласование
```
называет это дело. Непринципиальное неизвестное ждёт знающего агента или ведущего — словом в деле, строка по желанию. Старт двери найдёт ответ и впишет без переспроса. Отвеченное пишется сразу; один слот не держит остальные.

不要默默选择默认值。请读取图谱、仓库代码和旧配置；无法通过这些验证的内容——在对齐任务中询问相邻边界的 Agent。将值和来源写入前置元数据：项目性质（Nature）（不是简单的

production

——要说明哪些规则放宽了以及原因）、图谱名称、「技术栈」、质量门禁（第3步）。已接受的主观限制需保留；仅原则性的剩余问题才需要询问人工。

从旧问卷迁移。 如果「对齐状态」或缺口引用的是节点（

#N

）而非任务——这是旧合约的格式。读取节点（

iskron_look

）：带回复人姓名的回答——填入「已确认：确认人」插槽；未解决的——以「插槽：<名称>」的形式记入对齐任务，前置元数据中值为空，来源标记为

未对齐 — 任务#N

；问卷节点可以释放（

visarjana

，理由为「已迁移到任务#N」），如果是他人的节点——告知作者。

还需确认以下内容：

方向负责人 —— 所有者的 svatantra 角色（主角色），在第2步创建；插槽的原则性问题——通过对齐任务的主导方转达给她，不要用图谱中的问卷形式。
build/test 的共享可变状态（数据库、固定端口、dev 服务器、全局缓存、云沙箱）：如果存在——通过陷阱规则记录各通道的隔离要求（Agent 会在独立的 worktree 中并发运行不同分支）。
现实载体 →
```
REALITY.md
```
。从图谱、代码和同事的回复中确认：变更落地到哪里，会产生什么效果，哪些是可观测的，用什么命令 / URL / 请求观测，哪些是 Agent 可以自行获取的，哪些需要用户操作。尽量落实到每个类别的标准载体：是构建后的产物，而非源码；是活的接口，而非 handler；是干净安装，而非热缓存。没有可观测方式的类别——归入 Ceiling 并说明原因；对载体的推断不等于实际观测到的行为。带日期的测量数据（期限、版本、「当时观测到的」）——作为节点存入图谱，
```
REALITY.md
```
中仅保留观测所需的信息。
```
AGENTS.md
```
中的「Reality」章节用指针形式：提示在行为请求前先读
```
REALITY.md
```
，说明表格第一行的含义，Ceiling 也在该文件中。（关闭任务时表格的处理方式见 vahta 技能第3节「工作与接力」中关闭前
```
reality-audit
```
的段落。）
跨项目内存 —— 模板默认值：值来自骨架模板，来源为
```
推导得出：模板默认
```
，无需询问人工。每个人都有个人图谱
```
@<handle>/mind
```
，不要询问相关问题：如果不存在——按 minding 技能创建图谱和角色；memory-guard 的路由和消息始终会包含该分支。仅工作目录中提交到仓库的文件（AGENTS.md、钩子文件）和项目图谱可以配置 Agent 行为——绝对不要用全局指令文件（
```
~/.claude/CLAUDE.md
```
、
```
~/.config/opencode/AGENTS.md
```
…）、运行载体的内存、用户自定义钩子；不要询问也不要创建全局文件。安装技能是交付，不是配置。影响流程和结果的偏好——放在 AGENTS.md 或项目图谱中；个人偏好——放在
```
@<handle>/mind
```
中。
反馈反思 —— 是否在会话结束或合并时反思关于方法的经验，并将有价值的内容写入工作图谱（工具边界，发给管理员，经去重后以案例形式记录）。模板默认值为是，来源为
```
推导得出：模板默认
```
，无需询问人工：骨架模板的 feedback-reflection 区域保留，合并钩子会触发该流程。否 —— 仅当有书面确认时（
```
已确认：确认人
```
）：完全删除该区域。
与工作流套件共存 —— 仅当检测到强制套件时（其技能在列表中，或其目录在插件缓存中；目前是 superpowers）：(1) 完全互操作（推荐）—— 引入
```
references/superpowers-interop.md
```
中的子章节 + spec-write 钩子；(2) 仅文字说明；(3) 跳过 —— 说明风险：套件的设计会话内容不会沉淀到图谱中。

人工通常不在线程中。 流程会自动更新

AGENTS.md

及派生文件；人工到场不是必要条件。上下文中所有针对插槽的「确认」、「询问」、「验证」都遵循以下顺序：

先完成所有不依赖回复的工作：审计、可推导的内容、质量门禁、钩子。
先查图谱和代码，再问同事——相邻边界的 Agent。 未解决的内容——放在同一个对齐任务中，通过 iskron 门户的
```
ask
```
指令提问，状态为「等待负责人回复」；「插槽：<名称>」行是可选的，放在与任务卡片不同的键下（同处的「不要用工作行覆盖问题键」规则），不要为单个插槽创建节点或任务。用
```
iskron_case(action="invite")
```
邀请知情的同事；委托任务用
```
say
```
指令，
```
to
```
指向对应位置，遵循 iskron 门户「一次性任务——任务内消息」的规则。收到他们的
```
answer
```
后回复
```
ack
```
，将答案连同他们的名字填入插槽。从图谱或代码中得到的事实标记为「推导得出」，不需要在任务中记录行；不明显的依据可以在任务中发消息说明。
仅原则性的剩余问题——通过任务主导方转达给人工。 变更授权范围、已接受的限制、故障成本，选择或创建图谱（项目边界，第一阶段第1点），或者来源间存在无法解决的冲突——这些属于原则性问题；仅仅是没有回复或信息本身不算原则性问题。在升级之前，请说明你在图谱和代码中验证了什么，询问了哪些人，以及为什么这需要所有者决策。
```
designer
```
会在报告中返回这类问题；主导方将其以消息形式发送到任务中（可选添加「插槽：…」行）。发起者会唤醒人工并等待回复：用
```
invite
```
邀请其位置；如果没有位置——邀请其与边界关联的角色（
```
karta=<所有者角色>
```
,
```
holon=<仓库边界>
```
）。如果没有可用的位置——问题保留在主导方的任务中；其余工作继续进行。
是缺口，不是猜测：插槽值为
```
''
```
，来源为
```
'未对齐 — 任务#N'
```
；「对齐状态」会引用该任务。非原则性的未知内容等待知情 Agent 或主导方的回复——以任务消息形式，可选添加行。门户启动流程会找到答案并自动填入，无需反复确认。

已得到答复的内容立即写入；单个插槽不会阻塞其他工作。

Шаг 2 — Бутстрап графа

第2步 — 图谱引导

Графа нет — согласуй имя,
```
iskron_realm(action="create")
```
.
Фокус-контур (граница проекта,
```
contains
```
от корня) — спроектируй
```
design
```
, создай
```
iskron_add_holon
```
;
```
#seq
```
— в обложку. Контур несёт атрибут
repository
—
```
хост/организация/репо
```
из
```
git remote get-url origin
```
, без протокола и
```
.git
```
(например
```
github.com/iskron-ai/skills
```
); по нему работает
```
attrs_filter="repository:…"
```
, и старт двери сверяет его с origin. Ставь при заведении и на рефреше; один контур — один репозиторий.
Делатель — стюард. Роль агента (
```
iskron_add_karta
```
,
```
manifested_as=adhikarin
```
, мотивация — дистиллят Production statement) проведи
```
steward
```
к фокус-контуру — эта роль, не старшая, иначе ориентация на контур не найдёт делателя. Нет svatantra-роли владельца и поиск такта 1, п. 1 её не нашёл — создай; привязка — по тому же шагу standing. Оба seq — в обложку.
Холон + стюард — корень поля интеграции; обход держит
```
integrity
```
. Об «общих поверхностях» не спрашивай и списка в AGENTS.md не пиши; не найденная зависимость — дефект модели (
```
design
```
,
```
weaving
```
).

如果没有图谱——确认名称后执行
```
iskron_realm(action="create")
```
。
核心边界（项目边界，根节点的
```
contains
```
子节点）—— 按
```
design
```
规则设计，执行
```
iskron_add_holon
```
创建；
```
#seq
```
写入前置元数据。边界必须带有
repository
属性——值为从
```
git remote get-url origin
```
提取的
```
主机/组织/仓库
```
，不带协议和
```
.git
```
（例如
```
github.com/iskron-ai/skills
```
）；
```
attrs_filter="repository:…"
```
基于该属性工作，门户启动流程也会将其与 origin 比对。创建和刷新时都要设置该属性；一个边界对应一个仓库。
执行者是管理员（steward）。 Agent 角色（
```
iskron_add_karta
```
，
```
manifested_as=adhikarin
```
，动机为生产环境声明的提炼）通过
```
steward
```
关联到核心边界——是这个角色，而非更高级的角色，否则边界定位会找不到执行者。如果没有所有者的 svatantra 角色，且第一阶段第1点的搜索也没找到——就创建；绑定按 standing 技能的同一步骤执行。两个 seq 都写入前置元数据。
Holon + steward 是集成领域的根节点；由
```
integrity
```
负责遍历。不要询问「公共接口」相关问题，也不要在 AGENTS.md 中写列表；找不到的依赖属于模型缺陷（
```
design
```
、
```
weaving
```
范畴）。

Шаг 3 — Гейт качества (строжайший в принятом мандате)

第3步 — 质量门禁（在已接受的授权范围内尽可能严格）

По каждому пункту: строжайший вариант для стека, трейд-офф одной строкой, источник по Шагу 1. Послабления — из принятого ограничения, откалиброванного ценой поломки, во фронтматтер по-инструментно; нового основания нет — принципиальный вопрос. Ужесточение уже-ослабленного гейта — обязательство рефакторинга: сперва измерь (прогон на предлагаемой строгости, число провалов); смена принятого ограничения без основания — тем же порядком владельцу, возможно отдельной веткой. Прочие части прогона её не ждут.

Линтер максимально строгий (

@typescript-eslint/strict

; Ruff

E,F,B,I,N,UP,RUF

;

golangci-lint

широкий;

clippy -- -D clippy::pedantic

Форматтер, auto-fix on save + pre-commit (Prettier,
```
ruff format
```
,
```
gofumpt
```
,
```
rustfmt
```
).
Тайпчекер strict, если есть (
```
tsc --strict
```
,
```
mypy --strict
```
/
```
pyright --strict
```
).
Pre-commit-хук: линтер + форматтер + тайпчек по staged-файлам.
Тесты + дисциплина (unit для библиотек; +integration для сервисов; +e2e для UI; порог покрытия для production) — в «Конвенции кода».
CI: lint + typecheck + tests на каждый пуш, падает на предупреждениях; обязателен для
```
production
```
.
Гейт — ВЫЗЫВАЕМЫЙ: один вызов, чья цепочка и есть правило (
```
npm run gate
```
,
```
make check
```
,
```
just check
```
); в
```
AGENTS.md
```
— его имя, не список шагов; CI зовёт тот же вызов. Собранный руками гейт теряет шаг молча и кончается зелёным. Цепочку вынужденно собирают руками — запиши почему и чем проверяется полнота.
CI-паритет: всякая проверка, способная упасть, гейтит PR, не только post-merge (кодоген, генерация схем и доков, сборка образа, миграции) — дотяни до PR; неустранимый зазор — готчей.

Команды — в «Команды», дисциплина — в «Конвенции кода».

针对每一项：选择技术栈支持的最严格方案，用一行说明权衡，来源按第1步规则。放宽规则需基于已接受的限制（由故障成本校准），按工具类别写入前置元数据；如果没有新的依据——属于原则性问题。收紧已放宽的门禁 需要有重构的承诺：先测量（按提议的严格度运行，统计失败数）；无依据地变更已接受的限制——按同样流程转给所有者，可能需要单独开分支。流程的其他部分不会等待这项工作。

Linter 采用最严格配置（

@typescript-eslint/strict

；Ruff 启用

E,F,B,I,N,UP,RUF

规则集；

golangci-lint

启用广泛规则；

clippy -- -D clippy::pedantic

）。

格式化工具，保存时自动修复 + pre-commit 检查（Prettier、
```
ruff format
```
、
```
gofumpt
```
、
```
rustfmt
```
）。
类型检查器 启用 strict 模式（如果支持）（
```
tsc --strict
```
、
```
mypy --strict
```
/
```
pyright --strict
```
）。
Pre-commit 钩子：对暂存文件运行 linter + 格式化工具 + 类型检查。
测试 + 规范（库需要单元测试；服务需要加集成测试；UI 需要加端到端测试；生产环境需要覆盖率阈值）—— 写入「代码规范」。
CI：每次推送都运行 lint + 类型检查 + 测试，警告即失败；生产环境项目必须启用。
门禁是可调用的：一条命令即可运行整个检查链（
```
npm run gate
```
、
```
make check
```
、
```
just check
```
）；
```
AGENTS.md
```
中只写命令名，不列步骤；CI 也调用同一个命令。手动拼接的门禁会悄悄漏掉步骤，最终显示通过。如果不得不手动拼接检查链——说明原因以及如何验证完整性。
CI 一致性：任何可能失败的检查都要作为 PR 的门禁，而不是仅在合并后运行（代码生成、schema 和文档生成、镜像构建、迁移）——都要前移到 PR 阶段；无法消除的差异——记录为陷阱。

命令写入「命令」章节，规范写入「代码规范」章节。

Шаг 4 — Хуки

第4步 — 钩子

Деливерабл — ритуалы, не файл. Определи харнессы репо и прошей поверхность каждого в рабочем дереве (hooks-файл Claude Code, plugin-директория OpenCode проекта; хуки Codex живут в CODEX_HOME, вне worktree, и не прошиваются) по

references/harness-surfaces.md

. Где поверхности нет — скажи, какой ритуал не автоматизирован: его держит проза «Жизненного цикла сессии». Конфиг формата, о котором гадаешь, не пиши.

Хук меряется ценой в контексте и тем, чему учит: одна строка и указатель на раздел AGENTS.md, не пересказ ритуала; срабатывание — на самом событии; не ставится, если та же строка приходит другим путём (описание тула, дверь скилла); не учит обратному правилу (не наказывает законный вопрос человеку). Блокирует только хук с однозначным путём (memory-guard).

Claude Code: хуки в

.claude/settings.json

(коммитится). Мержи, никогда не перезаписывай — записи других наборов остаются рядом в тех же массивах. Конверт:

"<Событие>": [ { "matcher"?: …, "hooks": [ { "type": "command", "command": "… echo '{\"hookSpecificOutput\":{\"hookEventName\":\"<Событие>\",\"additionalContext\":\"<строка>\"}}' || true" } ] } ]

— вложенность

событие → массив → hooks

легко перепутать. Открой
references/hooks.md
и спроецируй фильтры пуша и мержа оттуда байт-в-байт, с образцами проверки. Проецируя фильтр в JSON, удваивай каждую обратную косую (

\n

→

\\n

) и экранируй кавычки

\"

: иначе фильтр не компилируется, хук молчит навсегда, а

|| true

это прячет. Хуки прогон пишет сам, как всю дугу такта 2. Харнесс, спрашивающий разрешение на запись

.claude/settings.json

как на самомодификацию, — его ограничение, не норма: назови его словом в отчёте и проверь чтением, что запись легла. Хуки:

SessionStart
→ прочитать раздел «Старт» двери
```
iskron
```
до действий; адреса репо (граф, фокус-контур, seq ролей агента и владельца); стояние только на вахту (слово «вахта»,
```
start
```
, адрес места из окна, кадр), одним
```
iskron_stand
```
;
```
start <граф> <роль> <дело №N>
```
входит в дело; у субагента свой мост-спутник (
```
iskron_stand
```
с
```
satellite_of
```
,
```
join
```
,
```
leave
```
— на нём), на мосту запустившего он в граф не пишет. Протокол старта не пересказывай.
PostToolUse
/Bash — пуш:
```
git push
```
отработал (по исходу, справка не будит) → пуш не отгрузил ничего: самопроверка диффа, словарный проход по тексту PR, холодное ревью этапа (раздел о ревью AGENTS.md); отгрузка — мерж.
PostToolUse
/Bash — мерж: мерж форжи слил PR (по исходу) либо подтяжка ствола (
```
git checkout main && git pull
```
) → акты после мержа из «Жизненного цикла сессии» (протки, продвинуть карту, модусы по свидетельству, закрыть по оси, reconcile, фидбэк-рефлексия, если согласована, словарный проход; у работы по ссылке от агента — только семя превращения и модусы поставки). Сообщение хука называет и исключение — тем же списком, что раздел
```
AGENTS.md
```
, иначе ритуал и хук расходятся.
PreToolUse

Write|Edit|MultiEdit|NotebookEdit
— memory-guard: путь внутри локальной директории проектной памяти → блок (exit 2, маршрутизирующее сообщение в stderr). Маршрут — из слотов сообщения
```
references/hooks.md
```
: граф проекта по имени из «Граф» фронтматтера, раздел персистентности — заголовком, как он стоит в
```
AGENTS.md
```
, на языке файла, и личный граф
```
@handle/mind
```
.
PostToolUse

Write|Edit
— spec-write (только полный interop, по interop-штампу AGENTS.md): путь похож на design/spec-док → напоминание, что запись дизайна — граф.
Свежесть ветки — предложи pre-push-хук (
```
references/hooks.md
```
).

OpenCode: плагин в

.opencode/plugins/

по образцу

references/harness-surfaces.md

. Поток событий
ctx.event.subscribe
один на сервер OpenCode машины: плагин проекта видит

session.created

и прочие события сессий всех каталогов, и приветствие с адресами этого репо, легшее в чужую сессию, ставит её под чужую роль. Подписчик пишет только в сессию своего каталога: каталог события (

location.directory

события или его

data

) сверяется с

ctx.location.directory

канонизированными (realpath, при ошибке — строка, без завершающего разделителя) — одна папка приходит то

/tmp/…

, то

/private/tmp/…

, и сырое сравнение теряет свою сессию; чужая — пропуск. Хуки

ctx.tool.hook

будит только вызов в каталоге экземпляра; от них требуется одно — исполняться как написаны, без неопределённых имён и бросков, кроме guard на пути памяти. Приветствие несёт те же адреса, что

SessionStart

, отказ guard'а — тот же маршрут, что memory-guard Claude Code: слоты шаблона образца (

<Граф>

<Фокус-контур>

<Роль агента>

<Роль владельца>

) заполняются из фронтматтера AGENTS.md,

<Раздел персистентности>

— его заголовком, как он стоит в файле, — в плагине репо угловых скобок не остаётся. Проверка — из корня репо

node ~/.iskron-bridge/iskron-bridge.mjs check-rituals

, на прогоне и на рефреше: код 1 — дыра или поломка (строка называет плагин, что случилось, и починку), перепиши по образцу, прогони снова, назови в отчёте. Нет

check-rituals

--help

домашнего моста (мост старше) или нет самого моста (файла нет,

node

отвечает

MODULE_NOT_FOUND

) — прочти каждый

.opencode/plugins/*

глазами по этому правилу и назови в отчёте, что ревизор не гонялся.

Self-check: четыре базовых хука на месте (старт, пуш, мерж, memory-guard); хуков, снятых прежними контрактами (сторож незастывания на

Stop

, указатель момента writing на пишущих тулах), нет — на рефреше убери свои, не трогая чужих; spec-write есть тогда и только тогда, когда interop-штамп говорит

full

;

SessionStart

зовёт «Старт» двери

iskron

(не

entry

) с реальными адресами; фильтры пуша и мержа — байт-в-байт из

references/hooks.md

и проверены на образцах оттуда; отказ memory-guard — в хуке и в плагине OpenCode — называет граф репо, раздел персистентности заголовком из

AGENTS.md

@handle/mind

, без угловых скобок; голый запрет без маршрута (контракт до 24) — перепиши;

check-rituals

(или чтение по правилу) не нашёл в

.opencode/plugins/*

дыры и поломки; ни одна чужая запись не выпала.

交付物是仪式流程，不是文件。 先确定仓库使用的运行载体，然后按

references/harness-surfaces.md

的说明，为每个运行载体在工作目录中植入钩子（Claude Code 的 hooks 文件、项目的 OpenCode 插件目录；Codex 的钩子存在 CODEX_HOME 中，不在工作目录里，不需要植入）。如果某个运行载体没有对应的钩子接口——说明哪些仪式没有自动化：由「会话生命周期」的文字描述负责。不确定格式的配置不要写。

钩子的价值取决于上下文成本和它传递的信息：仅一行内容加指向 AGENTS.md 章节的指针，不要复述仪式流程；在对应事件触发时执行；如果同样的信息可以通过其他途径（工具描述、技能门户）传递，就不要加钩子；不要传递反向规则（不要惩罚合理的人工提问）。只有路径明确的钩子（memory-guard）才会阻塞操作。

Claude Code：钩子配置在

.claude/settings.json

中（需提交到仓库）。要合并，绝对不要覆盖——其他套件的配置要保留在同一个数组中。配置格式：

"<事件>": [ { "matcher"?: …, "hooks": [ { "type": "command", "command": "… echo '{\"hookSpecificOutput\":{\"hookEventName\":\"<事件>\",\"additionalContext\":\"<字符串>\"}}' || true" } ] } ]

——

事件 → 数组 → hooks

的嵌套结构很容易搞混。请打开
references/hooks.md
，将推送和合并过滤器从那里逐字节投影过来，包含验证示例。将过滤器投影为 JSON 时，每个反斜杠都要双写（

\n

→

\\n

），引号要转义

\"

：否则过滤器无法编译，钩子会永远静默，而

|| true

会掩盖这个问题。钩子配置由流程自动写入，和第二阶段的所有工作一样。如果运行载体将写入

.claude/settings.json

视为自修改操作而请求权限——这是它的限制，不是规范：请在报告中说明，并通过读取验证写入是否成功。

钩子列表：

SessionStart
→ 操作前先阅读 iskron 门户的「启动」章节；获取仓库地址（图谱、核心边界、Agent 和所有者的角色 seq）；仅在值守时执行站班（关键词「вахта」、
```
start
```
、窗口中的位置地址、帧），用一次
```
iskron_stand
```
完成；
```
start <图谱> <角色> <任务#N>
```
会加入任务；子 Agent 有自己的卫星桥接器（
```
iskron_stand
```
带
```
satellite_of
```
、
```
join
```
、
```
leave
```
都在子 Agent 侧执行），它不会通过发起者的桥接器写入图谱。不要复述启动协议。
PostToolUse
/Bash — 推送：
```
git push
```
执行完成后（按退出码判断，帮助输出不会触发）→ 如果推送没有提交任何内容：执行 diff 自检、PR 文本词汇检查、阶段冷评审（AGENTS.md 中的评审章节）；如果有推送内容：执行合并流程。
PostToolUse
/Bash — 合并：代码托管平台的合并操作完成 PR 合并（按退出码判断）或者拉取主干更新（
```
git checkout main && git pull
```
）后 → 执行「会话生命周期」中的合并后操作（推进、更新角色状态、按证据更新模式、按轴关闭、reconcile、如果已确认反馈反思则执行、词汇检查；如果是 Agent 链接过来的工作——仅执行转化种子和交付模式）。钩子消息中列出的例外项要和
```
AGENTS.md
```
章节中的列表完全一致，否则仪式和钩子会不一致。
PreToolUse

Write|Edit|MultiEdit|NotebookEdit
— memory-guard：如果路径在本地项目内存目录内 → 阻塞（exit 2，将路由消息输出到 stderr）。路由规则来自
```
references/hooks.md
```
的消息插槽：项目图谱按前置元数据「图谱」中的名称，持久化章节用
```
AGENTS.md
```
中的对应标题（与文件中的措辞一致），加上个人图谱
```
@handle/mind
```
。
PostToolUse

Write|Edit
— spec-write（仅完全互操作模式，按 AGENTS.md 的 interop 戳记判断）：如果路径看起来像 design/spec 文档 → 提示设计内容应该写入图谱。
分支新鲜度 —— 建议配置 pre-push 钩子（
```
references/hooks.md
```
）。

OpenCode：插件放在

.opencode/plugins/

中，按

references/harness-surfaces.md

的模板编写。ctx.event.subscribe
的事件流在机器的 OpenCode 服务器上是全局唯一的：项目插件能看到所有目录的

session.created

和其他会话事件，如果把本仓库的地址欢迎消息发到了其他目录的会话中，会导致该会话被错误地关联到其他角色。订阅者只能向自己目录的会话写入：将事件的目录（事件的

location.directory

或其

data

字段）与

ctx.location.directory

都规范化后再比对（用 realpath，出错则用原始字符串，不带末尾分隔符）—— 因为同一个目录可能显示为

/tmp/…

或

/private/tmp/…

，原始比对会找不到自己的会话；如果是其他目录的会话则跳过。

ctx.tool.hook

钩子仅在实例目录内的调用时触发；对它们的要求只有一个——按编写的逻辑执行，不要有未定义的名称和抛出异常，除了内存路径的 guard 之外。欢迎消息携带的地址与

SessionStart

相同，guard 的拒绝逻辑与 Claude Code 的 memory-guard 路由相同：模板中的插槽（

<图谱>

、

<核心边界>

、

<Agent 角色>

、

<所有者角色>

）从 AGENTS.md 的前置元数据填充，

<持久化章节>

用文件中的对应标题——仓库插件中不能有尖括号占位符。验证方式：在仓库根目录运行

node ~/.iskron-bridge/iskron-bridge.mjs check-rituals

，在运行和刷新时都要执行：返回码1表示有缺口或故障（输出行会说明哪个插件、出了什么问题、如何修复），按模板重写后重新运行，并在报告中说明。如果本地桥接器的

--help

中没有

check-rituals

（桥接器版本太旧）或者桥接器不存在（文件不存在，

node

MODULE_NOT_FOUND

）—— 请按此规则人工检查每个

.opencode/plugins/*

文件，并在报告中说明未运行自动检查。

自检项：四个基础钩子都已配置（启动、推送、合并、memory-guard）；旧合约移除的钩子（

Stop

事件的未冻结守卫、写入工具的 writing 时刻指针）如果存在——刷新时移除我们自己的，不要动别人的；spec-write 存在当且仅当 interop 戳记为

full

；

SessionStart

调用的是 iskron 门户的「启动」（不是

entry

），并携带真实地址；推送和合并过滤器是从

references/hooks.md

逐字节复制的，且已用其中的示例验证过；memory-guard 的拒绝消息——无论是 Claude Code 的钩子还是 OpenCode 的插件——都要提到仓库图谱、

AGENTS.md

中的持久化章节标题和

@handle/mind

，没有尖括号；旧的无路由纯禁止规则（合约24及之前）——需要重写；

check-rituals

（或人工按规则检查）没有在

.opencode/plugins/*

中发现缺口和故障；没有任何第三方配置被意外删除。

Шаг 5 — Гигиена репозитория

第5步 — 仓库卫生

Закоммить

.claude/settings.json

, заигнорь

.claude/settings.local.json

; широкий игнор

.claude/

— добавь

!.claude/settings.json

. Проверь

git check-ignore -v .claude/settings.json .claude/settings.local.json

Трекаемые secret/env:
```
git ls-files '.env*' '*secret*' '*local*'
```
; трекается реальный (не
```
.example
```
) — в «Конвенции кода»: локальные правки не стейджить (
```
git update-index --skip-worktree <file>
```
), никогда
```
git add -A
```
/
```
commit -a
```
.
Директория проектной памяти (
```
~/.claude/projects/<encoded-path>/memory/
```
): эвакуируй, затем заморозь. Решения и ограничения → граф; ритуалы → AGENTS.md; готчи → дом по «Раскладке»; состояние ветки → git и PR; серверы и датированные долги → граф проекта; собственное пользователя → его личный граф (minding); предпочтения — по Шагу 1. Затем
```
MEMORY.md
```
— однострочный стаб-запрет («состояние живёт в репо или графе — см. AGENTS.md, раздел <заголовок раздела о персистентности, как он стоит в файле>»), memory-guard блокирует дальше. Стаб поверх непрочитанного уничтожает то, что должен был переселить.
Форжа и CLI — выведи, не предполагай GitHub:
```
git remote -v
```
→
```
gh
```
(GitHub),
```
fj
```
(Forgejo/Codeberg),
```
glab
```
(GitLab),
```
tea
```
(Gitea); проверь установку и вход, назови в «Git-воркфлоу» с командой наблюдения. Неопознанный хост — спроси.
«Стек», «Команды», «Структура проекта», «Конвенции кода» — реальное содержимое по зрелости; пусто в первый день — нормально,
```
TBD
```
— нет.
HANDOVER.md
не заводится, и AGENTS.md говорит почему (раздел скелета). Файл есть — эвакуируй по домам (git, PR с номером дела, дело, модусы узлов) и удали.
```
README.md
```
корня — короткий, человеку, AGENTS.md не дублирует. README компонента по «Раскладке» — карта кода делателя, компактно; прогон их не пишет.

提交

.claude/settings.json

，将

.claude/settings.local.json

加入 gitignore；如果 gitignore 宽泛地忽略了

.claude/

——添加

!.claude/settings.json

。用

git check-ignore -v .claude/settings.json .claude/settings.local.json

验证。

被跟踪的 secret/env 文件：运行
```
git ls-files '.env*' '*secret*' '*local*'
```
；如果有真实的（非
```
.example
```
）文件被跟踪——在「代码规范」中说明：本地修改不要暂存（
```
git update-index --skip-worktree <file>
```
），绝对不要用
```
git add -A
```
/
```
commit -a
```
。
项目内存目录（
```
~/.claude/projects/<编码路径>/memory/
```
）：先迁移内容，再冻结。决策和限制 → 图谱；仪式流程 → AGENTS.md；陷阱 → 按「布局」规则归属；分支状态 → git 和 PR；服务器和带日期的待办 → 项目图谱；用户个人内容 → 其个人图谱（minding）；偏好按第1步规则处理。然后创建
```
MEMORY.md
```
——单行占位禁止文件（「状态存储在仓库或图谱中——参见 AGENTS.md 的 <持久化章节标题，与文件中的措辞一致> 章节」），之后由 memory-guard 阻塞写入。在未读取内容的情况下直接创建占位文件会销毁本该迁移的内容。
代码托管平台和 CLI——推导得出，不要默认是 GitHub：从
```
git remote -v
```
判断 →
```
gh
```
（GitHub）、
```
fj
```
（Forgejo/Codeberg）、
```
glab
```
（GitLab）、
```
tea
```
（Gitea）；验证 CLI 是否已安装和登录，在「Git 工作流」中说明并给出查看命令。如果是未识别的托管平台——询问人工。
「技术栈」、「命令」、「项目结构」、「代码规范」——根据仓库成熟度填写真实内容；第一天为空是正常的，但不要写
```
TBD
```
。
不要创建
HANDOVER.md
，AGENTS.md 中会说明原因（骨架模板的章节）。如果该文件已存在——将内容按归属迁移（git、带任务编号的 PR、任务、节点模式）然后删除文件。
根目录的
```
README.md
```
要简短，面向人类，不要重复 AGENTS.md 的内容。按「布局」规则存在的组件 README——是执行者的代码地图，内容要紧凑；本流程不会写入这些文件。

Шаг 6 — Ролевые суб-агенты делегирования

第6步 — 委托用的角色子 Agent

Доктрина и шаблоны файлов —

references/delegation.md

; прозой AGENTS.md не проецируется.

Claude Code, всегда:
```
.claude/agents/reader.md
```
и
```
searcher.md
```
(средний тир),
```
worker.md
```
,
```
designer.md
```
,
```
reviewer.md
```
и
```
verifier.md
```
(верхний: исполнение, суждение, ревью и приёмка) — алиасы
```
sonnet
```
/
```
opus
```
;
```
haiku
```
— ни одной роли.
```
verifier
```
и
```
reviewer
```
— даже без рантайма: они делают
```
REALITY.md
```
и ритуал ревью исполнимыми;
```
searcher
```
— только чтение, поиск кандидатов «что граф знает о X» вне окна сессии: находки — зацепки, позвавший принимает их сверкой с окрестностью. Ни одна роль в граф не пишет; ткачество ведёт сам ведущий.
OpenCode (
```
opencode.json
```
/
```
.opencode/
```
или слово пользователя):
```
.opencode/agents/
```
те же шесть,
```
mode: subagent
```
, модель пришпилена в каждом файле из настройки пользователя (спроси или прочти
```
opencode.json
```
); из референса id не копируй; верхний тир — только Claude Opus или GPT-6.1 Sol.
Запись моста-спутника — одна форма на все ОС (
```
delegation.md
```
, «Форма записи одна на все ОС»):
```
command: node
```
,
```
args
```
—
```
-e
```
с кодом, собирающим путь к домашнему мосту из
```
os.homedir()
```
, затем
```
--
```
и
```
--satellite
```
; копируй блок из референса дословно. Проверена живьём на macOS (Claude Code 2.1.285); на Windows не сверена. Машинного пути в файле нет — он коммитится как есть. Прежняя проекция (
```
sh -c
```
, контракт до 18; абсолютный путь) — перепиши этим блоком.
```
description
```
— канал маршрутизации: триггер-образно — когда звать, что вернётся, чему не доверять.
Объёмное суждение без записи в граф (проекция файлов прогона
```
iskronify
```
, разбор слотов против кода) идёт роли
```
designer
```
; проектирование в графе, запись, ткачество, решения владельца и диалог остаются ведущему; приёмное (ревью диффа, приёмка утверждения) идёт холодному — ролевой файл законен; поиск по вопросу, только чтение, — тоже.
Мержи: одноимённый агент другого набора — вложи своё или переименуй свой (
```
iskron-reader
```
). Своя прежняя проекция (тело прошлого контракта) — перепиши текущим телом; хвост репо (
```
delegation.md
```
, «Хвост репо») — перенеси как есть; чужое тело — не трогай.
Self-check: файлы парсятся; каждый файл Claude Code несёт свою запись моста-спутника
```
iskron-sub-<роль>
```
— общей записи
```
iskron-sub
```
(контракт до 17) ни в одном нет; форма записи —
```
node -e
```
из референса,
```
sh -c
```
и машинного пути нет ни в одном;
```
doctor
```
из корня репо показывает файлы проекта в разделе «субагенты» без строк
```
НАДО:
```
(на английской поверхности —
```
TODO:
```
; есть — исполни их до отчёта); тела
```
worker
```
,
```
verifier
```
,
```
reviewer
```
,
```
designer
```
несут вход в дело строкой запуска и на общем мосту не зовут
```
iskron_stand
```
,
```
join
```
,
```
leave
```
(
```
reader
```
и
```
searcher
```
в дело не пишут); ни одно тело не разрешает запись в граф; файлов
```
searcher
```
и
```
designer
```
нет или
```
reader
```
пришпилен к
```
haiku
```
(контракт до 18) — допиши и перепиши;
```
worker
```
пришпилен к
```
sonnet
```
(контракт до 23) — перепиши на
```
opus
```
; своя прежняя проекция
```
weaver
```
(контракт до 22) — удали;
```
verifier
```
и
```
reviewer
```
читают
```
REALITY.md
```
репо; пришпиленные модели существуют; AGENTS.md не несёт доктрины делегирования (максимум указатель); хвост репо не потерян — по диффу каждого ролевого файла строки под
```
## Этот репо
```
и ключи фронтматтера сверх блока те же до и после прогона; у прежней проекции без заголовка каждая снятая строка, называющая предмет репо, стоит в хвосте, а снятые родовые названы в отчёте; чужие файлы не перезаписаны, свои прежние не оставлены.
Роль, спроецированная прогоном, в той же сессии может не зваться по имени (каталог ролей читается на старте) — скажи это в отчёте; холодное ревью этого прогона тогда идёт общим суб-агентом с телом роли в брифе, модель — только верхнего тира (Claude Opus или GPT-6.1 Sol): параметром вызова, где харнесс его даёт; где не даёт — моделью сессии, только если она из них, и отчёт это говорит; иначе ревью этим ходом не идёт — отчёт говорит и это.

Шаг 7 — Финализация

第7步 — 收尾

Тело — в AGENTS.md
(Codex и OpenCode читают нативно), таблица носителей — в REALITY.md
корня. Указатель
CLAUDE.md
— только для Claude Code; форма по
```
git config core.symlinks
```
и платформе:
- симлинки работают:
```
ln -s AGENTS.md CLAUDE.md
```
  ;
- не работают (Windows): копия байт-в-байт — её читает буквально любой тул, но это второй источник истины: перегенерируется каждым прогоном, числится в «Что обновлять когда», правки — только в
```
AGENTS.md
```
  ; либо однострочный
```
CLAUDE.md
```
  с
```
@AGENTS.md
```
  (без бэктиков: код-спан глушит импорт) — там, где копия хуже импорта, понятного одному Claude Code. Работающий указатель любой формы не переделывай. Пер-харнессные детали (merge root→cwd у Codex,
```
AGENTS.override.md
```
  ) —
```
references/harness-surfaces.md
```
  .
Легаси-конфиг: скелеты — рама; производные факты ре-спроецируй, авторское сохрани, сверив с кодом; проектное без слота — в «Конвенции кода» или новую секцию. Таблица Reality внутри
```
AGENTS.md
```
(контракт до 16) — переезжает в
```
REALITY.md
```
строками целиком, датированные наблюдения из неё — узлами в граф (не удаляются), в
```
AGENTS.md
```
остаётся указатель. Содержательный
```
CLAUDE.md
```
— влей в
```
AGENTS.md
```
, замени указателем. Файлы «Раскладки» не вливаются — только сверяются ссылки. Один источник на заботу.
Interop full / prose-only: подсекция
```
### Workflow-suite interop (superpowers)
```
в конце «Жизненного цикла сессии» из
```
references/superpowers-interop.md
```
(только деплоируемая часть) со штампом
```
*(interop: <full|prose-only> — verified against superpowers@<version> — re-check on suite upgrade)*
```
; на рефрешах аудируй её как любую заботу.
Проверочный проход (на равных с плотностью): каждая производная строка обоих файлов против источника — весь артефакт, не только тронутое. Не привязывается к источнику — авторское суждение (сохрани) или догадка (вырежи).
Проход плотности: «меняет ли строка то, что агент делает?» — режь нарратив и обоснования (в граф). Блоки канонов не трогаются — сверяются с узлом байт-в-байт.
Автоматический чекер «заявленное vs фактическое» — согласованный не-дефолт; строить — только узкий пер-репо по именованным строкам, обобщённый — никогда. Дисциплина — пере-прогон.

Штамп: хвостовая строка

AGENTS.md

—

*(iskronify: контракт <число из шапки>, штамп <YYYY-MM-DD> — прогони заново, когда описание установленного iskronify называет контракт выше или когда источники, из которых выведен этот файл, сдвинулись после этой даты.)*

. На рефреше перезапиши; двух не оставляй.

Обложка — YAML-фронтматтер, от первой строки
```
---
```
до закрывающей
```
---
```
, не раздел тела. Плоские пары ключей:
```
'Граф': '@owner/slug (rN)'
```
и
```
'Граф — источник': 'выведено'
```
; имена слотов — как в скелете, у каждого свой ключ
```
 — источник
```
со значением
```
выведено
```
/
```
согласовано: кто
```
/
```
не согласовано — дело №N
```
. Все значения — строки в одинарных кавычках; одинарную кавычку внутри удвой. Дырка — пустая строка значения и источник с делом; «Согласование» — дело либо
```
пусто
```
. Старую таблицу перенеси без потери значений и источников, убери раздел «Обложка»; тело оставь ритуалам. Не добавляй служебные ключи харнесса (например,
```
paths
```
): это метаданные проекта, не фильтр загрузки инструкций.
```
CLAUDE.md
```
-симлинк продолжает указывать на тот же файл. Проверь YAML-парсером плоскость и строковые значения, а указатель — чтением
```
CLAUDE.md
```
против
```
AGENTS.md
```
.
Готчи в
AGENTS.md
не живут: при
```
GOTCHAS.md
```
по «Раскладке» — строкой там, узел не обязателен (ловушка — знание о коде; узел, если есть, — ссылкой); иначе узел графа на контуре, в файле и коде —
```
(граф, #N)
```
. Строк
```
GOTCHAS.md
```
в граф не переносить.
REALITY.md
проверен: носители опираются на граф, код или названный ответ, их достижимость проверена либо ограничена Ceiling; ни одного датированного замера; раздел «Reality» в
```
AGENTS.md
```
— указатель без строк таблицы.
Во фронтматтере ни одного пустого значения при источнике «не согласовано» без №дела и ни одного плейсхолдера
```
<…>
```
скелета в значении; ни одна заметка
```

```
не пережила в обоих файлах.
Каждое имя скилла в проецируемых файлах (
```
AGENTS.md
```
,
```
REALITY.md
```
, хуки, ролевые файлы) разрешается как записано на канале установки репо — сверь с живым реестром, не по памяти; невызываемое имя не падает, а молчит. Механической сверки в прокачиваемом репо может не быть — тогда вручную, как имена тулов по живой поверхности сервера. Тело, едущее в несколько харнессов (ролевой файл), формы вызова не несёт вовсе — называй вызовы тулов.
На бутстрап-пуше граф отражает перемену структурой (контур, роль, готчи, карта); выравнивание — словом в деле, ждущий слот — строкой «слот: …».
Передай эстафету: закончи тизером роадмапа (скилл
```
product-roadmap
```
, quick-режим) по свежему репо, названным по имени. Назови обновлённые файлы и открытые слоты фронтматтера — дело №N, на ком и чего ждут; продолжение такта 2 не требует слова человека. Принципиальные вопросы владельцу — отдельно, с проверенными источниками; нет их — так и скажи. По поручению отчёт и остаток получает ведущий дела.

正文写入 AGENTS.md
（Codex 和 OpenCode 原生支持读取），载体表写入根目录的 REALITY.md
。CLAUDE.md
指针——仅用于 Claude Code；格式根据
```
git config core.symlinks
```
和平台决定：
- 支持符号链接：
```
ln -s AGENTS.md CLAUDE.md
```
  ；
- 不支持（Windows）：逐字节复制——任何工具都能读取，但这是第二真相源：每次运行都会重新生成，记入「何时更新什么」，修改仅在
```
AGENTS.md
```
  中进行；或者创建单行
```
CLAUDE.md
```
  ，内容为
```
@AGENTS.md
```
  （不要加反引号：代码 span 会禁用导入）——适用于复制方案不如导入方案好的场景（仅 Claude Code 支持导入）。任何形式的可用指针都不要改动。各运行载体的特殊细节（Codex 的 root→cwd 合并、
```
AGENTS.override.md
```
  ）——见
```
references/harness-surfaces.md
```
  。
旧配置处理：骨架模板作为框架；派生事实重新投影，主观内容对照代码验证后保留；没有对应插槽的项目相关内容——放入「代码规范」或新建章节。
```
AGENTS.md
```
内部的 Reality 表格（合约16及之前）——整行迁移到
```
REALITY.md
```
，其中带日期的观测内容转为图谱节点（不删除），
```
AGENTS.md
```
中仅保留指针。有实质内容的
```
CLAUDE.md
```
——合并到
```
AGENTS.md
```
中，替换为指针。「布局」相关文件不合并——仅验证链接。每项配置只有一个真相来源。
Interop full / prose-only：在「会话生命周期」末尾添加
```
### Workflow-suite interop (superpowers)
```
子章节，内容来自
```
references/superpowers-interop.md
```
（仅可部署部分），并带有戳记
```
*(interop: <full|prose-only> — verified against superpowers@<版本> — re-check on suite upgrade)*
```
；刷新时像其他配置项一样审计该章节。
验证检查（与紧凑性同等重要）：两个文件的每一行派生内容都要对照来源验证——检查整个产物，而不仅仅是修改过的部分。无法关联到来源的内容——要么是主观判断（保留），要么是猜测（删掉）。
紧凑性检查：问「这一行会改变 Agent 的行为吗？」——删掉叙述性和背景说明内容（移到图谱）。规范块不要改动——逐字节与节点比对验证。
「声明 vs 实际」的自动检查器——需要明确确认非默认配置才构建；仅针对特定仓库的命名行构建窄范围检查，绝对不要构建通用检查器。规范靠重复运行来保障。

戳记：

AGENTS.md

的最后一行是

*(iskronify: контракт <顶部的合约版本号>, штамп <YYYY-MM-DD> — прогони заново, когда описание установленного iskronify называет контракт выше или когда источники, из которых выведен этот файл, сдвинулись после этой даты.)*

。刷新时重写该行；不要保留多个戳记。

封面是 YAML 前置元数据，从第一行
```
---
```
到闭合的
```
---
```
，不属于正文部分。使用扁平键值对：
```
'Граф': '@owner/slug (rN)'
```
和
```
'Граф — источник': 'выведено'
```
；插槽名称与骨架模板一致，每个插槽都有对应的
```
 — источник
```
键，值为
```
выведено
```
/
```
согласовано: 确认人
```
/
```
не согласовано — задача №N
```
。所有值都是单引号包裹的字符串；内部的单引号要双写。缺口的值为空字符串，来源带任务编号；「Согласование」的值为任务编号或
```
пусто
```
。旧的表格内容要完整迁移值和来源，删除「Обложка」章节；正文仅保留仪式流程。不要添加运行载体的内部键（比如
```
paths
```
）：这是项目元数据，不是指令加载过滤器。
```
CLAUDE.md
```
符号链接继续指向同一个文件。用 YAML 解析器验证结构扁平且值都是字符串，通过读取
```
CLAUDE.md
```
和
```
AGENTS.md
```
验证指针对应关系。
陷阱（Gotcha）不存在于
AGENTS.md
中：如果按「布局」规则有
```
GOTCHAS.md
```
——就写在该文件里，不强制要求有图谱节点（陷阱是关于代码的知识；如果有节点就加链接）；否则用图谱边界上的节点表示，在文件和代码中用
```
(图谱, #N)
```
引用。不要将
```
GOTCHAS.md
```
的行迁移到图谱中。
REALITY.md
已验证：载体基于图谱、代码或指定的确认信息，其可访问性已验证，或受 Ceiling 限制；没有带日期的测量数据；
```
AGENTS.md
```
中的「Reality」章节是指针，没有表格行。
前置元数据中，没有任何「未对齐」来源的值为空且不带任务编号；值中没有任何骨架模板的
```
<…>
```
占位符；两个文件中都没有残留的
```

```
注释。
投影文件中的每个技能名称（
```
AGENTS.md
```
、
```
REALITY.md
```
、钩子、角色文件）都要与仓库安装通道中的记录一致——对照实时注册表验证，不要靠记忆；不可调用的名称不会报错，只会静默失效。待升级的仓库可能没有自动校验机制——那就手动校验，就像对照服务器实时接口验证工具名一样。会被多个运行载体加载的文件（比如角色文件）不要包含调用格式——仅提及工具调用名称。
引导推送时，图谱通过结构变更反映更新（边界、角色、陷阱、角色卡）；对齐状态通过任务消息更新，待处理插槽用「插槽：…」行记录。
接力传递：最后用
```
product-roadmap
```
技能的快速模式为新仓库生成一个简短的路线图预告，按仓库名称命名。列出更新的文件和前置元数据中未解决的插槽——说明任务编号#N、负责人和待办事项；第二阶段的继续不需要人工参与。给所有者的原则性问题单独列出，附带来源验证结果；没有问题就如实说明。如果是委托任务，报告和剩余事项交给任务主导方。