[2026-10-10] eagle: personal/projects/personal-os/personal-os-architecture-decision-2026-10-04.md personal/projects/personal-os/personal-os-data-analysis-workflow-2026-10-09.md personal/projects/personal-os/personal-os-rlm-stand-results-2026-10-10.md personal/projects/personal-os/personal-os-system-review-index.md personal/projects/personal-os/personal-os-windmill-system-map-2026-10-10.md

2026-10-10 22:25:51 +06:00
1 parent 4e03cfdf4b
commit 4b702f6f0f
@@ -1,5 +1,7 @@
 # Personal OS — архитектурный проект R2

+> Дополнение 10.10: строка «n8n/Node-RED не обоснованы» относилась к семантике истины, а не к оркестрации. Для визуальной исполняемой карты потоков развёрнут Windmill (open source, durable runs, холст) на том же PostgreSQL; правила, claims и принятие остаются кодом и таблицами. См. [[personal-os-windmill-system-map-2026-10-10]].
+
 > Актуальное уточнение 05.10: [шесть уровней Personal OS](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md). Условия: личный доступ, открытые компоненты, без изменения систем компании. Очередность: покрытие проектов → эталон и явные связи → испытание Cognee/Graphiti → роли и важность → внимание и ретроспекция. Исследование выявило потери Asana; исправления и модельные прогоны ещё не выполнены. Корпоративный shortlist больше не определяет первый этап.

 > Дополнение 04.10: [понимание потока работ и этапы WG-0–WG-4](/Users/admin/Developer/personal-os/planning/personal-os-work-graph-research-2026-10-04.md). Приоритет проверки — покрытие корпуса, обнаружение связей, текущая ситуация и роль пользователя. Это исследовательское уточнение для согласования; выбранный PostgreSQL core сохраняется, новые модели и graph runtime не внедрены.
@@ -225,6 +225,9 @@ Graphiti передаёт при извлечении отношений пре

 - Второй прогон (тот же день): одиночный вызов Qwen27B по схеме v2 (утверждения о состоянии с уликами) на 4 работах — все четыре дали валидный JSON, 80 из 80 улик существуют, роли Алекса и хронология верны. Две системные ошибки: релиз помечается подтверждённым по движению на release board или бот-упоминанию; закрытая подзадача читается как «реализовано» (CoreData в VSCode-миграции, хотя подход отменён). Эти ошибки не лечатся промптом, нужны правила в коде перед принятием. Утверждения лежат как candidate в `work_claims` (миграция 007). Готовые графовые продукты для этого шага не нужны. Отчёт: `eval/report-v2-2026-10-10.md`.

+
+- Вечер 2026-10-10: вся система описана как потоки в локальном Windmill (скелеты, без логики); одиночное извлечение из второго прогона — поток `f/analyse/work_claims_extract` со статусом PROPOSED. См. [[personal-os-windmill-system-map-2026-10-10]].
+
 ### 9.2. Дальнейшие шаги и условия перехода

 1. **Выбрать данные после развёртывания стенда.** Начальный ориентир — 10–15 связных работ, а не случайные отдельные записи. Алекс выбирает состав; для каждой работы собрать оригиналы, родителей/подзадачи, memberships, существенные комментарии, PR и связанные обсуждения. Зафиксировать snapshot, IDs, версии/hash, время события и загрузки, недостающие материалы. Реальные данные в стенд пока не загружать до выбора.
@@ -85,3 +85,7 @@ tags:
 - Задачи релизов нужно добавить в выборку.
 - Графовые продукты для этого шага не нужны; Cognee и Graphiti остаются вопросом для поиска между работами.
 - Цена: 4 работы ≈ 29 минут модели; 60–100 эпизодов это 7–12 часов батчем на этой машине.
+
+## 7. Дополнение (вечер 2026-10-10): карта системы в Windmill
+
+Обсуждение показало, что без визуальной карты Алекс не может участвовать в проектировании. Развёрнут локальный Windmill на хостовом PostgreSQL; вся система описана как 18 потоков-скелетов и обзорный холст, без логики и расписаний. Шесть стадий из раздела 5 стали потоком `f/analyse/work_claims_extract` со статусом PROPOSED. Подробности и правила работы с картой: [[personal-os-windmill-system-map-2026-10-10]].
@@ -7,12 +7,15 @@ updated: 2026-10-05

 > **Обновление 10.10.2026:** схема и данные E1 находятся в рабочей PostgreSQL-БД `personal_os` на `localhost:5432`; LaunchAgent сборщика Asana пишет туда и продолжает работу с сохранённых checkpoint. Временная E1-БД на порту 55439 больше не является целью сборщика. Покрытие пока неполное: строгую проверку проходят 17 из 28 проектов. См. текущий [[personal-os-action-plan-2026-10-05]] и [журнал восстановления E1](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md).

+> **Обновление 10.10.2026 (вечер):** система визуализирована в локальном Windmill как 18 потоков-скелетов и обзорный холст; логики и расписаний нет. Карта и правила: [[personal-os-windmill-system-map-2026-10-10]].
+
 **Сейчас работать по [[personal-os-action-plan-2026-10-05]].** В нём — детальные пакеты E1.1–E1.5, результаты, проверки, зависимости и участие Алекса. Обоснование выбора компонентов — [[personal-os-six-layer-analysis-2026-10-05]].

 Архитектурные противоречия устранены в плане: одна PostgreSQL-модель, immutable evidence и типизированные claims, semantic acceptance, единая публикация, scoped feedback, один владелец каждого collector и последовательные gates реализации. Runtime по этому плану ещё не внедрён; новые запуски и расписания не включались.

 | Документ | Назначение |
 |---|---|
+| [[personal-os-windmill-system-map-2026-10-10]] | Карта системы в Windmill: 18 потоков по стадиям fetch/observe/analyse/publish/attend, обзорный холст, источник `windmill/system-map.yaml`. |
 | [[personal-os-db-browser]] | Локальный браузер БД: запуск на `127.0.0.1:4317`, источник `personal_os` на `localhost:5432`, проверка режима read-only. |
 | [[personal-os-action-plan-2026-10-05]] | Текущая очередь E1–E5: ближайшие пакеты, поставки, проверки и зависимости. |
 | [[personal-os-system-review-2026-10-04]] | Полный план: роли, data flow, инструкции, расписания, SC1–SC8, AC01–AC16 и R0–R4. |
@@ -0,0 +1,59 @@
+---
+date: '2026-10-10'
+status: deployed-skeleton
+tags:
+  - personal-os
+  - windmill
+  - architecture
+  - system-map
+---
+# 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» сборщикам он не доверяет. Затем выбирается один поток, которому даётся «мясо».