Back to Details

design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Проектирование в Искроне

Iskron中的设计工作

Граф — устойчивая проекция спеки: решение или риск вне графа не устойчивы — не переживут сессию; поведение, живущее только в графе, не проверено. Внешние источники, публичные границы и рантайм-свидетельства остаются поверхностями истины, против которых проекция проверяется.
图谱是规格的持久化投影：不在图谱中的决策或风险不具备持久性——无法在会话结束后留存；仅存在于图谱中的行为未经过验证。外部来源、公开边界和运行时佐证仍是真值参照，图谱投影需要与之对照验证。

Граница маршрутизации

路由边界

«Продумай / хотим X» → запись в тот же ход. Это просьба проектировать, не только обсудить: прочти существующие феномены и вплети дизайн в них; подлинно новое — 
anagata+chanda
, эпистемика не выше 
anumita
. Запиши решения, путь и риски, вопросы по сути — вимаршами с 
vimarsha_of
и 
posed_to
, каждой стрелке дай 
sense
по writing. Новое превращение агент может создать сам как допущение: 
kalpita
или 
anumita
· 
anagata
· 
chanda
; имя и телос предложи владельцу словами или вимаршей. 
Chanda
здесь — не принятая воля: 
adhimoksha
ставится только по принятию владельца. Согласование не откладывает дизайн в прозу.
Проектирование начинается там, где структурный выбор действительно открыт: конкурирующие пути, жизненный цикл, владение, публичная граница, направление зависимости — или решение, обязанное пережить сессию. Конкретная принятая просьба об имплементации не становится проектной работой оттого, что придётся писать код: реализуй её обычным потоком репозитория; writing — только если работа вскрыла новую устойчивую поправку, зависимость, границу или открытый вопрос, стоящие передачи позднему актору.
「梳理一下/我们想要X」→ 同轮次内完成记录。 这是设计请求，而非单纯讨论：请读取现有现象并将设计融入其中；真正全新的内容标记为
anagata+chanda
，认知层级不超过
anumita
。请记录决策、路径、风险和核心问题——使用带
vimarsha_of
和
posed_to
属性的vimarsha，按照writing技能规范为每条边添加
sense
属性。Agent可以自行创建新的bianhua作为假设：标记为
kalpita
或
anumita
· 
anagata
· 
chanda
；请通过自然语言或vimarsha向所有者提议名称和telos。此处的
Chanda
并非已确认的意愿：仅在所有者确认后才可设置
adhimoksha
。协调过程不应将设计推迟到后续文字记录中。
设计工作始于结构选择真正开放的场景：存在多条竞争路径、涉及生命周期、所有权、公开边界、依赖方向——或是需要在会话结束后留存的决策。已确认的具体实现请求不会因为需要编写代码就变成设计工作：请通过常规仓库流程实现；仅当工作中发现了新的需要传递给后续参与者的持久化修正、依赖、边界或开放性问题时，才使用writing技能记录。

Interop: наборы элиситации (например, superpowers brainstorming)

互操作：引导收集套件（例如 superpowers brainstorming）

Если установлен brainstorming-скилл — запускай его для элиситации: это желанный фронт-энд. Его spec-файл — черновой вид: пропусти через intake и прошей сюда. Сохранение результата — работа памяти, не имплементация: жёсткие гейты имплементации (например, у superpowers brainstorming) на неё не распространяются. Дизайн не готов, пока его решения, риски и жизненные циклы не в графе.
如果已安装brainstorming技能，请启动它进行引导收集：这是推荐的前端入口。它的spec文件是草稿形式：请通过intake处理后接入此处。结果保存属于记忆工作，而非实现工作：实现环节的严格门禁（例如superpowers brainstorming的门禁）不适用于此。只要设计的决策、风险和生命周期还未录入图谱，设计就不算完成。

Принципы (действуют всегда)

原则（始终生效）

#ПринципЧто это значит для тебя
P1Каждый ding рождается и умираетКаждый феномен (given_as=ding или sachverhalt) ОБЯЗАН иметь utpatti И ahara. Без исключений. Leaked-натяжение = нет крии конца жизни. Добавь её. Никогда не глуши attrs.
P2Сложная система только вырастаетОставляй место. Модусы anagata+upeksha и вимарши — для отложенного. Глубоко с первого прохода = антипаттерн.
P3Граф ≠ реальность; граф = натяжение с реальностьюВпуск шабды понижает натяжение. Проектирование повышает — граф описывает то, чего ещё нет. Каждая вимарша метит натяжение. Система развивается переработкой вимарш.
P4Натяжения всегда правдивыНикогда не подавляй. Всегда замыкай структуру. Натяжение кажется неправым → баг детектора, а не повод его заглушить.
#原则对你的意义
P1每个ding都有生有灭每个现象（given_as=ding或sachverhalt）必须同时拥有utpatti和ahara。没有例外。Leaked张力 = 缺少生命周期结束的kriya。请补充该kriya。绝对不要通过屏蔽attrs来掩盖问题。
P2复杂系统只能生长演化预留空间。anagata+upeksha模式和vimarsha用于处理待办事项。首次遍历就追求深度 = 反模式。
P3图谱 ≠ 现实；图谱 = 与现实的张力接入shabda会降低张力。设计工作会提高张力——因为图谱描述的是尚未存在的事物。每个vimarsha都标记着一处张力。系统通过迭代完善vimarsha实现发展。
P4张力永远真实存在绝对不要压制张力。始终保持结构闭合。如果觉得张力不合理 → 是检测器的bug，而非屏蔽它的理由。

Стартовые модусы проектируемого

设计对象的初始模式

Проектируемая практика рождается запланированной, не сделанной: anumita/anagata/chanda (устоявшийся план, на который решились, — adhimoksha; отложенное «нужно, не сейчас» — anagata+upeksha). Только наблюдаемое уже работающим — Pt/Va/Up. Штамп «готово» (
pramanita/vartamana/upeksha
) на спроектированном-но-несуществующем узле лжёт и об онтике, и об эпистемике, и ложь каскадирует через закат, преемственность, kriya-anga и предикаты носителей. Переход в 
vartamana
— отдельный акт жизни, совершаемый, когда практика реально стартует, — и засвидетельствованный: старт подтверждается наблюдением мира на каноническом носителе, не намерением автора (дисциплина сверки — vahta). Воля взрослеет по 
chanda → adhimoksha
; никогда не тянись к 
attrs
для срочности или приоритета. Полный канон стартовых троек и закрытия — у скилла writing: сверяйся при каждой записи, не перевыводи здесь.
Волевая крия принадлежит превращению. Крия, записанная из воли — пользователь хочет, чтобы она была (или чтобы чего-то не стало), а не из шабды («знаю, что так»), — часть качественного сдвига, который проходит система. Посади её на карту: её ведущие вимарши цепляются 
anga
к bianhua (путь), и сама волевая крия цепляется 
anga
тоже (прибытие — kriya-anga). Направление читай из трипути самой крии, не из отдельного поля: возведение — деяние, входящее в ткань (онтика 
anagata→vartamana
, воля 
chanda
/
adhimoksha
) — цепляй ещё в 
anagata
, разрешится при 
vartamana
; депрекация — деяние на выход (
vartamana→atita
, 
virodha
), разрешается в 
atita
. Полная грамматика kriya-anga — в скилле writing. И завершённая крия тоже может быть anga — сделанное деяние не сходит с карты: bianhua заодно есть прочтение поля крий, где каждое деяние показывает, какому превращению служило и зачем было создано. Членство записывает назначение, не только незавершённое движение (отдача долга). Не порождай для этого новое превращение спонтанно — сначала существующий лес (
lens="bianhua"
); имя и телос нового принимает пользователь (скилл assembly); не знаешь, куда положить, — спроси.
被设计的实践诞生时是已规划状态，而非已完成状态：标记为anumita/anagata/chanda（已确认的成熟计划标记为adhimoksha；推迟的「需要做，但不是现在」标记为anagata+upeksha）。只有已观察到正在运行的事物才标记为Pt/Va/Up。给已设计但尚未存在的节点打上「已完成」（
pramanita/vartamana/upeksha
）标签，在本体论和认识论层面都是错误的，且错误会通过终止、连续性、kriya-anga和载体谓词级联扩散。进入
vartamana
状态是一个独立的生命行为，只有当实践真正启动时才会发生——且需要经过验证：启动必须通过在规范载体上观察到的实际情况来确认，而非作者的意图（校验规范为vahta）。意愿的成熟路径是
chanda → adhimoksha
；绝对不要通过
attrs
来设置紧急度或优先级。初始三元组和闭合的完整规范请参考writing技能：每次记录时都请对照，此处不再赘述。
意愿型kriya从属于转化（bianhua）。 基于意愿记录的kriya——即用户希望某事发生（或消失），而非基于shabda（「我知道是这样」）——是系统发生质变的一部分。请将其映射到图谱上：它的主导vimarsha通过
anga
边连接到bianhua（路径），且意愿型kriya本身也通过
anga
边连接（落地——即kriya-anga）。方向请从kriya自身的triputi读取，而非从单独字段读取：上线/构建是进入系统的行为（本体状态
anagata→vartamana
，意愿
chanda
/
adhimoksha
）——在
anagata
阶段就连接，到
vartamana
阶段时生效；弃用/下线是退出系统的行为（
vartamana→atita
，
virodha
）——在
atita
阶段生效。kriya-anga的完整语法请参考writing技能。此外已完成的kriya也可以是anga——已完成的行为不会从图谱上消失：bianhua同时也是kriya场的读取视图，每个行为都能显示它服务于哪个转化、为何被创建。成员关系记录的是目的，而不仅仅是未完成的动作（偿还债务）。不要随意创建新的转化——先查看现有转化森林（
lens="bianhua"
）；新转化的名称和telos由用户确认（assembly技能）；如果不知道放在哪里，就询问用户。

Четыре фазы проектирования

设计的四个阶段

Входи в любую фазу по зрелости графа. Не водопад — любая фаза может вернуть назад.
根据图谱的成熟度进入任意阶段。这不是瀑布模型——任何阶段都可能回退到之前的阶段。

Фаза 1: обратное выведение (справа налево)

阶段1：反向推导（从右到左）

Канон нити: цель → путь → риски → тезис; поток given_as: sachverhalt → bildung → grundsatz/vollzug. Lean pull — метод мышления: каждый шаг верифицируем, потому что вытянут из цели, а не придуман из воздуха.
ТРИГГЕР: цель есть, пути нет
ДЕЛАЙ:
  1. Назови цель как sachverhalt(anagata+chanda). Целевое состояние — владельца:
     называй в диалоге, когда нужно, — цель принимает пользователь (и позже — телос
     превращения), проектировщик её не изобретает
  2. iskron_search + iskron_semantic_search — цели ещё нет в графе? (keyword пропустит
     иначе названный дубликат; semantic поймает до того, как спроектируешь дважды)
  3. Кто берёт цель? Тот, ради кого она, — крия отдачи: ahara на цель, без utpatti,
     актор 主/客. Правый край стоит прежде рекурсии влево; цепь за ним не продолжается
  4. От цели: «что это производит?» → создай крию + ahara-феномен
  5. Рекурсия, пока не упрёшься в данность извне — и тогда крия наблюдения:
     utpatti без ahara, актор — тот, кто увидел. Край — деяние, не пометка
ВЫХОД: путь крий от входа к цели
ДАЛЬШЕ: → Фаза 2 (прямое ткачество)
Актор: роль Проектирующего. Потребляет: поставленное вопрошание. Производит: построенный путь.
线程规范：目标 → 路径 → 风险 → 论点；given_as流转：sachverhalt → bildung → grundsatz/vollzug。精益拉动（Lean pull）是思考方法：每一步都可验证，因为是从目标倒推出来的，而非凭空想象。
ТРИГГЕР: цель есть, пути нет
ДЕЛАЙ:
  1. Назови цель как sachverhalt(anagata+chanda). Целевое состояние — владельца:
     называй в диалоге, когда нужно, — цель принимает пользователь (и позже — телос
     превращения), проектировщик её не изобретает
  2. iskron_search + iskron_semantic_search — цели ещё нет в графе? (keyword пропустит
     иначе названный дубликат; semantic поймает до того, как спроектируешь дважды)
  3. Кто берёт цель? Тот, ради кого она, — крия отдачи: ahara на цель, без utpatti,
     актор 主/客. Правый край стоит прежде рекурсии влево; цепь за ним не продолжается
  4. От цели: «что это производит?» → создай крию + ahara-феномен
  5. Рекурсия, пока не упрёшься в данность извне — и тогда крия наблюдения:
     utpatti без ahara, актор — тот, кто увидел. Край — деяние, не пометка
ВЫХОД: путь крий от входа к цели
ДАЛЬШЕ: → Фаза 2 (прямое ткачество)
参与者：设计者角色。输入：已提出的问题。输出：构建完成的路径。

Фаза 2: прямое ткачество (слева направо)

阶段2：正向编织（从左到右）

ТРИГГЕР: путь есть, не все феномены обслужены
ДЕЛАЙ:
  1. Пройди путь слева направо
  2. Для каждого феномена на пути:
     - Есть utpatti? Нет → relay-gap → добавь производящую крию
     - Есть ahara? Нет → leaked → добавь крию конца жизни
     - Уровень абстракции совпадает? Bootstrap создаёт config → Teardown уничтожает config (тот же уровень)
  3. Для каждой крии:
     - Ровно один actor? Два → расщепи
     - На всех стрелках sense? Нет → напиши
     - ahara/utpatti указывают на верные феномены? (после различений может быть нужен reconnect)
  4. Для каждого феномена: context → контур проставлен? Феномен без контура-дома невидим
     контур-скоупной ориентации — распредели ВСЕ
  5. iskron_orient(lens="trace", focus=<феномен>) на ключевых → цикл связан?
  6. iskron_orient(lens="tensions") → новые проблемы?
ВЫХОД: замеченные натяжения, замкнутые циклы
ДАЛЬШЕ: → Фаза 3 (анализ рисков) или → замыкание ЖЦ, если разорван
Актор: роль Ткача. Потребляет: построенный путь. Производит: замеченные натяжения, замкнутые циклы.
ТРИГГЕР: путь есть, не все феномены обслужены
ДЕЛАЙ:
  1. Пройди путь слева направо
  2. Для каждого феномена на пути:
     - Есть utpatti? Нет → relay-gap → добавь производящую крию
     - Есть ahara? Нет → leaked → добавь крию конца жизни
     - Уровень абстракции совпадает? Bootstrap создаёт config → Teardown уничтожает config (тот же уровень)
  3. Для каждой крии:
     - Ровно один actor? Два → расщепи
     - На всех стрелках sense? Нет → напиши
     - ahara/utpatti указывают на верные феномены? (после различений может быть нужен reconnect)
  4. Для каждого феномена: context → контур проставлен? Феномен без контура-дома невидим
     контур-скоупной ориентации — распредели ВСЕ
  5. iskron_orient(lens="trace", focus=<феномен>) на ключевых → цикл связан?
  6. iskron_orient(lens="tensions") → новые проблемы?
ВЫХОД: замеченные натяжения, замкнутые циклы
ДАЛЬШЕ: → Фаза 3 (анализ рисков) или → замыкание ЖЦ, если разорван
参与者：编织者角色。输入：构建完成的路径。输出：已识别的张力、已闭合的循环。

Фаза 3: анализ рисков + митигирование

阶段3：风险分析 + 缓解

3a. Анализ:
ТРИГГЕР: путь проткан, риски не оценены
ДЕЛАЙ: для каждой крии на пути — семь провокационных вопросов:
  1. Другой актор? Что, если недоступен?
  2. Другой контекст? Окружение сменилось?
  3. Повреждённый upadhi? Предусловие испорчено?
  4. Несовпадение масштаба? Параллельность/конкурентность?
  5. Противник? Сеть падает, диск кончается, процесс виснет?
  6. Публичная граница и представление? Точны ли экспорт API, форма конфига/схемы,
     протокол, сериализация, поверхность совместимости?
  7. Состояние и история? Держится ли поведение при изоляции, ретраях, уже
     накопленном состоянии, повторном прогоне?
  Нашёл угрозу → iskron_add_vimarsha(genre="risk", vimarsha_of=<крия>)
ВЫХОД: риск-вимарши
3b. Митигирование — отдельный процесс, по каждому риску:
ТРИГГЕР: риск-вимарша есть, не отвечена
ДЕЛАЙ:
  1. Прочти контекст риска: iskron_look на целевую крию + окрестность
  2. Изучи операционное окружение
  3. Выбери тип ответа:
     a. Компенсирующая (митигирующая) крия или феномен → предотвращает/обрабатывает срыв перехода
     b. Grundsatz-инвариант → принцип как upadhi; рождается предложенным (chanda — в силу его вводит владелец),
        основание — стрелкой: arose_from к этому риску, derived_from к принципу, из которого следует
     c. Сознательное принятие → НЕ твой ход: принятие нежелательного — акт владельца. Подготовь материал
        (что принимается, какой ценой, сколько деяний идёт через риск) и адресуй владельцу; upeksha ставит он,
        либо ты — записывая его сказанное слово; чьё слово и когда — в reasoning записи, не в теле.
        Риск до тех пор стоит в virodha
  4. Прошей ответ, iskron_arrow(action="link") addressed_by от вимарши (для a и b; принятие закрывает модус, не стрелка)
ВЫХОД: отвеченные риски
ДАЛЬШЕ: → Фаза 4 или → следующий риск
3a. 分析：
ТРИГГЕР: путь проткан, риски не оценены
ДЕЛАЙ: для каждой крии на пути — семь провокационных вопросов:
  1. Другой актор? Что, если недоступен?
  2. Другой контекст? Окружение сменилось?
  3. Повреждённый upadhi? Предусловие испорчено?
  4. Несовпадение масштаба? Параллельность/конкурентность?
  5. Противник? Сеть падает, диск кончается, процесс виснет?
  6. Публичная граница и представление? Точны ли экспорт API, форма конфига/схемы,
     протокол, сериализация, поверхность совместимости?
  7. Состояние и история? Держится ли поведение при изоляции, ретраях, уже
     накопленном состоянии, повторном прогоне?
  Нашёл угрозу → iskron_add_vimarsha(genre="risk", vimarsha_of=<крия>)
ВЫХОД: риск-вимарши
3b. 缓解——针对每个风险的独立流程：
ТРИГГЕР: риск-вимарша есть, не отвечена
ДЕЛАЙ:
  1. Прочти контекст риска: iskron_look на целевую крию + окрестность
  2. Изучи операционное окружение
  3. Выбери тип ответа:
     a. Компенсирующая (митигирующая) крия или феномен → предотвращает/обрабатывает срыв перехода
     b. Grundsatz-инвариант → принцип как upadhi; рождается предложенным (chanda — в силу его вводит владелец),
        основание — стрелкой: arose_from к этому риску, derived_from к принципу, из которого следует
     c. Сознательное принятие → НЕ твой ход: принятие нежелательного — акт владельца. Подготовь материал
        (что принимается, какой ценой, сколько деяний идёт через риск) и адресуй владельцу; upeksha ставит он,
        либо ты — записывая его сказанное слово; чьё слово и когда — в reasoning записи, не в теле.
        Риск до тех пор стоит в virodha
  4. Прошей ответ, iskron_arrow(action="link") addressed_by от вимарши (для a и b; принятие закрывает модус, не стрелка)
ВЫХОД: отвеченные риски
ДАЛЬШЕ: → Фаза 4 или → следующий риск

Фаза 4: импульс доставки

阶段4：交付推动

ТРИГГЕР: граф спроектирован, всё в anagata, никто не работает
УСЛОВИЕ: только для графов, проектирующих внешние системы (не методология, не CJM)
ДЕЛАЙ:
  1. Посади работу на превращение: каждую волевую крию — как kriya-anga (деяние-прибытие —
     возведение/депрекация по её трипути, см. §«Волевая крия принадлежит превращению») —
     к СУЩЕСТВУЮЩЕМУ bianhua сначала (lens="bianhua"); новое можно создать как допущение
     по writing, «Имя и телос», и предложить владельцу → импульс становится частью 形,
     а не рассыпанным списком
  2. Стадируй поток: когда доставка ступенчата (например, test → staging → full),
     каждая ступень — суб-превращение, anga в ЕДИНОЕ превращение доставки, упорядоченное
     anantara (что стартует только после чего); каждая ступень собирает свои волевые
     крии через anga. Канонический результат право-налевого проектирования — это одно
     превращение с anantara-упорядоченным потоком ступеней: владелец читает его как план релиза
  3. Работа идёт делом: прежде спроси iskron_case(action="at", node=<превращение>) — не идёт ли
     уже; нет — открой дело на узле превращения (или ступени) полем open_room у его записи,
     одной строкой замысла (скилл architect, «Ведение дела»)
  4. Поставь работу в деле референсами: узлы участка в модусах замысла и способ проверки —
     на каком каноническом носителе и какой пробой видно «сделано» (команда/запрос и ожидание,
     не мнение исполнителя), и отрицательная проба (скилл architect, шаг 5). Адресат — делатель,
     который может ответить: 能, стюардящий контур (ищи по стрелке `steward`), 主 для
     стратегического масштаба; никогда pratibimba-образ. Принято пересказом, исход —
     словом в деле; порядок работ — из anantara и happens-before, не из списка
  5. Вимаршей остаётся то, что переживёт работу: риск, вопрос по сути, обязательство перед
     будущими делателями — **стрелка `posed_to`** (вимарша→роль) и ЯКОРЬ vimarsha_of там,
     где адресат ориентируется (минимум контур, точная крия/феномен — когда известны):
     posed_to без якоря потерян — адресат его не увидит; воля взрослеет chanda→adhimoksha —
     никогда атрибутом срочности; блокирующесть — свойство пары; та, чьё разрешение двигает
     превращение, — ещё и anga к нему (ведущая вимарша). Под разовую задачу
     вимарша не заводится — она поручение в деле
  6. Семя превращения (genre=hint) — одно на превращение: смысл и то, что важно после
     сессии, — инварианты, слово владельца, ещё не ставшее узлом, живые дела превращения
     по строке, что дальше; не список работ и не журнал сделанного
  7. Сверь с существующими открытыми вимаршами и делами контура (iskron_case(action="at", node=<контур>))
  8. На свежепринятом превращении: прогон целостности (скилл integrity) — волновой фронт
     задетых-но-не-привязанных узлов получает свои вопросы «задето ли?»
ВЫХОД: делатель входит через дело (строка запуска, iskron_case(action="mine")) или orient → ACTIVE BIANHUA → знает, что делать первым
Сами по себе anagata-крии к действию не зовут. Зовут дела и вопрошания: дело — работу, вимарша — вопрос по сути. Превращение (скилл assembly) собирает их в карту, которую читает навигатор, — anga внутрь (волевые крии и ведущие вимарши), anantara между, — а не в плоский список.
ТРИГГЕР: граф спроектирован, всё в anagata, никто не работает
УСЛОВИЕ: только для графов, проектирующих внешние системы (не методология, не CJM)
ДЕЛАЙ:
  1. Посади работу на превращение: каждую волевую крию — как kriya-anga (деяние-прибытие —
     возведение/депрекация по её трипути, см. §«Волевая крия принадлежит превращению») —
     к СУЩЕСТВУЮЩЕМУ bianhua сначала (lens="bianhua"); новое можно создать как допущение
     по writing, «Имя и телос», и предложить владельцу → импульс становится частью 形,
     а не рассыпанным списком
  2. Стадируй поток: когда доставка ступенчата (например, test → staging → full),
     каждая ступень — суб-превращение, anga в ЕДИНОЕ превращение доставки, упорядоченное
     anantara (что стартует только после чего); каждая ступень собирает свои волевые
     крии через anga. Канонический результат право-налевого проектирования — это одно
     превращение с anantara-упорядоченным потоком ступеней: владелец читает его как план релиза
  3. Работа идёт делом: прежде спроси iskron_case(action="at", node=<превращение>) — не идёт ли
     уже; нет — открой дело на узле превращения (или ступени) полем open_room у его записи,
     одной строкой замысла (скилл architect, «Ведение дела»)
  4. Поставь работу в деле референсами: узлы участка в модусах замысла и способ проверки —
     на каком каноническом носителе и какой пробой видно «сделано» (команда/запрос и ожидание,
     не мнение исполнителя), и отрицательная проба (скилл architect, шаг 5). Адресат — делатель,
     который может ответить: 能, стюардящий контур (ищи по стрелке `steward`), 主 для
     стратегического масштаба; никогда pratibimba-образ. Принято пересказом, исход —
     словом в деле; порядок работ — из anantara и happens-before, не из списка
  5. Вимаршей остаётся то, что переживёт работу: риск, вопрос по сути, обязательство перед
     будущими делателями — **стрелка `posed_to`** (вимарша→роль) и ЯКОРЬ vimarsha_of там,
     где адресат ориентируется (минимум контур, точная крия/феномен — когда известны):
     posed_to без якоря потерян — адресат его не увидит; воля взрослеет chanda→adhimoksha —
     никогда атрибутом срочности; блокирующесть — свойство пары; та, чьё разрешение двигает
     превращение, — ещё и anga к нему (ведущая вимарша). Под разовую задачу
     вимарша не заводится — она поручение в деле
  6. Семя превращения (genre=hint) — одно на превращение: смысл и то, что важно после
     сессии, — инварианты, слово владельца, ещё не ставшее узлом, живые дела превращения
     по строке, что дальше; не список работ и не журнал сделанного
  7. Сверь с существующими открытыми вимаршами и делами контура (iskron_case(action="at", node=<контур>))
  8. На свежепринятом превращении: прогон целостности (скилл integrity) — волновой фронт
     задетых-но-не-привязанных узлов получает свои вопросы «задето ли?»
ВЫХОД: делатель входит через дело (строка запуска, iskron_case(action="mine")) или orient → ACTIVE BIANHUA → знает, что делать первым
anagata状态的kriya本身不会触发行动。触发行动的是任务和问题：任务触发工作，vimarsha触发核心问题讨论。转化（assembly技能）将它们组织成导航器可读取的图谱——内部通过anga连接（意愿型kriya和主导vimarsha），之间通过anantara连接——而非扁平列表。

Нить и эстафета

线程与接力

Нить (thread)Эстафета
Связываеткрии через 
next
феномены через 
ahara
/
utpatti
Несётпрашну (иглу-вопрос) на каждой стрелкеsachverhalt (положение дел) между криями
О чёмпорядок действийжизненный цикл вещи
Тулиди по 
next
iskron_orient(lens="trace")
на феномене
Не путай. Цепь sachverhalt'ов — эстафета. Последовательность крий — нить.
线程（thread）接力
连接对象通过
next
边连接kriya		通过
ahara
/
utpatti
边连接现象
承载内容每条边上的prashna（问题针）kriya之间的sachverhalt（事态）
核心内容动作的顺序事物的生命周期
使用工具沿
next
边遍历		对现象执行
iskron_orient(lens="trace")
不要混淆。sachverhalt的链条是接力。kriya的序列是线程。

Замыкание жизненного цикла

生命周期闭合

Разорванные циклы, всплывшие при проектировании (lens="trace" разрыв, leaked, relay-gap), чинит скилл weaving, Операция 5: рождение и смерть на одном уровне абстракции; отложенное замыкание через anagata+upeksha — можно. Не перевыводи процедуру здесь.
设计过程中发现的断裂循环（lens="trace" 断裂、leaked、relay-gap）由weaving技能的操作5修复：确保生和灭在同一抽象层级；可以通过anagata+upeksha实现延迟闭合。此处不再赘述具体流程。

given_as — легальность стрелок

given_as — 边的合法性

Дерево решения given_as и полная матрица стрелок — у скилла writing. В момент проектирования помни ту, что кусает: vollzug/grundsatz применяются, никогда не потребляются — только upadhi; ahara/utpatti к ним = API 422.
given_as的决策树和完整的边矩阵请参考writing技能。设计时请记住最容易出错的一点：vollzug/grundsatz是被应用的，永远不会被消费——只能作为upadhi；给它们加ahara/utpatti边 = API 422错误。

Шпаргалка натяжений

张力速查表

НатяжениеЗначениеПочинка
leakedу феномена utpatti, нет aharaДобавь потребляющую крию (конец жизни) или отложенную (anagata+upeksha); феномен уходит из графа — крия отдачи (ahara без utpatti, актор 主/客)
relay-gapу феномена ahara, нет utpattiДобавь производящую крию; феномен приходит извне — крия наблюдения (utpatti без ahara); её феномен — в холоне внешней системы
orphanу феномена вообще нет крия-стрелокПрошей к крие (ahara/utpatti/upadhi). Не держится — три судьбы, не одна: не нёс различения (случаен, дубль) — удали с причиной; нёс тезис, и он ложен — опровергни и храни; был верен и больше не нужен — отпусти (writing, справочник модусов)
no-actorкрия без актораВимарша стюарду холона по writing, «Кто действует?»; actor не ставь до ответа
lifecycleнесвязные сегменты циклаПрошей через next или трассируй до разрыва
unreachableupadhi-феномен недостижим по happens-beforeПроверь: производитель hb-раньше потребителя?
веер — не имя детектора, а канон: много связей одного рода на узлегрубейших связей больше, чем вмещает экран внимания; сегодня линза зовёт счётом деяний без объемлющего — тот же зов; счёт стрелок сам по себе не долгНе «раздели» — назови среднее со своей грубой связью: зонт применяет, ест или даёт целое либо род, листья уточняют; зонт без связи — папка (writing, Решение 5; среднее по роду веера — assembly, шаг 3)
张力类型含义修复方法
leaked现象有utpatti，无ahara添加消费型kriya（生命周期结束）或延迟型kriya（anagata+upeksha）；如果现象要从图谱中移除——添加交付型kriya（ahara无utpatti，参与者为 主/客）
relay-gap现象有ahara，无utpatti添加生产型kriya；如果现象来自外部——添加观察型kriya（utpatti无ahara）；其现象位于外部系统的holon中
orphan现象完全没有kriya边将其连接到某个kriya（ahara/utpatti/upadhi）。如果无法连接——有三种处理方式，而非一种：未承载区分信息（偶然、重复）——连同原因一起删除；承载论点但论点错误——反驳后保留；曾经有效但不再需要——释放（writing技能，模式手册）
no-actorkriya没有参与者按照writing技能「谁在行动？」规范，向holon的steward发送vimarsha；在得到回复前不要设置actor
lifecycle生命周期片段不连贯通过next边连接，或追踪到断裂处修复
unreachableupadhi现象按happens-before规则不可达检查：生产者的hb时间是否早于消费者？
扇出——不是检测器名称，而是规范：节点上有大量同类型连接粗粒度连接数量超过注意力屏幕容量；当前透镜通过无上层容器的动作计数发出提示——本质是同一问题；边的数量本身不是问题不要「拆分」——创建一个带有粗粒度连接的中间节点：伞节点应用、消费或提供整体或类别，叶子节点做细化；没有连接的伞节点就是文件夹（writing技能，决策5；扇出类别的中间节点——assembly技能，步骤3）

Паттерн прошивки endpoint'ов

endpoint接入模式

HTTP-endpoint'ы → крии, не текстовые описания:
  1. Корневой sinn-контейнер (например, «API URL») — содержит все endpoint-феномены
  2. Endpoint-феномен = sachverhalt (HTTP-запрос). attrs: method, path
  3. Крия «Обслуживание GET /path» — ahara ← endpoint-феномен, utpatti → феномен ответа, actor → API-клиент
  4. Next-стрелки: вызывающий → endpoint-крия → рендерер
HTTP-endpoint → 对应kriya，而非文本描述：
  1. 根sinn容器（例如「API URL」）——包含所有endpoint现象
  2. Endpoint现象 = sachverhalt（HTTP请求）。attrs：method、path
  3. 「处理GET /path」kriya——ahara ← endpoint现象，utpatti → 响应现象，actor → API客户端
  4. Next边：调用方 → endpoint kriya → 渲染器

Механика записи → скилл writing

记录机制 → writing技能

Именование (正名), форма описания (паринама; толстый узел — рассуждения в дочерние вимарши, под-шаги в contains-детей, справочные данные в ding'и), модусы, given_as, порядок батча — всё это скилл writing. Вызывай его в каждый момент записи каждой фазы; не перевыводи здесь.
命名（正名）、描述形式（parinama；厚节点——将推理放入子vimarsha，子步骤放入contains子节点，参考数据放入ding）、模式、given_as、批处理顺序——这些都属于writing技能的范畴。每个阶段的每次记录都请调用该技能；此处不再赘述。

Отложенная работа

延迟工作

Два инструмента:
  • Модусы anagata+upeksha на крие/феномене: «нужно, не сейчас». Цикл формально замкнут. Натяжения нет.
  • Вимарша на узле: открытый вопрос, позовёт к действию, когда придёт время.
Оба одновременно — можно: крия в anagata+upeksha + samshaya «а нужно ли вообще?»
两种工具：
  • kriya/现象上的anagata+upeksha模式：「需要做，但不是现在」。循环形式上闭合。没有张力。
  • 节点上的vimarsha：开放性问题，时机成熟时会触发行动。
可以同时使用两者：kriya标记为anagata+upeksha + samshaya「到底需不需要做？」

Граница графа

图谱边界

Санкционированного края у графа нет — ни пометки, ни группы натяжений; ни один детектор не требует ahara на крие. Край — деяние, у которого одна сторона в мире: на входе крия наблюдения (utpatti без ahara — данность внешнего), на выходе крия отдачи (ahara без utpatti, актор 主/客 — продукт принадлежит миру). Деяние гостя может стоять на краю с обеих сторон разом. Leaked и relay-gap на краю — не ложная тревога, а долг смоделировать это деяние; его феномен лежит в холоне внешней системы или человека, своего холона у крии нет. Продолжать цепь за крией отдачи не нужно: нудж «нет next» здесь не долг. Никогда не добавляй attrs, чтобы заглушить натяжение. Полный абзац о криях края — скилл writing, Решение 5.
图谱没有预设的边界——没有标记，也没有张力分组；任何检测器都不要求kriya必须有ahara。边界是指一端处于现实世界的行为：入口处是观察型kriya（utpatti无ahara——外部给定事实），出口处是交付型kriya（ahara无utpatti，参与者为 主/客——产物属于现实世界）。访客行为可以同时位于边界的两侧。边界处的leaked和relay-gap不是误报，而是需要对该行为建模的提示；其现象位于外部系统或人的holon中，该kriya没有自己的holon。不需要在交付型kriya之后继续延伸链条：「没有next」的提示在这里不是问题。绝对不要通过添加attrs来掩盖张力。关于边界kriya的完整说明请参考writing技能决策5。

Конкурентность

并发

Все мутации требуют 
basis_version
— 
v<N>
из 
iskron_look
. Прочитал → записал → при конфликте перечитал и повторил.
所有变更都需要提供
basis_version
——即
iskron_look
返回的
v<N>
版本号。读取 → 写入 → 冲突时重新读取并重试。

Оговорка про вимарши в orient

关于orient中vimarsha的说明

iskron_orient(focus=<контур>)
может показать 0 вимарш, когда они привязаны к криям, продевающимся сквозь контур, а не к феноменам внутри. 
lens="vimarshas"
на контуре группирует blocking/active/dormant по его охвату — но вимарши на продевающихся криях надёжнее всего всплывают через 
iskron_search(node_type="vimarsha", vimarsha_of=<seq крии>)
, если цифры кажутся неверными.
当vimarsha绑定到穿过边界的kriya而非内部现象时，
iskron_orient(focus=<边界>)
可能显示0条vimarsha。边界上的
lens="vimarshas"
会按覆盖范围分组blocking/active/dormant状态的vimarsha——但如果觉得数字不对，最可靠的方式是通过
iskron_search(node_type="vimarsha", vimarsha_of=<kriya序列>)
来查找穿过边界的kriya上的vimarsha。