Fleet Management

Current Shape

Fleet management is implemented as tenant-aware reporting, rollup, feature-catalog, gateway, and deployment metadata paths rather than a generic runtime feature-switch system (workers/reporting/src/index.ts:31-46, workers/control-plane/src/routes/catalog.ts:7-24, docs/architecture/anti-goals.md:5-31).

The control plane feature catalog stores deployed feature metadata per tenant, including feature key, deployed version, integration provider, customization JSON, and last migration timestamp (workers/control-plane/src/routes/catalog.ts:7-24).

Feature catalog registration upserts feature rows per tenant and returns the tenant's registered feature list (workers/control-plane/src/routes/catalog.ts:51-114).

Feature catalog updates can change deployed version, customization JSON, last migration timestamp, and integration provider fields for a known feature row (workers/control-plane/src/routes/catalog.ts:116-186).

Feature catalog deletion removes the specific tenant-feature row after confirming the record exists (workers/control-plane/src/routes/catalog.ts:188-212).

Fleet Reporting

The reporting worker exposes network, branch overview, activity monitor, workforce, queue operations, customer analytics, service catalog, resources summary, event campaigns, alerts, scoring, audit, scheduled reports, and rollup endpoints (workers/reporting/src/index.ts:31-46).

Network summary counts active branches and active staff from config data and combines those counts with rollup totals, wait time, service time, utilization, revenue, customer count, appointment count, walk-in count, event count, queue joins, served count, abandoned count, and alert count (workers/reporting/src/routes/network.ts:21-153).

Region summary reads active region metadata, branch counts, staff counts, branch facts, and recent sparkline facts for fleet-level regional views (workers/reporting/src/routes/network.ts:156-230).

The current voyage reporting worker exposes the rollup endpoint and rollup-run persistence, but the checked-in middleware does not inject fanoutOps, so cross-region execution is not fully wired in this repo at this HEAD (workers/reporting/src/middleware/tenant-context.ts:1-34, workers/reporting/src/routes/rollup.ts:25-49).

Rollup run records include mode, window, source watermark, row counts, success state, and failure messages (workers/reporting/src/routes/rollup.ts:33-148).

The fully wired fleet-scale fanout path is in the Meridian tenant fork, where reporting middleware sets fanoutOps and fanoutCustomers and the reporting worker mounts the same admin/internal reporting surface against tenant-specific shard bindings (../voyage-bank/workers/reporting/src/middleware/tenant-context.ts:1-55, ../voyage-bank/workers/reporting/src/index.ts:21-46, ../voyage-bank/workers/reporting/src/routes/rollup.ts:29-53).

That split is the intended per-tenant deployment model: the platform repo owns the shared reporting capability, while the tenant fork wires it into a concrete fleet deployment and proves the 380-branch / 10-region runtime shape (../voyage-bank/e2e/specs/01-api/reporting-contracts.spec.ts:13-54, ../voyage-bank/workers/reporting/src/middleware/tenant-context.ts:47-53).

Meridian 380-Branch Proof Point

The Meridian reference E2E reporting contract asserts a network summary branch count of 380 (../voyage-bank/e2e/specs/01-api/reporting-contracts.spec.ts:13-18).

The same reporting contract asserts that region summary returns ten regions (../voyage-bank/e2e/specs/01-api/reporting-contracts.spec.ts:28-34).

The queue operations health contract asserts health data across ten regions (../voyage-bank/e2e/specs/01-api/reporting-contracts.spec.ts:46-54).

The Meridian admin assessment describes a network operations center for a 380-branch bank and checks that branch counts remain in the expected 370-390 range with exactly ten region table rows (../voyage-bank/e2e/specs/02-admin/haiku-assessment.spec.ts:15-21).

The branch directory assessment expects the Meridian branch directory to expose all 380 branches (../voyage-bank/e2e/specs/02-admin/haiku-assessment.spec.ts:57-73).

The activity monitor and queue operations assessments both target all 380 branches and ten regions (../voyage-bank/e2e/specs/02-admin/haiku-assessment.spec.ts:81-123).

Deployment and Rollback Metadata

Peer deployment automation writes deployment state after provisioning databases, KV, R2, queues, Worker deployments, Pages builds, and Pages deploys (../voyage-bank/scripts/deploy/deploy-all.ts:76-146).

The shared deploy helper defaults to dry-run mode, parses --execute and --environment, and records command output without executing destructive deploy steps during dry runs (../voyage-bank/scripts/deploy/shared.ts:69-111, ../voyage-bank/scripts/deploy/shared.ts:137-166).

The deploy-all script prints a summary that includes environment, mode, API base URL, Pages URL, dashboard URL, and deployment-state path (../voyage-bank/scripts/deploy/deploy-all.ts:148-163).

Corrections From Frozen HTML

The frozen page's feature-catalog, migration-targeting, and dry-run language should be framed as deployment/catalog metadata, because current anti-goals reject a shared SaaS codebase controlled by broad runtime switches (docs/architecture/anti-goals.md:5-31).

The frozen page should include the Meridian reference fork as the proof point for 380 branches and ten regions because that evidence lives in E2E contracts and tenant topology outside this headless platform repository (../voyage-bank/e2e/specs/01-api/reporting-contracts.spec.ts:13-54, ../voyage-bank/e2e/specs/02-admin/haiku-assessment.spec.ts:15-123).

last verified: 2026-04-24 voyage HEAD: 14f3b190db8817399dcd30e1dc4e1ae7674bbf8a voyage-bank HEAD: ef4d7d4f9a66a05d68c265debc681d506a0606c6