[Feature] Multiplayer UI: collaboration and single-user parity (U7)

[stephschofield]

Outcome

Independent authenticated users can collaborate through the existing Office, Missions, Factory, rooms, approvals, recovery, and artifact workflows while retaining every supported single-user capability.

Current position

Pending. A passing owner-only UI journey does not prove cross-user feature parity. Reuse existing staffing, operating-lane, and saved-connection work in #48, #145, #198, and #204; retain the existing snapshot coalescer rather than introducing another dashboard or refresh system.

Acceptance criteria

• Add shared machine/agent selection to existing mission preview/creation and expose ownership, grants, capacity, source readiness, queue reasons, and unsupported capabilities in the existing surfaces.
• Exercise every approved parity-matrix row using independent authenticated members and a nonmember/unauthorized actor.
• Preserve control leases, approval gates, budgets, recovery lineage, publication boundaries, historical attribution, and artifact authorization across users and reconnects.
• Update web, CLI, Factory, and MCP/ACP/A2A launch consumers coherently; preserve legacy immediate-only requests and prohibit unauthenticated team-mode A2A.
• Preserve bounded startup and snapshot coalescing; prove revocation and current authority on already-open clients, replay, and long-lived subscriptions.
• Run complete browser-to-server-to-runner parity and single-user regressions; retain real-owner/imported-agent and legacy mission-origin limitations explicitly until verified, rather than hiding them behind an owner-only pass.

Dependencies

Blocked by #244 and #245. Existing related feature issues retain their own scopes and acceptance; coordinate integration rather than replacing them.

Coordination and execution boundary

Part of #239. This records the existing U1–U10 workstream, not a new execution request. All original R1–R14/M01–M37 requirements and review gates remain in force. Related issues retain their owners and lineage. Keep the existing office and retained evidence untouched. No factory:ready label, automatic dispatch, cloud deployment, publication, or merge is authorized by filing this issue.

Status reflects saved development checkpoints inspected September 13, 2026, not a new runtime verification.

Multiplayer UI delivery breakdown - September 16, 2026

This issue is the canonical Feature for the U7 collaboration UI and cross-client/single-user parity outcome beneath epic #239. The six original acceptance items, dependencies, review gates and execution boundary above remain unchanged.

Atomic child tasks

Child task	Existing U7 acceptance coverage	Planning position
#313 - Mission-centered collaboration foundation	Partial items 3/5; contributes to 6	Implemented in draft PR #306; not merged or aggregate acceptance
#314 - Shared machine/agent selection	Item 1; preserves 3/5	Placeholder; blocked by #244/#245 contracts
#315 - Consistent web/CLI/Factory/gateway launch context	Item 4; preserves 3/5	Placeholder; blocked by #244/#245 contracts
#316 - Integrated U7 multi-actor/single-user verification	Items 2/3/5/6, with coverage of 1/4	Placeholder; final verification follows the three implementation tasks and #242

Numbers above identify the original checklist order, not newly assigned R/M requirement identifiers. The full original R1-R14/M01-M37 workstream remains authoritative.

PR #306 will close only #313 on merge. Keep this feature and #239 open until their full acceptance is satisfied. PR #306 remains draft; the author controls readiness and requests ecorp-team review.

Existing owners/scopes to integrate, not duplicate

• Multiplayer U2: add durable membership, ownership, and sharing contracts #241/Multiplayer U3: complete browser sign-in, invitations, and member management #242: membership, sharing, sign-in, invitations and member management.
• Multiplayer U4: deliver machine join and owner-controlled agent import #243/Multiplayer U5: synchronize authorized repositories safely across runners #244/Multiplayer U6: make scheduling capacity- and ownership-aware #245 and Replace the static crew with mission-scoped dynamic staffing #48/Connect and test saved repositories and native coding agents from the workspace #198/Carry saved project and coding-agent connections through Factory intake #204: enrollment, installations, source preparation, scheduling, staffing and saved connections.
• Unify Factory, missions, approvals, and Comms into one dark-factory operating lane #145 and [UI/UX] Actual factory console: visibility, usability, themes and executive view #257/[UI/UX] Make mission, run and audit history searchable and complete #258/[UI/UX] Expose live run activity, freshness and execution blockers #259/[UI/UX] Add in-console source-change and evidence review #260/[UI/UX] Surface authorized spend and budget headroom across work #261/[UI/UX] Add guided contract revision and recovery forms #262: operating lane, contextual notifications/control requests, history, activity, evidence review, budgets and recovery forms. PR feat(web): surface Factory run activity, freshness, and blockers #265 remains a separate [UI/UX] Expose live run activity, freshness and execution blockers #259 slice.
• [Design system] Establish DESIGN.md and align the ECorp console with HeroUI v3 #266/[UI/UX] Add accessible Light, Dark and System themes #263/[UI/UX] Add Executive and Operations presentation modes #264: HeroUI, themes and presentation modes; no reparenting or redesign of this work.
• Add ephemeral authenticated human presence to shared rooms #253: human presence; Negotiate internal ECorp browser/server/runner compatibility before command admission #254: internal wire compatibility; Multiplayer U8: add authorized shared issue and backlog mutations #247: shared backlog mutations.
• Multiplayer U9: package private deployment and operator recovery #248/Multiplayer U10: prove the complete three-device journey and release readiness #249: private deployment and full release/device evidence; [Feature] Human-delegated OBO flow for agent tasks (MVP: Azure SQL schema discovery) #285: the separately tracked OBO feature.
• Shared authoritative state stays with existing backend work, including Require a shared claim authority for contributor factories on the same backlog #161. The meeting's agent-mesh/memory proposals do not authorize another ledger, identity system or messaging product.

Tracking state

The feature's full acceptance remains pending. Existing owner, labels and Project status are preserved; the new foundation task is In Progress because its PR is draft, and the other tasks are Todo placeholders. No factory:ready, assignment, dispatch, reviewer request, readiness change, merge or deployment is authorized by this planning update.