Writing

Запись в Искрон

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

Пять решений, по порядку. Не перескакивай.

Прежде всего: граф и кросс-граф

Каждый вызов тула требует realm=<токен>. Подтверди, в какой граф пишешь, до первого вызова.

Кросс-графовые стрелки не работают. iskron_arrow(action="link", source="739", target="29") резолвит оба seq внутри текущего графа. Если #29 в твоём графе — не тот узел, ты только что создал неверную стрелку. Кросс-графовые ссылки — текстом в описании («см. <граф> #29»), никогда стрелками.

Гейт новизны — читатель и использование

Перед каждым созданием и семантическим обновлением назови: (1) позднюю роль/сессию — или именованный класс читателя/запроса, — которая это состояние достанет; (2) конкретное решение, ответ, проверку или передачу, которую то извлечение изменит; (3) что здесь ново относительно принятого требования, репозитория, эстафеты и существующего графа. Моделируй только несущее поперёк раундов.

Тест — род, не восстановимость. Два рода, оба первоклассны:

• Транскрипция — пропусти. То, что принятые артефакты уже кодируют, пересказанное прозой: пункты требований, рабочие логи, транскрипты тестов, существование фичи, форма публичного вывода, реализованный алгоритм, прозаическая копия состояния репо. Сошлись на источник.
• Структура — пиши. Несущая структура и отношения, которые артефакты не кодируют как проходимые связи: композиция (из чего вещь состоит, через какие фазы идёт), радиус поражения и кросс-артефактная зависимость, граница владения, соответствие-или-дрейф между артефактами. Пиши их, даже когда содержание восстановимо чтением: восстановленный текст всё равно оставляет связь непроходимой.

Где роды встречаются: алгоритм — не композиция. Зеркалить внутренний алгоритм артефакта в узлы — не новая структура: пошаговая перекодировка кода, который читатель может просто прочесть, остаётся source-only — если только онтологическое обязательство не требует модели (правило метода ниже) или именованное кросс-узловое рассуждение не нуждается в этой связи. Устойчивая дельта решения графо-достойна всегда: принятая поправка, противоречие, зависимость, вердикт свидетельства, граница владения, открытый вопрос, потеря которых изменила бы позднее действие. Неизвестность точной будущей задачи — не вето, но лишь при пройденном тесте: именованный класс читателя («кто трассирует фазы этого метода», «кто спросит, что сломает изменение X») вместе с рассуждением, которое связь делает возможным. Спекулятивная пустая структура — связи без класса читателя и без рассуждения — не лицензируется никогда.

Гейт никогда не блокирует обязательство метода («метод — половина узла»): у vollzug/grundsatz называется применяющая крия (upadhi), а фазы моделируются её contains-детьми — это структурное моделирование, не транскрипция; пересказ протокола прозой в теле остаётся запрещён.

Признак применения — наружный, перед записью

Скилл грузится в один момент, а пишется в другой, и между ними его текст становится фоном: агент пишет по своему плану и по фразе человека. Поэтому применение считается по знаку снаружи, как у двери: перед iskron_batch или фабрикой назови по каждому узлу три ответа гейта новизны — кто прочтёт, что извлечение изменит, что здесь ново. Не назвал — не пишешь этот узел. Отдельно для hint: его тело — гроссбух превращения, и в него проходит то, чего не покажут iskron_orient и линзы — исходы перемен снаружи с вердиктами, что дальше, решение, взятое словом, состояние внешнего мира; шаги, критерии приёмки, состав работы — узлы участка с модусами, и в семени они не пересказываются. Фраза человека «одна вимарша для отслеживания прогресса» — просьба о семени превращения: структура хода читается картой, исходы — гроссбухом в семени. Строки CHECKS в ответе фабрики — работа этого же такта, не сведение: подсказка исполняется или отклоняется словом, а не пересказывается.

Решение 1: какой тип узла?

bianhua — тип уровня сборки, не рутинная запись — это работа скилла assembly. Тест: «система станет X, чем она ещё не является» — не выговаривается → не bianhua. Никогда — ради одной вимарши: сначала найди существующее превращение (lens="bianhua", iskron_semantic_search(node_type="bianhua")); неясно → спроси пользователя. Вимарши агент пишет для себя; bianhua — интерфейс владельца: имя должно читаться пользователем, телос принимает он. Стрелки — в Решении 5.

Феномен не существует сам по себе — он существует для крии (ноэма для ноэзиса). Если ни одна крия его не потребляет, не производит и не обусловливается им — ты собираешься записать сироту.

Ловушки

Феномен в маске крии. «Создание токена» — акт. «⚙️ Токен доступа» — то, что акт производит. Тест: имя несёт до/после? → крия. Именует то, что стоит сквозь это до/после? → феномен.

Крия в маске феномена. «⚙️ Поток аутентификации» — если он преобразует состояние, это крия. Существительное на крие — запах, не лицензия.

Роль или феномен. Решает операциональный тест — можно ли адресовать этому вимаршу и ждать ответа? Нет → не роль (машина → ding-феномен; теория/метод/принцип → sinn/vollzug/grundsatz). Полный гейт и четыре рода роли — в Решении 2b.

Контур или феномен(sinn). «📦 Контур авторизации» — что внутри, что снаружи? Не отвечается → скорее феномен(sinn). Контур-папка — антипаттерн.

Решение 2: given_as (только феномен)

Как этот феномен даёт себя? Полное дерево решения — references/given_as.md.

Критично: vollzug/grundsatz не бывают ahara или utpatti — API 422. Метод и правило применяются — только upadhi.

Sinn — самая дешёвая клетка таблицы, и потому парковка. Под давлением лень находит её безошибочно: предупреждение приходит после действия, эта строка стоит до. Развилка: дверь входит в граф не вещью самой по себе и не смыслом «дверь», а местом, где делатель действует — то, ЧЕРЕЗ что идёт крия, это ding/sachverhalt с upadhi от неё; то, что она ест или производит, — её ahara/utpatti; sinn остаётся понятию, которое ничего не делает и через которое ничего не делают. Финишная черта любой записи: узел не записан, пока не назван тянущий его — какая крия сломается, если узел исчезнет? Ни одна — ты паркуешь, не пишешь; одинокая стрелка context глушит детектор, но на вопрос не отвечает.

Решение 2b: manifested_as (только роль)

manifested_as — обязательное поле каждой роли — способ проявленности делателя (āvirbhāva), параллель given_as: не «как дано», а «как этот делатель присутствует как начало действия». Сначала гейт, потом род.

Гейт — можно ли адресовать этому делателю вимаршу и ждать ответа?

• Нет — действует, но не ответит (cron, воркер, CI, процесс): не роль. Сделай ding-феномен и приведи к крие как upadhi.
• Нет — не действует, а стоит как теория / метод / принцип (Эриксон, ньяя, how-to): не роль. Сделай феномен sinn / vollzug / grundsatz (входит через intake).
• Да → роль. Какого рода?

Адресация по родам (куда может указывать posed_to): 主 — стратегические вопросы («берём ли?», «что в приоритете?»); ему не назначают задачи — он их назначает. 能 — рабочие вопросы и задачи; адресата находи по стрелке steward (кто отвечает за контур, где живёт твой вопрос); вне его мандата → эскалируй к 主. 象 — никогда posed_to; только actor для моделирования пути, решения о его пути — к 主/能, который его проектирует. 客 — posed_to можно, но быстрого ответа не жди; его actor-рёбра пересекают границу, и трассировка там обрывается by design.

Поиск адресата. Не выбирай из строки ROOT KARTAS в orient — там только корневые роли (суб-роли свёрнуты в «· N sub»), и имя, содержащее твоё ключевое слово, — ещё не та роль: 象-образ часто носит имя системы, а 能, отвечающий за её код, — суб-роль архетипа разработчика. Возьми действительное множество — iskron_search(q="", node_type="karta") — или иди по стрелке steward от контура, где живёт работа. Каждая строка роли несёт глиф рода (主/能/象/客); 象 — никогда не адресат. Роли другого репозитория живут в том же графе как суб-роли — не ищи граф с именем репо.

Ловушки:

• Имя человека — не роль. «Дмитрий» → «Владелец продукта» — роль, не человек.
• Одна внешняя сущность — часто два узла: Stripe-API (ding-феномен, машина) и Stripe-менеджер (agantuka-роль). Различай по адресуемости.
• Модус работы (Сборщик, Ткач, Explorer) — суб-роль через group, не отдельный тип — manifested_as наследуется от родительской роли.
• Стюардом контура может быть только svatantra / adhikarin; pratibimba / agantuka за границу не отвечают.

Решение 3: модусы

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

Каждый модус — вопрос, на который ты отвечаешь, а не галочка.

Самопроверка и устойчивые тройки — references/modes.md.

Главная ловушка: upeksha — не дефолт. anagata + upeksha = «это будет существовать, и нам всё равно». Для проектируемого почти всегда ложь. Честнее anagata + chanda или adhimoksha — а между ними решает степень решимости, не устройство: решился (adhimoksha) или отпустил (visarjana) — воля уже названа, различать нечего.

Остаётся пара chanda | upeksha, и для неё есть положительный различитель — один вопрос: держится это намерением или устройством? Ограждение прежде вопроса: он про состояние или деяние, к которому воля не отрицательна, — нейтральное или желаемое, которое есть или будет (vartamana, anagata); отвергаемое — virodha (инцидент, текущий баг, депрекация) — узнаётся по роду узла и в вопрос не входит; на vikalpa не задаётся вовсе (chanda там запрещена поверхностью). Случай, на котором выведен, — цепь мержа манифестов: слияние кладёт их в ствол, применение — в кластер, гейт проверяет набор перед этим. Две формы одного вопроса. Состоянию (sachverhalt): возникает ли оно само? «Манифесты в стволе» и «объект применён» возникают от устройства — воли для их существования не нужно, upeksha честна. «Набор проверен» само не возникает никогда: гейт никто не обязан гонять, цепь ниже пройдёт так же, только с непроверенным набором, — состояния добиваются, оно держится намерением, chanda говорит точное. Деянию (kriya): продолжалось бы оно, если бы никто не настаивал? Слияние и применение продолжались бы — так устроено, upeksha; гейт прекратился бы, едва перестали настаивать, — chanda. Спрашивать у деяния «возникает ли оно само» — категориальная ошибка: деяние совершают, не возникает. На anagata устройство ещё не стоит — пока оно не встало, состояние держится намерением, и «по устройству» отвечается только про vartamana. Фальсификатор встроен: стал гейт обязательным механически — доставка требует его сама — chanda превратилась в ложь о воле, ставь upeksha. На других родах данности феномена и на роли тест не проверен и не переносится наугад; по чтению автора, волевой модус карты — отношение к её существованию, не к её работе.

Решение 4: имя и описание

Имя (正名)

Имя узла — не ярлык, а тезис о его природе. Неверное имя — расплывчатое, коллидирующее с типом, натянутое, механически переведённое — порождает цепочку распадов: читающий путает категории, вимарши летят не туда, эстафеты рассинхронизируются. Мёртвое имя ещё и не находится поиском.

🔥 — конвенция для sachverhalt-инцидентов. Эмодзи выбирает автор по смыслу, не по типу.

Описание (тело)

Тело адресуется типовым именем на каждой поверхности — имя, под которым читаешь, есть имя, под которым пишешь, при создании и обновлении. iskron_look рендерит его под этим заголовком; фабрики и iskron_update / batch-update принимают его под этим именем. Передавай типовое имя или description, никогда оба — двойную передачу отвергает guard.

Что в теле, по типам:

• Kriya (essence): паринама — «До: X. После: Y.» Читается как список задач — переписывай.
• Phenomenon (description): что это ЕСТЬ и какие крии его потребляют / производят / обусловливаются им. Не можешь назвать ни одной — ты ещё не знаешь, что пишешь.
• Vimarsha (description): сам вопрос. Что считать ответом?
• Holon (description): какой принцип отделяет внутреннее от внешнего. iskron_add_holon требует ответа на четыре вопроса — ответь.
• Karta (motivation): что движет ролью. iskron_add_karta требует её.
• Bianhua (telos): качество назначения — «система становится …» (см. Решение 5).

Вневременность — закон, не любезность. Имя и описание обращены к будущему читателю: они говорят, чем узел есть и как им пользоваться, — не как он возник. Тело читается вне времени: будущий агент встречает его без сессии вокруг, и хроника в теле — шум для всех, кроме писавшего. У провенанса три законных дома: attrs (posed_by, source, decided_at), ребро arose_from (происхождение как структура) и iskron_history (полный audit trail с reasoning каждой дельты).

• Вон из тела: даты, маркеры сессий, имена людей (атрибуция → attrs.posed_by), git-ссылки (SHA/ветки/PR), журналы DONE/changelog. История живёт в iskron_history и git; сделанная работа меняет сам граф — модусы, стрелки, описания, — а не дописывается логом.
• Запахи нарушения: «теперь», «после того как», «в этой сессии», дата в прозе, хвост «✅ сделано», любой рассказ о том, что было не так раньше, описание-протокол («установлено, подтверждено») вместо описания-закона.
• Где время законно: phenomenon(given_as=sachverhalt) — инцидент/состояние — несёт метку времени в attrs, не в прозе; shabda (цитируемое внешнее слово) датировано по природе; закрытая вимарша читается как архив (тело замерло при закрытии). Всюду иначе — вне времени. Тело семени превращения (hint) — не хроника, а текущий гроссбух работы: правится до состояния «что стоит сейчас», прошлое у платформы (Решение 5).

Решение 5: стрелки

Без стрелок = сирота = невидим.

Связь — в ребре; объяснение связи — в sense этого ребра. Назвал потребителя в описании — проведи ребро тем же ходом, а прозу переложи в sense стрелки: проза о том, кто потребитель, не заменяет ребра — она его комментирует. Ловушка добросовестности (пять контуров независимо, у разных авторов): когда потребителей много, выбор одного кажется произволом — и автор не выбирает никого, оставляя узел структурно висящим при полностью известной связности. Множественность — не довод против рёбер, а указание провести их все: upadhi дёшев, ни одно из многих не объявляет себя единственным. Потребитель за границей графа (человек, внешний агент) — это край, и он помечается краем, а не молчанием. Читающий агент идёт по рёбрам; связь, живущая в теле, доступна лишь тому, кто уже дошёл, — то есть тому, кому она не нужна.

И то же держится этажом выше — где правило ловит собственного автора. Проведя ребро, его «почему» клади в sense — никогда в тело предложением о ребре. sense едет вместе с ребром, и его читает каждый, идущий по связности; тело открывается лишь тому, кто уже пришёл. «Почему», оставленное в теле, вручено — снова — читателю, которому оно больше не нужно. Раздел чист: тело говорит, чем узел есть, ребро — что он связывает, а sense ребра — почему связывает именно так.

Kriya (четыре вопроса)

Фабрика держит 1–2 воротами: iskron_add_kriya отказывает крие, у которой нет ни ahara, ни utpatti (настоящий вход графа передаёт attrs.boundary="init" — см. «Граница графа»).

1. Потребляет? → ahara к феномену. ahara = УНИЧТОЖЕНИЕ. Просто читает → upadhi.
2. Производит? → utpatti к феномену. Не можешь назвать utpatti? Стой — ты не понял крию.
3. Кто действует? → actor к роли.
4. Контекст? → upadhi к феномену. attrs.mutable=true, если изменяется.
5. Частью чего? → перед записью на верхний уровень поищи родительскую крию (locate-before-write): iskron_semantic_search(q=<частью чего это является>); при честном попадании передай parent_id=<seq> (создаёт contains от родителя). Без насилия — неверный родитель хуже отсутствующего; не выговаривается зонт — оставайся на верхнем уровне сознательно. Самая сжимающая ось — та, которую фабрики не спрашивают; спроси её сам.

Плюс: next (смысл = прашна — вопрос да/нет). contains — для под-шагов.

Граница графа топологична: ни один детектор не требует ahara на краю графа, и attrs.boundary="init" никогда не глушит натяжения. Маркер — положительная заявка с двумя действиями: при создании он снимает ворота фабрики на ahara/utpatti, а в чтении рендерится санкционированным входом. Ставить его, чтобы увильнуть от честного ahara, — антипаттерн.

Phenomenon

• context → контур. Только phenomenon → holon. Kriya/karta/vimarsha → holon запрещено.
• derived_from, specifies → родословная феномен-к-феномену.
• Ожидания зависят от given_as — см. references/given_as.md.

Karta

• steward → контур: кто отвечает за границу. Стюардом может быть только svatantra (корневые контуры) или adhikarin (конкретные); pratibimba / agantuka — нет. adhikarin без единого steward — предупреждение: работает, но ни за что не отвечает.
• group → старшая роль (суб-роль в группе); actor — входящее, от каждой крии, которую роль исполняет.

Vimarsha

• vimarsha_of → узел(ы), о которых вопрос. Якори каждую вимаршу — несущую ожидание (posed_to, anga к превращению) вдвойне: агенты находят работу, ориентируясь на контур, а ни anga, ни posed_to не помещают вимаршу ни в чей контур — незаякоренная, она невидима адресату и не будет сделана. Минимум — контур, где живёт ожидаемая работа; лучше — точный феномен/крия внутри него.
• posed_to → роль: ребро-инбокс — адресуй вопрошание делателю, который может ответить, чтобы он собирал «мои открытые вопросы» (iskron_search(posed_to=<роль>)). Это стрелка к узлу-роли, не поле — создавай inline (arrows: [{arrow_type:"posed_to", target:<роль>, volitive_mode:"chanda"}]) или через iskron_arrow(action="link", arrow_type="posed_to", …). Запрещено к pratibimba (образ не ответит). Адресата выбирай по Решению 2b — 能, стюардящий контур вопроса; 主 — для стратегического масштаба. Четыре слова-адреса поверхность разрешает сама, в момент записи: posed_to="me" — человек твоих ключей (эскалация), "agent" — карта стояния этой сессии (вопрос себе, носитель ожидания), "steward" — стюард контура твоего якоря (прогулку «якорь→контур→steward» проходит поверхность, а не ты), "realm-owner" — владелец графа (вопрос вне всякого мандата; у графа под орг-владением слово отказывает честно, называя контракт). Слова работают и на iskron_arrow(action="link") целью. Ручная прогулка остаётся пониманием и фолбэком — слово отказало (контур без стюарда, сессия без стояния, орг-владение) — отказ учащий и называет ход. Оно не заменяет vimarsha_of: одно ребро-инбокс не помещает вопрос ни в чью контур-ориентацию. Зеркальный провал так же реален: vimarsha_of без posed_to на вопросе, ожидающем действий другого делателя, — делегирование, выродившееся в записку в пустоту: заякорено, видно в территории, ни в чьём инбоксе. Делегирующая вимарша не закончена, пока не стоит ребро-инбокс. Без штампов срочности: ранжирование очереди — акт владельца очереди, не постановщика: не ставь priority-attrs и не заполняй priority-образный параметр тула (воля взрослеет chanda → adhimoksha; аффорданс в схеме тула — не мандат).
• vimarsha_of (о ЧЁМ) и anga (куда двигаю) — не схлопывай. vimarsha_of именует предмет: нынешний, как-есть узел, о котором сомнение. anga именует становление, которое двигает ответ: превращение, будущий телос. Ловушка — тяга к ответу: уронить актора или назначение работы в vimarsha_of, когда их место на anga. Мета-ход: ответь на два вопроса раздельно — «о ЧЁМ сомнение?» (→ vimarsha_of), «какое становление двигает ответ?» (→ anga). Одна вимарша законно несёт оба.
• arose_from → наблюдение-исток.
• Жанр определяет жизненный цикл: risk → может realized_as в sachverhalt. hint → закрывает тот, кто координирует превращение, на его приёмке.
• hint — гроссбух превращения, не payload: одно семя на превращение, его тело — текущий гроссбух работы: исходы перемен снаружи с вердиктами и что дальше — то, чего orient и линзы не покажут. Структура работы-в-полёте живёт на карте через anga; модусы и рёбра в семени не повторяются. Форму и предел роста держит vahta.

Bianhua

• anga (часть→целое): составляющая → bianhua, которое она двигает. Три рода носителей — вимарша, суб-превращение, крия. Передавай anga=<refs> на iskron_add_bianhua или iskron_arrow(action="link", arrow_type="anga", source=<ref>, target=<bianhua>) позже. Носитель сохраняет собственное якорение (вимарша — свой vimarsha_of) — anga добавочен. превращение с нулём anga — пустое превращение, фабрика предупреждает. Ациклическое дерево: один anga-родитель на источник.
• Крия как носитель anga: вимарша-anga несёт путь (вопрос, чьё разрешение двигает перемену); крия-anga несёт прибытие — деяние, которое само составляет превращение. Два прочтения, выводимые из трипути самой крии, не отдельное поле (нет anga_kind): возведение — деяние, входящее в ткань (онтика anagata→vartamana, воля chanda/adhimoksha); депрекация — деяние, покидающее её (vartamana→atita, virodha). Завершённая крия всё равно линкуется — оконченное деяние есть отданный долг, не блок; на завершённом носителе нет 422. Каждая крия-anga входит в прогресс превращения; её resolved читается из трипути носителя.
• anantara (порядок): превращение → превращение, которое должно завершиться раньше. anantara_after=<refs>. Ациклично; задаёт критический путь.
• telos — это описание: пиши качество назначения («система становится …»), рендерится как TELOS: в iskron_look. Ни given_as, ни context, ни ahara/utpatti/upadhi на превращении (422). Жизненный цикл и работа с полем — скиллы inquiry и assembly.

Смысл на стрелках

Каждая стрелка несёт смысл — ПОЧЕМУ.

• next → прашна. ✓ «Путь построен — где он может сломаться?» ✗ «Перейти к следующему шагу.»
• upadhi → почему этот феномен важен ИМЕННО ЗДЕСЬ.
• ahara → что потреблено и почему.

После записи

1. Читай блок CHECKS:, который печатает ответ фабрики. Фабрика самопроверяется — отдельный вызов не нужен. Чисто? Дальше. Сначала чини предупреждения. Замечание: not_orphan на свежем феномене ожидаем, пока его не подхватит крия (ahara/utpatti/upadhi) — context-стрелка к контуру его НЕ снимает. Приведи к крие. Подсказка в ответе — рабочий элемент, не FYI: «Not attached to any transformation — check the map» значит выполнить названную проверку (lens="bianhua") и либо привязать, либо явно вынести решение пользователю — не пересказывай строку мимоходом.
2. Тело называет потребителя или условие — а ребра нет? Проведи тем же ходом (все, если их много), прозу — в sense. Связь — в ребре; тело её объясняет, не несёт.
3. Феномен с ahara/utpatti: iskron_orient(lens="trace", focus=<seq>) — жизненный цикл связан?
4. Kriya: actor, ahara, utpatti — все существуют?
5. Отпусти то, что заменил. Locate-before-write ищет дубликаты до записи; это его зеркало после. Живая матрица стрелок допускает supersedes только вимарша→вимарша — там используй его, перенеси нагрузку старого вопроса и закрой (visarjana). Для остальных типов узлов не изобретай обобщённого ребра-преемника: перенеси key:true, якоря и потребителей, которым пора переехать; добавь другое легальное отношение (derived_from, specifies) только когда его смысл истинен; предшественника отставь модусом его носителя. Перепроверь iskron_arrow(realm="?"), прежде чем учить или автоматизировать паттерн замены. Преемник, не отпустивший предшественника, оставляет живой дубликат канона.
6. Не путай проверки графа со свидетельством реальности. CHECKS:, связность trace, акторы и легальные стрелки устанавливают только целостность графа. Для поведенческого sachverhalt: инспекция кода обосновывает anumita; фокусный внутренний/mock-тест — максимум pratyakshita (свидетельство, которое сверка градуирует как provisional, большего не чеканит); pramanita требует сверки реальностью (наблюдаемый контракт, каноническая публичная граница, исполненный фальсификатор, свежее независимо наблюдаемое свидетельство — дисциплина в reality-audit и связке вахты). Исполняемое свидетельство считается только с записанным успешным кодом выхода («код выхода — вердикт»). Упавшая широкая сюита не опровергает отдельно изолированный факт автоматически — но без фокусного exit-zero-фальсификатора именно этого факта держи anumita и повесь reverify-вимаршу. Свежий black-box-тест квалифицируется, когда пересобирает и исполняет именно эту границу; авторство само по себе не повышает и не понижает.

Операционное

reasoning. Каждый пишущий тул принимает reasoning="...". Используй.

basis_version. Каждый iskron_update, iskron_arrow (delete/reconnect/update) и iskron_delete_node требует его. Прочитал → записал → перечитал при конфликте.

Кросс-граф. Текстовые ссылки в описаниях. Никогда стрелки.

Жанры вимарши

Не выбирается один → спутаны два вопроса. Разведи.

Стартовые тройки и закрытие — канон носителей

Каждый род (тип × given_as × genre) несёт жизнь/закрытость одной осью трипути (U1); остальные лишь квалифицируют. Фабрики iskron_add_* печатают каноническую СТАРТОВУЮ ТРИПУТИ рода, а iskron_look глоссирует носитель на каждом узле — читай их; не штампуй расходящуюся тройку. Эпистемика никогда не закрывает (U2, кроме badhita у эпистемо-носимых родов): она квалифицирует достоверность и восходит Kl→An→Pt→Pm. Ловушка, которую канон чинит: virodha НЕ означает единообразно «закрыто» — он поляризован родом (U3):

• risk — virodha и есть живой модус: активный риск стоит в virodha. Закрывается только модусами: upeksha (принят) ∨ visarjana (отпущен); addressed_by/realized_as — информационны, не гейт: материализация риск не закрывает (сбывшийся риск хуже открытого).
• vyabhichara / hetu-dosha / semantic-drift — носитель онтический: дефект есть, пока vartamana; virodha конститутивен (дефекта не хотят). Закрытие — atita (расхождение устранено) ∨ visarjana.
• kriya / karta / phenomenon(vollzug) — virodha = депрекация: живое напряжение «хотим это вывести», не закрытие. Закрытие — atita (kriya/karta также nashta) ∨ visarjana.
• samshaya / prati-paksha / hint — здесь virodha есть закрытие (отказ).

И проектируемая работа рождается anagata в проектной тройке, никогда в «готовой» pramanita/vartamana/upeksha (та лжёт, будто деяние уже идёт) — стартовые модусы проектирования держит скилл design.

Порядок в батче (iskron_batch)

Загрузи схемы фабрик до create-батча. iskron_batch оборачивает фабрики iskron_add_*, но не ослабляет их дисциплину — каждый create валидируется полной схемой своей фабрики. В окружении с отложенными тулами батч грузится без них, и слепая сборка фабричного батча — это изучение обязательных параметров по одному 422 за раунд-трип. Перед батчем найди и прочти схему каждого iskron_add_*, который позовёшь. Первый create незнакомого типа безопаснее одиночным вызовом фабрики, чем в мегабатче — и не пакуй тяжёлые многоабзацные описания в мегабатч.

Порядок внутри батча:

1. Сначала феномены
2. Потом крии (ссылаются на феномены)
3. Сквозные стрелки — последними

Inline-форма стрелок

Inline arrows на фабриках — та же каноническая форма, что arrow_link, с новым узлом как неявным источником: {arrow_type, target, sense?, direction?, quantifier?, attrs?, <modes>}. Обязательны arrow_type, target и volitive_mode — стойка не наследуется от нового узла, и фабрика отклоняет inline-стрелку без неё тем же контрактом, что iskron_arrow(action="link"); sense/direction/quantifier опциональны, direction переворачивает ориентацию, когда новый узел — цель, а не источник. Фабрика валидирует форму строго: неизвестный ключ (например, дореномный edge_type) отвергается именованной ошибкой, указывающей на arrow_type; про отсутствующий target так и говорится. Ни молчаливого принятия, ни сырого TypeError.

Два паттерна, оба первоклассные:

• Inline arrows — для рёбер, исходящих из нового узла (vimarsha_of вимарши, context феномена). Передавай в create-операции.
• Отдельный arrow_link с temp:N — для рёбер между двумя узлами одного батча или указывающих в новый узел. Ссылайся на созданные узлы 0-базным индексом temp:N; temp:N должен указывать на create-опа с меньшим индексом.

Конститутивные ahara/utpatti крии обязаны остаться inline. Фабрика валидирует каждый add_kriya по его собственным inline arrows в момент создания — потребление/производство, отложенное в хвостовой arrow_link, не засчитывается, и крия падает («a kriya must declare ahara or utpatti»). Клади ahara/utpatti в arrows create-опа; когда потребляемый/производимый феномен создаётся тем же батчем — поставь его раньше и ссылайся inline через temp:N (inline-стрелки резолвят temp:N так же, как arrow_link). В хвостовых arrow_link — только действительно сквозные рёбра (next, upadhi к уже существующему узлу).

anga/anantara на iskron_add_bianhua — исключение: передавай их собственными параметрами anga= / anantara_after=, никогда в arrows.