Agent Orchestrator

A read-only look at how this repo is maintained

This site is maintained by one person and eight agents

eonelabs.my runs on a CLAUDE.md orchestration setup: a single top-level session routes each change to a narrowly scoped Claude Code subagent (backend, frontend, content/SEO, QA, DevOps, security, docs, or mobile) and nothing reaches production without an explicit approval gate.

See the roster See the approval gate

This page is a static explainer. It has no backend of its own and no way to trigger a real agent, deploy, or database action. It's a description of a workflow, not a control panel.

01

One repo, several very different concerns

This is a solo project, not a team, but a single change ("add a new blog field") can still touch a FastAPI model, an admin form, a public JS fetch, and the docs all at once. A flat context window blurs those concerns together, and scoped subagents keep each one focused.

Scoped context

Each subagent only sees the tools and instructions relevant to its lane. A docs pass doesn't carry DB-schema reasoning it doesn't need.

Least privilege

QA and security review-only agents have no write access. They report findings; they don't quietly patch auth code themselves.

Hard gates

Merges to main, production DB actions, and manual gcloud commands always stop for a human yes.

02

Eight agents, eight lanes

Defined in .claude/agents/ in the repo. The orchestrator picks one lane per sub-task; a change spanning several lanes gets broken up and integrated by the orchestrator, not handed wholesale to one agent.

03

Nothing ships without a stop

A worked (illustrative) example: someone asks for a schema change. Click a stage to see what happens at each step. The last one always waits for a real human reply, it never auto-continues.

04

See it running

This is a scripted, client-side recreation, not a live feed. It loops through a hardcoded sequence of realistic dispatch events to give a feel for the internal "Orchestrator Constellation" dashboard used to keep the roster above honest. The real one runs on a live database and isn't public.

Demo replay, not a live feed

Constellation

--:--:--
Orchestrator
Claude Code

Each node is one of the eight scoped subagents in .claude/agents/. Amber = actively dispatched, rose = flagged for review, slate = idle.

Recent activity

    Roster

      05

      Diagrams

      How a request moves from chat to a merged, deployed change.

      Sequence: a schema-touching request

      The orchestrator fans out to the right lanes, then stops for approval before anything touches main or the database.

      sequenceDiagram
    actor Ikhwan
    participant Orch as Orchestrator (Claude Code)
    participant Backend as eonelabs-backend
    participant Docs as eonelabs-docs
    participant QA as eonelabs-qa
    actor Human as Ikhwan (approval)

    Ikhwan->>Orch: "Add a featured flag to Projects"
    Orch->>Backend: model + schema + router change
    Backend-->>Orch: diff (model.py, schemas.py, admin form)
    Orch->>Docs: update README / CLAUDE.md if structure changed
    Docs-->>Orch: diff
    Orch->>QA: local verification (uvicorn --reload)
    QA-->>Orch: pass/fail per area

    Orch->>Human: Approval Gate: PR ready, DB migration needed
    Human-->>Orch: approve migration + merge
    Orch->>Orch: open PR, merge triggers Cloud Build

      Roster at rest

      Where each agent's read/write access stops.

      flowchart LR
    Orch["Orchestrator\n(top-level session)"]

    Orch --> BE["eonelabs-backend\nread+write"]
    Orch --> FE["eonelabs-frontend\nread+write"]
    Orch --> CS["eonelabs-content-seo\nread+write"]
    Orch --> QA["eonelabs-qa\nread-only"]
    Orch --> DO["eonelabs-devops\nread+write"]
    Orch --> SEC["eonelabs-security\nread-only"]
    Orch --> DOC["eonelabs-docs\nread+write"]
    Orch --> MOB["eonelabs-mobile\nread+write"]

    BE --> Repo[("Local working tree")]
    FE --> Repo
    CS --> Repo
    DO --> Repo
    DOC --> Repo
    MOB --> Repo

    DO -. approval gate .-> Prod[("Cloud Run / Neon\n(production)")]