platform/master
5
2
Fork 0
Code Issues 6 Pull requests Projects 1 Releases Packages Wiki Activity Actions

ref #3: [feat] add context and tasks for master-service

Browse source
This commit is contained in:
Azamat 2026-04-02 12:04:47 +03:00
parent f0c4988b44
commit 7b3f82e805
10 changed files with 137 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

19
docs/006-mvp-docker-sandbox-orchestration.md Normal file
View file

@ -0,0 +1,19 @@
# 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.