Files
obsidian-vault/personal/projects/personal-os/personal-os-windmill-system-map-2026-10-10.md
T
2026-10-15 09:50:58 +00:00

108 lines
16 KiB
Markdown
Executable File
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
> 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 задач без ошибок. [Контракт и проверка](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md#постоянный-worker--14102026).
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. Локальный агент вызывается отдельно, его результат остаётся кандидатом. [Приёмка в репозитории](/Users/admin/Developer/personal-os/planning/github-work-situations-2026-10-14.md).
Карта теперь содержит 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. Это само по себе не доказывает подходящую гарантию длительного батча. [Официальный контракт](https://nodered.org/docs/user-guide/context). |
| Activepieces | Самостоятельная установка использует PostgreSQL и Redis; прежняя причина про хранение только в памяти снята. [Официальная установка](https://www.activepieces.com/docs/install/options/docker-compose). |
| Dagu | Имеет Web UI, графы, логи и редактор YAML; тезис об отсутствии настройки узлов в UI снят. Сопоставимый canvas-тест здесь не проводился. [Официальный Web UI](https://docs.dagu.sh/overview/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`).