Phase 1 made the provisioner able to activate allowlisted extensions
post-ready but kept the bare upstream images. Phase 2 ships the images that
actually carry the extension/module files, and selects them only when a
venture requests features — bare sandboxes stay on the light upstream image
(no heavier pull, honoring the 'existing opters stay bare' decision).
- _PostgresEngine / _RedisEngine gain kitchen_sink_image + image_for(features):
bare (no features) -> the light image; features requested -> the kitchen-sink
image. The provisioner runs engine.image_for(features), not engine.image, so
the bare path is byte-for-byte unchanged. Mongo inherits the base image_for
(returns its image regardless — no activatable features).
- docker/sandbox-pg.Dockerfile: pgvector/pgvector:pg16 (ships vector) + postgis
apt install; contrib (pg_trgm/citext/uuid-ossp) inherited from the official
postgres base. Built at deploy via the sandbox-pg-image compose one-shot
(mirrors the agent-image builders); the provisioner's _ensure_image finds the
local tag and never pulls. Published by release.yml; pulled in registry
compose. The verify step fails loudly if an extension's files are missing.
- _RedisEngine kitchen-sink image: redis/redis-stack-server:latest (headless;
ships search/json/bloom as loadable-but-unloaded modules — no custom build).
- Extended the sandbox image-tag ghost-tag guard (the mongo:8-alpine regression
test) to also cover kitchen_sink_image: skips locally-built roboco-* images,
uses the namespaced Docker Hub endpoint for redis/redis-stack-server.
Image-specific package names / module .so paths are verified at the CEO's NAS
deploy (the spec's NAS smoke); the unit tests with the fake runner remain the
CI bar, and the verify step is the fail-loud safety net for a wrong build.
