[2026-10-14] eagle: personal/projects/personal-os/autonomous-agent-safety.md personal/projects/personal-os/executor-orchestrator-redesign.md personal/projects/personal-os/executor-v2-redesign.md personal/projects/personal-os/hermes-cron-jobs.md personal/projects/personal-os/hermes-deployment-patterns.md personal/projects/personal-os/hermes-native-vs-docker.md personal/projects/personal-os/knowledge-lifecycle.md personal/projects/personal-os/multi-agent-design-patterns.md personal/projects/personal-os/multi-host-cron-topology.md personal/projects/personal-os/obsidian-vault-strategy.md

This commit is contained in:
Alexey Martemyanov committed 2026-10-14 21:51:10 +06:00
1 parent c35ecf3ed7
commit 809ef6284e
20 files changed
+1116 -579

No files matched your search

@@ -1,7 +1,7 @@
---
title: Autonomous Agent Safety Patterns
created: '2026-05-24'
updated: '2026-05-24'
updated: '2026-10-14'
type: concept
tags: [agent, security, architecture, executor, rules]
sources:
@@ -10,8 +10,8 @@ sources:
- wiki/personal-os-agent-rules.md
confidence: high
related:
- "[[concepts/executor-security-incident]]"
- "[[concepts/executor-orchestrator]]"
- "[[personal/projects/personal-os/executor-security-analysis]]"
- "[[personal/projects/personal-os/executor-orchestrator-redesign]]"
- "[[personal-os-agent-rules]]"
---
@@ -62,7 +62,7 @@ session context.
## The Auto-Approve Table Pattern
From [[concepts/executor-orchestrator]]: instead of blanket trust or blanket
From [[personal/projects/personal-os/executor-orchestrator-redesign]]: instead of blanket trust or blanket
denial, classify actions by risk tier:
| Risk | Action type | Default |
@@ -108,6 +108,6 @@ can be reviewed without running the agent:
## See Also
- [[concepts/executor-security-incident]] — incident post-mortem with full timeline
- [[concepts/executor-orchestrator]] — post-incident architecture (orchestrator pattern)
- [[personal/projects/personal-os/executor-security-analysis]] — incident post-mortem with full timeline
- [[personal/projects/personal-os/executor-orchestrator-redesign]] — post-incident architecture (orchestrator pattern)
- [[personal-os-agent-rules]] — Eagle's specific rules derived from these patterns
@@ -5,7 +5,7 @@ aliases:
- "Spawned Worker Pattern"
- "executor-orchestrator-redesign"
created: '2026-05-14'
updated: '2026-05-31'
updated: '2026-10-14'
tags:
- personal-os
- executor
@@ -15,7 +15,7 @@ related:
- "[[personal/projects/personal-os/executor-v2-redesign]]"
- "[[personal/projects/personal-os/executor-spawning-research]]"
---
> ⛔ **НЕ РЕАЛИЗОВАНО / ИСТОРИЧЕСКОЕ (2026-10-03).** Personal OS выключен. См. [[personal/projects/personal-os/personal-os-status-2026-10]].
> ⛔ **НЕ РЕАЛИЗОВАНО / ИСТОРИЧЕСКОЕ (2026-10-03).** старый Executor выключен; текущий контур указан в [[personal-os-status-2026-10]]. См. [[personal/projects/personal-os/personal-os-status-2026-10]].
# Plan: Executor as Spawned Worker — Orchestrator Pattern
@@ -5,7 +5,7 @@ aliases:
- "executor-v2-redesign"
- "Executor v2"
created: '2026-04-30'
updated: '2026-05-31'
updated: '2026-10-14'
tags:
- personal-os
- executor
@@ -17,7 +17,7 @@ related:
---
# Executor v2 Redesign
> ⛔ **ИСТОРИЧЕСКОЕ (2026-10-03).** Реализовано в репо, кроны на паузе; Personal OS выключен.
> ⛔ **ИСТОРИЧЕСКОЕ (2026-10-03).** Реализовано в репо, кроны на паузе; старый Executor выключен; текущий контур указан в [[personal-os-status-2026-10]].
> См. [[personal/projects/personal-os/personal-os-status-2026-10]] · [[personal/projects/personal-os/personal-os-failed-approaches]].
**Date**: 2026-04-30
@@ -2,12 +2,12 @@
title: Hermes Cron Jobs
aliases: [hermes cron, scheduled jobs, cron jobs]
tags: [personal-os, hermes, automation, cron]
updated: 2026-06-24
updated: '2026-10-14'
---
# Hermes Cron Jobs
> ⚠️ **Снимок на 2026-06-24.** Personal OS выключен (2026-10-03), кроны personal-os не возобновляются.
> ⚠️ **Снимок на 2026-06-24.** старый Executor выключен; текущий контур указан в [[personal-os-status-2026-10]] (2026-10-03), кроны personal-os не возобновляются.
> См. [[personal/projects/personal-os/personal-os-status-2026-10]].
All scheduled jobs running in Hermes on Eagle. Managed via **Eagle Dashboard → Crons tab** (`http://localhost:8880`).
@@ -1,16 +1,16 @@
---
title: Hermes Deployment Patterns
created: '2026-05-29'
updated: '2026-05-29'
updated: '2026-10-14'
type: concept
namespace: personal
tags: [hermes, architecture, agent, eagle, kraken, infra]
sources: []
confidence: medium
related:
- "[[tech/hermes-eagle-mac]]"
- "[[tech/hermes-docker-kraken]]"
- "[[tech/hermes-kraken-api]]"
- "[[family/how-to/hermes-eagle-mac]]"
- "[[family/how-to/hermes-docker-kraken]]"
- "[[family/how-to/hermes-kraken-api]]"
- "[[personal-os-architecture]]"
---
@@ -56,9 +56,9 @@ Config volume: `…/docker/hermes/config` → `/opt/data` (`HERMES_HOME`).
`No user exists for uid <N>` **до** чтения ключа. Записать запись изнутри нельзя (`/etc/passwd`
root-owned) → либо bind-mount готового passwd, либо `useradd` в **Dockerfile**, если образ
действительно собирается локально. Проверять `docker inspect --format '{{.Config.Image}}'` +
наличие `build:` в compose **до** правки Dockerfile. Подробности: [[tech/hermes-docker-kraken]].
наличие `build:` в compose **до** правки Dockerfile. Подробности: [[family/how-to/hermes-docker-kraken]].
See [[tech/hermes-docker-kraken]].
See [[family/how-to/hermes-docker-kraken]].
## Pattern 3: Kraken API Server (OpenAI-compat)
@@ -71,7 +71,7 @@ See [[tech/hermes-docker-kraken]].
The tunnel terminates at cloudflared running with `network_mode: host`,
hitting `localhost:8642` directly.
See [[tech/hermes-kraken-api]].
See [[family/how-to/hermes-kraken-api]].
## Comparison
@@ -1,7 +1,7 @@
---
title: Hermes — Native (Eagle) vs Docker (Kraken) Deployment
created: '2026-05-22'
updated: '2026-05-22'
updated: '2026-10-14'
last_synced: '2026-05-22'
type: comparison
namespace: work
@@ -59,7 +59,7 @@ sources:
- `--init` флаг обязателен (zombie reaping)
- `--network=host` для доступа к Zulip на том же хосте
- Vault монтируется через `-v /home/kraken/obsidian:/vault`
- Полный набор правил → [[tech/hermes-docker-kraken]]
- Полный набор правил → [[family/how-to/hermes-docker-kraken]]
## Общее для обоих
@@ -79,7 +79,7 @@ sources:
## Связанные страницы
- [[tech/hermes-eagle-mac]] — детали настройки на Eagle
- [[tech/hermes-docker-kraken]] — детали Docker деплоя на Кракен
- [[family/how-to/hermes-eagle-mac]] — детали настройки на Eagle
- [[family/how-to/hermes-docker-kraken]] — детали Docker деплоя на Кракен
- [[personal-os-architecture]] — полная карта системы
- [[tech/kraken-network]] — сетевая топология
- [[family/how-to/kraken-network]] — сетевая топология
@@ -7,7 +7,7 @@ tags:
- synthesis
- vault
created: '2026-05-19'
updated: '2026-05-19'
updated: '2026-10-14'
type: concept
confidence: 0.9
sources:
@@ -18,7 +18,7 @@ sources:
---
# Knowledge Lifecycle — From Session to Permanent Memory
Синтез: как знание движется от рабочей сессии к постоянной памяти в personal-os. Объединяет [[concepts/agent-memory-architecture]], [[concepts/vault-strategy]] и [[wiki-ingest-process]].
Синтез: как знание движется от рабочей сессии к постоянной памяти в personal-os. Объединяет [[personal/projects/personal-os/agent-memory-architecture]], [[personal/projects/personal-os/obsidian-vault-strategy]] и [[wiki-ingest-process]].
## Общая схема
@@ -76,7 +76,7 @@ Procedural Memory (skills/, workflows)
## Связанные страницы
- [[concepts/agent-memory-architecture]] — когнитивная таксономия памяти (episodic/semantic/procedural)
- [[concepts/vault-strategy]] — три задачи vault: enrichment, LLM wiki, proactive research
- [[personal/projects/personal-os/agent-memory-architecture]] — когнитивная таксономия памяти (episodic/semantic/procedural)
- [[personal/projects/personal-os/obsidian-vault-strategy]] — три задачи vault: enrichment, LLM wiki, proactive research
- [[wiki-ingest-process]] — hash-based incremental ingest из raw/ symlinks
- [[personal-os-self-modification]] — как система эволюционирует через корректировки
@@ -1,7 +1,7 @@
---
title: Multi-Agent Design Patterns
created: '2026-05-25'
updated: '2026-05-25'
updated: '2026-10-14'
type: concept
namespace: work
tags: [agent, architecture, system]
@@ -11,16 +11,16 @@ sources:
- wiki/concepts/autonomous-agent-safety.md
- wiki/concepts/agent-memory-architecture.md
related:
- "[[concepts/executor-orchestrator]]"
- "[[concepts/autonomous-agent-safety]]"
- "[[concepts/agent-memory-architecture]]"
- "[[personal/projects/personal-os/executor-orchestrator-redesign]]"
- "[[personal/projects/personal-os/autonomous-agent-safety]]"
- "[[personal/projects/personal-os/agent-memory-architecture]]"
---
# Multi-Agent Design Patterns
Synthesis of recurring patterns across the personal-os multi-agent system
and related agent architectures. Distilled from [[concepts/executor-orchestrator]],
[[concepts/autonomous-agent-safety]], and [[concepts/agent-memory-architecture]].
and related agent architectures. Distilled from [[personal/projects/personal-os/executor-orchestrator-redesign]],
[[personal/projects/personal-os/autonomous-agent-safety]], and [[personal/projects/personal-os/agent-memory-architecture]].
## Pattern 1 — Orchestrator / Worker Split
@@ -42,7 +42,7 @@ orchestrator has the only escalation path to the human.
require escalation. Publish the table explicitly.
**Why:** Autonomous agents fail catastrophically when they expand scope
unexpectedly (see [[concepts/executor-security-incident]]). Explicit tables
unexpectedly (see [[personal/projects/personal-os/executor-security-analysis]]). Explicit tables
make failure modes visible.
**Implementation:** Message-type-based approval table. Unknown message types
@@ -64,7 +64,7 @@ knowledge (semantic memory) from immutable facts (procedural/episodic).
fail to retain important session-to-session knowledge.
**In personal-os:** status.md (working) / wiki pages (semantic) /
SCHEMA.md + vault-filling-guide (procedural). See [[concepts/agent-memory-architecture]].
SCHEMA.md + vault-filling-guide (procedural). See [[personal/projects/personal-os/agent-memory-architecture]].
**Pattern rule:** Never update semantic memory from within an active session.
Crystallize post-session. Never trust working memory as a source of truth
@@ -101,7 +101,7 @@ question in list" do not benefit from LLM reasoning and introduce failure modes.
## See Also
- [[concepts/executor-orchestrator]] — concrete orchestrator/worker implementation
- [[concepts/autonomous-agent-safety]] — safety checklist derived from incidents
- [[concepts/agent-memory-architecture]] — memory taxonomy for LLM agents
- [[entities/psychologist-app]] — dual-agent architecture (patterns 1 and 4)
- [[personal/projects/personal-os/executor-orchestrator-redesign]] — concrete orchestrator/worker implementation
- [[personal/projects/personal-os/autonomous-agent-safety]] — safety checklist derived from incidents
- [[personal/projects/personal-os/agent-memory-architecture]] — memory taxonomy for LLM agents
- [[personal/projects/psychologist-app/overview]] — dual-agent architecture (patterns 1 and 4)
@@ -1,7 +1,7 @@
---
title: Multi-Host Cron Topology
created: '2026-05-27'
updated: '2026-05-27'
updated: '2026-10-14'
type: concept
namespace: personal
tags: [system, agent, eagle, kraken, pipeline, sync]
@@ -12,8 +12,8 @@ sources: []
# Multi-Host Cron Topology
Synthesis of how scheduled jobs are distributed across Eagle and Kraken.
Co-occurs in [[tech/hermes-eagle-mac]], [[tech/hermes-docker-kraken]],
[[concepts/watchlist-automation]], and [[personal-os-agent-rules]].
Co-occurs in [[family/how-to/hermes-eagle-mac]], [[family/how-to/hermes-docker-kraken]],
[[family/projects/watchlist-automation]], and [[personal-os-agent-rules]].
## Design Principle
@@ -36,7 +36,7 @@ media-pipeline tasks (watchlist, arr stack). Duplication is a bug.
Eagle crons are Hermes agent jobs — require LLM, vault access,
Asana context. All run via Hermes native (not Docker). See
[[tech/hermes-eagle-mac]].
[[family/how-to/hermes-eagle-mac]].
## Kraken (RPi5) — Pipeline Jobs
@@ -48,7 +48,7 @@ Asana context. All run via Hermes native (not Docker). See
Kraken crons are shell scripts or Python3 — deterministic, no LLM.
Run via Hermes cron on Kraken Hermes instance (port 8642, Docker).
See [[tech/hermes-docker-kraken]] and [[concepts/watchlist-automation]].
See [[family/how-to/hermes-docker-kraken]] and [[family/projects/watchlist-automation]].
## Migration History
@@ -66,6 +66,6 @@ entries or double-adds. Check: `hermes cronjob list` on both hosts.
## See Also
- [[personal-os-agent-rules]] — Eagle's rules and allowed writes
- [[tech/hermes-eagle-mac]] — Eagle Hermes config
- [[tech/hermes-docker-kraken]] — Kraken Hermes Docker setup
- [[concepts/watchlist-automation]] — Full watchlist flow
- [[family/how-to/hermes-eagle-mac]] — Eagle Hermes config
- [[family/how-to/hermes-docker-kraken]] — Kraken Hermes Docker setup
- [[family/projects/watchlist-automation]] — Full watchlist flow
@@ -5,7 +5,7 @@ aliases:
- "obsidian-vault-strategy"
- "LLM Wiki Plan"
created: '2026-05-15'
updated: '2026-05-31'
updated: '2026-10-14'
tags:
- personal-os
- obsidian
@@ -14,7 +14,7 @@ tags:
- llm-wiki
status: active
related:
- "[[wiki/personal-os-architecture]]"
- "[[personal/projects/personal-os/personal-os-architecture]]"
- "[[personal/projects/personal-os/executor-security-analysis]]"
---
# Obsidian Vault Strategy & LLM Wiki Plan
@@ -546,5 +546,5 @@ skills/ → процедуры и workflows пошагово
---
## Связанные заметки
- [[wiki/personal-os-architecture|Personal OS Architecture]]
- [[personal/projects/personal-os/personal-os-architecture|Personal OS Architecture]]
- [[personal/projects/personal-os/executor-security-analysis|Executor Security Analysis]]
@@ -1,18 +1,30 @@
# Personal OS — план действий E1–E5
> **Актуальное состояние на 10.10.2026.** Рабочая БД для E1 — PostgreSQL `personal_os` на `localhost:5432`. Сборщик LaunchAgent использует `E1_TARGET_DATABASE_URL=postgresql://admin@localhost:5432/personal_os`; временная БД на `55439` больше не является целью записи. Миграция `005_asana_coverage.sql` применена, восстановленные E1-данные импортированы. LaunchAgent `com.personalos.asana-expansion-e1` продолжает backfill с сохранённого checkpoint каждые 15 минут. На момент проверки проходят строгую сверку 17 из 28 проектов; 11 проектов, 11 прямых задач и 995 внешних зависимостей остаются неполными. Подробный журнал: [расширение E1 в репозитории](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md).
Дата: 05.10.2026. Статус: **историческое состояние на дату подготовки — план подготовлен; реализация E1 ещё не начата**.
Дата исходного плана: 05.10.2026. Актуализировано 14.10.2026: схема E1 и восстановленные данные находятся в основной `personal_os`; E1.2 projection и полная приёмка E1.5 ещё не завершены. По сохранённому ID-манифесту проверены 21/28 проектов, 35 080/35 080 memberships; 11 прямых задач недоступны, 1 685 внешних dependency targets отсутствуют. Это локальная сверка с ID scan 06.10, а не повторный живой обход Asana.
Основание: [исследование шести уровней](/Users/admin/Developer/personal-os/planning/personal-os-six-layer-analysis-2026-10-05.md), [архитектурные контракты](/Users/admin/Developer/personal-os/planning/personal-os-architecture-decision-2026-10-04.md), [контракт данных R2](/Users/admin/Developer/personal-os/planning/personal-os-evidence-graph-design-2026-10-04.md). Этот документ конкретизирует порядок исполнения. Предложения о технологиях не означают, что они уже установлены или выбраны по результатам испытаний.
## Что делаем сейчас
**Текущая итерация — E1: сделать проверяемой загрузку трёх Asana-проектов.** В её конце мы должны видеть полный доступный состав выбранных проектов, все принадлежности задач, доступную историю и дерево подзадач. Для каждого пробела будет причина, а для каждого запуска — воспроизводимый отчёт.
**Дополнение 14.10.2026 — work items и контекст дизайнов реализованы и перенесены в основную БД.**
Каждый локальный ворктри без принятой связи должен получать отдельный устойчивый
work item на дашборде для ручного либо агентского резолва: привязать существующую
работу/задачу, учитывать локально, исключить с причиной либо подготовить и завести
задачу Asana. Повторный сбор сохраняет item и принятое решение. В контекст работы
добавляются tech-design задачи Asana, опубликованные документы и их драфты
Obsidian, включая драфты без Asana ID; смысловые совпадения проходят резолв.
Порядок, действия и критерии приёмки — в [текущем плане GitHub и рабочих
ситуаций](/Users/admin/Developer/personal-os/planning/github-work-situations-2026-10-14.md#work-items-и-tech-designs).
Проверены устойчивые items, сохранение решений, цепочки дизайнов, отдельный
вызов локальной модели из Windmill и безопасное создание задачи из черновика.
Пользователь разрешил основной перенос; все 17 таблиц перенесены с совпадением
полных хешей. Windmill и дашборд переключены на `personal_os`.
**Текущая итерация — E1: сделать проверяемой загрузку Asana-проектов.** Пилот трёх проектов завершён; по его результату [расширен scope](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md). Полный ID-обход завершён для 28 проектов: 26 текущих подписок и два проверенных пилота. Задачи из остальных проектов, напрямую связанные с пользователем, грузятся адресно. В конце должны быть видны полный доступный состав выбранных проектов, все принадлежности задач, доступная история и дерево подзадач. Для каждого пробела будет причина, для каждого запуска — воспроизводимый отчёт.
Начальный порядок: Apple Team Meta Project → Apple Feature Flags Registry → Scheduled Rotations. Meta Project даёт разные типы объектов и известные примеры потерь; остальные проверяют переносимость решения. Размер полных проектов пока не измерен, поэтому длительность массовой выгрузки определяется после дешёвого обхода IDs.
Первые страницы этих проектов уже проверены; найдены пропуски задач, комментариев и связей. **Полное покрытие ни одного из трёх проектов пока не доказано.** Готовность E1 не означает полноту всех источников или готовность персонального ранжирования.
В исходном рабочем зеркале были пропуски задач, комментариев и связей. Тестовый E1 backfill теперь сверен с независимым ID-обходом всех трёх пилотов; [отчёт](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/README.md). Это не означает полноту всех источников, рабочего зеркала или готовность персонального ранжирования.
### Кто что делает
@@ -59,7 +71,7 @@
Дорабатываются `db.js`, shape нормализованной задачи и версия схемы. Новая миграция использует существующий контракт source records/relations, насколько он уже реализован; если это ещё только проект R2, минимальные Asana-таблицы служат adapter storage с явным mapping в R2. Создание второго независимого реестра истины недопустимо.
Названия и номер миграции фиксируются после E1.1; `005_asana_coverage.sql` — возможное имя, а не уже созданный файл. Подготовка выполняется на отдельной тестовой БД. Применение к рабочей БД входит в E1.5.
Миграция подготовлена в `migrations/005_asana_coverage.sql` и применена только к отдельной тестовой БД. Применение к рабочей БД входит в E1.5.
**Критические проверки:** два проекта у одной задачи; перенос секции; снятие membership; полный пустой список; ответ без поля; повтор одного payload; более старый source snapshot после нового; rollback транзакции при ошибке. Устаревший снимок сохраняется как наблюдение, но не перезаписывает более свежее текущее состояние. При равном timestamp и конфликтующем содержимом требуется повторная сверка, а не произвольный победитель.
@@ -85,7 +97,7 @@
Исчезновение из полного списка означает «не наблюдается в этом контейнере». Оно может быть переносом, удалением или изменением доступа. Удаление объекта нельзя вывести из одного отсутствия в проекте; окончание известной связи и неизвестный статус самого объекта хранятся раздельно.
**Предлагаемый артефакт:** `scripts/asana-project-backfill.js` с режимами audit/dry-run, выбранным scope, checkpoint/resume и отчётом; shared helpers в `asana.js`/`sync.js`. У CLI должен быть явный target БД и идентификатор run. Имена флагов фиксируются при реализации, готовой команды запуска пока нет.
**Артефакт:** `scripts/asana-project-backfill.js` с выбранным scope, checkpoint/resume, бюджетом и явной целевой БД. Read-only ID-обход — `scripts/asana-coverage-scan-ids.js`; независимая сверка тестовой БД — `scripts/asana-coverage-verify.js`. Режим dry-run перечисляет только ID. Пробный полный backfill Meta Project запущен на отдельной тестовой БД; итоговая сверка ещё не готова.
**Приёмка:** более одной страницы задач/stories/детей, глубина дерева больше одного уровня, повторные страницы, одинаковые timestamps, 403/429/5xx, обрыв процесса, expired offset, редактирование старого комментария и отсутствие поля проходят проверку.
@@ -127,9 +139,6 @@ Asana не обещает единый транзакционный snapshot н
## E2. Получить общий корпус и эталон смысла
> Дополнение 11.10: перед батчем E2 нужны триаж шума и зеркало GitHub PR; ситуации Алекса (шум, не начатое, устаревшее, локальные эксперименты, тихие merge, draft, неотработанные ревью) становятся контрольными случаями. См. [[personal-os-windmill-system-map-2026-10-10]] §6.
**Зависимость:** первые реальные эпизоды готовятся после сверки Meta Project; окончательная оценка компонентов начинается после E1.4 и проверки необходимых дополнительных источников.
| Пакет | Работа | Готовый результат |
@@ -233,10 +242,13 @@ flowchart LR
| Пакет | Статус | Следующий проверяемый результат |
|---|---|---|
| E1.1 | planned — первый | Fixtures и исходный coverage report с воспроизведёнными потерями |
| E1.2–E1.3 | planned — после контракта E1.1 | Хранение всех memberships и возобновляемый полный обход |
| E1.4–E1.5 | planned — после проверок | Сверенный доступный корпус трёх проектов в рабочем зеркале |
| E2–E3 | planned | Общий эталон и выбранный открытый механизм извлечения/графа |
| E1.1 | verified — [отчёт и fixtures](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/README.md) | 6 тестов, независимый полный ID-обход SDK и source/local diff |
| E1.2 | in_progress — схема и writer проверены на тестовой БД | Совместимый projection для старых читателей |
| E1.3 | complete — три проекта загружены в отдельную тестовую БД | 7658 уникальных задач с потомками и 125 970 stories |
| E1.4 | verified для трёх пилотов — [итоговые отчёты](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/README.md) | 4618/4618 исходных memberships; известных потерь и неполных разделов нет |
| E1 expansion | in_progress — [scope, ID manifest и критерии](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/expansion-2026-10-06.md) | Backfill в основной БД: 21/28 проектов проходят критерий; новая live-ID дельта и полная история ещё требуют проверки |
| E1.5 | in_progress — [005 применена, E1 импортирован 10.10](/Users/admin/Developer/personal-os/planning/asana-coverage-pilot/e1-5-readiness-2026-10-06.md) | Projection/lease и завершение полной приёмки; применения 005 ждать уже не нужно |
| E2–E3 | E2 in_progress, E3 planned | 486 работ с кандидатами модели; независимый эталон, semantic acceptance и сравнение graph-механизмов ещё не приняты |
| E4–E5 | planned | Проверенные личные приоритеты и посильный контур внимания |
**Первый пакет реализации: E1.1 — воспроизводимые проверки потерь и независимый отчёт покрытия Asana.**
**Следующее действие: завершить checkpoint backfill 28 проектов и адресных задач, повторно сверить ID, stories и детей; отдельно завершить projection/lease и приёмку E1.5 после уже выполненного импорта.**
@@ -6,13 +6,15 @@ tags:
- data-analysis
- workflow
- knowledge-graph
updated: '2026-10-10'
updated: '2026-10-14'
---
# Personal OS — анализ выгружаемых данных: контекст, связывание и workflow
Дата исходного исследования: 2026-10-09, Asia/Bishkek. Обновлено: 2026-10-10 по фактическому развёртыванию локального стенда.
**Локальная сверка E1 14.10:** 21/28 проектов по ID scan 06.10, 35 080/35 080 memberships, 11 недоступных прямых задач и 1 685 отсутствующих внешних dependency targets. Это не новый live-ID обход. Текущий [план E1–E5](/Users/admin/Developer/personal-os/planning/personal-os-action-plan-2026-10-05.md).
**Статус:** локальный RLM-стенд развёрнут и проверен на синтетическом входе с Qwen3.8-27B и Qwen3-Coder-30B-A3B. Основной кандидат — Qwen3.8-27B на MLX; Coder — для сравнения, 9B — для последующей проверки дешёвых дочерних вызовов. Рабочие данные ещё не выбраны; качество анализа, graph runtime и производственный workflow ещё не проверены и не выбраны по результатам испытаний. Архив, incoming и потребители аналитики к стенду не подключены.
Дата исходного исследования: 2026-10-09, Asia/Bishkek. Обновлено: 2026-10-14 по сохранённым результатам БД, двум resolver jobs и проверке дашборда.
**Статус на 14.10.2026:** локальный стенд прошёл синтетические проверки и реальные одиночные извлечения на Asana. В основной БД 486 анализов / 486 работ (480 completed), все 12 244 claims — кандидаты. Рабочая выборка и схема v2 существуют; независимый эталон качества и semantic acceptance не завершены. RLM-циклы ранних прогонов не дошли до FINAL. Отдельный resolver ворктри через Windmill прошёл две попытки, 7/7 цитат и оба input hash проверены; смысловые связи не приняты. Архивный пакет выполнен вручную, постоянный incoming-контур и graph runtime не подключены. Подробности: [[work-claims-results-2026-10-12]] и [[personal-os-rlm-stand-results-2026-10-10]].
**Согласованный порядок:** проверяемый локальный RLM на небольшом наборе связных работ → расширение на архив → подключение incoming. Подробный текущий статус и шаги — в разделе 9.
@@ -42,7 +44,7 @@ updated: '2026-10-10'
- Внутри full-проектов код не задаёт фильтров по исполнителю, давности или завершённости. Он собирает историю событий и комментариев, рекурсивные подзадачи, связи dependencies/dependents; предусмотрена отдельная догрузка карточек внешних зависимостей.
- Ограничение 3 000 API-запросов за запуск и 600 на проект разбивает процесс на возобновляемые порции; это не фильтр смысловой релевантности.
- В 28 проектах перечислено 32 390 уникальных задач **до** рекурсивного обхода подзадач. Эта цифра не является размером всего собранного корпуса.
- Запись E1 идёт в отдельную тестовую БД. Её историческая догрузка отличается от обычного sync, где есть окно изменений 30 дней для полного обновления проектов.
- С 10.10 запись E1 идёт в основную `personal_os` после восстановления и подтверждённого импорта; до этого использовалась отдельная тестовая БД. Её историческая догрузка отличается от обычного sync, где есть окно изменений 30 дней для полного обновления проектов.
В прочитанном 9 октября срезе E1 среди 31 943 загруженных основных задач:
@@ -213,7 +215,7 @@ Graphiti передаёт при извлечении отношений пре
У каждого прогона сохраняются снимок входа, hash, модель и revision, настройки и версии пакетов, трасса вызовов, результат и статус. Полные запросы и ответы API также журналируются локально. `.runtime` и `datasets/private` исключены из Git. Внешняя сеть нужна для установки и скачивания весов; подготовленный REPL использует локальные пакеты и обращается только к локальному API. Сервис запускается вручную, автозапуска после перезагрузки нет.
**Ещё не реализовано:** адаптер рабочих выгрузок, предметные инструменты поиска/чтения оригиналов, индексы, схема смысловых результатов и независимый эталон, смешанные вызовы с 9B, массовая обработка архива и incoming.
**Состояние списка задач на 14.10:** экспорт рабочих данных и schema v2 реализованы, архивный батч выполнен. Остаются независимый эталон/semantic acceptance, общий поиск по корпусу, смешанные вызовы с 9B и incoming. Датированные этапы ниже сохраняют первоначальный план и не заменяют текущий статус выше.
### 9.1a. Дополнение 2026-10-10 (вечер): выборка и первый прогон на рабочих данных
@@ -266,7 +268,7 @@ Graphiti передаёт при извлечении отношений пре
Предварительные модельные выводы не служат независимым эталоном для оценки той же модели. Проверка человеком сосредоточена на важных неоднозначностях и контрольных примерах, а не на ручном разборе всех десятков тысяч задач.
**Следующий ожидаемый результат:** выбранный малый набор и рабочий проверяемый срез RLM на нём. **Результат последующих испытаний:** «история + новое изменение → найденный контекст → проверяемые связи/состояние», оценка массового прогона и обоснованный выбор моделей и готового компонента. Эти результаты ещё не получены.
**Следующий ожидаемый результат:** выбранный малый набор и рабочий проверяемый срез RLM на нём. **Результат последующих испытаний:** «история + новое изменение → найденный контекст → проверяемые связи/состояние», оценка массового прогона и обоснованный выбор моделей и готового компонента. Малый набор и одиночный рабочий срез получены; полный RLM-цикл, независимое качество и обработка incoming ещё не приняты. См. датированные результаты выше.
## 10. Открытые вопросы
@@ -3,9 +3,14 @@ tags:
- personal-os
- database
- runbook
updated: '2026-10-14'
---
# Браузер БД Personal OS
**Проверено 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).
**Work items**: ручная связь с Asana, объединение контекста related repos, локальный учёт, исключение с причиной, отдельный вызов локального агента. **Tech designs**: задачи Asana и заметки Obsidian с версиями/hash; смысловой `draft_of` требует принятия. Новая Asana-задача сначала сохраняется локальным черновиком, затем создаётся отдельным действием из проверенного черновика. Сам агент внешних записей не делает. Содержимое внешних дизайн-документов пока не загружается.
Локальный интерфейс для просмотра данных Personal OS на `http://127.0.0.1:4317`.
## Источник данных
@@ -31,7 +36,7 @@ curl -fsS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:4317/
curl -fsS http://127.0.0.1:4317/api/bootstrap
```
В bootstrap ожидаются `sources.e1=true` и `read_only=true`. Если соединение не устанавливается, проверить PostgreSQL на `localhost:5432`, поле `database` в `config.json` и отсутствие старого `E1_COVERAGE_DATABASE_URL`.
В bootstrap после поставки 14.10 ожидаются `sources.e1=true`, `evidence_origin=primary`, `work_dashboard=true`, `local_resolution_enabled=true`, `read_only=false`. Последнее означает наличие действий через host runner; SQL-соединения браузера по-прежнему read-only. Если соединение не устанавливается, проверить PostgreSQL на `localhost:5432`, поле `database` в `config.json` и отсутствие старого `E1_COVERAGE_DATABASE_URL`.
## Ссылки
@@ -10,6 +10,8 @@ tags:
---
# Personal OS — результаты первых прогонов на рабочих данных (2026-10-10)
**Обновление отчётов 14.10:** разделы 1–7 — датированные первые эксперименты. Полный каталог результатов по 486 работам: [[work-claims-results-2026-10-12]]; все claims остаются кандидатами. Дополнение 8 содержит отдельную проверку связывания BSP-ворктри, не повтор статусов всего корпуса. GitHub mirror и work dashboard уже перенесены в основную БД; отсутствие GitHub-таблиц в исходной выборке 10.10 ниже является историческим фактом.
Продолжение [[personal-os-data-analysis-workflow-2026-10-09]], раздел 9. Здесь зафиксировано, что было сделано, что получилось, где модель систематически ошибается и что из этого следует. Исходные файлы прогонов, эталоны и отчёты на английском: `tools/rlm-lab/datasets/private/sample-2026-10-10/` в репозитории personal-os (каталог вне git).
## 1. Выборка
@@ -3,11 +3,15 @@ title: Personal OS — статус (октябрь 2026)
tags:
- personal-os
- status
updated: '2026-10-04'
updated: '2026-10-14'
confidence: 1
---
# Personal OS — срез 2026-10-04, связанные проекты сверены 2026-10-14
**Проверено 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).
Датированные наблюдения 04.10 ниже — история проверки. Они не утверждают текущую свежесть источников, состояние расписаний или отсутствие последующих запусков. Общий аналитический контур и принятие model claims ещё не завершены.
> Проверенный срез и исправленный план R2: [[personal-os-system-review-index]]. Датированные цифры ниже — история наблюдений; целевые контракты и этапы задаёт пакет R2. Новая архитектура ожидает утверждения.
@@ -1,10 +1,14 @@
---
status: draft-review
revision: R2 + six-layer-analysis
updated: 2026-10-05
updated: '2026-10-14'
---
# Personal OS: план и анализ шести уровней
**Проверено 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).
E1: 21/28 проектов проходят локальный критерий по сохранённому ID scan 06.10; 35 080/35 080 memberships. Каталог модели: [[work-claims-results-2026-10-12]], 486 работ, 480 completed, 12 244 candidate claims. Дополнительный кейс связывания BSP: [[personal-os-rlm-stand-results-2026-10-10#8. Дополнение 2026-10-14: локальный агент — привязка BSP-ворктри к работе Asana]]. Ниже сохраняется история исследований; граф R2 целиком не внедрён.
> **Обновление 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]].
@@ -16,7 +20,7 @@ updated: 2026-10-05
| Документ | Назначение |
|---|---|
| [[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-db-browser]] | Локальный браузер БД: запуск на `127.0.0.1:4317`, источник `personal_os` на `localhost:5432`, проверка read-only SQL и доступных локальных решений. |
| [[personal-os-action-plan-2026-10-05]] | Текущая очередь E1–E5: ближайшие пакеты, поставки, проверки и зависимости. |
| [[personal-os-system-review-2026-10-04]] | Полный план: роли, data flow, инструкции, расписания, SC1–SC8, AC01–AC16 и R0–R4. |
| [[personal-os-evidence-graph-design-2026-10-04]] | Конкретные таблицы, ключи, typed relations, время, discovery, принятие claims, lineage и публикация. Заменяет ранний иллюстративный DDL. |
@@ -53,4 +57,4 @@ updated: 2026-10-05
4. Проверка роли пользователя и матрицы важности.
5. План внимания, ретроспекция и эксплуатационная приёмка.
[[personal-os-buy-adapt-build-2026-10-05]] сохранён как справочный обзор; корпоративный shortlist больше не определяет первый этап. Исследование завершено, дефекты сборщика ещё не исправлены, модели не испытывались. Печатные PDF остаются R2 и не содержат этого уточнения.
[[personal-os-buy-adapt-build-2026-10-05]] сохранён как справочный обзор; корпоративный shortlist больше не определяет первый этап. Это состояние исследования на 05.10. Позже схема E1 и backfill реализованы, локальные модели испытаны; полнота источников и semantic acceptance остаются неполными. Печатные PDF остаются R2 и не содержат этого уточнения.
@@ -1,27 +1,32 @@
---
date: '2026-10-10'
status: deployed-skeleton
status: partial-real-flows
tags:
- personal-os
- windmill
- architecture
- system-map
updated: '2026-10-14'
---
# Personal OS — карта системы в Windmill (2026-10-10)
Продолжение [[personal-os-rlm-stand-results-2026-10-10]]. Вечером 10 октября после обсуждения принято: нужна визуальная, исполняемая карта системы, а не рисунок. Развёрнут локальный Windmill; вся система описана как 18 потоков-скелетов и один обзорный поток. Логики в узлах нет, расписаний нет.
**Проверено 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 | 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. |
| 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. Что развёрнуто
@@ -52,7 +57,7 @@ tags:
- Пока поток — скелет, источник правды — `system-map.yaml`; push перезаписывает правки на холсте. Как только поток получает реальные шаги, источником становится его `flow.yaml`, правки делаются на холсте и забираются `wmill sync pull`; поток убирается из генератора. По одному потоку за раз.
- Сборщики Mattermost и Zoom нуждаются в залогиненном Chrome на Mac и не могут выполняться в контейнере. Их узлы остаются тонкими (триггер/наблюдение), пока не выбран host-side runner.
- Обзорный поток, запускающий всё подряд, — демонстрация, а не реальная каденция. Расписания вешаются на отдельные потоки.
- Ничего в Asana/GitHub не пишется; старый Executor остаётся выключенным.
- Потоки сбора и локальный агент не пишут в Asana/GitHub. С 14.10 дашборд содержит отдельное действие создания Asana-задачи из проверенного черновика; старый Executor остаётся выключенным.
## 5. Следующий шаг
@@ -1,6 +1,6 @@
---
title: Research Queue
updated: '2026-05-24'
updated: '2026-10-14'
type: meta
---
@@ -15,6 +15,6 @@ type: meta
## Completed
- [x] WireGuard VPN → [[tech/wireguard-vpn]] (2026-05-23)
- [x] Executor Architecture v2 → [[concepts/executor-orchestrator]] (2026-05-19)
- [x] Executor Security Incident → [[concepts/executor-security-incident]] (2026-05-22)
- [x] WireGuard VPN → [[family/how-to/wireguard-vpn]] (2026-05-23)
- [x] Executor Architecture v2 → [[personal/projects/personal-os/executor-orchestrator-redesign]] (2026-05-19)
- [x] Executor Security Incident → [[personal/projects/personal-os/executor-security-analysis]] (2026-05-22)
@@ -1,7 +1,7 @@
---
title: Vault Namespace Rules
created: '2026-05-23'
updated: '2026-05-23'
updated: '2026-10-14'
type: tech
namespace: personal
tags: [vault, meta, conventions]
@@ -11,7 +11,7 @@ related:
# Vault Namespace Rules
Rules for where notes live in the Obsidian vault. See also [[SCHEMA]] for
Rules for where notes live in the Obsidian vault. See also [[personal/projects/personal-os/wiki-schema]] for
full frontmatter conventions.
## Namespace Assignments
File diff suppressed because it is too large. Load diff