MultiverbeBOS

Mother Session Orchestrator + N Parallel Sub-Sessions

Pattern operativo standard per task Claude Code >4h decomponibili in 2+ stream paralleli. Originato 2026-05-13 (reconciliation Stream A↔C + Stream A finalize · session ID mother 5071abe1-1ff4-414c-bba5-e193f6d1c692).

Cos'è

Un task pesante viene gestito da 1 mother session in BOS (control center) + N child sessions (P1, P2, ...) in worktree separati del repo target. La mother monitora e orchestrizza via live state JSON di BOS; le child fanno il lavoro effettivo (code, refactor, test) ognuna su scope strict mutuamente esclusivo.

Trigger criteria · quando attivare

  • Task >4h lavoro totale stimato
  • Decomponibile in 2+ stream con scope strict separati (no overlap file/feature)
  • Esiste un repo BOS / SSoT da cui orchestrare (Multiverbe-Business/)
  • Founder vuole status updates frequenti senza riaprire sessione cara ogni volta

Quando NON attivare

  • Task <2h → 1 sessione singola basta
  • 1 solo stream parallelo → niente "mother" overhead
  • Lavori su repo senza BOS / live state files

Architettura (ASCII)

                ┌──────────────────────────────────┐
                │   FOUNDER (Gregorio)             │
                │   briefing 5 righe in chat       │
                └──────────────▲───────────────────┘
                               │
                ┌──────────────┴───────────────────┐
                │   MOTHER session                 │
                │   D:\Desktop\Multiverbe-Business │
                │   actor_session_name=mother-DATE │
                └─┬────────────┬────────────┬──────┘
                  │ inbox.json │activity.json│sessions.json
                  │  locks     │  kpi.json   │
        ┌─────────▼─────┐ ┌────▼──────┐ ┌────▼──────┐
        │ CHILD P1      │ │ CHILD P2  │ │ CHILD Pn  │
        │ worktree A    │ │ worktree B│ │ worktree N│
        │ scope strict  │ │ scope str │ │ scope str │
        └───────────────┘ └───────────┘ └───────────┘

Tutti scrivono/leggono source/_meta/live/*.json nel repo BOS condiviso.

Setup steps (founder)

  1. Apri mother session in BOS:
    • cd D:\Desktop\Multiverbe-Business
    • Avvia Claude Code worktree branch dedicato (es. claude/<orchestrator-name>)
    • Mother auto-carica AGENTS.md + status.json + decisions
    • Mother registra heartbeat actor_session_name: "mother-YYYY-MM-DD"
  2. Bulk-approve edge decisions upfront (D1-D6 style) per minimizzare handoff mid-execution
  3. Apri N child sessions in worktree del repo target (es. D:\Desktop\Multiverbe\.claude\worktrees\<nome>):
    • Ogni child riceve nel prompt iniziale il mother session_id come reference
    • Ogni child scope strict documentato (file/feature non-overlapping)
    • Ogni child registra heartbeat actor_session_name: "P1-..." / "P2-..." etc.
  4. Update status.json action items child: scheduled → in_progress + started_at + mother_session_orchestrator: <UUID> pointer

Operating protocol mother (8 punti)

  1. Auto-load contesto BOS (AGENTS.md + status.json + decisions-log + eventuale reconciliation doc)
  2. Register heartbeat actor_session_name: "mother-YYYY-MM-DD" via scripts/live/heartbeat.mjs
  3. Update status.json action_items child: scheduled → in_progress + started_at + mother_session_orchestrator pointer UUID
  4. Idle polling 5-10min OR on-demand founder (mai polling vuoto)
  5. Response founder = 5 righe max:
    • 📅 [HH:MM] · P1 [%+last update] · P2 [%+last update]
    • 🚦 Blockers (o "Nessuno")
    • 📬 Inbox (msg pending da child)
    • 🎯 Next auto-action mother
    • ⚡ Risk emergente
  6. Autonomous OK per: naming variance, library choice triviale, decisioni bulk-approvate (D1-D6 style), test cases extra
  7. Chiedere founder PRIMA di: schema DB change, auth pattern change, cost cap variation, push master, decisioni architetturali non bulk-approvate
  8. Quando tutti child "done" + smoke E2E passa → mother prepara merge gate summary 10 righe per founder approve

Co-working protocol child → mother (inbox.json)

Child appendono entry via scripts/live/inbox.mjs:

{
  "from": "P1",
  "to": "mother",
  "type": "question" | "progress" | "blocker",
  "body": "Stream A reconciliation 60%. Edge case su X: applico bulk-approve D3? requires_action=false (FYI).",
  "requires_action": false,
  "ts": "2026-05-13T14:32:00Z"
}

Mother risponde same channel from: "mother", to: "P1". Eventi paralleli loggati in activity.json (type: progress | decision | blocker_resolved | merge_gate).

Regole hard universali

  • ZERO commit/push BOS senza founder approve esplicito
  • ZERO merge to master senza founder approve esplicito
  • ZERO autonomous decision su scope architetturale non bulk-approvato
  • Response founder max 5 righe default (10 righe solo per merge gate summary)
  • NO polling vuoto · aspettare evento (inbox/activity) o input founder
  • ZERO INFO LOSS se mother edita chunks source/*.md (verbatim mandatory, vedi pre-edit protocol AGENTS.md)

Esempio storico · 2026-05-13

  • Mother: branch claude/condescending-hamilton-77da87 · worktree in BOS · session_id 5071abe1-1ff4-414c-bba5-e193f6d1c692
  • P1: reconciliation Stream A↔C nel worktree codice D:\Desktop\Multiverbe\.claude\worktrees\publish-hosting\ · ETA 4-6h
  • P2: Stream A finalize + smoke E2E ristoratore Lugano · ETA 3-5h
  • Decisioni bulk-approvate upfront: D1-D6 (naming, lib choices, test boundaries) per minimizzare handoff
  • Polling cadence: mother poll inbox.json + activity.json ogni 5-10 min o on-demand founder
  • Risultato: founder ha visto status P1/P2 in chat senza riaprire sessioni costose, cache mother mantenuto warm tra check

Reference

  • AGENTS.md (root BOS) — auto-load protocol + regole hard + orchestrazione multi-Claude legacy
  • scripts/live/heartbeat.mjs — register/heartbeat/end session
  • scripts/live/inbox.mjs — sendMessage cross-session
  • scripts/live/activity-log.mjs — append-only event log
  • scripts/live/lock.mjs — acquireLock/releaseLock cross-session chunk
  • Memoria Claude trigger: ~/.claude/projects/D--Desktop-Multiverbe-Business/memory/feedback_mother_orchestrator_standard.md