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

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

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

Пять входов:

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

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

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

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

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

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

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

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

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

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

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

lens="trace"

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

next

-нить и trace её

ahara

utpatti

upadhi

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

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

design

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

weaving

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

sense

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

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

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

ready

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

reality-audit

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

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

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

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

Протокол

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

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

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

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

vimarsha_of

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

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=<телос фразой>)

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

Собирай пары

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

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

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

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

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

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

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

vimarsha_of

, остальные —

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

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

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

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

6. Доложи

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

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

Режим 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
```
в заявленный контур.
Доложи заявленное-но-непрошитое, пара за парой. Каждое неподкреплённое утверждение получает одну из двух судеб, выбранных с владельцем: прошить (утверждение было верно, но не записано — недостающие рёбра отдай ткачеству) или ослабить прозу (утверждение было театром — артефакт преувеличивает граф). Никогда не оставляй прозу, преувеличивающую граф, и никогда не прошивай рёбра лишь ради того, чтобы проза стала правдой.

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

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

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

integrity

NPX Install

Tags

SKILL.md Content