Multiplayer coordination dashboard parity

BMO’s multiplayer proof story spans four read-model sections that usually live in different commands: a reference trace corpus validated in CI, a conformance profile posture check, live-export capability metadata (pointing at bmo stigmergy multiplayer export without running it), and optional operator-runtime conformance for one session. The multiplayer coordination dashboard composes those sections into one JSON readout so maintainers, automation, and sponsor-copy workflows can inspect posture without running separate tools.

The dashboard is read-only. It labels reference corpus rows as reference_corpus and runtime export as code_backed. It does not authorize coordination, acquire workspace claims, or block concurrent writes. For mutation-time overlap control, use workspace claims; for live child-agent inspection, use /agent-family; for a full trace document from a seeded zone, use bmo stigmergy multiplayer export.

Maturity: Maintainer-facing reference surface. Use it for remote inspection, automation, parity checks, and claim-matrix row C20 (maintainer matrix: maintainer artifact outside this repository at workspace root; proof ladder in Stigmergic delivery). It is not a collaboration product or a pre-write conflict gate.

Doc ownership: This page is the canonical parity contract (schema, surfaces, auth, parity scope, verification). Live-export flags, strict vs best-effort export, and zone-pressure requirements live in the maintainer topic multiplayer.md — do not duplicate export detail here.

What it is not

Do not claim	Use instead
A team or org collaboration dashboard	/agent-family, mesh, or your own orchestration layer
A pre-write conflict gate	Workspace claims (process-local, advisory or hard)
Live multi-writer proof from corpus rows	Strict bmo stigmergy multiplayer export on a seeded harness
Live export health probe	bmo stigmergy multiplayer export --json (dashboard only advertises the CLI)
Full trace JSON in the dashboard payload	bmo stigmergy multiplayer export --json
Day-to-day zone pressure and follow-through	/cognition, explain/triage CLI
Unified orchestration / task read model	Task aggregate (get_task_aggregate)

Fixed envelope strings from the read model:

• mutation_boundary: read-only dashboard; it does not authorize coordination or mutation
• coordination_posture_note: reference traces supply product scenarios; conformance supplies the trust contract
• live_export.notes: runtime export is code-backed and redacted; it is not a live SaaS dashboard

When to use it

You need…	Prefer
Reference trace coverage before sponsor or demo copy updates	This dashboard (reference + conformance sections)
Corpus validity vs live export capability in one document	This dashboard
Operator-runtime capability snapshot for one session	This dashboard with --session-id
Who acts next in a session family	Run observability parity (cue ledger)
Recommendation follow-through over a calibration window	Operator cognition parity
Unified task / work-intelligence read model	Task aggregate (get_task_aggregate)
Ranked local child-agent conductor view	/agent-family
Strict JSON trace from a live contested zone	bmo stigmergy multiplayer export --json (strict default)

Composition

App.MultiplayerCoordinationDashboard in internal/app/multiplayer_coordination_dashboard.go:

1. Loads the reference corpus and summarizes each canonical fixture.
2. Validates conformance profile posture (corpus_valid, warnings on failure).
3. Synthesizes live_export in multiplayercoord.NewReadout — it does not invoke bmo stigmergy multiplayer export or probe export health.
4. Optionally attaches operator_runtime when session_id is set and OperatorRuntimeConformancePayload returns without error.

graph TB
  subgraph loaded["Loaded at build time"]
    RT["Reference trace corpus
internal/multiplayertrace/testdata/"]
    CP["Conformance validation
multiplayer_reference_trace_corpus"]
    OR["Operator runtime
session-scoped checks"]
  end

  subgraph synthesized["Synthesized metadata"]
    LE["live_export block
CLI pointer only"]
  end

  APP["App.MultiplayerCoordinationDashboard"]
  OUT["Readout JSON
bmo.multiplayer_coordination_dashboard.v1"]

  RT --> APP
  CP --> APP
  LE --> APP
  OR -. optional session_id .-> APP
  APP --> OUT

  subgraph jsonSurfaces["JSON parity surfaces"]
    HTTP["GET /v1/multiplayer-coordination-dashboard"]
    CLI["bmo stigmergy multiplayer dashboard --json"]
    TOOL["get_multiplayer_coordination_dashboard"]
    MCP["bmo_get_multiplayer_coordination_dashboard"]
  end

  subgraph presentation["Presentation surfaces (not JSON parity)"]
    TUI["/multiplayer_dashboard summary"]
    CLITXT["CLI without --json tabwriter"]
  end

  OUT --> HTTP
  OUT --> CLI
  OUT --> TOOL
  OUT --> MCP
  OUT -. rendered summary .-> TUI
  OUT -. tabwriter .-> CLITXT

Ecosystem map

flowchart LR
  subgraph prevention["Coordination prevention (mutation path)"]
    WC["Workspace claims"]
    PC["Plan contracts"]
  end

  subgraph observation["Coordination observation (read path)"]
    AF["/agent-family"]
    COG["/cognition"]
    TA["get_task_aggregate"]
    MP["/multiplayer_dashboard"]
    EXP["multiplayer export"]
  end

  WC -. does not replace .-> MP
  AF -. different question .-> MP
  TA -. different question .-> MP
  MP -->|"points to CLI for"| EXP
  PC -. orthogonal .-> MP
  COG -. different question .-> MP

Surfaces

Surface	Entry	Default session scope	Output
HTTP	GET /v1/multiplayer-coordination-dashboard	none	JSON
CLI	bmo stigmergy multiplayer dashboard --json	none	JSON (same app read model)
CLI (text)	bmo stigmergy multiplayer dashboard	none	Tabwriter summary, not parity JSON
Agent tool	get_multiplayer_coordination_dashboard	none	JSON when getter wired
MCP	bmo_get_multiplayer_coordination_dashboard	none	JSON when provider wired
TUI	/multiplayer_dashboard	active session id when present	Scrollable summary only

Aliases: /multiplayer-coordination-dashboard, /multiplayer_coordination_dashboard.

Parity scope

What is guaranteed in code today:

Pair	Guarantee
HTTP vs server tool getter	TestMultiplayerCoordinationDashboardFn_JSONMatchesHTTPSurface — same JSON modulo generated_at_unix (stripped in test because wall-clock may differ)
CLI --json vs HTTP	Same App.MultiplayerCoordinationDashboard read model; no automated byte-equal test
Agent tool (detached TUI)	Falls back to app.MultiplayerCoordinationDashboard when HTTP getter is not wired (coordinator_option_builders.go)
MCP vs HTTP	Same provider hook as server getter when MCP is enabled; no HTTP byte-equal test in MCP package tests
TUI / CLI text	Non-parity presentation layers over the same underlying read model

generated_at_unix is not a parity field across back-to-back calls.

Getter unavailable

When the parity getter is not wired (typical: agent tool before HTTP server start, MCP with nil provider):

Agent tool returns structured JSON error (not a readout):

{
  "error_code": "parity_getter_unavailable",
  "message": "Multiplayer coordination dashboard is not available because the parity getter is not wired.",
  "suggested_tools": ["operator_cognition_readout", "get_task_aggregate"],
  "http_route": "GET /v1/multiplayer-coordination-dashboard"
}

MCP returns a text error containing not available when the provider is nil.

TUI calls com.App.MultiplayerCoordinationDashboard directly and does not use the parity getter — it remains available in detached TUI when the app is loaded.

Request controls

Optional session scope for the operator_runtime section:

Parameter / flag	Effect
session_id / --session-id	Attempt operator-runtime conformance for one session
recent_runs_limit / --recent-runs-limit	Cap operator_runtime.recent_runs when session is set (default 5)

Omitted or empty session_id returns reference traces, live-export metadata, and conformance profile only — no operator_runtime key.

filters_applied always echoes recent_runs_limit (default 5 from multiplayercoord.NewReadout, even when session_id is omitted). When session_id is set, it is also echoed in filters_applied.session_id.

CLI examples:

# Reference + export metadata only
bmo stigmergy multiplayer dashboard --json

# Include operator-runtime conformance
bmo stigmergy multiplayer dashboard \
  --session-id sess-abc \
  --recent-runs-limit 10 \
  --json

HTTP example:

curl -sS -H "Authorization: Bearer $BMO_AUTH_TOKEN" \
  "http://127.0.0.1:8080/v1/multiplayer-coordination-dashboard?session_id=sess-abc&recent_runs_limit=10"

HTTP validation: Non-integer recent_runs_limit returns 400 with invalid recent_runs_limit.

Authentication and availability

HTTP route: GET /v1/multiplayer-coordination-dashboard (addProtectedRoute + requireAuth).

Condition	Behavior
AuthToken configured, missing or wrong Bearer	401
No AuthToken, AllowNoAuth false	401 authentication required
No AuthToken, AllowNoAuth true	200 without Bearer
App not ready on HTTP server	503 App not ready
Corpus load or parse failure	500 (hard error)
Corpus validation fails	200 with conformance_profile.corpus_valid: false and warnings
session_id set, session service unavailable	200 with warning; no operator_runtime
session_id set, unknown session or runtime build error	200 with operator_runtime_unavailable: … warning; no operator_runtime
session_id set, session known, degraded ledger	200 with operator_runtime attached; checks may be partial / missing; warnings may include no_recent_runs

Unlike operator cognition parity, the dashboard does not return 503 when the recommendation ledger is unavailable for a session-less call: reference traces and export metadata do not require a session ledger.

Canonical fields

Schema version: bmo.multiplayer_coordination_dashboard.v1 (internal/multiplayercoord/readout.go).

Top-level envelope

Field	Meaning
schema_version	bmo.multiplayer_coordination_dashboard.v1
generated_at_unix	UTC generation stamp (not parity-stable across calls)
filters_applied	Echo of recent_runs_limit (always) and session_id (when set)
reference_traces	Bounded summary per canonical corpus fixture
live_export	Synthesized export CLI pointer and maturity label
conformance_profile	Multiplayer proof profile posture
operator_runtime	Optional; present only when session_id is set and payload build returns without error
mutation_boundary	Fixed read-only disclaimer
coordination_posture_note	Trust-contract summary
warnings	Non-fatal notices (corpus invalid, session down, runtime unavailable)

reference_traces[]

Each row summarizes one fixture from the canonical manifest (multiplayertrace.ReferenceTraceFiles()):

Field	Meaning
fixture_file	Basename under internal/multiplayertrace/testdata/
trace_id	Trace identifier inside the fixture
scenario_kind	concurrent or sequential_handoff
title	Human title when present in fixture
step_count	Number of composed steps
actor_count	Number of actors
maturity_label	Always reference_corpus

Canonical fixtures:

File	Role
concurrent_workspace_contention.json	Baseline concurrent scenario
concurrent_interrupted_explicit_approval.json	Stress: interrupted concurrent window
sequential_evidence_handoff.json	Baseline sequential handoff
sequential_stale_work_superseded.json	Stress: stale work superseded

Incidental JSON beside this manifest is ignored by conformance loaders.

live_export

Synthesized in NewReadout — not read from a live export invocation.

Field	Meaning
available	Always true today (advertises export exists; does not probe it)
cli_command	bmo stigmergy multiplayer export
maturity_label	code_backed
notes	Redaction / not-a-SaaS-dashboard disclaimer

Export flags, strict vs best-effort semantics, and zone-pressure requirements: multiplayer.md.

conformance_profile

Field	Meaning
profile_id	multiplayer_reference_trace_corpus
maturity_label	reference_corpus
corpus_valid	Result of ValidateMultiplayerReferenceTraceCorpus

operator_runtime

Attached when session_id is set and OperatorRuntimeConformancePayload returns without error. Built by operatorruntime.BuildPayload (internal/operatorruntime/conformance.go). A returned payload may still carry degraded checks and warnings (for example no_recent_runs) — that is not the same as the attach failing (unknown session → warning, no operator_runtime key).

Field	Meaning
schema_version	Operator-runtime payload version (currently 1)
profile	bmo
session_id	Scoped session
checks	Seven capability probes (see below)
recent_runs	Bounded session-family run references
warnings	Diagnostic codes such as session_unknown, no_recent_runs, workspace_claims_advisory, minimal_mcp_only

Check keys and status vocabulary (present | partial | advisory | missing):

Key	What it probes
actor_identity	Known session + durable run lineage for actor type
authority_boundary	Permission and question surfaces
workspace_state	Shared runtime vs advisory workspace claims
runtime_evidence	Durable agent run ledger and recent session-family rows
handoff_recovery	Continuity capsules and historian retrieval
interruptibility	Authority gates + run lineage + interruptibility evidence model
boundary_honesty	Full app runtime vs minimal MCP-only posture

Each check includes summary text and sources[] with name, kind, durability, and summary.

Example payload (trimmed)

One reference row shown; live CLI returns all four canonical fixtures. generated_at_unix is illustrative.

{
  "schema_version": "bmo.multiplayer_coordination_dashboard.v1",
  "generated_at_unix": 1718841600,
  "filters_applied": {
    "recent_runs_limit": 5
  },
  "reference_traces": [
    {
      "fixture_file": "concurrent_workspace_contention.json",
      "trace_id": "concurrent_workspace_contention",
      "scenario_kind": "concurrent",
      "title": "Concurrent workspace contention with validation handoff",
      "step_count": 4,
      "actor_count": 3,
      "maturity_label": "reference_corpus"
    }
  ],
  "live_export": {
    "available": true,
    "cli_command": "bmo stigmergy multiplayer export",
    "maturity_label": "code_backed",
    "notes": "Runtime export is code-backed and redacted; it is not a live SaaS dashboard."
  },
  "conformance_profile": {
    "profile_id": "multiplayer_reference_trace_corpus",
    "maturity_label": "reference_corpus",
    "corpus_valid": true
  },
  "mutation_boundary": "read-only dashboard; it does not authorize coordination or mutation",
  "coordination_posture_note": "reference traces supply product scenarios; conformance supplies the trust contract"
}

With --session-id, expect an additional operator_runtime object and filters_applied.session_id set.

TUI vs machine surfaces

Multiplayer coordination dashboard

Live BMO TUI: /multiplayer_dashboard renders a scrollable summary of reference trace rows, corpus_valid, live-export metadata, and warnings — not the full JSON parity payload (use CLI --json or HTTP for operator_runtime checks).

The TUI dialog (internal/ui/dialog/multiplayer_coordination_dashboard.go) renders a scrollable summary: schema line, corpus_valid, live-export flags, per-fixture reference rows, warnings, and coordination posture note. When operator_runtime is present, the TUI shows a one-line stub (“see CLI/HTTP JSON for full payload”) rather than inlining every check.

Press r to refresh (2s load timeout). When opened from an active session, the TUI passes that session id by default; CLI and HTTP default to no session unless you set one explicitly.

Relationship to runtime features

runtime_features distinguishes the two access paths:

Feature	Marks when
multiplayer_coordination_dashboard_api	GET /v1/multiplayer-coordination-dashboard succeeds
multiplayer_coordination_dashboard_tool	Agent or MCP getter returns payload

Use these to tell whether HTTP routes, native tools, or both are exercised on a live instance.

Operator smoke checks

bmo stigmergy multiplayer dashboard --json

With HTTP service running and auth configured:

curl -sS -H "Authorization: Bearer $BMO_AUTH_TOKEN" \
  "http://127.0.0.1:8080/v1/multiplayer-coordination-dashboard" | jq .

Maintainer conformance lanes (HTTP/CLI parity tests, trace export, and stigmergy spec harness) live in docs/topics/quality/ci.md and the multiplayer.md maintainer topic — not on this public reference page.

Related

• Maintainer topic: multiplayer.md (live export detail — canonical owner for export semantics)
• Operator cognition parity
• Run observability parity
• Multi-agent workflows (workspace claims)
• Stigmergic delivery (zones and export context)