integrity

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Целостность в Искроне — волновой фронт превращения

Iskron中的完整性——变更的波前

Bianhua — ХОЛИСТИЧЕСКАЯ перемена, кросс-контурная по определению. Его карта показывает, что его двигает (anga); она молчит о том, чего оно коснётся. Этот скилл делает волновой фронт видимым: каждая вовлечённая часть графа получает явный вопрос — «задето ли? спроектируй адаптацию» — чтобы превращение не могло честно свершиться, пока его воздействие не рассмотрено.

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

Пять входов:

задача звучит как «интеграция чего-то» — особенно в сотрудничестве делателей — режим спецификации интеграции (Режим 0 ниже): сначала граф, потом работа;
начинается сущностное изменение или идёт холодное ревью диффа — режим поля интеграции изменения (Режим 1): холон репозитория + его steward + узлы изменения;
превращение только что создано и телос принят владельцем (сюда передают assembly, шаг 5, и design, Фаза 4) — прямой протокол ниже;
пользователь просит проверить существующее превращение на целостность / воздействие — тот же прямой протокол;
прозаический артефакт заявляет опору на граф и требует проверки — режим claim-аудита (Режим 3 ниже).

Bianhua 是整体性的变革，本质上具有跨边界性。它的图谱展示了驱动它的因素（anga）；但对于它会波及什么，图谱并未说明。本skill可让波前变得可见：图谱中每个涉及的部分都会收到一个明确的问题——「是否受到影响？请设计适配方案」—— 只有当变更的所有影响都被评估后，变更才算真正完成。

该skill背后遵循通用的波定律：任何可修改的节点都有其来源（输入——对它的要求）和消费者（输出——从它发出的波）；修改不是一个点状行为，而是接力链上的事件，只要波的影响还没被评估，修改就不算完成——哪怕节点本身已经修复。变更的边界约束就是这一定律在变更尺度上的体现。

五个输入场景：

任务表述为**「某事物的集成」——尤其是在执行者协作的场景下—— 对应集成规范模式**（下文模式0）：先构建图谱，再开展工作；
实质性变更启动，或正在进行diff冷评审 —— 对应变更集成范围模式（模式1）：仓库holon + 其steward + 变更节点；
变更刚创建且所有者已接受其telos（assembly第5步、design第4阶段的输出会流转到这里）—— 执行下文的直接协议；
用户要求检查现有变更的完整性/影响范围 —— 同样执行直接协议；
文本类工件声称基于图谱构建，需要验证 —— 对应claim审计模式（下文模式3）。

Режим 0 — спецификация интеграции: сначала граф

模式0 —— 集成规范：先构建图谱

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

Разведка жизненных циклов. Обе стороны передачи:
```
iskron_orient(lens="trace")
```
по предмету передачи с каждой стороны границы — где рождается, кто должен потребить, где эстафета рвётся. Затем волновой фронт (протокол ниже) — чего ещё коснётся передача.
Впиши недостающее. Феномены и крии, которых ещё нет, встают в графе в модусах замысла — ontic
```
anagata
```
, epistemic не выше
```
anumita
```
, volitive
```
chanda
```
/
```
adhimoksha
```
(канон стартовой тройки — writing). Передаточный феномен на границе — сердце спецификации: его рождение и потребление и есть интеграция.
Спрашивай и тки по ходу. Вопросы соседу — в деле интеграции (ниже); вопрос по сути, нужный позднему читателю, — ещё и вимаршей; подразумеваемые-но-непрошитые связи — weaving. Решение, принятое в разговоре, немедленно вносится в граф; изменившаяся ситуация — немедленно отражается: разговор — где решение случается, граф — где оно существует.
Потом работа — по спецификации (вахта: её разметка замысла и есть эта спецификация, §2c совпадает), по ходу — уточнение спецификации, никогда не молчаливый дрейф от неё.
Валидация. Поставка в CI; сведение разметки с отгруженным (вахта, закрытие такта); отчёт: что специфицировано, что сделано, что разошлось. И чужой взгляд: стюард смежной поверхности (steward-стрелки задетых контуров называют его) принимает интерфейс, спецификацию и отчёт — не код — карточкой в деле интеграции.

Это рефлексивный цикл деятельности — план, действие, рефлексия результата, — смазанный коммуникацией; план живёт в графе, а не в терминале.

集成始终是在生命周期闭环的框架下，将某物从某处传递到另一处：某物诞生于一个边界内，必须在另一个边界内被消费，且这个接力必须跨越边界。因此集成工作不是从代码开始，而是从图谱生成的规范开始——且规范是一个图谱集群，而非文档。

生命周期调研。 针对传递的双方，在边界两侧对传递对象执行
```
iskron_orient(lens="trace")
```
—— 明确它在哪里诞生、谁应该消费它、接力链在哪里断裂。随后执行波前分析（见下文协议）—— 明确这次传递还会波及哪些内容。
补全缺失项。 尚未存在的phenomenon和kriya，以构想模式加入图谱——ontic模式为
```
anagata
```
，epistemic模式不高于
```
anumita
```
，volitive模式为
```
chanda
```
/
```
adhimoksha
```
（初始三元组的规范为writing）。边界上的传递phenomenon是规范的核心：它的诞生和消费过程就是集成本身。
边询问边编织。 对相邻方的问题——记录在集成事项中（见下文）；对本质问题的疑问（后续读者需要了解的）——同时记录为vimarsha；隐含但未被显式关联的连接——通过weaving补全。对话中达成的决策会立即录入图谱；变化的情况也会立即同步：对话是决策发生的地方，图谱是决策存续的地方。
随后按规范开展工作（Vakhta：其构想标记就是该规范，与§2c一致），过程中可对规范进行细化，但绝不允许无声地偏离规范。
验证。 交付到CI；将标记与已交付内容对齐（Vakhta，周期关闭）；输出报告：已规范内容、已完成内容、存在差异内容。同时需要第三方评审：相邻边界的steward（受影响边界的steward箭头会指向他）通过集成事项中的卡片验收接口、规范和报告——而非代码。

这是一个反思性的活动循环——计划、执行、结果反思——由沟通串联；计划存续于图谱中，而非终端里。

Дело интеграции

集成事项

Вимарша

posed_to

стюарду соседа никого не будит — её читают ориентацией по поводу (standing, «Обмен»). Поэтому интеграция, которой нужна другая сторона сейчас, идёт делом на передаточном феномене; вимарша держит только суть, нужную позднему читателю. Разговор — standing, «Обмен»; карточки и

ack

— дверь iskron, «Ожидание от делателя»; ведение и закрытие — architect, «Ведение дела».

Открывает сторона, начинающая интеграцию, на передаточном феномене:
```
open_room
```
при его записи — создании на шаге 2 или
```
iskron_update
```
, если он уже есть. Сначала
```
iskron_case(action="at", node=<феномен>)
```
: дело на нём уже открыто — войди в него, второе не заводи. Работа уже идёт в деле —
```
parent_room
```
.
Зовёт steward-роль каждого задетого контура — её называет
```
iskron_orient(focus=<контур>)
```
, — и своей стороны, если это не твоя роль. За роль кто-то стоит на доске —
```
invite
```
со
```
standing
```
; никто —
```
iskron_case(action="invite", karta=<роль-стюард>, holon=<её контур>)
```
, приглашение ждёт, пока за роль встанут.
Карточки —
```
ask
```
роли-стюарду, по предмету на карточку: форма стыка — передаточный феномен, кто производит и кто потребляет, к какому сроку —
```
choice
```
с твоей рекомендацией; сам стык принимается пробой,
```
yes_no
```
отвечает принимающая сторона (architect, «Стык согласуют до работы — пробой»); приёмка соседом спецификации, интерфейса и отчёта (шаг 5) —
```
yes_no
```
. Ответ —
```
ack
```
и тем же ходом в граф, что он решил: феномен, потребляющая крия и её модусы, отвеченная вимарша. Работа через границу — «Разовая задача — слово в деле» двери iskron.
Закрывается, когда интегрировали обе стороны — строка каждой с наблюдённым исходом под своим ключом («интегрировано: <контур>»), не под ключом карточки до её
```
ack
```
(дверь iskron, «Ключ вопроса не перекрывай строкой работы»), — и отчёт «специфицировано, сделано, разошлось» стоит в деле; остаток — в графе (открытые вимарши
```
posed_to
```
отвечающей роли, неотгруженные крии в
```
anagata
```
), не только в журнале. Затем
```
propose_close
```
ведущего.

指向相邻方steward的

posed_to

类型vimarsha不会主动通知任何人——人们通过定向浏览（standing，「交流」）来查看它。因此需要另一方立即参与的集成，会以传递phenomenon上的事项形式推进；vimarsha仅保留后续读者需要的核心信息。对话属于standing（「交流」）范畴；卡片和

ack

属于iskron门（「等待执行者响应」）；事项的管理和关闭属于architect（「事项管理」）范畴。

由发起集成的一方在传递phenomenon上开启：在步骤2创建phenomenon时执行
```
open_room
```
，如果phenomenon已存在则执行
```
iskron_update
```
。首先执行
```
iskron_case(action="at", node=<phenomenon>)
```
：如果该phenomenon上已经有事项——直接进入即可，不要重复创建。如果工作已经在事项中进行——使用
```
parent_room
```
关联。
邀请每个受影响边界的steward角色——可通过
```
iskron_orient(focus=<边界>)
```
获取该角色——如果己方不是该角色，也需要邀请己方的steward。如果看板上有人担任该角色——以
```
standing
```
状态发送
```
invite
```
；如果无人担任——执行
```
iskron_case(action="invite", karta=<steward角色>, holon=<其所属边界>)
```
，邀请会等待有人担任该角色后生效。
卡片：向steward角色发送
```
ask
```
，卡片上的内容包括：对接形式——传递phenomenon、生产者和消费者、截止时间——附带你的建议的
```
choice
```
选项；对接本身通过试用验收，由接收方用
```
yes_no
```
答复（architect，「工作前先通过试用确认对接」）；相邻方对规范、接口和报告的验收（步骤5）——也用
```
yes_no
```
。答复为
```
ack
```
，且决策内容会同步录入图谱：包括phenomenon、消费侧kriya及其模式、已答复的vimarsha。跨边界工作属于iskron门的「一次性任务——事项中的承诺」范畴。
关闭条件：双方都完成集成——每一方的结果都以各自的键（「已集成：<边界>」）记录，在卡片收到
```
ack
```
前不要用工作记录覆盖卡片键（iskron门规则：「不要用工作行覆盖问题键」）；且事项中已存在「已规范、已完成、有差异」的报告；剩余事项记录在图谱中（指向负责角色的未关闭
```
posed_to
```
vimarsha、处于
```
anagata
```
状态的未交付kriya），而非仅存在于日志中。之后由负责人执行
```
propose_close
```
。

Режим 1 — поле интеграции изменения: перед кодом и на холодном ревью

模式1 —— 变更集成范围：编码前与冷评审阶段

Режим только читает. «Протокол» ниже пишет в граф — он к этому режиму не относится; холодный ревьюер до него не идёт.

Для определения поля не нужен авторский список «общих поверхностей». Достаточны постоянные опоры репозитория — фокус-холон и steward-роль — плюс узлы, чьё воплощение меняется. Всё остальное выводится заново: список, записанный прозой при бутстрапе, устаревает в ходе работы и подменяет обход.

本模式为只读模式。 下文的「协议」会对图谱进行写入——不属于本模式范畴；冷评审人员不会执行到协议步骤。

确定范围不需要作者提供的「公共表面」列表。只需要仓库的固定锚点——焦点holon和steward角色——加上其实现发生变更的节点即可。其余内容都可以重新推导：初始化阶段用文本记录的列表会在工作过程中过时，不应直接用它替代遍历操作。

1. Назови вход

1. 明确输入

До кода: дело работы и его зачин (или ведущая вимарша, если работа идёт от вопроса по сути) и крии, феномены или правила, которые изменение собирается воплотить. Если нужного поведения в графе нет — сначала
```
design
```
: область интеграции нельзя вывести из пересказа намерения.
На ревью: дифф всей ветки против транка и референсы на все узлы графа, чьё воплощение он меняет. Дифф показывает кодовую поверхность, но не заменяет связность графа; ретроспективный пересказ автора не считается референсом.
Всегда: фокус-холон репозитория и его steward из AGENTS.md. Холон задаёт границу, steward — первый адрес для того, что граф выводит наружу.

编码前： 工作事项及其起因（如果工作源于本质问题，则为核心vimarsha），以及变更计划落地的kriya、phenomenon或规则。如果图谱中不存在所需的行为——先执行
```
design
```
：集成范围无法从意图的转述中推导出来。
评审阶段： 整个分支与主干的diff，以及对所有其实现被变更的图谱节点的引用。diff能展示代码层面的变化，但不能替代图谱的关联性；作者的事后复述不算作引用。
所有场景： 仓库的焦点holon及其在AGENTS.md中定义的steward。holon定义边界，steward是图谱向外输出信息的第一联系人。

2. Выведи замыкание

2. 推导闭包

Для каждого узла используй то же семантическое замыкание, что в Протоколе §2: феномен —

lens="trace"

в обе стороны; крия —

next

-нить и trace её

ahara

utpatti

upadhi

; vollzug/grundsatz — их upadhi-потребители; холон — его охват. Пересечение границы продолжает обход в соседнем холоне и выводит на его steward-роль. Затем прочти открытые вимарши на затронутых узлах и контурах.

Если trace не достигает потребителя, которого подразумевает код или постановка, — это не повод дописать потребителя в отчёт. Это дефект модели: недостающие крии и феномены допроектирует

design

, рёбра доткет

weaving

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

sense

对每个节点使用与协议§2中相同的语义闭包：

phenomenon：双向执行
```
lens="trace"
```
；
kriya：沿
```
next
```
链追溯，并追踪其
```
ahara
```
/
```
utpatti
```
/
```
upadhi
```
；
vollzug/grundsatz：它们的upadhi消费者；
holon：其覆盖范围。

跨越边界后，继续在相邻holon中遍历，并定位到其steward角色。随后查看受影响节点和边界上的未关闭vimarsha。

如果trace没有到达代码或需求中隐含的消费者——不能直接在报告中补加这个消费者。这是模型的缺陷：缺失的kriya和phenomenon需要通过

design

补充设计，缺失的边需要通过

weaving

补全。新消费者需要同时在代码和图谱中添加；关系存在于边中，其含义由

sense

定义。

3. Классифицируй состояние интеграции

3. 对集成状态分类

По каждому затронутому жизненному циклу или соседнему холону дай один статус:

```
ready
```
— структурный путь связан, обязательных открытых вимарш нет, названное свидетельство соседнего компонента доступно;
```
question
```
— решение удерживает открытая вимарша;
```
wake
```
— нужен ответ или действие steward-роли соседнего холона;
```
graph-gap
```
— связность обрывается или поведение осталось только в прозе/коде;
```
unknown
```
— доступного свидетельства недостаточно; никогда не повышай это до ready выводом из исходников.

ready

здесь означает только доступную ступень свидетельства. Поведенческую готовность принимает

reality-audit

на каноническом носителе; граф сам по себе её не доказывает.

为每个受影响的生命周期或相邻holon分配一个状态：

```
ready
```
—— 结构路径已连通，无必须关闭的未解决vimarsha，相邻组件的指定证明可获取；
```
question
```
—— 存在未解决的vimarsha，导致决策阻塞；
```
wake
```
—— 需要相邻holon的steward角色给出答复或采取行动；
```
graph-gap
```
—— 关联性中断，或行为仅存在于文本/代码中（未在图谱中体现）；
```
unknown
```
—— 可用证明不足；绝不能通过从源码反推的方式将该状态升级为ready。

这里的

ready

仅表示证明材料达到了可用层级。行为层面的就绪性需要通过规范载体上的

reality-audit

来确认；图谱本身无法证明这一点。

4. Два исполнения одного прохода

4. 单次遍历的两种执行方式

Основной агент действует по отчёту: graph-gap →
```
design
```
/
```
weaving
```
; question →
```
inquiry
```
; wake → ход в деле интеграции на феномене, переходящем к этому соседу (режим 0, «Дело интеграции»; нет — открой): карточка его steward-роли или
```
say
```
с
```
to
```
его месту, уже сидящему там. После изменений проходит поле снова.
Холодный reviewer работает read-only: ничего не чинит и не пишет в граф. Помимо находок по диффу возвращает отчёт интеграции — затронутые холоны и steward-роли, пройденные и оборванные эстафеты, открытые вимарши, статусы соседей, кого нужно разбудить и на каком феномене его дело. Недостаточные референсы или оборванный trace дают
```
NEEDS_CONTEXT
```
, не стилистическое одобрение.

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

主Agent 根据报告执行操作：graph-gap → 执行
```
design
```
或
```
weaving
```
；question → 执行
```
inquiry
```
；wake → 在传递给该相邻方的phenomenon上推进集成事项（见模式0「集成事项」；如果没有则创建）：向其steward角色发送卡片，或向已在事项中的相关人员发送
```
say
```
消息。变更完成后重新遍历范围。
冷评审员（cold reviewer） 以只读模式工作：不修复任何问题，也不向图谱写入内容。除了diff的发现外，还需输出集成报告——包括受影响的holon和steward角色、已遍历和中断的接力链、未解决的vimarsha、相邻方状态、需要通知的人员及其对应的phenomenon事项。若引用不足或trace中断，应给出
```
NEEDS_CONTEXT
```
，而非风格化的批准。

本模式的输出不是新的依赖文档，而是当前步骤的决策，以及在结构不完整的情况下，向图谱中添加的新kriya、phenomenon、边和vimarsha。

Протокол

协议

1. Встань на превращение

1. 定位变更

iskron_orient(lens="bianhua", focus=<seq>)

→ телос, anga-драйверы, вычисленный охват.

Затравочное множество = якоря (

vimarsha_of

-цели) существующих anga-вимарш + узлы, которые телос называет явно.

iskron_orient(lens="bianhua", focus=<seq>)

→ 获取telos、anga驱动因素、计算出的覆盖范围。

种子集 = 现有anga类型vimarsha的锚点（

vimarsha_of

目标） + telos明确提及的节点。

2. Распространи фронт — семантическое замыкание, не радиус

2. 扩散波前——语义闭包，而非半径扩散

От каждой затравки иди по замыканию, несущему её ответственность — одно замыкание на затравку, никогда N-hop от всего сразу:

Тип затравки	Замыкание	Как
феномен	его эстафета, в обе стороны	`iskron_orient(lens="trace", focus=<seq>)`
крия	её next-нить + её ahara/utpatti/upadhi-феномены	`iskron_orient(lens="topology", focus=<seq>, arrow_types="next")` , затем трассируй феномены
контур	contains-поддерево	`iskron_orient(focus=<контур>)`
vollzug / grundsatz	upadhi-потребители — кто применяет метод/принцип, который вот-вот изменится	окрестность `iskron_orient(focus=<seq>)`

Плюс один семантический проход по всему графу:

iskron_semantic_search(q=<телос фразой>)

— концептуально близкие узлы, которые структура пропускает.

Собирай пары

(узел, почему-вовлечён)

— обоснование несущее: оно идёт в описание вимарши.

从每个种子点出发，沿承载其责任的闭包遍历——每个种子点对应一个闭包，绝不对所有节点一次性执行N跳遍历：

种子类型	闭包范围	执行方式
phenomenon	其双向接力链	`iskron_orient(lens="trace", focus=<seq>)`
kriya	其 `next` 链 + 其ahara/utpatti/upadhi关联的phenomenon	`iskron_orient(lens="topology", focus=<seq>, arrow_types="next")` ，随后追踪phenomenon
边界	contains子树	`iskron_orient(focus=<边界>)`
vollzug / grundsatz	upadhi消费者——即应用即将变更的方法/原则的节点	`iskron_orient(focus=<seq>)` 邻域

再对整个图谱执行一次语义遍历：

iskron_semantic_search(q=<telos短语>)

——找出结构遍历可能遗漏的概念相近的节点。

收集

(节点, 被涉及的原因)

对——理由必须是实质性的：会被写入vimarsha的描述中。

3. Вычти уже покрытое (идемпотентность)

3. 扣除已覆盖部分（幂等性）

якоря существующих anga-вимарш этого превращения — уже в поле;
узлы, уже стоящие под прежним samshaya «задето ли …?» этого bianhua (
```
iskron_search(q="", anga_of=<bianhua>)
```
и читай якоря).

Повторный прогон добавляет только новый фронт — вопросов он не дублирует.

该变更的现有anga类型vimarsha的锚点——已在范围内；
已经处于该bianhua的旧samshaya「是否受到影响…？」之下的节点（执行
```
iskron_search(q="", anga_of=<bianhua>)
```
读取锚点）。

重复运行只会添加新的波前——不会重复创建问题。

4. Кластеризуй и предъяви — принимает владелец

4. 聚类并提交——由所有者确认

Сгруппируй остаток по общей адаптации: по эстафете, по контуру, по семейству крий. Один samshaya на кластер; узел получает собственный вопрос, только когда его адаптация явно особая. Вимарша законно якорится к нескольким узлам — один якорь через

vimarsha_of

, остальные —

iskron_arrow(action="link", arrow_type="vimarsha_of")

Сначала предъяви список кандидатов пользователю — текстом, никогда меню опций, — каждый со своим «почему вовлечён». Не распыляй вимарши в одностороннем порядке — фронт есть гипотеза, пока владелец не кивнул.

将剩余节点按共同适配原则分组：按接力链、按边界、按kriya家族。每个集群对应一个samshaya；只有当某个节点的适配方案明显特殊时，才为其单独创建问题。一个vimarsha可以合法地锚定到多个节点——一个锚点通过

vimarsha_of

设置，其余通过

iskron_arrow(action="link", arrow_type="vimarsha_of")

添加。

先向用户展示候选列表——以文本形式，绝不要用选项菜单——每个候选都附带「被涉及的原因」。不要单方面分散创建vimarsha——在所有者确认前，波前只是一个假设。

5. Поставь вопросы целостности

5. 提出完整性问题

Для каждого одобренного кластера:

iskron_add_vimarsha(genre="samshaya",
  name="<эмодзи> Задето ли <X> превращением «<bianhua>»?",   # на языке графа
  vimarsha_of=<первый якорь>, posed_by=<короткий адрес: роль, стояние или имя>,   # не проза; почему — в reasoning
  epistemic_mode="anumita", ontic_mode="vartamana", volitive_mode="chanda")
→ добавочные якоря: iskron_arrow(action="link", arrow_type="vimarsha_of", ...)
→ iskron_arrow(action="link", arrow_type="anga", source=<новая>, target=<bianhua>,
   sense="фронт целостности: превращение не может свершиться, пока не отвечено")
→ опционально: iskron_arrow(action="link", arrow_type="posed_to", source=<новая>, target=<роль-стюард>,
   sense="адресовано стюарду задетого контура")

Стрелка

posed_to

(опциональна) адресует вопрос роли, стюардящей задетый контур — svatantra/adhikarin, способной ответить; никогда

pratibimba

(образ не ответит). Она ждёт следующей ориентации роли, поэтому нужный сейчас ответ — в деле. Вопрос фронта не передаёт феномена: дело открой

open_room

при записи самой вимарши и позови стюарда, как в режиме 0, «Дело интеграции».

Описание фиксирует: что телос означает для этих узлов и что считается ответом — «не задето» (закрыть visarjana с записанной причиной) или «задето» (спроектировать адаптацию — скилл design; новая работа

arose_from

этого вопроса).

对每个已确认的集群：

iskron_add_vimarsha(genre="samshaya",
  name="<эмодзи> Задето ли <X> превращением «<bianhua>»?",   # на языке графа
  vimarsha_of=<первый якорь>, posed_by=<короткий адрес: роль, стояние или имя>,   # не проза; почему — в reasoning
  epistemic_mode="anumita", ontic_mode="vartamana", volitive_mode="chanda")
→ добавочные якоря: iskron_arrow(action="link", arrow_type="vimarsha_of", ...)
→ iskron_arrow(action="link", arrow_type="anga", source=<новая>, target=<bianhua>,
   sense="фронт целостности: превращение не может свершиться, пока не отвечено")
→ опционально: iskron_arrow(action="link", arrow_type="posed_to", source=<новая>, target=<роль-стюард>,
   sense="адресовано стюарду задетого контура")

posed_to

箭头（可选）将问题指向负责受影响边界的角色——即有能力答复的svatantra/adhikarin；绝不能指向

pratibimba

（镜像无法答复）。它会等待角色的下一次定向浏览，因此如果需要立即答复——应通过事项推进。波前问题不会随phenomenon自动传递：在创建vimarsha时执行

open_room

开启事项，并按照模式0「集成事项」中的方式邀请steward。

描述中需明确：telos对这些节点意味着什么，以及什么算作有效答复——「未受影响」（执行visarjana关闭并记录原因）或「受影响」（设计适配方案——使用design skill；新工作通过

arose_from

关联到该问题）。

6. Доложи

6. 汇报

iskron_orient(lens="bianhua", focus=<seq>)

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

iskron_orient(lens="bianhua", focus=<seq>)

——现在驱动因素中包含了完整性波前。告知用户哪些内容已被关联，哪些是有意排除在外的。

Режим 3 — claim-аудит: несёт ли граф заявленное

模式3 —— claim审计：图谱是否支撑声明内容

Прямой проход спрашивает «чего коснётся превращение?». Обратный — зеркальный вопрос: несёт ли граф то, что заявляет проза? Запускай всякий раз, когда артефакт заявляет опору на граф — отрендеренный роадмап, отчёт, резюме, телос со ссылками на способности: «направление D двигает роль X», «D растёт из способности Y», «поток A питает B», «риск покрыт». Детекторы узлового зерна этот провал не ловят: каждый узел по отдельности легален; ложь живёт в зазоре между текстом и структурой.

Извлеки утверждения. Из артефакта выпиши каждое утверждение о структуре: владение (роль двигает/владеет X), фигура-на-почве (направление продолжает способность), поток (A производит то, что потребляет B), покрытие риска («смягчён…»), якорение («ведётся в графе»).
Проверь каждое read-only. Владение → роль несёт реальные рёбра
```
actor
```
/
```
steward
```
к названным деяниям (
```
iskron_look
```
; роль с нулём рёбер — театр). Продолжение → ведущая крия достигает способности через
```
upadhi
```
/
```
context
```
(
```
lens="topology"
```
). Поток → эстафета существует (
```
lens="trace"
```
). Покрытие → риск несёт
```
addressed_by
```
или модус сознательного принятия. Якорение → у вимарши есть
```
vimarsha_of
```
в заявленный контур.
Доложи заявленное-но-непрошитое, пара за парой. Каждое неподкреплённое утверждение получает одну из двух судеб, выбранных с владельцем: прошить (утверждение было верно, но не записано — недостающие рёбра отдай ткачеству) или ослабить прозу (утверждение было театром — артефакт преувеличивает граф). Никогда не оставляй прозу, преувеличивающую граф, и никогда не прошивай рёбра лишь ради того, чтобы проза стала правдой.

Сам аудит ничего не пишет; он производит таблицу «утверждения × вердикты». Дисциплина приёмки та же, что у фронта: каждую судьбу выбирает владелец.

正向遍历会问「变更会波及什么？」。反向遍历则是镜像问题：图谱是否能支撑文本所声明的内容？ 每当工件声称基于图谱构建时，都可以运行本模式——比如渲染后的路线图、报告、简历、带有能力引用的telos：例如「方向D驱动角色X」、「D源于能力Y」、「流程A为B提供输入」、「风险已被覆盖」。节点级别的检测器无法发现这类问题：每个节点单独看都是合法的；虚假存在于文本和结构之间的缝隙中。

提取声明。 从工件中提取每一条关于结构的声明：所有权（角色驱动/拥有X）、基础关系（方向基于能力延伸）、流程（A生产的内容由B消费）、风险覆盖（「已缓解…」）、锚定（「在图谱中维护」）。
以只读模式逐一验证。 所有权 → 角色是否通过
```
actor
```
/
```
steward
```
边与所述行为关联（使用
```
iskron_look
```
；没有任何边的角色是空壳）。延伸关系 → 主导kriya是否通过
```
upadhi
```
/
```
context
```
到达能力节点（使用
```
lens="topology"
```
）。流程 → 接力链是否存在（使用
```
lens="trace"
```
）。风险覆盖 → 风险是否有
```
addressed_by
```
边，或处于有意识接受的模式。锚定 → vimarsha是否有指向所述边界的
```
vimarsha_of
```
边。
逐对汇报「已声明但未关联」的内容。 每条无支撑的声明都有两种处理方式，由所有者选择：补全关联（声明是正确的，但未被记录——缺失的边交给weaving处理）或修正文本（声明是夸大的——工件高估了图谱的实际情况）。绝不能保留夸大图谱的文本，也绝不能为了让文本变成事实而随意补加边。

审计本身不会写入任何内容；它会生成一张「声明 × 判定」的表格。验收规则与波前的规则相同：每种处理方式都由所有者选择。

Дисциплина шума

噪声约束

Один samshaya на кластер, не на узел; обоснование в каждом описании — вопрос, по которому читатель не назовёт следующий ход, есть шум по определению.
Идемпотентные повторные прогоны (шаг 3).
Никогда — новое превращение из этого прохода. Если фронт открывает нечто похожее на другое превращение — это сборочное наблюдение: отнеси пользователю (имя и телос превращения — поверхность приёмки владельца).

每个集群对应一个samshaya，而非每个节点一个；如果每条描述中的理由——也就是读者无法据此推出下一步行动的问题——按定义就是噪声。
重复运行需保持幂等（见步骤3）。
绝不能从本次遍历中创建新的变更。 如果波前发现了类似另一个变更的内容——这是一个装配观察项：将其提交给用户（变更的名称和telos是所有者的验收接口）。