explore leveraging apple native containers

[anantshri]

Apple has native containers now see if we can support them https://github.com/apple/container within aidc.

keep in mind this comes after all the pending pull requests are merged.

[ai-anant]

🤖 Watchdog analysis

This is an automated triage report. No code changes were made — this is an explore/design issue explicitly gated on merging pending PRs, so I'm providing architecture guidance rather than a quick-fix PR. No existing PR addresses this issue.

Root cause (architectural reality)

This isn't a bug — it's a feature exploration for supporting Apple's native container runtime (github.com/apple/container) in aidc. The practical obstacle is that aidc is pervasively coupled to the Docker CLI + Compose:

• lib/aidc.sh:168 — hard aidc::need_cmd docker git prerequisite.
• lib/aidc.sh:1741 and :1748 — all lifecycle ops go through docker compose -f $workspace/.devcontainer/compose.yaml.
• ~38 direct docker usages across the file: docker inspect (lines 395/413/528), docker stats (399/506), docker volume ls (449), docker ps (486), plus exec/cp used by the transcript-sync and bootstrap paths (e.g. :781 docker compose exec … bootstrap-state.sh sync).

Apple's container tool runs OCI images directly in a lightweight Linux VM on Apple Silicon (Virtualization.framework) and does not implement the Docker/Compose surface aidc depends on: multi-service compose.yaml up/down, named-volume lifecycle with com.docker.compose.project labels, docker exec into a running container, docker cp for host↔container file sync, and docker stats for the aidc status output. So this is a second runtime backend, not a docker→container swap.

Existing PR status

• Aidc currently has 9 open PRs (perf: skip image rebuild when image already exists (fast path for aidc up/claude) #14–fix: rewrite in-container /workspace to host path in synced transcripts #23, all from ai-anant). None reference #25 (no #25, Fixes#25, etc. in their bodies), and the issue timeline has no cross-referenced PRs.
• The issue itself says this work "comes after all the pending pull requests are merged" — consistent with treating those as a prerequisite, not as coverage for this issue.
  → Nothing addresses explore leveraging apple native containers #25 yet; no duplicate to avoid.

Fix guidance (design)

1. Sequence: Land the pending PRs first (as the issue states). Several of them (perf: keep build caches out of the image (uv/go/cargo/apt) #16 caches, perf: slim the base image (drop unconditional build-essential + nodejs) #17 base-image slim, feat: split image into shared aidc-base + thin per-project layer #18 shared base layer, feat: shared read-only toolchain volumes (one copy of Go/Rust/JDK for all projects) #20 toolchain volumes, fix: move pre-existing .devcontainer aside instead of refusing to init #21 init gating, fix: rewrite in-container /workspace to host path in synced transcripts #23 transcript path fix) reshape the container/volume model and would conflict with an "apple runtime" effort started now.

2. Introduce a runtime-provider abstraction before touching runtime code. Define AIDC_CONTAINER_RUNTIME="${AIDC_CONTAINER_RUNTIME:-docker}" (docker|apple) in lib/aidc.sh and route every Docker touchpoint through wrapper functions, e.g.:

   • aidc::rt_need() — the need_cmd check in aidc::cmd_up / prereq validation.
   • aidc::rt_compose_up/down — wraps the docker compose -f … calls at lines 1741/1748.
   • aidc::rt_exec / aidc::rt_cp — wraps the exec/cp used by bootstrap-state.sh sync and transcript sync.
   • aidc::rt_volumes / aidc::rt_stats / aidc::rt_inspect — wraps the docker volume ls, docker stats, docker inspect calls used by cmd_status (lines 395-542).
   • AIDC_MANAGED_PATHS and the compose template generation in cmd_init should also become runtime-aware so an apple runtime writes its own container config instead of compose.yaml.

3. Scope an initial "apple" milestone narrowly. Start by supporting just aidc init + aidc up + aidc shell/exec (a single container, /workspace mount, code mounted read-only) on the Apple runtime, and prove the two highest-value aidc guarantees first: (a) transcript sync back to host /insights, and (b) the baked-in security scanners (semgrep/gitleaks/trufflehog + per-toolchain linters). Those are the invariants aidc exists for; the rest (multi-service compose, stats UI, volume labels) can be explicitly documented as unsupported in the first cut.

4. Verify Apple runtime capabilities before committing to a design. Read apple/container's current README/releases and container run CLI to confirm which of these it supports today: read-only host mounts, named volumes/persistence, exec at runtime, port publishing, and resource/stats reporting. Anything missing becomes a documented limitation and a cmd_status-side note rather than a silent failure.

5. Keep host-side bits Mac-specific-compatible. aidc is nominally macOS-only, but the VM-isolation backend already branches Darwin→lima / Linux→firecracker (lib/aidc.sh:~970). Where an "apple" runtime only exists on Apple Silicon, gate the selection on uname + arch and fall back cleanly to docker.

PR status

No PR opened. This is a meaningful architecture addition (new runtime backend + abstraction layer) explicitly deferred behind pending merges, and requires decisions about scope and Apple-runtime capability validation — not a quick, low-risk change. Guidance only, as requested by the issue.

Verification

To be run when implementation begins: bash -n lib/aidc.sh for syntax; smoke-test aidc init + aidc up + aidc shell under the apple runtime on the branch; verify transcript-sync to /insights on container exit; run the security scanners inside the container; and confirm aidc status degrades gracefully (no crash) when runtime stats are unavailable. For the Docker path, run the same flow under AIDC_CONTAINER_RUNTIME=docker to confirm zero regression.