integrity

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

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

Правка узла не завершена, пока волна к его потребителям не рассмотрена — даже если сам узел исправлен.

Пять входов:

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

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

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

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

План живёт в графе, а не в терминале.

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

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

• Открывает сторона, начинающая интеграцию, на передаточном феномене: 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 отвечает принимающая сторона (справка двери iskron leading.md: «Стык согласуют до работы — пробой»); приёмка соседом спецификации, интерфейса и отчёта (шаг 5) — yes_no. Ответ — ack и тем же ходом в граф, что он решил: феномен, потребляющая крия и её модусы, отвеченная вимарша. Работа через границу — «Разовая задача — слово в деле» справки двери iskron cases.md.
• Закрывается, когда интегрировали обе стороны — строка каждой с наблюдённым исходом под своим ключом («интегрировано: <контур>»), не под ключом карточки до её ack (справка двери iskron cases.md, «Ключ вопроса не перекрывай строкой работы»), — и отчёт «специфицировано, сделано, разошлось» стоит в деле; остаток — в графе (открытые вимарши posed_to отвечающей роли, неотгруженные крии в anagata), не только в журнале. Затем propose_close ведущего.

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

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

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

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

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

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

Для каждого узла используй то же семантическое замыкание, что в Режиме 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, не стилистическое одобрение.

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

Режим 2 — протокол волнового фронта

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, «Дело интеграции».

Онтика вопроса — онтика его предмета (writing, «Решение 3: модусы»): задетый узел действует — vartamana, проектируемый — anagata. Описание фиксирует: что телос означает для этих узлов и что считается ответом — «не задето» (закрыть visarjana с записанной причиной) или «задето» (спроектировать адаптацию — скилл design; новая работа arose_from этого вопроса).

6. Доложи

iskron_orient(lens="bianhua", focus=<seq>) — среди драйверов теперь фронт целостности. Скажи пользователю, что привязано и что сознательно оставлено за бортом.

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

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

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

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

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

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