ADR-048: Agent-Driven Local Dev Stack with Docker Compose and Playwright

Status

Proposed

Context

• Aspire + Dynaplex services (notably the bbu-rfid project) are iterated on by multiple agents who currently rely on manual rebuild/restart cycles via IDE or CLI.
• The host and services must remain visible and controllable on the developer machine (no hidden temp locations) so humans can inspect and override when needed.
• Agents need a deterministic way to roll new builds into the running stack and must always exercise Playwright UI tests after changes.
• We need a shared, local workflow that automates rebuild/deploy while retaining observability and avoiding per-agent bespoke setups.

Decision

Adopt a containerized dev workflow with Docker Compose (or Tilt where available) to orchestrate the Aspire AppHost and all bbu-rfid services, plus an always-on Playwright gate:

• Create dev-focused Dockerfiles for the Aspire AppHost (projects/bbu-rfid/src/Acsis.Dynaplex.Projects.BbuRfid) and each bbu-rfid component using acsis-core.slnx as the build context; expose fixed ports and mount logs/config from a known repo folder.
• Author docker-compose.dev.yml that runs the AppHost and bbu-rfid services, includes named volumes for data (e.g., PostgreSQL), and a ui-tests service that packages Playwright tests from engines/assettrak-ui/src/acsis-assettrak-ui with cached node_modules volume.
• Provide helper scripts under a visible /dev folder:
  • ./dev/up → docker compose -f docker-compose.dev.yml up -d --build to start the full stack.
  • ./dev/reload <service> → rebuild the target image, restart that service, and then run docker compose run --rm ui-tests so Playwright always executes after a change; failures stop promotion.
• Enable live iteration via docker compose watch (preferred) or Tilt resources: watch engines/<domain>/src paths, rebuild images on change, and/or mount source to support dotnet watch run where hot reload is viable.
• Keep all container state and logs in named volumes and repo-mounted folders so service health and output remain inspectable (docker compose ps/logs).

Consequences

• Pros: Single, reproducible dev stack; agents can self-serve rebuilds without local manual steps; UI regression coverage enforced via Playwright on every reload; consistent ports, logs, and config locations visible to the developer.
• Cons/Costs: Requires maintaining dev Dockerfiles and compose definitions; rebuild cycles may be slower than pure dotnet watch; needs Docker Compose v2.17+ (or Tilt) for watch; local resource usage increases when all services and Playwright run together.