[Phase 3] Implement the team up, down, and status MVP

[Saber5656]

Background

PRD FR-4 requires Teams support. For the MVP, the scope should focus on sandboxed multi-agent lifecycle management. Conflict resolution and per-agent file permission control remain out of scope.

Scope

• Define the team configuration schema.
• Start multiple agent containers with cage team up.
• Create a shared workspace volume and internal network.
• Display container and session status with cage team status.
• Clean up team resources with cage team down.
• Clarify the scope of cage sync --team or defer it explicitly.

Acceptance Criteria

• Team configuration parsing and validation tests exist.
• up, down, and status are functional rather than no-op stubs.
• Shared workspace responsibilities are documented.
• The supported scope of sync --team is clear.

References

• cage-demo/docs/PRD.md FR-4
• cage-demo/docs/architecture/architecture.md Teams layer
• cage-demo/src/cli/team.rs
• cage-demo/src/team/*

Technical Audit Addendum (2026-07-06)

• Design conflict to resolve before implementing: FR-3 diff/sync assumes one workspace + one baseline per session, but FR-4.2's shared team volume breaks that assumption (multiple agents mutate one tree; whose baseline does sync --team diff against?). Decide explicitly:
  • (a) one shared workspace volume with a single team-level baseline ref, cage sync --team produces one unified diff; or
  • (b) per-agent workspaces plus an explicitly shared directory that is excluded from sync.
    Record the decision in the team configuration schema before coding — this is the main reason the legacy src/team/* stayed a stub.
• Naming/collision: team container, volume, and network names must reuse the collision-resistant session-ID scheme required by [Phase 3] Provide a safe DinD sidecar mode #20 so two teams (or a team plus solo sessions) on one host cannot collide.
• Resource multiplication: N agents × default limits (4g/2cpu) can exceed host capacity; team up should print the aggregate and warn when it exceeds available memory (THREAT-TM-D-01/D-02).
• Credential injection ([Phase 1] Inject credentials through tmpfs and delete them after startup #11) happens per-container; the team path must reuse it unchanged (no shared credential volume).