В предыдущей публикации я попытался ответить на вопрос Зачем деятелю систематическое медленное чтение и как это реализовать?
Хотя в публикации были расписаны задачи, принципы и ряд других основных элементов практики, не думаю, что мне удалось ответить на вопрос, как реализовать медленное чтение.
Почему? Потому что чтение неотделимо от письма. Про мышление письмом особо не рассказал - тема реализации медленного чтения не раскрыта.
Другое наблюдение. Потребление информации происходит не только в результате чтения, но и в результате просмотра видео (учебных курсов, докладов).
Просмотр видео также может рассматриваться как начало творческого конвейера, как и чтение, если в процессе деятель размышляет через письмо.
Интересно, почему в МИМ-руководстве эта аналогия не приведена?
Но цель этой публикации — найти ответ на вопрос, как же организовать творческий конвейер.
Хотя с начала практики у меня уже набралось порядочное количество артефактов мышления письмом, конвейер пока не выстраивается так, как хотелось бы.
Я сразу начал использовать IWE. Так как я принадлежу к числу тех, кто документацию не читает, то мне кажется, что мое текущее состояние конвейера отличается от того, как задумано в IWE.
Ниже я попытался задокументировать, как это задумано в IWE.
Что меня смущает — контент из разных предметных областей в итоге сходится в DS-Knowledge-Index. Для меня это кажется неестественным. Например, черновики остаются в архиве <DS-репо>. Т. е. если позже захочется проследить ход собственных мыслей от заметки (DS-strategy/archive/notes/Notes-Archive.md) к черновику (<DS-репо>/archive/) и к публикации (DS-Knowledge-Index/docs/) придется перемещаться по трем разным репозиториям.
Реализация творческого конвейера в IWE
Концепция (DP.M.003): 4 стадии превращения мысли в публикацию.
| Стадия | TTL | Файл/инструмент | Роль |
|---|---|---|---|
| Заметка | 7д | DS-strategy/inbox/fleeting-notes.md |
R18 Автор заметок |
| Черновик | 7д | <DS-репо>/drafts/ + DS-strategy/drafts/draft-list.md |
R1 Стратег |
| Заготовка | 14д | DS-Knowledge-Index/docs/ (status: draft) |
R4 Автор |
| Пост | — | DS-Knowledge-Index/docs/ (status: published) → S47 → внешние каналы |
R21 Публикатор |
Ритуалы: Note-Review (23:00, R1) → Strategy Session (еженедельно).
Стражи: Day Open флаг по просроченным TTL, Strategy Session блокирует без решения.
Самооценка: DS-self-development/content/modeling-4-4-creative-conveyor.md (7 подстадий).
Связи: Slow Reading (Ch3) → Stage 1; Writing-Thinking (Ch4) → Stage 2→3; Capture-to-Pack на каждом рубеже.
Механика переходов
Пометки заметок в fleeting-notes.md
| Вид в файле | Значение | При переходе в следующую стадию |
|---|---|---|
**Заголовок** |
Новая, не обработана | Остаётся до Note-Review |
**Заголовок** 🔄 |
Неясно, вернуться при стратегировании | Остаётся, разбирается на Strategy Session |
Заголовок (без bold) |
Обработана — как прочитанное сообщение | → DS-strategy/archive/notes/Notes-Archive.md + удалить из файла |
~~Заголовок~~ |
Шум (тест, дубль, случайное) | → DS-strategy/archive/notes/Notes-Archive.md + удалить из файла |
Стадия 1 → 2: Заметка → Черновик
Note-Review (ежедневно, 23:00) классифицирует жирные заметки. Источник: FMT-exocortex-template/roles/strategist/prompts/note-review.md §10.
- Категория «Черновик» → рекомендация в WeekPlan (секция «Предложения Note-Review»). Файл НЕ создаётся.
- Пользователь одобряет → создаётся
<DS-репо>/drafts/YYYY-MM-DD-slug.md+ запись вDS-strategy/drafts/draft-list.md. - Заметка де-болдируется (обработана).
- §10a: заметка копируется в
DS-strategy/archive/notes/Notes-Archive.mdс категорией «Черновик». - §10b (БЛОКИРУЮЩЕЕ): блок заметки удаляется из
DS-strategy/inbox/fleeting-notes.mdцеликом. Без этого шага файл засоряется. - §10c (верификация): прочитать
fleeting-notes.mdи убедиться, что блок удалён. Если не удалился — повторить шаг 10b. Не переходить дальше пока файл не чист.
Стадия 2 → 3: Черновик → Заготовка
R4 Автор переносит содержимое в DS-Knowledge-Index/docs/YYYY/YYYY-MM-DD-slug.md (status: draft).
Черновик в <DS-репо>/drafts/ закрывается: запись в DS-strategy/drafts/draft-list.md → статус done → перемещается в <DS-репо>/archive/.
Почему заготовка идёт в DS-Knowledge-Index, а не в <DS-репо>/docs/?
Переход Черновик → Заготовка — это переход из рабочего пространства (DS/instrument, DS/governance) в поверхность публикации (DS/surface). Это смена типа репозитория, а не просто смена папки.
Три причины централизации в DS-Knowledge-Index:
- S47 смотрит в одно место. Multi-Channel Publisher ищет
status: publishedвDS-Knowledge-Index. Если публикации в доменных репо — S47 должен обходить все. - Кросс-доменная находимость. Читатель не должен знать, в каком доменном репо лежит нужный материал — всё в одном индексе.
- OwnerIntegrity. Один артефакт — одно место. Иначе одна идея может существовать одновременно и в
DS-self-development, и вDS-Knowledge-Indexв разных стадиях.
Почему DS-Knowledge-Index содержит посты из разных доменов — и это правильно?
DS-Knowledge-Index — репо типа DS/surface. Его задача — публичное лицо всего IWE, а не одного домена. Пять принципов:
- Аудитория не знает внутреннюю структуру. Читателю всё равно, что пост про SQS живёт в
DS-IT-systems, а про Writing — вDS-self-development. Он читает человека, не его файловую систему. - Разделение типов репо.
DS/instrumentиDS/governance— рабочее пространство (точность важнее стиля).DS/surface— публикационная территория (стиль = доверие). Разные требования → разные репо. - Единый издательский процесс (SC.005). S47 не разбирается в доменах — только в
status: published. Один протокол для всего контента независимо от источника. - Кросс-доменное перекрёстное опыление. Читатель, пришедший за SQS, обнаруживает пост о Writing-as-Thinking — и видит связь между ними. Это невозможно, если публикации разбросаны по доменным репо.
- IWE — среда мышления через все домены. Knowledge Index отражает целостность: IT + саморазвитие + стратегия — не раздельные активности, а единая мыслительная среда одного человека.
Стадия 3 → 4: Заготовка → Пост
Переход делается в том же файле DS-Knowledge-Index/docs/YYYY/YYYY-MM-DD-slug.md — он не перемещается и не архивируется:
- R21 Публикатор редактирует заготовку: добавляет вводный контекст для новой аудитории (без жаргона домена).
- R21 меняет
status: draft→status: publishedв frontmatter файла. - S47 (Multi-Channel Publisher) обнаруживает файл с
status: publishedи публикует в каналы (LinkedIn, Telegram, Medium и др.).
Что остаётся в DS-Knowledge-Index: файл со статусом published хранится там постоянно — это единственная копия финального поста. Не удаляется, не архивируется. Становится частью публичного индекса.
Заготовка ≠ Пост — различение содержания, не местоположения:
| Заготовка (status: draft) | Пост (status: published) | |
|---|---|---|
| Аудитория | Тот, кто знает контекст | Новая аудитория без контекста |
| Начало | Сразу к сути | Вводный абзац: «зачем читать» |
| Жаргон | Допустим (МИМ-термины, аббревиатуры) | Убран или объяснён |
| Файл | Тот же | Тот же — только frontmatter меняется |
Почему разные <DS-репо>/drafts/ сходятся в один реестр
DS-strategy — репо типа DS/governance, личный стратегический хаб. Его задача — координация всего IWE, а не хранение предметного контента. draft-list.md — инструмент координации, не хранилища.
Паттерн: распределённое хранение + централизованный реестр.
DS-self-development/drafts/writing-vs-thinking.md ──┐
DS-strategy/drafts/sdd-vs-tdd-distinction.md ──┼──→ DS-strategy/drafts/draft-list.md
DS-IT-systems/drafts/sqs-processing-patterns.md ──┘ (R1 видит всё)
Без централизованного реестра три операционные проблемы:
- Guards не работают. Правило ≤5/6–10/>10 считает суммарное количество черновиков во всех репо. Без реестра R1 должен обходить каждый
DS-*/drafts/вручную. - TTL-стражи слепые. Day Open проверяет просроченные TTL по одному файлу. Без
draft-list.md7-дневный срок черновика вDS-IT-systems/незаметно истечёт. - Strategy Session без контекста. Решение «продвигать / архивировать / переносить» требует полного списка. Без реестра — нет единой точки обзора.
Файл живёт там, где ему принадлежит по домену. Запись о файле — всегда в DS-strategy/drafts/draft-list.md, откуда R1 управляет конвейером.
Guards (анти-накопление)
| Черновиков в drafts/ | Состояние |
|---|---|
| ≤5 | Норма |
| 6–10 |  Предупреждение (Note-Review анонсирует) |
| >10 |  Блокировка — новые черновики не добавляются до Strategy Session |
Примеры по трём темам
Пример 1 — Writing (Мышление письмом):
| Стадия | Артефакт | Содержимое |
|---|---|---|
| Заметка (7д) | DS-strategy/inbox/fleeting-notes.md |
«Письмо не фиксирует готовую мысль — оно создаёт среду, где мысль возникает» |
| Черновик (7д) | DS-self-development/drafts/ch4-thinking-writing/writing-vs-thinking.md + DS-strategy/drafts/draft-list.md |
Различение письмо-как-фиксация vs письмо-как-мышление, примеры из опыта |
| Заготовка (14д) | DS-Knowledge-Index/docs/2026/2026-04-29-writing-as-thinking.md (status: draft) |
«Почему я не могу объяснить идею, пока не напишу её» — для МИМ-клуба |
| Пост | DS-Knowledge-Index/docs/2026/2026-04-29-writing-as-thinking.md (status: published) → S47 |
Тот же текст, убран жаргон МИМ, добавлен вводный контекст |
Пример 2 — Spec-Driven Development:
| Стадия | Артефакт | Содержимое |
|---|---|---|
| Заметка (7д) | DS-strategy/inbox/fleeting-notes.md |
«SDD: контракт (спецификация) пишется ДО кода. TDD тестирует поведение — SDD фиксирует намерение» |
| Черновик (7д) | DS-strategy/drafts/sdd-vs-tdd-distinction.md + DS-strategy/drafts/draft-list.md |
Где граница SDD/TDD, кто владелец контракта, почему важно на команде |
| Заготовка (14д) | DS-Knowledge-Index/docs/2026/2026-04-29-sdd-contract-before-code.md (status: draft) |
«Спецификация как первый артефакт» — для команды, со схемой SDD-цикла |
| Пост | DS-Knowledge-Index/docs/2026/2026-04-29-sdd-contract-before-code.md (status: published) → S47 |
«Почему мы стали писать спецификацию до кода» — с результатами из практики |
Пример 3 — AWS SQS Processing:
| Стадия | Артефакт | Содержимое |
|---|---|---|
| Заметка (7д) | DS-strategy/inbox/fleeting-notes.md |
«SQS: visibility timeout истёк раньше обработки → дублирование. Решение: heartbeat или уменьшить batch size» |
| Черновик (7д) | DS-IT-systems/drafts/sqs-processing-patterns.md + DS-strategy/drafts/draft-list.md |
3 паттерна: idempotency, DLQ strategy, batch size tuning — с кодом из фикса |
| Заготовка (14д) | DS-Knowledge-Index/docs/2026/2026-04-29-sqs-three-traps.md (status: draft) |
«AWS SQS: три ловушки» — для технического чата, без объяснения азов |
| Пост | DS-Knowledge-Index/docs/2026/2026-04-29-sqs-three-traps.md (status: published) → S47 |
Тот же текст + вводная секция для читателя без AWS-контекста |
Заключение
Задокументировав конвейер, я лучше понял логику IWE: централизация координации (draft-list.md, DS-Knowledge-Index) при распределённом хранении черновиков. Смущение по поводу «перемещений между тремя репозиториями» объясняется выбранной архитектурой — каждый артефакт живёт в своём типе репозитория (governance → instrument → surface).
Буду рад узнать ваш опыт: как вы организовали творческий конвейер?
Совпадает ли ваше понимание IWE с тем, что я описал, или есть нюансы, которые я упустил?