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

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

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; инструмент потоков только перемещает данные между шагами.

Кандидат	Почему нет
n8n	Fair-code, не open source.
Node-RED, Activepieces	Состояние в памяти; батч на 7–12 часов умирает с процессом.
Dagu	Это runner в духе GitHub Actions: граф и логи, но без холста, настройки узлов и просмотра данных между шагами. Алекс с ним не работал.
Temporal, Prefect, Dagster	Либо без визуального редактора, либо Python-first.
Windmill	Холст, шаги на Python/TS/Bash/SQL, durable runs, approval-шаги, просмотр входа/выхода каждого узла, AGPL, Docker-стек на Mac.

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 не пишется; старый 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).

9.2 KiB Raw Blame History Unescape Escape