Project
Master OS
A production AI operating system spanning 9 git repositories and 7 business domains. One command drives the full session loop: scouts, interview, parallel-by-brand ticket dispatch, FSM-gated merge, and daily wiki distillation.
What it is
The Master OS is a custom AI operating system I designed, built, and operate solo across seven business domains: Sandbox (content and curriculum engine), UMANO (music events and record label), VioletStudios (AI production tools), Suite52 (artist persona), Blockwise Intelligence (algorithmic trading — hard-siloed), MaxProduct (AI product incubator), and Personal (career and professional assets).
Nine independent git repositories are unified under a single orchestration layer. One
command — /start — drives the full session loop. The system runs daily,
compounds institutional knowledge into a growing wiki, and enforces trust boundaries at
the infrastructure level rather than relying on model instruction-following.
The premise: a solo operator running multiple businesses simultaneously can achieve 10x throughput if the orchestration layer is correct. Correctness requires infrastructure enforcement, not convention. The Master OS is that infrastructure.
Architecture highlights
pass, pytest green, ruff clean, system_doctor A 19/19 — before any branch merges to main Key engineering decisions
Hooks-deterministic / advisory split
Trust boundaries that must hold 100% of the time live in PreToolUse hooks. The
ticket-state-guard.json hook blocks direct writes to
tickets.json — every state transition must go through
scripts/tickets.py, which validates against a finite state machine.
The pre-merge-gate.json hook intercepts every merge on a
claude/T-* branch and fails it unless all checks pass. Correctness
doesn't depend on the model reading its instructions.
4-layer Blockwise Intelligence silo defense
The live trading system is isolated by four independent layers: settings.json deny-list (Claude Code config), advisory rules file (CLAUDE.md-layer), PreToolUse boundary-guard hook (runtime interception), and safety_guard.py (Python runtime check). Any one layer can fail without breaching the silo — all four must fail simultaneously. Defense-in-depth for a system where a misread could trigger financial consequences.
Distillation with authority delegation
Each session produces logs, merged tickets, and research notes. The first
/start of each calendar day runs distillation: parallel distiller
subagents classify candidates as high/medium/low confidence, then route writes to
designated authority agents (librarian for brand wiki pages, operator-global for
cross-brand docs). Distillers never write directly — authority chains are preserved
across the distillation boundary. High-confidence findings auto-promote; medium surfaces
in the next interview for approval; low stays in the daily ledger only.
Intelligent cadence
/start replaced 10 discrete Phase 5 routines. Each phase is skippable
based on freshness signals from session_state.py:should_run(phase).
Run it 10 times in a day — it skips re-scouting if no new commits in the 9 tracked
repos, skips distillation if already run today, but always runs dispatch (the ticket
queue must drain). Same command whether checking in after 20 minutes or returning
after a week. The system decides what's stale.
Scale (as of May 2026)
Evidence of shipping
Phase 6 shipped 2026-05-07 — a complete replacement of the 10-routine Phase 5 system
with a single /start session loop. Parallel-by-brand dispatch is operational:
concurrent ticket executors across brand worktrees with zero collision, enforced by
worktree isolation and the FSM merge gate. The system has processed hundreds of tickets
across all seven domains since Phase 6 launch.
The best evidence the system works: this portfolio site was planned, scaffolded, designed, and deployed via Master OS ticket execution — a ticket executor in an isolated worktree wrote the Astro pages while a parallel executor handled wiki updates.