---

> 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`).