[2026-05-15] vault restructure: personal-os plans → personal/projects/personal-os, briefs → work/briefs
This commit is contained in:
Alexey Martemyanov
@@ -1,115 +0,0 @@
|
||||
# Plan: Executor as Spawned Worker — Orchestrator Pattern
|
||||
|
||||
**Date**: 2026-05-14
|
||||
**Status**: Planning
|
||||
**Parent**: [[executor-v2-redesign]]
|
||||
|
||||
## Problem
|
||||
|
||||
Currently Eagle (орёл) handles executor tasks inline in the conversation:
|
||||
- Takes on the task directly in the discussion thread
|
||||
- Asks Alex for permissions mid-task, blocking the flow
|
||||
- Creates tight coupling between conversational layer and execution layer
|
||||
|
||||
## Desired Architecture
|
||||
|
||||
```
|
||||
Alex → Eagle (orchestrator, in Zulip topic)
|
||||
↓ spawn
|
||||
Executor (worker process, separate Hermes session)
|
||||
↓ writes to Zulip #executor topic
|
||||
Eagle monitors #executor
|
||||
↓ reads recent output (not full thread)
|
||||
↓ auto-approve obvious decisions
|
||||
↓ escalate ambiguous → @mention Alex
|
||||
```
|
||||
|
||||
## Roles
|
||||
|
||||
### Eagle (Orchestrator)
|
||||
- Receives task request in any Zulip topic
|
||||
- Queues task to `executor_queue` DB table
|
||||
- Spawns Executor worker via `hermes cron run` or similar
|
||||
- Monitors `#executor` topic for Executor messages
|
||||
- Reads only recent N messages (sliding window, not full thread)
|
||||
- Auto-approval logic:
|
||||
- "create worktree" → approve
|
||||
- "run tests" → approve
|
||||
- "open draft PR" → approve
|
||||
- "push to branch" → approve
|
||||
- "modify unrelated file" → DENY + escalate
|
||||
- "post Asana comment" → escalate to Alex
|
||||
- Any scope expansion → escalate to Alex
|
||||
- @mention Alex only when ambiguous or high-risk
|
||||
|
||||
### Executor (Worker)
|
||||
- Separate Hermes session/process
|
||||
- Bot identity: "Executor" or "Исполнитель" (not Eagle)
|
||||
- Communicates via `#executor` Zulip topic
|
||||
- Posts structured messages: `[REQUEST: <action>]`, `[STATUS: <phase>]`, `[DONE: <result>]`
|
||||
- Does NOT ask Alex directly — all escalations go to Eagle
|
||||
- On permission denied → explain why, ask what to do differently
|
||||
|
||||
## Message Protocol (Executor → Eagle)
|
||||
|
||||
```
|
||||
[STATUS: investigation] Analysing bug GID 123456...
|
||||
[REQUEST: create_worktree] Branch: fix/tab-preview-stuck
|
||||
[REQUEST: run_tests] Scheme: macOS UI Tests CI
|
||||
[STATUS: pr_open] Draft PR: https://github.com/...
|
||||
[DONE: pr_ready] PR #1234 opened, CI green, ready for review
|
||||
[ESCALATE: scope_expansion] Found unrelated issue in TabBar.swift — should I fix it?
|
||||
```
|
||||
|
||||
## Auto-approval Rules (Eagle)
|
||||
|
||||
| Message type | Auto action |
|
||||
|---|---|
|
||||
| `[REQUEST: create_worktree]` | ✅ approve silently |
|
||||
| `[REQUEST: run_build]` | ✅ approve silently |
|
||||
| `[REQUEST: run_tests]` | ✅ approve silently |
|
||||
| `[REQUEST: open_draft_pr]` | ✅ approve silently |
|
||||
| `[REQUEST: push_branch]` | ✅ approve silently |
|
||||
| `[REQUEST: post_asana_comment]` | ⚠️ show Alex, wait |
|
||||
| `[REQUEST: merge_pr]` | ❌ always escalate |
|
||||
| `[ESCALATE: *]` | ⚠️ always escalate |
|
||||
| `[ESCALATE: scope_expansion]` | ❌ deny by default + notify Alex |
|
||||
|
||||
## Eagle Monitoring Loop
|
||||
|
||||
Eagle does NOT run a continuous monitoring process. Instead:
|
||||
- Option A: Hermes cron (every 2 min) → check `#executor` for unprocessed `[REQUEST]` or `[ESCALATE]` messages → process them
|
||||
- Option B: Webhook trigger on Zulip `#executor` stream → Eagle session wakes up
|
||||
|
||||
**Recommendation: Option A** (simpler, uses existing cron infra)
|
||||
|
||||
## Context Window Management
|
||||
|
||||
Eagle reads Executor's thread with sliding window:
|
||||
- Last 20 messages from `#executor` for the current `executor_run_id`
|
||||
- Filter by `run_id` tag in messages to handle concurrent runs
|
||||
- Structured messages allow O(1) parsing without LLM
|
||||
|
||||
## Relation to Executor v2
|
||||
|
||||
This is a UI/coordination layer ON TOP of executor-v2 bash daemons:
|
||||
- executor-runner.sh still does the heavy lifting
|
||||
- Eagle becomes the gatekeeper/orchestrator that monitors and approves
|
||||
- Executor worker sends structured messages via Zulip API (or hermes platform API)
|
||||
|
||||
## Implementation Steps
|
||||
|
||||
1. Define message protocol (structured tags)
|
||||
2. Add Zulip message sender to executor worker prompts
|
||||
3. Create Eagle monitoring cron (2 min interval, `#executor` stream)
|
||||
4. Implement auto-approval logic in Eagle monitoring prompt
|
||||
5. Add escalation → `@mention Alex` in monitoring prompt
|
||||
6. Test with a real executor run in dry-run mode
|
||||
|
||||
## Open Questions
|
||||
|
||||
- How does Executor "spawn" as a separate bot persona?
|
||||
- Option A: Same Hermes instance, different SOUL/persona config
|
||||
- Option B: Separate Hermes gateway with "Executor" identity
|
||||
- Option C: `hermes run -p executor-worker.md` as subprocess (non-interactive)
|
||||
- Concurrent runs: Eagle needs to track run_id per conversation thread
|
||||
@@ -1,110 +0,0 @@
|
||||
# Plan: Executor Orchestrator — Spawned Worker Pattern
|
||||
|
||||
**Date**: 2026-05-14
|
||||
**Status**: Research needed
|
||||
**Parent**: [[executor-v2-redesign]]
|
||||
**Linked**: [[executor-orchestrator-redesign]]
|
||||
|
||||
## Background (from session 2026-05-14)
|
||||
|
||||
Alex's request (verbatim intent):
|
||||
> Ты (орёл) должен спавнить воркер процессы, от лица другого бота (не Eagle а Executor), и как оркестратор реагировать на его "я сделал" / запросы пермишенс, читать недавний контекст (не весь тред) — и аппрувить/денаить автоматом, либо эскалировать и меншенить меня если ambiguity.
|
||||
|
||||
Also from Kraken dictation (2026-05-14, not saved due to vault bug):
|
||||
> Собирать планы в executor чтобы по крону запускались конкретные работы — не как сейчас что каждый агент по поставленной задаче работает, а чтобы автоматически спавнились если в папке Obsidian есть работа.
|
||||
|
||||
## Core Design
|
||||
|
||||
```
|
||||
Eagle (orchestrator, Zulip topic)
|
||||
↓ spawn
|
||||
Executor (worker, separate process/session)
|
||||
↓ messages to #executor topic
|
||||
Eagle monitors #executor (sliding window, last ~20 msgs)
|
||||
↓ auto-approve obvious / escalate ambiguous
|
||||
↓ @mention Alex only for ambiguity or high risk
|
||||
```
|
||||
|
||||
## Research Findings (2026-05-14)
|
||||
|
||||
### Q1: How to spawn Executor as separate bot persona?
|
||||
|
||||
**Answer: Hermes Profiles** — the correct mechanism.
|
||||
|
||||
Hermes supports named profiles: each profile = separate `~/.hermes/profiles/<name>/` with its own `SOUL.md`, `.env`, `config.yaml`, gateway, bot token, memory, cron jobs.
|
||||
|
||||
```bash
|
||||
hermes profile create executor --clone # clone Eagle config
|
||||
# then configure:
|
||||
echo "You are Исполнитель..." > ~/.hermes/profiles/executor/SOUL.md
|
||||
# set different Zulip bot token for "Executor" bot in Zulip
|
||||
nano ~/.hermes/profiles/executor/.env # ZULIP_BOT_EMAIL=executor-bot@zulip.local
|
||||
executor gateway install # separate systemd/launchd service
|
||||
```
|
||||
|
||||
**Key properties:**
|
||||
- Each profile can have its own Zulip bot token → appears as different bot in UI
|
||||
- `executor gateway start` runs independently from Eagle
|
||||
- Cron jobs in `executor` profile run under executor's identity
|
||||
- Safety: if two profiles share same Zulip token → second gateway is blocked with error
|
||||
|
||||
**Spawn pattern**: Eagle triggers Executor by sending a message to the Executor's Zulip topic (or writing to a shared queue). Executor's gateway picks it up as a new session.
|
||||
|
||||
OR: Eagle uses `cronjob(action='create', schedule='once', ...)` with executor profile — but this stays within Eagle's identity. For true persona separation → need separate profile with separate gateway.
|
||||
|
||||
**Recommended: Option B (separate profile + gateway)**
|
||||
- `executor` profile with its own SOUL, its own Zulip bot ("Исполнитель")
|
||||
- Eagle sends trigger message to `#executor` as Eagle → Executor bot responds as Executor
|
||||
- Natural separation of concerns, no code changes needed
|
||||
|
||||
### Q2: How does Eagle monitor #executor without blocking?
|
||||
|
||||
**Answer: Hermes cron every 2 min** (simplest, already proven infrastructure)
|
||||
|
||||
- Eagle cron job: `*/2 * * * *` → query Zulip REST for recent `#executor` messages → parse `[REQUEST]`/`[ESCALATE]` tags → auto-approve or @mention Alex
|
||||
- Alternative: Zulip webhook → Hermes webhook trigger (needs setup, lower latency)
|
||||
- Cron is sufficient given that executor tasks run for minutes-hours, not seconds
|
||||
|
||||
### Q3: Message protocol format
|
||||
|
||||
Need a structured format Executor uses so Eagle can parse O(1) without LLM:
|
||||
```
|
||||
[REQUEST:create_worktree] branch=fix/tab-preview-stuck run_id=42
|
||||
[REQUEST:run_tests] scheme="macOS UI Tests CI"
|
||||
[STATUS:investigation] Analysing bug...
|
||||
[STATUS:pr_open] PR #1234 https://github.com/...
|
||||
[DONE:pr_ready] CI green, no comments
|
||||
[ESCALATE:scope_expansion] Found unrelated issue in TabBar.swift
|
||||
```
|
||||
|
||||
### Q4: Plans-to-executor trigger (from Kraken dictation)
|
||||
|
||||
If there are "work items" in an Obsidian folder (e.g. `work/plans/executor-queue/`), cron should auto-spawn workers.
|
||||
|
||||
Research: what's the folder-watching mechanism? Options:
|
||||
- Eagle morning-brief cron checks folder, spawns workers
|
||||
- Dedicated `executor-plans-watcher` cron (every 30 min)
|
||||
- Executor-analyzer.sh already does this via DB — maybe just add Obsidian→DB bridge
|
||||
|
||||
## Auto-Approval Rules (draft)
|
||||
|
||||
| Action | Auto | Rule |
|
||||
|---|---|---|
|
||||
| create worktree | ✅ approve | safe, reversible |
|
||||
| run build | ✅ approve | safe |
|
||||
| run tests | ✅ approve | safe |
|
||||
| open draft PR | ✅ approve | draft = no merge |
|
||||
| push to branch | ✅ approve | executor branch only |
|
||||
| post Asana comment | ⚠️ escalate | external side effect |
|
||||
| merge PR | ❌ always escalate | irreversible |
|
||||
| modify files outside worktree | ❌ deny | scope violation |
|
||||
| scope expansion | ❌ deny + notify | default policy |
|
||||
|
||||
## Implementation Phases
|
||||
|
||||
1. **Research** (this phase) — answer Q1-Q4 via web search + Hermes source inspection
|
||||
2. **Protocol** — define message format, write Executor posting code
|
||||
3. **Eagle monitor** — cron job that reads #executor, applies auto-approval rules
|
||||
4. **Worker spawn** — Eagle can trigger Executor on demand
|
||||
5. **Plans watcher** — Obsidian folder → auto-spawn (Q4)
|
||||
6. **Test** — dry run with a real executor task
|
||||
@@ -1,33 +0,0 @@
|
||||
# Bug: Kraken Cannot Write to Obsidian Vault
|
||||
|
||||
**Date**: 2026-05-14
|
||||
**Status**: Fixed ✅ (2026-05-14)
|
||||
|
||||
## Root Cause (confirmed)
|
||||
|
||||
mcpvault возвращает `Permission denied` по двум причинам:
|
||||
1. **Папка не существует** в sparse checkout — mcpvault не создаёт субдиректории
|
||||
2. **Ownership mismatch** — Hermes/mcpvault внутри контейнера работает как `hermes` (uid=10000), vault принадлежит `kraken` (uid=1000), права `755` → запись запрещена
|
||||
|
||||
## Fix Applied
|
||||
|
||||
1. Созданы все нужные папки в vault (Eagle → push на NAS → Кракен pull):
|
||||
- `personal/inbox/`, `personal/plans/`, `personal/documents/`, `personal/instructions/`, `personal/projects/`
|
||||
2. `chmod -R a+w ~/obsidian/personal ~/obsidian/family` на хосте Кракена
|
||||
3. В `sync-vault.sh` добавлен `chmod -R a+w` после каждого pull — чтобы права восстанавливались на новых файлах
|
||||
4. SOUL.md обновлён — явно перечислены все пути в `personal/`
|
||||
|
||||
## Open: Image Handling
|
||||
|
||||
Отдельная проблема обнаружена при попытке сохранить фото из Telegram в inbox.
|
||||
|
||||
**Что произошло**: Gemini API кончились кредиты (HTTP 429) → fallback на OpenRouter (gpt-oss-120b, minimax-m2) → эти модели не умеют vision → ошибка "No endpoints found that support image input"
|
||||
|
||||
**Желаемое поведение**: агент должен уметь работать с изображениями на уровне ФС в зависимости от контекста:
|
||||
- Если нужно распознать/проанализировать → пустить в vision-capable модель
|
||||
- Если нужно просто сохранить → положить файл в `personal/inbox/` и записать заметку со ссылкой на путь
|
||||
- Если модель не умеет vision → не падать, а сохранить файл и сообщить агенту путь
|
||||
|
||||
**Что нужно в Hermes**: при `image_routing` добавить режим `save_to_fs` — сохранить файл локально, передать агенту путь вместо байтов. Агент сам решает что делать по контексту.
|
||||
|
||||
**Текущий workaround**: пополнить Gemini API кредиты на Кракене.
|
||||
@@ -1,7 +0,0 @@
|
||||
# Plan: Time Machine via WireGuard VPN — ВЫПОЛНЕНО
|
||||
|
||||
> Перенесено в [[wireguard-vpn]]
|
||||
> Дата: 2026-05-14
|
||||
> Статус: ✅ реализовано
|
||||
|
||||
Детали реализации, топология, ключи и диагностика: `family/how-to/wireguard-vpn.md`
|
||||
Reference in New Issue
Block a user