adr: multiple sandbox images

[rsindall]

Summary

• Short human ADR asking for multiple named sandbox images in one QM deploy (e.g. commercial vs dev tool/skill packs).
• Covers register/pin images, scope-or-room selection, and per-image publish.

Test plan

• Maintainer review of adrs/multi-sandbox-images.txt only (no code)

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[rajpratham1]

The proposal identifies a compelling product direction—supporting multiple sandbox images within a single QM deployment—but as written it is a product request rather than a complete Architecture Decision Record (ADR). It lacks the architectural detail needed to evaluate feasibility and long-term impact.

What is good
Addresses a realistic operational need:
Different workloads (engineering, commercial, research, etc.) often require different toolchains.
Multiple smaller images could reduce image size and avoid shipping unnecessary tools to every sandbox.
Provides concrete high-level requirements:
Named sandbox images.
Image-specific tool/skill packs.
Image selection per scope/room/agent.
Independent image publishing.
Explains why the current alternatives are undesirable:
One large "mega-image".
Multiple QM deployments.
Blocking issues

1. Missing architectural decision

An ADR should describe:

Context
Decision
Alternatives
Consequences

This document mainly lists desired capabilities without stating the proposed architecture.

For example, it doesn't answer:

Is the image selected when the sandbox is created?
Can it change during a run?
Is selection static or policy-driven?
Is image metadata stored in deployment configuration, database, or elsewhere?
2. Configuration model is undefined

The proposal mentions:

scopes / rooms / agents can be pinned

but leaves the selection hierarchy completely unspecified.

Important questions include:

What happens if both an agent and a scope specify different images?
What is the precedence order?
What is the default when nothing is configured?
Can users override the configured image?

Without this, reviewers cannot evaluate the design.

3. Operational implications are missing

Supporting multiple images introduces deployment and maintenance questions that aren't discussed:

How are images versioned?
How are upgrades coordinated?
How is compatibility with skills ensured?
How are unused images garbage-collected?
Does each image require its own publishing pipeline?

These trade-offs should be acknowledged.

4. Security and isolation considerations

The proposal notes that separate images help isolate toolchains, but it does not clarify whether:

this is intended as a security boundary,
merely an operational optimization,
or both.

If different images contain privileged tools, the ADR should explain how image selection is controlled and who is authorized to choose an image.