stack/docs/fleet/NORTH_STAR.md

Mosaic Fleet — NORTH STAR

Generated file — do not edit by hand. Projected deterministically from NORTH_STAR.yaml by the pure generator in packages/mosaic/src/commands/fleet.ts (renderNorthStarMarkdown). Edit the YAML, then regenerate. Self-contained Mosaic — no Hermes dependency.

Mission

A self-driving Mosaic system that 24/7 unattended converts a machine-readable goal set into merged, CI-green, budget-bounded change — looping plan→backlog→assign→execute→verify→merge→reassess — on Mosaic's OWN native backlog/dispatch engine. Mosaic is general-purpose: the user declares the system type they want (software delivery, personal assistant, research, business/operations, …) and the orchestrator provisions the matching persona roster and structure; the delivery fleet is one profile among many.

Substrate

The Mosaic Backlog is the backlog of record + dispatch engine, built on Mosaic's native Postgres storage service (@mosaicstack/db drizzle; PGlite-embedded by default, full Postgres by config). NOT Hermes.

Standing objectives

• NS-1 — Single machine-readable source (this file) drives planning; prose docs are projections.
• NS-2 — Every backlog item is an independently-shippable unit with stable id, priority, depends_on DAG, represented as a Mosaic Backlog card; spend tracked as advisory projection.
• NS-3 — The supervisor guarantees movement: no idle agent while ready dependency-satisfied work exists; no empty backlog without a replan request; assignment via Mosaic native dispatch/claim.
• NS-4 — Exactly one merge-gate approver; nothing reaches main except via pr-merge.sh after pr-ci-wait.sh success; Gitea branch protection is the backstop.
• NS-5 — Every unit bounded by wall-clock TTL on its claim; token caps enforced only where a real meter exists, else advisory.
• NS-6 — Context cleared between tasks for ephemeral runners (reset_between_tasks); persona+mission re-injected per task.
• NS-7 — Meta-loop (session-review + enhancer) continuously proposes small fleet-improvement PRs.
• NS-8 — Single operator-flippable PAUSE kill-switch (fleet/run/PAUSED) honored before every dispatch and every merge.
• NS-9 — Mosaic is a general-purpose multi-agent system: the user declares the SYSTEM TYPE to run (e.g. software delivery, personal assistant, research, business/operations) and the orchestrator provisions the matching persona roster and org structure from a cross-domain baseline persona library; the delivery/coding fleet is one profile among many.

Success criteria

• AC-NS-1 — The supervisor keeps a two-agent floor (1 orchestrator + >=1 enhancer) healthy across reboot.
• AC-NS-2 — A goal added to this YAML is decomposed to cards and either merged or escalated, with no human in the loop.
• AC-NS-3 — No PR merges with failure/error/no-status/timeout CI, and none bypass pr-merge.sh.
• AC-NS-4 — TTL is enforced on claims; token caps remain advisory until a real meter exists.
• AC-NS-5 — Flipping fleet/run/PAUSED halts dispatch and merges within one tick.
• AC-NS-6 — A user can declare a system type and the fleet provisions the matching persona roster + topology from the baseline library, with no code change.
• AC-NS-7 — A user-customized persona (edited or added via the orchestrator) survives mosaic update: baseline reseed never clobbers user overrides.

Workstreams

id	title
A	Substrate — Mosaic Backlog on native Postgres storage service
B	Supervisor — movement guarantee, two-agent floor, dispatch/claim
C	Planner — goal decomposition into independently-shippable cards
D	Merge-gate — single approver, pr-merge.sh after CI wait
E	Meta-loop — session-review + enhancer improvement PRs
F	Safety-rails — TTL claims, advisory spend, PAUSE kill-switch
H	Personas & system profiles — cross-domain library, system-type provisioning, update-surviving customization

Goals (backlog projection)

id	title	phase	priority	depends_on
A1	Machine-readable NORTH_STAR.yaml + Markdown projection	1	must-have	—
A2	Mosaic Backlog schema + storage-service card store (drizzle/PGlite)	1	must-have	A1
A3a	Card lifecycle — create/claim/release with stable ids + depends_on DAG	1	must-have	A2
A3b	TTL-bounded claim enforcement (wall-clock) on cards	1	must-have	A3a
A4	Advisory spend projection per card (degrades to TTL, no real meter)	1	should-have	A3a
B1	Supervisor tick — readiness scan, two-agent-floor health check	2	must-have	A3a
B2	Native dispatch/claim — assign ready dependency-satisfied work	2	must-have	A3b, B1
B3a	Planner decompose — goal added to YAML → cards	2	must-have	A2, B1
B3b	Replan request on empty backlog; escalate on no-decompose	2	should-have	B3a
G1	PAUSE kill-switch + merge-gate honored before dispatch and merge	2	must-have	B2
H1	Cross-domain baseline persona library (exec, marketing, ops, research, assistant + engineering roles)	1	must-have	A1
H2	System-type profiles — declarative mapping of system type to persona roster + topology	2	must-have	H1
H3	System-type provisioning — user declares type; orchestrator instantiates the matching roster + structure	2	must-have	H2
H4	Update-surviving persona customization — ad-hoc edits/additions persisted in a PRESERVE-protected override layer (baseline merged with overrides)	2	must-have	H1

Assumptions (vetoable)

• ASM-1 (vetoable) — The Mosaic Backlog on the native Postgres storage service is the backlog of record.
• ASM-2 (vetoable) — Claude gate roles have no native busy status, so readiness = pane-idle + heartbeat.
• ASM-3 (vetoable) — Two-agent floor = 1 orchestrator + >=1 enhancer.
• ASM-4 (vetoable) — Baseline personas ship in framework/fleet/roles/ (reseeded on update); user overrides live in a separate PRESERVE_PATHS-protected layer and win on merge.

Spend

• advisory: true
• No per-task token meter yet; budgets degrade to TTL. Spend is tracked only as an advisory projection alongside each card.