111 lines
5.4 KiB
Markdown
Executable File
111 lines
5.4 KiB
Markdown
Executable File
# 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
|