Hinata Runtime Workflow

Status: design-intent explanation — non-canonical (repointed 2026-06-10, finding H9). Live doctrine lives in the dedicated law files (security-privacy-doctrine · calendar-architecture · credential-model · infrastructure-access · hinata-architecture). Where this document and a law conflict, the law wins.

What this document is. A single reference describing (1) how Hinata is actually run today, and (2) how it should be run — the optimal workflow for an agentic second brain. It is the entry point for the deliverable set in this folder:

File	Purpose
runtime-workflow.md (this file)	How Hinata is used + the optimal workflow + delegation logistics with examples
CLAUDE.md (vault root)	The primary local harness — the General & Sole Writing Authority
CLOUD.md (vault root)	The cloud arm — unattended/long-running execution on the web
ANTIGRAVITY.md (vault root)	The agentic builder & executioner
CODEX.md (vault root)	The scripter & mastery coach (assist-only, no vault writes)
GEMINI.md (vault root)	The secondary support worker (diagnostics/vision/research)
settings.json	The ideal harness configuration (fully populated)
config-howto.md	Every settings argument explained + the settings↔CLAUDE.md↔cli.md relationships + everything customisable

These are reference / ideal-workflow versions. They do not replace the live canonical files at vault-root *.md and .claude/settings.json; they document the target state those files are converging on. Where this document and a law in supreme-court/ conflict, the law wins — the law store is supreme.

---

1. What Hinata is, in one paragraph

Hinata is a federated AI second brain for Michael Nnamah. Instead of one model holding one context window, work is distributed across a chain of command: a General (the human-facing orchestration thread) routes to 5 Colonels (pillar-level synthesis), 3–4 Captains (cross-cutting system agents), and ~40 Commanders (domain specialists), each carrying its own fresh context. Governance is repo-canonical — every rule lives in this git repo, so a cloud clone is governed identically to a local session. The result should feel like one expert who knows everything about Michael, because it is a coordinated team where each member carries specialised memory.

Chain of command

                         Michael (sovereign — all major decisions)
                                      │
                        ┌─────────────┴─────────────┐
                        │   HINATA  (the General)    │   orchestrates, decides, synthesises
                        │   main thread · Tier-O max │   target: 10–20% of tokens
                        └─────────────┬─────────────┘
              ┌───────────────┬───────┴────────┬───────────────┐
        5 COLONELS        4 CAPTAINS       (Lieutenants)
     pillar synthesis   system / cross-     gate-keepers
     "Spirit Bomb"        cutting work     & optimisers
        │                     │
   ~40 COMMANDERS  ◄──────────┘   domain specialists — load context.md + knowledge-base fresh
   (FORGE · FOUNDATION · FLOW · FIRE · SYNTHESIS)        target: 40–70% of tokens

Rank order: General → Colonels → Captains (parallel authority) → Lieutenants → Commanders. Lieutenants outrank Commanders operationally — they shape what commanders receive and what gets automated.

The 5 pillars

Pillar	Colonel	Domain	Example commanders
FORGE	Levi Ackerman	craft, growth, output	Zuko (career), Trunks (coding), Squidward (music), Shikamaru (learning), Jiraiya (writing)
FOUNDATION	Saitama	stability, security, infra	Kakashi (work), Bulma (finances), All Might (health), Zoro (fitness), Itachi (security)
FLOW	Makima	strategy, networks, leverage	Lelouch (networking), Cell (end-state), Erwin (opportunity-cost), Iroh (creative strategy)
FIRE	Goku	energy, connection, life	Killua (friendship), Sanji (nutrition), Naruto (dreams), Mufasa (legacy), Roxanne (partnership)
SYNTHESIS	Sung Jinwoo	discovery, signal, recombination	Heimerdinger (NLP), Nujabes (audio), L (research), Hashirama (investment), Madara (surveillance)

The captains (system layer)

Captain	Role
Canary	Inbox triage + routing. 4 outcomes: ROUTE / FLAG / HOLD / DISCARD. Lieutenants: Nami, Robin, Vegapunk, Jinbe, Rick Sanchez.
Jimmy Neutron	Vault maintenance, automation scripts, harness health, token-compression events.
Orochimaru	Daily/weekly/monthly scout. Owns the model-rank ladder, the review topology, and the mentor-mentee program.
Meruem	Federation evolution — tracks domain-doctrine + evolution across all 40 commanders. Quality arbiter (promoted captain 2026-06-03).

---

2. The five surfaces (CLIs) at a glance

Hinata is driven through five harnesses. Each is launched into the vault as its working directory and is governed by the same repo-canonical laws. They differ in write authority and strength.

CLI	Role	Strength	Write authority	Launch
Claude (local)	The General — primary harness	Structural & strategic	Full vault+Sandpit write + the only Git commit authority	hinata-claude.command → claude
Cloud	The General's cloud arm	Unattended / long-running	Full, on an ephemeral clone → delivered via cloud/[task-id] branch	claude.ai/code or claude --remote (no launcher)
Antigravity	Agentic builder & executioner	Vision, agentic building, codebase modification	Build-only — full file write, but never commits	hinata-antigravity.command → agy
Codex	Scripter & mastery coach	High-speed scripting, sandboxed drills	None to vault — sandboxed scripts; reports diffs	hinata-codex.command → codex
Gemini	Secondary support worker	Diagnostics, vision, research	New files only — read-only audits; no edits to existing	hinata-gemini.command → gemini

The two write-authorised CLIs are local Claude and Cloud — they are the same General, differing only in transport. Everything else captures into the inbox and lets the General assimilate. Full per-CLI contracts are in the vault-root CLI files (CLOUD.md, ANTIGRAVITY.md, CODEX.md, GEMINI.md). The routing decision tree is in §9.

---

3. How Hinata is used today (the as-is runtime)

3.1 The session lifecycle

A local session moves through harness-enforced hooks so that discipline survives context drift:

launch (hinata-*.command → cd vault → exec CLI)
  │
  ├─ SessionStart hooks: inject latest handover · prune stale plans · read state · sync Telegram creds · scan home-root
  │
  ▼
read the bridge + `memory/memory_claude-code.md` + open task rows   ← never assume continuity; read first
  │
  ▼
WORK  ──► orchestrate: route domain units to commanders, cross-pillar to colonels, infra to captains
  │        (each UserPromptSubmit fires: clear-detector · token-check at ~50k)
  │
  ├─ at ~50k tokens: compression — Jimmy extracts decisions, Hinata rewrites state, log written
  ├─ at 97% context: proactively fire /handover (mandatory — never wait for tools to fail at 99%)
  │
  ▼
/handover (unified close): state-review snapshot · persist session to transcript ·
           reconcile open loops in memory_claude-code.md · write the durable re-attach point ·
           loop-evidence auto-closure sweep · Orochimaru session analysis ·
           Diataxis-coverage survey (the-government/ + supreme-court/, non-blocking, gaps queue as task rows) ·
           git commit + PUSH
  │
  ├─ Stop hooks: session-end delegation-ratio verdict · signal /clear · async git push (vault + Sandpit)
  ▼
/clear (forced) — next session re-attaches from the handover file

3.1.1 Handover contract — Diataxis-coverage gate (2026-06-14)

Executing captain: Orochimaru (audit/survey) · Jimmy Neutron applies any file-system fixes the survey identifies. Parallel to Step 9 of the handover skill (Orochimaru session analysis): Step 9 mines patterns across sessions; the Diataxis-coverage survey mines this session's doc-debt against canonical surfaces.

Every /handover invocation MUST survey whether session work produced doc-worthy outputs that belong under the-government/ (reference, how-to, tutorial, explanation per format-design/diataxis) or doctrine changes that belong under supreme-court/runtime/ or supreme-court/format-design/. The survey:

• Enumerates files changed since the last vault backup: commit (incl. unstaged work).
• Classifies each substantive change against the Diataxis decision tree (action vs cognition · acquisition vs application).
• Cross-checks three failure modes: (1) referenced-but-missing — session text cites a the-government/ path that does not resolve; (2) produced-but-unfiled — substantive procedure / reference / decision lives only in chat, memory, or a >500-char task detail with no paired canonical doc; (3) stale-after-change — existing canonical doc describes a procedure/reference that this session materially changed (endpoint moved, lane retired, credential model shifted) and the doc was NOT touched. Stale beats missing.
• Reports a Diataxis-coverage block inline in handover output AND in memory/memory_[cli].md § Diataxis coverage.
• Queues each gap as an open task row in /mnt/data/hinata/tasks/tasks.json via tasks_io (category prefix d per feedback_task-id-format), owner = the commander that produced the work.
• Never halts the push — with one loud-flag carve-out: a stale-after-change gap that contradicts a supreme-court/ law surfaces at the TOP of the Diataxis block with a [STALE-LAW] prefix. Push still proceeds; Michael sees the contradiction inline. Silent queueing of stale law is doctrine-drift. Other gap classes surface + queue without inline escalation, per feedback_dont-stop-ungated and CLOSURE-BY-DEFAULT.

Skill implementation: .claude/skills/handover/SKILL.md § Step 11. Mirrored in .codex/, .gemini/, .antigravitycli/ skill folders only if/when those CLIs gain Diataxis writing authority — vault writes today are Claude-only, so the survey runs Claude-side and gaps for other-CLI work surface as task rows owned by the relevant commander.

3.2 The data plane (where everything lands)

Store	Location	Holds
CT100 postgres (hinata DB · system.tasks)	Z2 container 100	The canonical tasks table (480+ rows), events (incl. commander.attention.shift), domain collector schemas. Fallback: the-government/tasks/tasks.json.
Vault (this repo)	iCloud + GitHub	Laws, agents, skills, context.md, doctrine HTML, memory folds
Sandpit (~/Sandpit/hinata)	local + hinata-sandpit repo	Logs, audio, large binaries, the classifier, Hinata Studio, token-burn snapshots
Token-burn	Sandpit/data/token-burn/YYYY-MM/DD-MM.md	Daily 3-band delegation snapshots + verdict
Bot memory	Sandpit/data/bot-memory/*.jsonl	Per-commander Telegram conversation history

3.3 The scheduler layers

Layer	Count	Examples
Z2 host systemd timers	~34–36	API polls, Telegram alerts, Orochimaru scout, briefings (SSH-trigger model: Z2 schedules → SSHes to Mac for Apple-bound scripts → mirrors to postgres)
CT107 internal timers	3	tasks-sync 03:05 · generate-html 03:10 · monthly audit 1st 03:30
Mac LaunchAgents	~21	Apple Health, Screen Time, Calendar/Reminders/Contacts, Cloudflare tunnel, Telegram bot-poller (the irreducibly Mac-locked set)
Session crons (/schedules)	6	07:03 morning briefing · 12:02 midday · 18:03 evening · review · Orochimaru scout · monthly audit — all firing Telegram

3.4 The audit chain

Each audit owns one surface and cascades downstream. Audits are police, not law — they enforce doctrine, they never become it.

structure-audit  →  agent-audit  →  task-audit  →  prompt-audit  →  website-audit
(file/folder +      (agent-def     (tasks +       (commander       (HTTP + deploy +
 doctrine; most      drift; +       inbox)         prompts;          architecture)
 violent, run        Phase 7 model               no vault writes)
 first)              ladder)
        chat-audit (daily; fans to all 5 colonels + 2 re-review + Sung Jinwoo merge; Phase 7 = doctrine enforcement)
        audit-audit (scheduled-only; verifies the chain is internally consistent)

3.5 The honest current gap

The single biggest live runtime anomaly is that delegation has collapsed. Recent token-burn snapshots read:

## 02-06 09:49 — token burn snapshot
- Hinata main: 100.00% (48.9M / 48.9M) — STRUCTURAL-FAILURE
- State: 0.00% · Commander: 0.00% · verdict: STRUCTURAL-FAILURE

The General is doing nearly all the work in the main thread (rolling delegation has hit ~0.45–1.5% against a 40–70% legal floor for commanders). The whole point of a federation — fresh context per specialist, parallel throughput, attributable burn — is being defeated. Closing this gap is the primary objective of the optimal workflow below.

---

4. The optimal workflow — 10 principles for an agentic second brain

1. Capture is frictionless and source-agnostic. Every input (Telegram, voice memo, email, CLI handover) lands in one intake (inbox/ + a CT100 task row) and is auto-triaged by Canary. Nothing depends on Michael remembering to file it.
2. The General orchestrates, never executes domain work. Main thread stays ≤20% of tokens. Every domain unit goes to its commander; every cross-pillar synthesis to its colonel; all Bash to Jimmy Neutron. This is the fix for §3.5.
3. Parallel fan-out is the default, not the exception. Decompose the work and dispatch up to the concurrency cap (25), re-fanning as units complete. Under-utilising parallelism when work decomposes is a structural failure of the same severity as under-delegating.
4. Right surface for the work. Structural/strategic/vault-writes → Claude (local). Long-running/unattended/off-Mac → Cloud. Vision/search/agentic build → Antigravity. High-speed scripting & sandboxed drills → Codex. Diagnostics/research support → Gemini. (Decision tree in §9.)
5. Durability is the unit of completion. Nothing is real until committed and pushed (local) or branch-pushed/bundled (cloud). A commit without a push is not a backup. A cloud run that errors before shipping = work LOST → re-dispatch from BASE.
6. Closure-by-default. Open loops are driven to closure behind evidence gates (artifact exists + newer than the task + single match). The backlog shrinks every session. End-state: the tasks table holds only Michael-gated items.
7. Halt only on a true bottleneck. Four canonical bottlenecks (source-of-truth unparseable · filesystem unwriteable · context exhausted · unauthorised outward action), and only after a 4-tier check confirms no tier can take the next step. "Unsure / delicate / I'd rather ask" is never a bottleneck. Everything else: log to sweep-events.jsonl and continue.
8. Fan while surfacing. Surfacing a blocker is not the end of a turn. If disjoint work remains, dispatch it in the same turn. A response that ends "awaiting your direction" while completable work exists is a halt — and a violation.
9. Right model for the agent. Orochimaru's six-rank ladder assigns models by measured performance. Main thread = Tier-O at max effort; the group floor = Tier-S high; only proven agents escalate to Tier-O. Don't burn the top tier on every subagent.
10. Sustainability is co-equal with throughput. The burnout brake (All Might + Snorlax) is a first-class gate. Schedule high-cognitive work in morning slots, flag burnout risk before recommending a plan, and never optimise productivity at the expense of mental health. This is the deliberate counterweight to the dont-halt / parallel-max engine.

---

5. The optimal session loop

1. ATTACH      Read the handover re-attach point + `memory/memory_claude-code.md` + open task rows. State the one-line goal.
2. FRAME       Decompose the request into disjoint work-units. Name the owner of each (commander / colonel / captain).
3. EMIT        For any non-trivial unit (≥2 steps, ≥1 durable artifact, or could span a session) write a task row
               FIRST — with a `Closure:` path and a populated `prompt` (Format A delegable / Format B Michael-action).
4. FAN         Dispatch all independent units in ONE message as parallel Agents (up to 25). Emit a
               commander.attention.shift event per dispatch so burn is attributable.
5. SYNTHESISE  Collect results. For ≥2 commanders in a pillar, route the synthesis to that colonel, not main thread.
6. REVIEW      Owning colonel signs off (PASS / REWORK) before any row flips to done. Cross-commander work gets a
               synthesis note; structural/irreversible work gets a /state-review tier.
7. SURFACE     Give Michael the next move (not a menu). One risk/caveat. If blocked, name it AND keep fanning.
8. CLOSE       Drive rows to closure behind the evidence gate. Push. The push is the completion.
9. HANDOVER    At 97% context (or /handover): snapshot, persist state, reconcile loops, write the re-attach point,
               commit+push, /clear.

---

6. The optimal task lifecycle

CAPTURE ──► TRIAGE ──► ROUTE ──► EXECUTE ──► REVIEW ──► CLOSE ──► FOLD
  inbox/    Canary:     to the    commander    colonel    evidence   transcript
  + task    growth-     owning    loads fresh  sign-off   gate +     memory (5d→
  row       filter      commander context +    + KPI      Closure    weekly→monthly);
            (default    / colonel  KB; tools-   check     path       tasks table
            DISCARD) +  / captain  ops for                          = Michael-gated
            enrichment             Bash                              only at end-state
            check

Key contracts on this spine:

• task-mode-default (Bugatti) — emit the row before execution; for consequential work surface the Bugatti review (plan + decision points + risk) and gate execution on Michael's call; then execute, verify, delete the old. The conversation dies on exit; only the row + handover + Closure path survive. See ../preferences-styles/bugatti-mode.
• Closure path — every row carries Closure: <artifact path or verification command>, the contract the auto-closer checks.
• prompt field — every row carries a populated production prompt (strict mode: an unfilled dimension → BLOCKED, queued in inbox/pending-review/, never a stub).
• overlap check — before emitting a new row, scan open rows on 4 axes (>60% keyword overlap · same commander+domain · same closure path · explicit ID reference); any hit → FOLD the old into the new (supersedes: #OLD).
• review cascade — no row closes without its owning colonel's verdict; ≥2 related commander outputs get a recombination/synthesis note.

---

7. Delegation logistics (with worked examples)

This is the operational heart of the system. Get this right and §3.5 is solved.

7.1 Who owns what (routing)

Work shape	Dispatch to	Why
Domain-specific build (finance, music, coding, career…)	the owning commander	loads its context.md + knowledge-base fresh
Cross-commander / pillar synthesis (≥2 commanders in one pillar)	the colonel (Levi/Saitama/Makima/Goku/Sung Jinwoo)	deploys accumulated knowledge of all its commanders — the "Spirit Bomb"
Inbox triage / task-audit	canary-organiser	captain owns routing logic
Session-log analysis / improvement loops	orochimaru-scout	captain owns scout doctrine
Vault maintenance / infra scripts	jimmy-neutron-brain-ops	captain owns automation
Any Bash / file transform / PDF / diagram	jimmy-neutron-brain-ops	captain owns all Bash execution
Multi-file refactor / cross-codebase search	Explore (×N in parallel)	read-only, protects main context
Plan design before a substantive build	Plan	architect agent
Broad/cross-cutting work	a random state colonel	general-purpose is FORBIDDEN — always use a named commander/captain with subagent_type set to their rank

Discretionary-colonel rule: the same colonel may not be picked on two consecutive discretionary dispatches (exclude last-used, choose randomly).

7.2 The three-band token law (the economy)

Rolling-14-day session tokens MUST distribute across three tiers:

Tier	Who	Normal target	Failure threshold
Commander	the full commander fleet	40–70 %	< 20 % = STRUCTURAL-FAILURE
State	3 captains (+ 5 colonels when used)	20–40 %	< 10 % or > 50 % = STRUCTURAL-FAILURE
Hinata main-thread	the General working directly	10–20 %	> 40 % = STRUCTURAL-FAILURE

The bands sum to 70–130 % (overlap is intentional — soft enforcement). Strict pass = all 3 in band; MILD-WARN = 1–2 outside; STRUCTURAL-FAILURE = a severe miss in any band. Measured by check-delegation-ratio.py --rolling-days 14 --json; enforced per-session by session-end-check.sh (<40 % → SEVERE Telegram flag; persistent <40 % over 3 sessions → systemic debt surfaced to Orochimaru). Full thresholds: supreme-court/kpi-thresholds/delegation-thresholds.

7.3 The two axes — never conflate them

Question	Signal to use	Note
Delegation ratio — was the work fragmented into subagents?	subagent-span tokens ÷ eligible execution-session tokens	spans are the correct signal here only
Commander attribution — which commander did this burn belong to?	commander.attention.shift events × session-window JOIN	subagent_type spans capture ~0.04 % of tokens — an explicit anti-pattern for attribution

The named error is grouping burn by subagent_type: it only sees the 0.04 % that flowed through Agent calls and misses the 99.96 % in the main thread. Emit an attention.shift on every dispatch:

~/Sandpit/hinata/scripts/emit-event.sh <commander> commander.attention.shift "<reason>" '{"session":"<id>"}'

7.4 Parallelism & pacing

• Cap: fan out as close to the 25-agent concurrency cap as the work sensibly supports. "10 is not a ceiling." The only brake: each agent must own a real, distinct, non-overlapping unit.
• Re-fan: maximise continuously — re-dispatch as units complete; never sit below ~20 agents while autonomous work exists.
• Split heavy work: any unit estimated > 30 min or 50k tokens must be split into parallel sub-agents before dispatch.
• Runtime benchmark per spawn: <5 min GREEN · 5–10 AMBER · 10–15 WARN · 15–20 ESCALATE (Telegram + post-mortem) · >20 KILL-ELIGIBLE (abort, re-dispatch as two bounded units). Cloud gets a 20-min base ceiling. Explore/Plan agents are WARN-exempt.
• Bind to a task-id: every dispatch binds to a row (status: in_progress on dispatch, closed with burn recorded on completion). Never close a row whose work didn't land.

7.5 When NOT to delegate (main-thread is correct)

Reading a single known path · a one-line edit · a single Bash command · closing one task row · composing the final reply to Michael. Delegating these adds latency without protecting context.

7.6 Worked examples

Example A — single-commander domain task. "Tailor my CV for this Senior Data Scientist role."

• Route → FORGE / Zuko (career). The /apply-to-job skill chains Zuko: score role-fit → CV + cover letter via cv-cover-letter-editor → interview-research → quiz prep → log the application. Jimmy Neutron renders the .docx.
• Emit attention.shift zuko on dispatch.
• Band math (≈200k tokens): Zuko 150k = 75 % commander, Canary intake 20k = 10 % state, main orchestration 30k = 15 %. → strict PASS.
• Close: row carries Closure: applications/[role]/cv-[date].docx; Levi (FORGE) signs off PASS before status=done.

Example B — cross-pillar weekly plan. "Plan my week across job search, music, gym, and the dbt cert."

• Spans FORGE (Zuko, Squidward, Shikamaru) and FOUNDATION (Zoro, All Might, Snorlax) — ≥2 commanders per pillar → invoke the colonels Levi and Saitama, in parallel. Each colonel fans to its commanders: up to 6 commander agents + 2 colonels concurrently.
• Brakes apply: All Might's 14-day burnout flag forces recovery blocks; creative-priority-order ranks music highest on calendar conflicts; high-cognitive work goes to morning slots.
• Colonels return pillar syntheses; the General merges them into one plan (HTML Gantt) and surfaces the next move.
• Band math (≈500k): commanders 300k = 60 %, colonels + Canary 150k = 30 % state, main 50k = 10 %. → strict PASS.

Example C — long-running infra build → cloud. "Build the burnout-detection pipeline on Z2."

• Route → Jimmy (infra + scripts) + Itachi (creds). expected_duration > half-day → cloud dispatch per the CLOUD handover protocol.
• Local: write the task-payload to ~/.claude/plans/cloud/[id].md, stable scoped commit, push BASE.
• Cloud: boots, executes autonomously (never pauses to ask), commits to cloud/[id], pushes, writes memory/cloud-handover-[dd-mm-yy].md, stops — no PR.
• Local next session: git fetch finds the branch → /state-review gate → row-level assimilation onto current main → batch-delete the remote branch at session end (one consent).
• Cloud-execution delegates at ≥60 %.

Example D — vault audit (mass parallel). "Audit the vault."

• Runs the chain: task-audit fans inbox triage to Canary and vault-delta to Orochimaru; chat-audit fans the transcript to all 5 colonels in parallel, then 2 colonels re-review, then Sung Jinwoo merges all 7 outputs.
• Up to ~25 concurrent agents. Per-row failures isolate to sweep-events.jsonl; halt only on a canonical bottleneck.

Example E — the anti-pattern (what NOT to do). The General reads, analyses, writes, and closes everything itself.

• Result: a 517M-token session with 0.04 % delegated → ~100 % main-thread → token-burn snapshot reads STRUCTURAL-FAILURE → session-end-check fires a SEVERE Telegram flag.
• Fix: decompose → emit rows → fan to commanders/colonels → emit attention.shift → re-measure. (This is exactly §3.5.)

Delegation math, explicitly — a 1M-token execution session.

target         commander 40–70%   state 20–40%   main 10–20%
ideal split    4 commanders ×150k = 600k (60%)   2 colonels + Canary = 250k (25%)   main 150k (15%)
verify         check-delegation-ratio.py --rolling-days 14 → {commander:60, state:25, hinata_main:15} → PASS
attribute      attention.shift events × window JOIN → per-commander burn  (NOT subagent spans)

7.7 Dispatch lifecycle (composite Bash-chain + stream-safety)

The 3-band law tells you the share (commander 40–70%, state 20–40%, main 10–20%). supreme-court/runtime/dispatch-lifecycle (enacted 2026-06-13) tells you the shape of each dispatch so the share holds.

Composite Bash-chain. Commanders default to Read, Write, Glob, Grep + optional Edit; Bash is captain-only. When a task needs both a domain edit AND Bash to land (dry-run, commit, push, container exec), it is composite work. Decision tree:

• Bash is a thin wrapper (≤1 dry-run + 1 commit + 1 push) → dispatch Jimmy Neutron with the commander's context file loaded. Domain knowledge transfers via context load; Bash stays captain-side.
• Bash is a separate concern downstream of the edit → dispatch the owning Commander for the edit + Jimmy Neutron in parallel with chain-with-dependency (Jimmy reads from main HEAD after Commander commits).
• Asking a Commander to "edit and commit" is silently impossible — the agent edits, then either fails the commit or skips it. Main thread inherits and burns its own budget. This is the dominant 2026-06-13 failure mode.

Stream-safety standard clause. Every [Execute] / [Plan] dispatch prompt MUST include a "Stream-safety:" block with three rules:

1. Emit a short progress line (≤80 chars) BEFORE each tool call.
2. Avoid single tool calls >60s (openpyxl load_workbook on live tracker, multi-MB Read) — split into multiple short calls.
3. If Read returns >500 lines, narrow the next read with offset / limit.

Skip only for single-tool dispatches. The clause is the only durable death-signal for stream-idle-timeout — silent agents get cut by the harness, not by themselves.

---

8. Halt discipline

The autonomous posture is permanent, implemented by permissions.defaultMode: "acceptEdits". Four laws interlock:

1. acceptEdits — autonomous by default; "plan" as default would kill delegation and parallel-max.
2. parallel-max — 25 agents, uncapped, re-fan continuously. Fan immediately; never categorise-and-stop.
3. fan-while-surface — surfacing ≠ halting (grammar below).
4. true-bottleneck-halt-only — halt only on a canonical bottleneck that survives the 4-tier check.

The 4 canonical bottlenecks (only permitted halts): (1) source-of-truth (tasks table and tasks.json fallback) unparseable · (2) filesystem unwriteable · (3) context literally exhausted · (4) an unauthorised outward action (git push origin / external publish not durably authorised). Local writes, merges, and branches are not outward actions.

Before any halt, run the 4-tier check: confirm that none of Commander / Colonel / State-Captain / Hinata-main can take the next step. "Hinata-main is unsure / it's delicate / I'd rather ask" is never a bottleneck.

Response grammar (fan-while-surface):

• Pattern A (nominal): surface the question in ≤2 sentences tagged to its row, then — Fanning: <next-wave disjoint work>.
• Pattern B (true bottleneck): HALT: <canonical bottleneck>. 4-tier check: Commander/Colonel/State/Hinata-main = [results].
• Pattern C: queue empty — clean stop.

Forbidden final-sentence grammar while work remains: "Standing by." · "Awaiting your direction." · "Holding for your decision." · "Let me know if…"

---

9. The five CLIs in the optimal workflow — routing decision tree

Is the work STRUCTURAL / STRATEGIC / a vault write / a high-stakes decision?
   └─ YES → Claude (local)   [the General · Sole Writing Authority]
   └─ NO ↓
Is it LONG-RUNNING / UNATTENDED / better off-Mac (autopilot, bugfix, build, audit)?
   └─ YES → Cloud            [branch cloud/<task-id> → push → local assimilate · no PR]
   └─ NO ↓
Does it need VISION / SEARCH / AUTONOMOUS BUILDING (active code modification)?
   └─ YES → Antigravity      [build-only · never commits · Claude/Michael commits]
   └─ NO ↓
Is it HIGH-SPEED SCRIPTING / a SANDBOXED DRILL / DevOps scaffolding?
   └─ YES → Codex            [no vault writes · reports diffs · Socratic drills]
   └─ NO ↓
Is it DIAGNOSTIC / RESEARCH / a handover packet (Claude credits exhausted)?
   └─ YES → Gemini           [new files only · read-only audits · deprecating June → prefer Antigravity]

Cross-CLI contract: every CLI's single handover write target is inbox/[cli]-handover-[dd-mm-yy].md with source: cli-[name] frontmatter, auto-processed by Canary. The secondary CLIs (Antigravity/Codex/Gemini) keep their skills homogeneous to one another; changes flow downstream from Claude only, never upstream. Antigravity is the migration authority maintaining that parity.

---

10. The cloud track (CLI handover protocol)

The CLOUD handover protocol owns both bookends of a cloud run (/plan-cloud skill retired 2026-06-11 — superseded by the per-CLI handover protocol; nothing can launch the user-billed cloud session itself). It is a closed loop with 4 context-aware modes:

Mode	Where	Trigger	Action
1	local	no task-id	git fetch --prune; if cloud/* branches pending → assimilate then STOP; else auto-select a cloud-friendly OPEN task, write payload, commit, push
2	local	[task-id]	port that task → payload → stable commit → push → report "ready to boot"
3	cloud	payload loaded	the payload IS the execution unit — execute iteratively & fully autonomously, commit to cloud/[task-id]
4	cloud	task done	commit → push branch (durability) → write memory/cloud-handover-[dd-mm-yy].md → confirm durable before teardown

Phases: Frame → LOAD (pre-cloud stable commit + push BASE; Sandpit preflight --strict) → Physical prompt (governance prompt FORBIDDEN — repo-canonical; task-payload REQUIRED) → FREEZE → UNLOAD (fetch/bundle-verify, diff vs BASE) → FOLD + ASSIMILATE (mandatory /state-review gate; reconcile, never overwrite; row-level replay for the tasks table; skip cloud's auto-generated artifacts and regenerate locally) → Durable + cleanup (batch branch deletion at session end, one consent).

Branch discipline: cloud/[task-id] (task-id only, no date suffix) → push → STOP. Never push main. Never open a PR by default. Local assimilation per the CLOUD handover protocol behind a state-review gate is cloud's merge gate. On a multi-branch wave, the BASE-drift gate (cloud-landing-check.sh) forces cherry-pick mode for any drifted branch — never blind-merge.

---

11. Governance & safety constants

Constant	Rule
Law store is supreme	supreme-court/ overrides CLAUDE.md. Laws live in supreme-court/ subdirectories.
Repo-canonical config	All governance is in-repo so cloud clones inherit it. No per-dispatch governance prompt.
vault = root	The vault is the working directory. Dissolved folders (general/, timeline/, documentation/, reviews/) must never be recreated.
6 permitted write locations	vault · ~/Sandpit/hinata · ~/Library/LaunchAgents · ~/.cursor/skills* · ~/Library/CloudStorage/OneDrive-Personal/hinata-onedrive. /Users/nnamdi/ home root is off-limits.
commit-includes-push	A commit without a push is not a backup. iCloud sync is not a substitute.
no destructive git	git reset --hard, git clean -fd, force-push, git branch -D forbidden without explicit instruction.
sovereign commits	No Co-Authored-By trailer, no vendor model names in author-controlled content. Use Tier-O / Tier-S / Tier-H. Commit author Michael Nnamah (cloud) or Hinata [hinata@vault.local].
credential discipline	Itachi is the source of truth. Never print a credential value; never auto-rotate (detect → redact → surface → wait). Never echo a credential in Telegram.
Telegram only on breakage	Reserve the channel for actual failure; routine digests follow the wrap-up protocol only. Noise trains the user to ignore it.
integer phases, .md output	Skills/plans use flat integer steps; all vault output is .md; .html only in a dedicated studio folder. Mermaid diagrams encouraged for visual output.

---

12. Maturity roadmap & open loops

Three maturity stages:

1. Tools & Automation (largely achieved) — schedulers, collectors, postgres, the Telegram fleet, Z2 migration.
2. Health & Biometric Pipeline (next) — wire the biometric loop: Apple Health import (built but idle) → rolling-14-day burnout flag (All Might + Snorlax).
3. End State (future) — sovereign local inference: a 64 GB NUC + Pi5 + Tailscale running a 72B local model + vector store + embeddings (Cell's scoping; ~£900 hardware, ~45-month cost crossover). Sovereignty primary, cost secondary; Mac-optional.

Load-bearing open loops: Z2 GitHub deploy key not yet added (blocks git clone onto Z2) · Vaultwarden master-password login to ingest 36 credential files · VPS endpoint repointing (8 scripts still hit the old VPS) · Minato (the Telegram advisor) not yet deployed to CT106 · mail-poller cron wiring on CT102 · ~35 remaining Mac LaunchAgents migratable to Z2 · the delegation STRUCTURAL-FAILURE itself (the #1 systemic anomaly — see §3.5 / §7).

---

13. The sustainability brake (why this matters)

The autonomy engine (acceptEdits + parallel-max + fan-while-surface) is deliberately relentless. Its only designed counterweight is the burnout brake: All Might's rolling 14-day flag (gym sessions + training days) and Snorlax's sleep signal, plus the standing rules to schedule high-cognitive work in the morning and to flag burnout risk before recommending a plan. An agentic second brain that maximises Michael's output while degrading his health has failed its prime directive. Mental health and productivity are co-equal — never optimise one at the expense of the other.

---

Related: CLAUDE.md · CLOUD.md · ANTIGRAVITY.md · CODEX.md · GEMINI.md (all vault root) · settings.json · config-howto.md. Supreme source of truth: supreme-court/.