obsidian-vault/personal/projects/personal-os/personal-os-windmill-system-map-2026-10-10.md

---

Runtime 14.10.2026: старый Asana collector заменён постоянным worker в основной personal_os. Windmill schedule каждые пять минут, live project/personal rosters каждые 15 минут, events cursors, independent retries и совместимая legacy read projection. Первый live pass перечитал все 28 проектов и нашёл 35 620 memberships; начальный refresh backlog показан отдельно в dashboard. Автоматический scheduled batch выполнил 3 000 GET и обновил 648 задач без ошибок. Контракт и проверка.

date: '2026-10-10' status: partial-real-flows tags:

• personal-os
• windmill
• architecture
• system-map updated: '2026-10-14'

---

Personal OS — карта системы в Windmill (2026-10-10)

Проверено 14.10.2026: GitHub, ситуации, work items и designs находятся в основной personal_os после подтверждённого переноса 17 таблиц с совпавшими хешами. 121 work item / 17 репозиториев, 105 в очереди; 79 проверенных PR, 215 точных Asana–PR связей; 16 сигналов и 39 явных gaps. Локальный агент вызывается отдельно, его результат остаётся кандидатом. Приёмка в репозитории.

Карта теперь содержит 21 поток и отдельный overview. Реальные шаги есть у f/analyse/work_triage, f/fetch/github_prs, f/analyse/work_situation; остальные mapped flows остаются скелетами. work_claims_extract не развёрнут: каталог 486 работ получен отдельными скриптами стенда. Статусы settled/running в карте описывают соответствующие внешние процессы, а не наличие реализации в Windmill. Расписаний для новых GitHub/work flows не добавляли. Разделы 1–7 ниже — датированная история.

Продолжение personal-os-rlm-stand-results-2026-10-10. Вечером 10 октября после обсуждения принято: нужна визуальная, исполняемая карта системы, а не рисунок. Развёрнут локальный Windmill; вся система описана как 18 потоков-скелетов и один обзорный поток. На момент начальной поставки 10.10 логики в узлах не было; текущая реализация указана выше.

1. Почему Windmill, а не n8n / Node-RED / Dagu

Требования Алекса: видеть систему целиком как граф потоков данных, участвовать в проектировании, менять узлы, видеть что прошло между шагами. Ранние заметки (personal-os-architecture-decision-2026-10-04, personal-os-six-layer-analysis-2026-10-05) отклоняли n8n/Node-RED по другой причине: они не дают семантики истины. Это верно, но не относится к слою оркестрации: правила и claims остаются кодом и таблицами PostgreSQL; инструмент потоков только перемещает данные между шагами.

Кандидат	Уточнение проверки 14.10.2026
n8n, Temporal, Prefect, Dagster	Не выбранные в этой итерации варианты; сопоставимого испытания на этом корпусе нет.
Node-RED	Общее утверждение «состояние только в памяти» неверно: есть filesystem context store. Это само по себе не доказывает подходящую гарантию длительного батча. Официальный контракт.
Activepieces	Самостоятельная установка использует PostgreSQL и Redis; прежняя причина про хранение только в памяти снята. Официальная установка.
Dagu	Имеет Web UI, графы, логи и редактор YAML; тезис об отсутствии настройки узлов в UI снят. Сопоставимый canvas-тест здесь не проводился. Официальный Web UI.
Windmill	Выбран и развёрнут как текущий слой оркестрации; эта поставка проверяет его локальные потоки, а не превосходство над всеми альтернативами.

2. Что развёрнуто

• windmill/ в репозитории personal-os: docker-compose.yml (server, worker, native worker, LSP, caddy), .env вне git, README.md.
• Один PostgreSQL: Windmill использует БД windmill на хостовом PostgreSQL 17 (роли windmill, windmill_user, windmill_admin). Данные Personal OS остаются в personal_os. Контейнеры выходят на хост через host.docker.internal; проверено, что соединение из контейнера приходит с 127.0.0.1 и проходит по pg_hba.
• UI: http://localhost:8000, workspace personal_os. Пароль суперадмина сменён Алексом; CLI-токен в windmill/.env.
• Образ закреплён: ghcr.io/windmill-labs/windmill:1.829.0. Попутно удалён протухший логин ghcr.io из ~/.docker/config.json, он блокировал анонимные pull.

3. Карта

Источник — windmill/system-map.yaml. Генератор windmill/bootstrap/gen_map.py создаёт workspace/f/<стадия>/<поток>__flow/ со стабами по одному на стадию; wmill sync push отправляет на сервер. Каждый стаб возвращает своё описание: что читает, что пишет, какой скрипт ему соответствует.

Стадии: fetch → observe → analyse → publish → attend. Обзорный поток f/system/overview — один холст, где узлы — потоки, сгруппированные параллельными ветками по стадиям.

Статус	Потоки
settled	asana_sync, mattermost, zoom_notes, github_snapshot, activity, focus_shadow
running	asana_expansion_e1
disabled	zoom_export, status_readonly
draft	project_truth
PROPOSED	work_claims_extract — шесть стадий: read_tasks → read_stories → build_packet → run_model → parse_result → write_claims; черновой код шагов лежит в windmill/bootstrap/steps, не развёрнут
PLANNED	corpus_and_gold_e2, work_links, mechanism_e3, claims_review, roles_importance_e4, attention_loop_e5, retrospector

Прогон обзорного потока прошёл: воркер, Python и сеть до хоста работают.

4. Границы и правила

• Пока поток — скелет, источник правды — system-map.yaml; push перезаписывает правки на холсте. Как только поток получает реальные шаги, источником становится его flow.yaml, правки делаются на холсте и забираются wmill sync pull; поток убирается из генератора. По одному потоку за раз.
• Сборщики Mattermost и Zoom нуждаются в залогиненном Chrome на Mac и не могут выполняться в контейнере. Их узлы остаются тонкими (триггер/наблюдение), пока не выбран host-side runner.
• Обзорный поток, запускающий всё подряд, — демонстрация, а не реальная каденция. Расписания вешаются на отдельные потоки.
• Потоки сбора и локальный агент не пишут в Asana/GitHub. С 14.10 дашборд содержит отдельное действие создания Asana-задачи из проверенного черновика; старый Executor остаётся выключенным.

5. Следующий шаг

Алекс смотрит холст и system-map.yaml и говорит, где картина неверна: каких потоков нет, какие стадии названы неправильно, каким «settled» сборщикам он не доверяет. Затем выбирается один поток, которому даётся «мясо».

6. Дополнение 2026-10-11: ситуации, которых не видит извлечение claims

Алекс перечислил реальные ситуации: административный шум («пройти опрос», «подтвердить банковский счёт»), назначенное, но не начатое; сделанное наполовину и давно не обновлённое (нужен пост о состоянии); локальные worktree-эксперименты без push; смерженные PR без комментария в задаче; PR-черновики; PR с комментариями без реакции. Извлечение claims читает только Asana-записи одного поддерева и видит из этого лишь «назначено, не начато». Пять из семи ситуаций требуют зеркала GitHub PR, которого в БД нет (PR есть только как URL в тексте и как живой снимок открытых PR).

В карту добавлены (только план, не реализовано):

Поток	Статус	Что делает
f/fetch/github_prs	planned	Зеркало моих PR: состояние, draft, ревью, комментарии, дата merge, ссылка на задачу из тела PR. Идёт раньше батча на 250 работ.
f/analyse/work_triage	proposed	Разделить шум и работу до извлечения: правила по проекту/имени, один дешёвый вызов модели для нерешённых корней, кандидат-аннотация в task_annotations, подтверждение Алексом (approval-шаг). Подтверждённый шум исключается из E2.
f/analyse/work_situation	planned	Флаги по работе кодовыми правилами поверх claims + PR + worktrees: noise, untouched, stale, local-only, merged-silent, draft-pr, review-pending, каждый с уликой; одно предлагаемое действие на флаг для attend. Записей в Asana/GitHub нет.

Эти семь ситуаций должны стать контрольными случаями эталона E2.

Список E2: все мои задачи сведены к корням по цепочке parent из asana_task_observations: 1396 корней, 135 с открытой моей работой, 115 закрытых за 3 месяца. Предложение: 135 + 115 = 250 работ после триажа; из них ~80 для ручной разметки. Файл: tools/rlm-lab/datasets/private/e2-draft-2026-10-11/list.md. Батч по 10 оставшимся работам выборки 10.10 запущен 11.10 в 11:43 (eval/batch-2026-10-11.log).

7. Результат первого прохода E2 (11–12 октября 2026)

Очередь отработала целиком с 11:43 11.10 до 07:20 12.10 на локальной Qwen3.8-27B через проверенный путь стенда (build_input.py → baseline.py → rlm-claims-load.js), не через Windmill-поток извлечения, который остаётся скелетом. Триаж шёл через реальный поток Windmill f/analyse/work_triage без паузы на подтверждение.

Фаза	Работ	Исход
Выборка 10.10, остаток	10	все загружены
E2: 50 открытых + 30 закрытых с июля	80	80 загружены, 4 невалидных JSON
b: остаток окна с июля	98	все загружены
c: закрытые за 12 месяцев	294	293 загружены, 1 сбой по таймауту

Итого в work_analysis_runs 481 прогон, 475 валидных, 18,5 часа модели, в среднем 8 тысяч токенов промпта. В work_claims 11 995 утверждений-кандидатов; 5 807 с цитатой, из них 5 794 цитаты существуют в записях. Триаж в task_annotations: 494 корня work, 227 recurring, 54 rotation, 47 admin, 15 personal, 18 unknown.

Что видно до разметки:

• Флаг confirmed по-прежнему бесполезен: 707 из 712 «implemented» и 238 из 240 «released» помечены как подтверждённые. Правила принятия в коде обязательны до любого использования.
• Четыре крошечные работы (одна задача, несколько историй) получили голый массив или эхо схемы вместо объекта; нужен строгий повтор для тонких входов.
• Модель иногда выдаёт состояния вне перечня («completed», «closed»); разбор результата не проверяет enum.
• Одна работа с 300 подзадачами дала пакет 405 тысяч символов: обрезка по бюджету в build_input.py не гарантирует предел, вызов не уложился в 30 минут. Чинится принудительной обрезкой.
• Mattermost и Zoom ни к одной работе не привязались: явных ссылок нет, это ожидаемо до потока work_links.

Данные: tools/rlm-lab/datasets/private/{e2,e2b,e2c}-2026-10-11/ (вне git), журнал очереди queue-2026-10-11/queue.log.

Полная выгрузка результатов по всем 486 работам со ссылками на Asana и выводом модели: work-claims-results-2026-10-12 (2 МБ; генерируется scripts/rlm-results-export.js).