# 006 MVP Docker Sandbox Orchestration

Context
- The service needs a first MVP for sandbox orchestration behind `/api/v1/create`.
- The first version must stay small, avoid auth, and preserve clean architecture boundaries.

Decision
- Use Docker as the outer runtime adapter for sandbox start and stop operations.
- Keep sandbox entities and errors in `domain/` and orchestration ports in `usecase/`.
- Use an in-memory session repository for the MVP instead of a central database.
- Keep one active sandbox per `chat_id` and reuse it until TTL expiry.
- Set default sandbox TTL to 300 seconds.
- Mount chat storage as `rw`, dependencies as `ro`, and lambda-tools as `ro`.
- Run expired sandbox cleanup as an in-process background loop in the HTTP app lifecycle.

Consequences
- Inner layers stay free from Docker and FastAPI details.
- The MVP is single-instance oriented and not yet suitable for multi-node coordination.
- Repository and runtime can be replaced later without changing usecase contracts.