- + Block A7.0 Origins Document (NEW) — pre-history reconstruction перед main A7
- + Block A7.5 Domain Application (NEW) — применение findings к specific use case
- Block A7 переформулирован: вместо single report → 4-document publication suite (Executive · Main · Origins · Application)
- 11 → 13 skills (+ecosystem-origins-document, +ecosystem-domain-application)
- Pattern card structure formalized в Опоре 14: phenomenon + 5-почему + numbers grid + transferability
Trigger: gap analysis показал что Ж имеет 6 standalone HTML + 4 print versions vs наш 1 main HTML.
- + Опора 13 · Provenance Discipline · обязательный аудит происхождения. Запрещает batch reclassification без re-fetch source
- + Опора 14 · Coverage Assessment · формальная фаза оценки покрытия предметной области по 6 dimensions перед synthesis
- + Block A4.0 между A3 и A4 — Provenance Discipline gate
- + Block A4.99 между A4 и A5 — Coverage Assessment gate
- 9 → 11 skills (+ecosystem-coverage-assessment NEW, +ecosystem-analytical-report NEW)
Trigger: exp-2v2 reclassification trap → user critique → exp-2v3 validation of corrections (338 entities · 100% web-sourced · GO verdict)
IDEF0-разложение метода реконструкции экосистемы
Слой под 8 шагами METHOD.html. Каждый шаг разложен как IDEF0-блок: входы / управление / механизмы / выходы + явная петля уточнения и явные точки хранения. Цель — устойчивая работа на стыке «Claude · файлы · детерминированные функции · пользователь · внешние инструменты», без потери контракта между сессиями.
User review публикационного отчёта exp-2 выявил структурную ошибку метода (онтология определяется ДО reconnaissance). v4.0 method добавляет 4 фазы + cross-cutting loop. IDEF0 v3.0 синхронизирует декомпозицию.
- Новые блоки A0 / A1.5 / A3 / A6.5 в основном flow (см. контекстную диаграмму v3.0)
- Новая cross-cutting петля Ontology-delta feedback — feedback от extract/reflect/contradictions к A1.5 ontology
- Опора 11 · Inductive-deductive flow — фиксация что reconnaissance precedes ontology (no inverted causality)
- Опора 12 · Ontology-evolution-log — continuous ontology-history.md с versioned onto-extensions
- 9 операционных скиллов (vs 5 в v2.2): +2 новых (reconnaissance · ontology-design) + 1 expanded scope (publish-draft объединяет A6.5+A7) + 6 модифицированных → v2.0
Архивная копия v2.2 сохранена: archive/v3.2-pre-major-revision/methodology/IDEF0-v2.2.html. См. REVIEW-AND-CORRECTIONS для полного rationale.
- Блок A4 операционализирован полностью: 8-фазный protocol (A4.1 setup → A4.2 extract per hub → A4.3 F1+F2 merge → A4.4 CH validation → A4.5 F3-F7 → A4.6 DAG-VIZ → A4.7 reflect_block → A4.8 A4-RESULT). Pipeline_per_hub из 7 шагов (research-plan §B3) теперь mandatory часть A4.2.
- Новый блок A4-D · D-stage (centrality validation + CH check scripts). См. METHOD.html §08b для деталей. Включает D1-D6 metrics + CH-N validation scripts с двумя distance уровнями для dynasty hypotheses.
- Блок REFLECT (между iter_N и iter_N+1) — отдельный meta-блок реализующий FINDING #3 discovery-first iterative cycle. 6-section reflect_block + iter_{N+1}_decision (GO/STOP/PIVOT). Operationalized в скилле
ecosystem-reflect-iter. - 9-я опора жёсткости · ID-reuse pattern для cross-bridge graph integrity (same person/org = same node ID across all hubs).
- 10-я опора жёсткости · graph-structure-not-metadata для CH validation (проверять соседства/пути, не label-сходство).
- 3 рабочих скилла в Опоре 4 «механизмы» (детерминированная часть):
ecosystem-init·ecosystem-plan-research·ecosystem-extract-and-aggregate·ecosystem-reflect-iter.
Зачем второй уровень детализации
В METHOD.html шаги описаны как этапы работы. Этого достаточно, чтобы понять что делать. Этого мало, чтобы держать работу устойчивой при множестве прогонов и сессий, особенно когда часть шагов выполняется в LLM-чате, часть в файлах, часть пользователем вручную.
Второй слой нужен, чтобы:
- Зафиксировать контракты. У каждого шага явно прописан вход (формат, источник, валидация) и выход (формат, место хранения, провенанс). Любой следующий шаг читает свой вход из файла, а не «из памяти сессии».
- Разделить детерминированную часть и LLM-часть. В каждом блоке видно, что делается жёстким алгоритмом (валидация шаблона, классификация по правилу, расчёт CI), а что — рассуждением LLM. Жёсткое — переиспользуется и не зависит от сессии. LLM — заменяется, дообучается, перезапускается.
- Закрепить петлю уточнения. Внутри каждого блока — единый паттерн взаимодействия с пользователем: вопросы → черновик → согласование → фиксация. Это не вольный диалог, а формальный «такт».
- Держать жёсткость через сессии. Сессия LLM теряется. Файлы — нет. Каждый блок при заходе читает свой набор файлов-якорей, поэтому новая сессия начинает с того же состояния, что закончила предыдущая.
Паттерн IDEF0 в этом виде уже отработан в проектах П33 (MIRA) и DAISY (ИИ-Повар). Там — система агентов; здесь — система шагов реконструкции экосистемы. Структура та же: 4 типа стрелок (C/I/O/M) + явная петля внутри блока + разделение слоёв (бизнес-процесс / служебный / мета). Эталон сохранён в /04_KNOWLEDGE/schemas-and-technologies/idef0-layered-pattern.md.
Условные обозначения
Для механизмов внутри блоков используются ярлыки: LLM рассуждение Claude, DET детерминированная функция / скрипт, USR действие пользователя, FILE файл-якорь (читается/пишется напрямую).
Контекстная диаграмма A-0 — конвейер целиком
Верхний уровень: весь метод П49 как одна функция. Что входит, что управляет, что снизу удерживает, что выходит наружу.
cases/)
I6 реестр своих проектов (05_PROJECTS/INDEX.md)
cases/XX/ со всеми артефактами
O2 обновлённая онтология предметной области (двумерно: П5 × R/P/T/D)
O3 публикационный пакет (brief · HTML · deck · граф)
O4 gap-список для своих проектов
O5 публикация на life.avmakin.com/m2ai/runs/XX (если включено)
Декомпозиция A0 — 8 блоков
Конвейер раскладывается на 8 функциональных блоков. Они идут последовательно, но между ними возможны возвраты (например, при незакрытых Competency Questions возврат с A7 на A4).
| Блок | Функция | Главный вход → выход | Якорь-файл |
|---|---|---|---|
| A1 | Параметры запуска | запрос → parameters.yml | parameters.yml |
| A2 | План исследования | parameters → research-plan.md | research-plan.md |
| A3 | Треки и распределение | plan → tracks-grid.md | tracks-grid.md |
| A4 | Онтология + дельта знаний | сырые материалы → ontology.yml · entities.csv · relations.csv · delta.md | ontology.yml |
| A5 | Синтез и аналитика | граф → synthesis.md · analytics.html | synthesis.md |
| A6 | Валидация по CQ | synthesis → competency-questions.md | competency-questions.md |
| A7 | Зеркало в свои контуры | synthesis + INDEX портфеля → mirror-map.md | mirror-map.md |
| A8 | Gap-analysis + публикация | mirror → gap-analysis.md · publish/ | gap-analysis.md |
Каждый блок при входе читает свой вход из файла-якоря, а не из памяти сессии. Каждый блок при выходе пишет свой результат в файл-якорь, а не «оставляет в чате». Это делает конвейер устойчивым к смене сессий, переключению между чатами и параллельным прогонам.
Универсальный паттерн одного блока
Все 8 блоков сделаны по одной форме. Это снижает когнитивную нагрузку: один раз понял паттерн — понял всё.
Если DoD не выполнен — петля повторяется.
C1 — методика «как делать» (раздел METHOD.html по этому блоку). C2 — шаблон выхода «что должно получиться» (template-файл). Разделение даёт две степени свободы: можно менять методику, не ломая контракт выхода, и можно менять шаблон, не переписывая методику. Этот паттерн пришёл из IDEF0-разбора ИИ-Повара и доказал устойчивость.
Детальное раскрытие · 3 ключевых блока
Полностью раскрываю три блока, в которых специфика самая значимая. Остальные 5 описаны кратко по той же форме в таблице ниже.
A1 · Параметры запуска
templates/parameters.template.yml
C3 Acceptance: 6 параметров заполнены, пользователь явно подтвердил рамку
parameters.yml предыдущего прогона
I3 Реестр cases/ — чтобы не повторять тему
I4 v3 Документы и материалы по теме (если есть на руках)
I5 v3 Ссылки на открытые источники (web URLs, arxiv ID, GitHub repos)
I6 v3 Источники данных компании (CRM-выгрузки, internal docs, регламенты)
I7 v3 Рабочая гипотеза пользователя (опц., становится working_hypothesis)
I8 v3 Key questions — что точно хочу узнать (опц.)
cases/XX/parameters.yml (с 6 обязательными + 3 опц. v3)
O2 cases/XX/decisions.log — что подтверждено
O3 cases/XX/sources.yml — типизированный реестр источников: документы / web / БД
O4 Сигнал «ok · идём на A2»
parameters.yml · decisions.log · sources.yml
Визуальная подсказка — процентовка наполнения (см. §06 «два индикатора»). Если валидация падает — возврат на ②.
A4 · Онтология + извлечение + дельта
ontology.template.yml + delta-pass.template.md
C3 Типология П5 (5 категорий · 56 типов)
C4 Acceptance: ≥90% сущностей с типом · все утверждения классифицированы · CI/VI рассчитаны
ontology.yml
I3 Накопленные entities.csv + relations.csv
I4 tracks-grid.md — для контекста трека
+ DELTA
ontology.yml
O2 Обновлённые entities.csv + relations.csv
O3 delta.md с разбивкой по 4 категориям
O4 Лог расширений типологии (если активировалось User-Driven Schema Evolution)
ontology.yml · entities.csv · relations.csv · delta.md
Внутренний цикл (по неоднозначностям): для спорных утверждений — LLM задаёт уточняющий вопрос USR (или просит дополнительный источник) — повтор Classify.
A5 · Синтез и аналитика
synthesis.template.md + competency-questions.template.md
C3 Acceptance: каждое утверждение синтеза → ссылка на entities/relations; нет «голых» обобщений
ontology.yml (актуальная)
I2 entities.csv + relations.csv
I3 delta.md
I4 parameters.yml (для аудитории/формата)
synthesis.md (с провенансом каждой формулировки)
O2 analytics.html (визуальные срезы)
O3 Сигнал на A6 (запуск проверки CQ)
synthesis.md · analytics.html
Если по итогам A6 (валидация CQ) ответ <80% — возврат сюда с уточняющими вопросами.
Остальные 5 блоков · сжатая таблица по тому же шаблону
| Блок | Inputs (главное) | Controls | Mechanisms | Outputs · якорь |
|---|---|---|---|---|
| A2 План исследования | parameters.yml | METHOD §04 шаг 02; research-plan.template.md |
LLM декомпозиция в вопросы · DET проверка покрытия рамки · USR утвердить | research-plan.md |
| A3 Треки | research-plan.md | METHOD §04 шаг 03; tracks-grid.template.md |
LLM разбивка на треки · DET проверка ортогональности · USR ответственные | tracks-grid.md |
| A6 Валидация CQ | synthesis.md + parameters.yml | METHOD §04 шаг 05 (вкладка CQ); competency-questions.template.md |
LLM прогон вопросов по тексту синтеза · DET подсчёт «ответ / частично / нет» · USR добавить свои CQ | competency-questions.md |
| A7 Зеркало | synthesis.md + 05_PROJECTS/INDEX.md | METHOD §04 шаг 06; mirror-map.template.md |
LLM проекция явлений → проекты · DET match по тегам · USR уточнить «попадает/частично/разрыв» | mirror-map.md |
| A8 Gap + публикация | mirror-map.md + состояние проектов | METHOD §04 шаги 07-08; gap-analysis.template.md + publish-brief.template.md |
LLM формулировка gap + опций · DET ранжирование · USR утверждение приоритетов · сборка publish-пакета | gap-analysis.md + publish/ |
Универсальная петля уточнения
Один и тот же 5-тактный паттерн внутри каждого блока. Не вольный диалог, а формальная последовательность.
Правила петли
- Видимый список ВСЕХ вопросов v2. Перед началом такта-2 LLM показывает весь scope вопросов одним списком — пользователь видит, сколько ещё впереди и какие. Это снимает тревогу «когда же это кончится» и даёт ощущение контроля над процессом.
- Один вопрос за такт-2, а не пакет. При сохранении общего списка на виду — задаём по одному, чтобы каждый ответ был осознанным. Если параметров девять (6 базовых + 3 опц.) — девять последовательных тактов 2.
- Черновик-объект, не реплика v2. На такте 3 LLM создаёт
draft.<step>.mdкак файл в кейсе. Согласование «на словах в чате» — не считается; редактирование меняет файл. - Confirm = переименование v2. На такте 5 после явного «да» от пользователя —
draft.<step>.md → final.<step>.md+ цитата согласия вdecisions.log. До переименования файл — кандидат, после — состояние прогона. - Согласование цитируется в decisions.log. «Аleksei: да, тип онтологии — стандартная». Это якорь, который переживёт сессию.
- Фиксация — детерминированная. Валидатор шаблона прогоняется автоматически; если падает — петля не считается закрытой.
- Если такт-5 успешен — переход к следующему блоку. Если нет — возврат на такт-2 с указанием, что именно не сошлось.
«Сейчас в чате обсудим — потом запишу». Это убивает воспроизводимость. Правильно: черновик в файле появляется уже на такте 3; согласование меняет файл, а не висит в реплике LLM.
Два визуальных индикатора петли NEW v2
Чтобы пользователь видел прогресс и доверял системе, петля сопровождается двумя визуализациями. Обе обязательны для скиллов, опционально — для ручного прогона.
Метафора — отпечаток пальца в iPhone: с каждым новым ответом «загорается» больше областей шаблона. Реализация: визуальная сетка обязательных полей шаблона (например, 9 параметров parameters.yml). Заполненное поле — закрашено акцентным цветом, незаполненное — серое. Сверху — прогресс-бар (3/9 · 33%). Видно мгновенно, что осталось.
████████████░░░░░░░░ 55%
✓ тема ✓ горизонт ✓ фокус
✓ аудитория ✓ тип онтологии
☐ глубина дельты ☐ working_hypothesis
☐ key_questions ☐ custom_scoring
Эталон стиля — Block-Zh-Talent-Migration-Map.html (Peace_Committee_AI_2026, D3.js force-directed, 333 узла/565 связей, многослойная фильтрация, цветовая семантика, hover-tooltips). Адаптация: каждый узел — сущность из entities.csv, каждая связь — из relations.csv. Метки изменений: зелёный = NEW в текущем проходе, синий = CONFIRMED, оранжевый = CONTRADICTION (не красный!), серый = KNOWN. Боковая панель — фильтр по статусу/CI/когнитивному типу/трекам.
● 47 узлов (12 NEW · 28 CONFIRMED ·
5 CONTRADICTION · 2 KNOWN)
— 89 связей
Фильтры: [когн.тип ▾] [статус ▾] [трек ▾]
Технология: D3.js v7 force-simulation
Источник стиля: /Peace_Committee/
Block-Zh-Talent-Migration-Map.html
Метафора процентовки — Apple TouchID setup wizard (постепенное «загорание» отпечатка по мере касаний).
Граф — /Cowork/Peace_Committee_AI_2026/2 - Block-Zh-Talent-Migration-Map.html (зеркало в cases/01-western-ai-ecosystem-2026-04/source/synthesis-and-analytics/). Технология self-contained: D3.js v7 + чистый HTML/SVG, без зависимостей кроме CDN-загрузки D3. Поддерживает hover-tooltips, drag, zoom/pan, левую панель фильтров, правую панель деталей.
Как держать жёсткость через сессии
Сессия LLM теряется. Файлы — нет. Конвейер устроен так, что новая сессия может зайти в середину прогона и продолжить без потерь.
Двенадцать опор жёсткости (+2 новых после v3.0)
parameters.yml · research-plan.md · tracks-grid.md · ontology.yml · synthesis.md · competency-questions.md · mirror-map.md · gap-analysis.md. Это полный набор точек состояния. По наличию/отсутствию файла можно мгновенно понять, на каком блоке прогон.
В каждом cases/XX/ лежит INIT_MESSAGE.md с готовым промптом: «Прочитай parameters.yml, ontology.yml, последний artifact. Состояние прогона — N. Текущая задача — ...». Этим достигается, что новая сессия за один шаг входит в контекст.
В каждой папке кейса — log решений. Не «обсудили устно», а «дата · блок · цитата согласия». Это якорь для случаев, когда нужно быстро понять, почему параметр такой, а не иной. Один или несколько коротких записей на каждый закрытый такт-5 петли.
Дополнение к decisions.log, появилось по итогам Эксперимента-2 (FINDING #1). Содержит ВСЁ взаимодействие: мои вопросы (QUESTION), мои черновики (DRAFT), технические наблюдения (ANALYSIS), ответы пользователя (ANSWER), директивы (DIRECTIVE), критики и reframing (CRITIQUE), финальные согласия (CONFIRM), находки по ходу (FINDING). Каждая запись: [timestamp · phase · actor · type] content. Без этого:
теряется контекст «почему здесь именно так, а не иначе»; невозможно метаобучение системы; при сверке утверждений с источниками — теряется промежуточная логика.
Разделение нагрузки: decisions.log = «что было решено» (быстрый ответ), interaction.log = «как именно к этому пришли» (полный контекст).
parameters.yml — YAML schema (6 ключей, enum для «тип онтологии»). entities.csv — column schema (id · type · name · source · created_at · CI). delta.md — наличие 4 разделов. Валидатор запускается на такте-5 каждой петли. Без валидации — выход не считается зафиксированным.
При обновлении ontology.yml — старая версия копируется в archive/ontology-vN.yml. Это даёт возможность откатиться или сравнить, как менялось понимание области между прогонами.
В entities.csv и relations.csv в каждой строке — поле source (путь к файлу + цитата/якорь внутри). При расхождениях между сессиями всегда можно вернуться к источнику и пересмотреть.
Расчёт CI · валидация шаблонов · построение adjacency графа · подсчёт покрытия CQ — детерминированные функции. Они не зависят от состояния чата. Если LLM в новой сессии «забыл» — DET перезапускается на текущих файлах и даёт тот же результат.
В каждой строке entities.csv / relations.csv / delta.md хранится char-locator: source_file + source_char_start + source_char_end. Клик на утверждение в analytics.html / графе → выделение точного фрагмента в raw_text источника. Клик на цитату → подсветка утверждений, которые на ней базируются. Это не только UX-удобство, но инструмент верификации: пользователь мгновенно видит, правильно ли LLM интерпретировал фрагмент. Без двусторонней верифицируемости любая ошибка LLM в extract-фазе тиражируется через весь дальнейший конвейер.
При extract из нескольких hubs (фаза A4) каждый hub имеет свой ID prefix (ENT-NNN, ENT-MNN, ENT-PNN, ENT-INN, ENT-SNN, etc.). Если person/org уже есть в графе под ENT-X — не создавать дубликат, использовать существующий ID в relations нового hub. Это создаёт cross-bridge edges автоматически через graph topology. Дублирование = false-negative cross-bridge counts (граф будет показывать 0 bridges где их 10). См. doctrine skills/ecosystem-extract-and-aggregate/doctrines/id-reuse-cross-bridges.md.
При проверке hypothesis типа «X-узлов в Y-positions» — не проверять через label string match (`hub_source.contains('X')` или ID prefix). Проверять через actual graph structure: соседи, кратчайшие пути, intersections of edge sets. Bug pattern первой итерации CH-2 проверки exp-2: проверяли metadata-тег → ложно-отрицательный verdict «PRELIMINARY». Refined check через neighborhood hub_sources дал 6/10 top-betweenness cross-bridges. См. doctrine skills/ecosystem-extract-and-aggregate/doctrines/metadata-vs-graph-structure.md.
В v3.2 и ранее метод имел inverted causality: Q5 онтология определялась в A1 через guess, ДО reconnaissance экосистемы. Это запирало мышление в narrow box и упускало целые классы акторов. v4.0/v3.0 fix: сначала A0 cartographie (actors-map + dependencies-map + events-timeline) даёт inductive «карту территории», только потом A1.5 синтезирует формальную онтологию с пониманием всех нужных типов. Это same pattern как в Block-Zh academic structure — там сначала SVG-карта 1280×820 с 50+ named boxes, ПОТОМ формальная классификация. См. METHOD v4.0 §00 + §01b. Anti-pattern: определять Q5 в A1 «угадыванием» — это всегда даёт incomplete ontology.
Эта опора создаёт cross-cutting петлю feedback между data layer и schema layer:
- Trigger 1: Extract phase обнаружил новый relation type → flag for
onto-extension v+1 - Trigger 2: Reflect_block emerged_questions указывают на missing entity type → propose onto-extension
- Trigger 3: A5 contradictions Class 6 ONTOLOGY_GAPS выявил entities не вписывающиеся в Q5 → propose
- Action: Onto-extensions versioned (v8 → v9 → v10) с explicit rationale в
ontology-history.md
В v3.2 emerged extensions (was_juror_then_ambassador · patron_of · helped_found · 9 institutional archetypes) появлялись постфактум без формализации. Опора 12 предотвращает это: continuous feedback гарантирует что онтология «дышит» с данными.
Состояние прогона = (набор файлов-якорей) + (decisions.log) + (детерминированные индексы) + (char-locators до источника). Сессия LLM — это рабочая память, она может меняться. Файлы и char-locators — долговременная память, она инвариантна и проверяема. Эта тройка даёт ту жёсткость, которую ты ищешь.
Эксперимент-1 · что попробовать прямо сейчас
Не строить все 13 скиллов сразу. Прогнать петлю уточнения на одном блоке, на знакомом материале, увидеть как держится — и только после этого закладывать остальное.
Что берём
- Материал: кейс Western AI · 2026-04 (
cases/01-western-ai-ecosystem-2026-04/source/). Он уже знаком и есть как референс. - Блок: A1 (Параметры запуска). Самый простой, самый показательный для петли уточнения. После него — А4 (онтология+дельта) на одном небольшом подмножестве материала.
- Скилл: пока ничего нового не пишем. Прогоняем вручную, по 5-тактной петле, через обычный чат. Цель — потрогать паттерн и увидеть слабые места.
Шаги эксперимента
- Подготовить «эксперимент-1»-папку. Создать
cases/exp-1-loop-test/с пустыми parameters.yml + decisions.log + INIT_MESSAGE.md (готовый промпт «прочитай и продолжи»). - Прогнать петлю A1. 6 параметров последовательно (по одному за такт-2). Каждое согласование — цитата в decisions.log. На такте-5 — валидация YAML вручную (пока без скрипта).
- Закрыть сессию. Открыть новую сессию. Скопировать INIT_MESSAGE — увидеть, начинается ли работа «с того места», или теряется.
- Прогнать петлю A4 на одном источнике. Взять одну страницу из материалов Western AI. Прогнать 4 такта (Scan → Extract → Classify → Gap-fill). Записать в delta.md по шаблону.
- Чекаут. Заполнить короткий отчёт в
cases/exp-1-loop-test/REPORT.md: что сработало, что нет, какие правки нужны в IDEF0-разложении, какие — в шаблонах, какие — в DET-функциях.
Что проверяем
- Жёсткость петли уточнения. Действительно ли «один вопрос за такт» удерживает фокус, или это слишком медленно.
- Переход между сессиями. Работает ли INIT_MESSAGE как «загрузчик контекста».
- Демаркация LLM vs DET. Видна ли граница, не размывается ли она в реальной работе.
- Шаблоны. Те ли поля в parameters.yml и delta.md; что нужно добавить/убрать.
- Темп. Сколько реально времени уходит на один блок, чтобы оценить трудозатраты на полный прогон.
Что НЕ делаем в эксперименте-1
- Не строим скиллы (даже первой волны).
- Не пишем DET-скрипты для валидаторов (только проверяем глазом).
- Не делаем синтез на полном корпусе — только на одном источнике.
- Не тратим время на красоту артефактов — это draft-режим.
Если паттерн держится — закладываем Волну 1 скиллов (ecosystem-init, ecosystem-ontology, ecosystem-extract-knowledge-delta, ecosystem-synthesis, ecosystem-validate-cqs) и пишем первые DET-валидаторы. Если что-то рассыпается — пересобираем IDEF0-разложение в той части, где сломалось, перед тем как закладывать скиллы. Это и есть «раз-два-три раз-два-три»: маленький прогон → правка → следующий прогон.