Fleet Management Overview

Benchmarked against: Anthropic — Admin API overview / Workspaces & admin Tools: factory_floor_status, agent_heartbeat, update_captain_location Scope: All ships (SS1, SS2, SS3)

Fleet management is how SuperPortia monitors and coordinates its multi-ship, multi-agent operation. The Captain oversees the fleet from a single vantage point — the Factory Floor — while agents self-report their status and coordinate through the Work Order system.

The fleet

SuperPortia operates a fleet of three ships:

Ship	Codename	Hardware	Location	Status
SS1	Beagle 1	Mac Mini M4 Pro	Office (Tainan)	Active
SS2	Beagle 2	Windows PC	Home	Building
SS3	Beagle 3	Cloudflare Cloud	Cloud	Planning

Each ship runs its own set of agents with specific roles:

Agent roster per ship

Identity	Role	Model	Platform
`Mac App 小克`	Chief Engineer	Opus 4.6	Claude Desktop App
`Mac CLI 小克`	Chief Engineer	Opus 4.6	Claude Code CLI
`Mac App 小A`	Assistant	Sonnet 4.6	Claude Desktop App
`Mac CLI 小A`	Assistant	Sonnet 4.6	Claude Code CLI
`小西`	Strategist	Opus/Sonnet	Claude Chat

The same roster structure applies to SS2 (Win App 小克, Win CLI 小克, etc.). SS3 has Web 小克 for web-based operations.

Factory floor

The Factory Floor is the real-time dashboard of the fleet. It shows:

┌─────────────────────────────────────────────┐
│  FACTORY FLOOR STATUS                        │
├─────────────────────────────────────────────┤
│  Captain: 夏哥 @ 台南工作室                    │
│                                              │
│  TEAM STATUS                                 │
│  ├─ Mac CLI 小克  🟢 working  WO-2026-...    │
│  ├─ Mac App 小克  ⚪ idle                     │
│  └─ Mac CLI 小A   🟡 has pending WO          │
│                                              │
│  ACTIVE WORK ORDERS                          │
│  ├─ WO-2026-0305-001 [in_progress] ...       │
│  └─ WO-2026-0305-002 [in_progress] ...       │
│                                              │
│  AWAITING REVIEW                             │
│  └─ WO-2026-0304-003 [review] ...            │
│                                              │
│  BLOCKED                                     │
│  └─ (none)                                   │
│                                              │
│  SYSTEM HEALTH                               │
│  ├─ Cloud UB: ✅ healthy                      │
│  ├─ D1: ✅ responsive                         │
│  └─ Vectorize: ✅ operational                  │
└─────────────────────────────────────────────┘

Access via: factory_floor_status() — available on both Local UBI and Cloud UB.

What it shows

Section	Data source	Update frequency
Captain location	`update_captain_location`	Manual (Captain or agent updates)
Team status	`agent_heartbeat`	Per-session (agents report at boot)
Active WOs	Work order system	Real-time (status transitions)
Awaiting review	WO status = `review`	Real-time
Blocked items	WO status = `blocked`	Real-time
System health	`sre_status` / `cloud_ub_health`	On demand

Agent lifecycle

Heartbeat

Every agent session begins with a heartbeat:

agent_heartbeat()

This registers the agent as online in the agent_registry table with:

Agent identity
Ship ID
Platform
Current task (if any)
Last seen timestamp

Captain location

The Captain's working location is tracked on the Factory Floor:

update_captain_location(
    location="台南工作室",
    updated_by="小克"
)

Common locations: 台南工作室 (Office in Tainan), 家中 (Home), or custom strings.

Fleet coordination patterns

Cross-ship work

When a task requires work across multiple ships:

Captain creates WO with cross-ship scope
WO assigned to primary ship agent
Agent coordinates via messaging — send_agent_message to other ship's agents
Each ship executes its part — file ops local, shared data via Cloud UB
Results converge in Cloud UB — single source of truth

Disaster recovery

The dual-ship architecture provides mutual rescue capability:

Scenario	Response
SS1 goes down	SS2 agents continue via Cloud UB
SS2 goes down	SS1 agents continue (primary ship)
Cloud UB goes down	Local UBI provides cached data; R2 backup for recovery

This is why Cloud UB is the shared backbone — both ships can operate independently as long as the cloud layer is available.

Agent handoff

When one agent finishes a session and another needs to continue:

Pre-exit: save unfinished todos via ingest_fragment (tag: session-handoff)
Next session: SessionStart hook queries Cloud UB for handoff items
New agent picks up where the previous left off

See Agent Intelligence Protocol §5b for the Session Handoff protocol.

Monitoring commands

What to check	Command
Who's working on what	`factory_floor_status()`
All active WOs	`list_work_orders(status="in_progress")`
WOs awaiting review	`list_work_orders(status="review")`
Blocked WOs	`list_work_orders(status="blocked")`
System health	`sre_status()` or `cloud_ub_health()`
Agent mailbox	`check_agent_mailbox()`

Page	Relationship
SRE Status & Health	System health monitoring details
Work Order System Admin	WO system configuration
Agent Messaging	Inter-agent communication
Data Residency	Where fleet data lives
Backup & Recovery	Disaster recovery procedures

The fleet​

Agent roster per ship​

Factory floor​

What it shows​

Agent lifecycle​

Heartbeat​

Captain location​

Fleet coordination patterns​

Cross-ship work​

Disaster recovery​

Agent handoff​

Monitoring commands​

Related pages​