Core image: measure the candidate bases

[qcentic-adm]

Part of #6

Question

What do the candidate base images for the Core container actually scan at, and how does each get Node 24 + git without curl … nodesource | bash?

The Core cannot be distroless — it spawns PTY sessions, so it needs a shell, git, a Node runtime for the agent CLIs, and enough of a userland to be a machine you do work on. Today it is ubuntu:24.04 + apt-get install build-essential python3 unzip zip jq ripgrep vim-tiny + a piped NodeSource install, which is where the "1k+ vulnerabilities on steps 6 and 7" and the "13 on the base" come from.

Produce, for each candidate, a measured baseline rather than an opinion:

• debian:13-slim / debian:12-slim
• ubuntu:24.04 and ubuntu:24.04 minimal/chiseled
• cgr.dev/chainguard/wolfi-base (and what the free :latest-only tier means for pinning)
• Anything else that credibly clears the bar

For each, report: CVE count by severity from the same scanner the user is using; whether a shell and a package manager are present; how Node 24 arrives (distro package / official nodejs.org tarball / apk); how git arrives; approximate final image size with git + Node 24 installed; and licensing or registry-access constraints.

Also settle the sub-question that keeps the count honest: which of the current apt packages does a Core actually need at runtime? build-essential, python3, vim-tiny, zip and unzip are in there for the dev fixture's convenience, not because the daemon requires them — separate what the daemon needs, what the agent CLIs need, and what nobody needs.

Do not pick the base — that is the next ticket. Deliver the evidence it will be picked on.

[qcentic-dev]

Measured baseline for the Core base image

Everything below is something I built and scanned today. Numbers, method, and Dockerfiles are all here so #8 can argue with them and #10 can share a scanner with them. No base is picked — that is #8.

The harness that produced every number is committed at docs/research/core-base-measure/ (one line per image in images.tsv; ./build.sh && ./scan-all.sh reproduces the lot). The licensing / registry / archive-version half, which cannot be settled by building anything, is at docs/research/core-base-image-constraints.md with a primary source per claim.

Scanner and method — read before quoting any number

Scanner	Trivy 0.73.0
Vulnerability DB	schema v2, UpdatedAt 2026-08-03T07:52:05Z (downloaded 2026-08-03T12:47:54Z)
Command	trivy image --scanners vuln --format json --input <image>.tar
Unfixed CVEs	included — Trivy's default. Tables report total and fixable
Builder	podman 4.9.3 rootless, linux/arm64
Size	podman image inspect --format '{{.Size}}' — uncompressed on disk, not registry download size

Arch cross-check. Every bare base re-scanned on linux/amd64 via trivy image --platform linux/amd64. Counts identical to arm64 (debian:13-slim 169, debian:12-slim 160, ubuntu:24.04 42, alpine:3.22 0, wolfi-base 0). The arm64 numbers transfer to x64.

Two things that will mislead anyone quoting these numbers

1. Count distinct CVEs, not findings. Trivy emits one finding per binary package, so one CVE in a source package that ships five binaries counts five times. UBI's Node 24 RPM is the clean demonstration: 105 findings, but only 21 distinct CVEs, each counted against nodejs, nodejs-libs, nodejs-docs, nodejs-full-i18n and npm. Both columns are below; distinct is the honest one, and every "fixable" column below is also on the distinct basis.

2. CVE counts are not comparable across distro families. They read out each vendor's security tracker, not the code. debian:13-slim ships newer curl and perl than ubuntu:24.04 and scans far worse:

package	debian:13-slim	findings	ubuntu:24.04	findings
curl	8.14.1-2+deb13u4	17	8.5.0-2ubuntu10.11	0
perl	5.40.1-6	15	5.38.2-3.2ubuntu0.3	0
git	1:2.47.3-0+deb13u1	3	1:2.43.0-1ubuntu7.3	1

Trivy's Status field says the same thing. On debian:13-slim + git + Node 24: 283 affected + 17 fix_deferred, 0 fixable. On ubuntu:24.04 + git + Node 24: 17 affected + 26 fixed. On ubi9-minimal: 175 affected + 15 will_not_fix + 7 under_investigation + 1 end_of_life. Choosing Ubuntu over Debian on the raw total buys a smaller number; it does not obviously buy less risk.

---

Table 1 — bare bases, nothing added

base	size	findings	distinct	C/H/M/L/U (distinct)	fixable	shell	pkg mgr	libc
debian:13-slim	103 MB	169	70	4/8/23/31/4	0	sh + bash	apt	glibc
debian:12-slim	100 MB	160	77	5/8/24/38/2	0	sh + bash	apt	glibc
ubuntu:24.04	103 MB	42	21	0/0/16/5/0	15	sh + bash	apt	glibc
cgr.dev/chainguard/wolfi-base:latest	15 MB	0	0	—	0	sh only — no bash	apk	glibc
alpine:3.22	9 MB	0	0	—	0	sh (busybox)	apk	musl
ubi9/ubi-minimal:latest	112 MB	143	102	0/5/53/44/0	0	sh + bash	microdnf	glibc
node:24-trixie-slim	255 MB	181	82	5/12/28/33/4	12	sh + bash	apt	glibc
node:24-bookworm-slim	252 MB	172	89	6/12/29/40/2	12	sh + bash	apt	glibc
node:24-alpine	164 MB	12	12	1/4/5/2/0	12	sh only	apk	musl
cgr.dev/chainguard/node:latest-dev	842 MB	0	0	—	0	sh + bash	apk	glibc
ubuntu/chiselled-jre:8-22.04_edge	102 MB	0	0	—	0	none at all	none	glibc

On "ubuntu:24.04 minimal". There is no separate minimal tag to compare against — measured, the Docker official ubuntu:24.04 image is already the stripped rootfs: 92 installed packages, and neither the ubuntu-minimal nor ubuntu-standard metapackage is present. Table 1's ubuntu:24.04 row is the minimal one.

On "chiselled". I measured a real one rather than arguing it away. ubuntu/chiselled-jre scans at 0 and is 102 MB — and podman run … /bin/sh fails with executable file /bin/sh not found in $PATH. It has no shell and no package manager, which is the same posture #6 already settled is fine for the Panel and fatal for a Core. There is also nothing to adopt even if that were acceptable: chiselled images are built app-specifically with chisel cut onto FROM scratch, the only chiselled repo in Canonical's namespace is that JRE one, and while a nodejs chisel slice does exist for 24.04 it carves noble's archive and therefore yields Node 18.19.1.

Table 2 — the comparable layer: base + git + Node 24 + curl + CA certs

curl and ca-certificates are in the layer because all four vendor agent-CLI installers need them (measured below) — a Core without curl cannot install its own agents.

base	how Node 24 arrives	Node	git	size	findings	distinct	C/H/M/L/U (distinct)	fixable
debian:13-slim	nodejs.org tarball, sha256-verified	24.18.1	2.47.3	409 MB	312	119	5/15/43/52/4	12
debian:12-slim	nodejs.org tarball	24.18.1	2.39.5	398 MB	348	158	6/24/60/66/2	12
ubuntu:24.04	nodejs.org tarball	24.18.1	2.43.0	396 MB	55	33	1/4/21/7/0	25
wolfi-base:latest	apk add nodejs-24	24.18.1	2.55.0	200 MB	0	0	—	0
alpine:3.22	apk add nodejs → 22.23.2, not 24	22.23.2	2.49.1	97 MB	0	0	—	0
ubi9/ubi-minimal	nodejs.org tarball	24.18.1	2.52.0	373 MB	210	143	1/9/83/50/0	12
ubi9/ubi-minimal	microdnf module enable nodejs:24	24.18.0	2.52.0	339 MB	294	144	0/8/86/50/0	0
node:24-trixie-slim	preinstalled	24.18.1	2.47.3	365 MB	312	119	5/15/43/52/4	12
node:24-bookworm-slim	preinstalled	24.18.1	2.39.5	353 MB	348	158	6/24/60/66/2	12
node:24-alpine	preinstalled	24.18.1	2.54.0	180 MB	12	12	1/4/5/2/0	12
chainguard/node:latest-dev †	preinstalled — but it is Node 26.5.1	26.5.1	2.55.0	842 MB	0	0	—	0

† This row is the bare base repeated, not a separate build: chainguard/node:latest-dev already ships git 2.55.0 and a Node, so the layer would add nothing. It is in Table 2 only so the comparison is complete — and the Node it ships is 26.5.1, which never satisfies "Node 24" at all.

How Node 24 arrives is nearly a non-choice, and it barely moves the number. No stable Debian or Ubuntu release has Node 24 in its archive (trixie has 20.19.2, bookworm 18.20.4, noble 18.19.1 — and noble's is in universe, not main; no -backports suite carries nodejs at all). Only Wolfi (nodejs-24, 24.18.1), UBI 9 AppStream (module stream nodejs:24, 24.18.0, no subscription needed) and Alpine 3.23+ have it. Everywhere else Node 24 is the nodejs.org tarball — which the repo already knows how to verify: scripts/lib/harness-tarball.mjs checks it against the release's own SHASUMS256.txt. Nothing here needs curl … nodesource | bash.

The two UBI rows show the delivery method does not change the risk. Tarball route = 143 distinct; RPM route = 144. The findings differ (210 vs 294) purely because the RPM route splits the same 21 Node CVEs across 5 binary packages. Seven CVE IDs appear in both routes; the tarball route reports them against undici / tar / brace-expansion, the RPM route against npm. Same code, different label.

---

Where the CVEs actually are — and the provenance for "1k+" and "13"

I rebuilt deploy/dev/core.Dockerfile verbatim (minus the three COPYs needing a build context, which add no packages) and scanned it, then isolated each package group on top of the plain ubuntu:24.04 + git + Node 24 layer.

image	size	findings	distinct	C/H/M/L/U (distinct)	fixable
ubuntu:24.04 + git + Node 24	396 MB	55	33	1/4/21/7/0	25
… + build-essential	656 MB	1316	1238	2/58/1066/112/0	18
… + the six the ticket names: python3 unzip zip jq ripgrep vim-tiny	448 MB	65	38	1/4/26/7/0	25
… + those six and less (today's list minus build-essential)	448 MB	65	38	1/4/26/7/0	25
deploy/dev/core.Dockerfile as it stands today	751 MB	1340	1248	2/58/1074/114/0	18

(I measured the six the ticket names and today's seven separately, because today's Dockerfile also installs less, which the ticket doesn't list. less costs nothing — the two rows are identical — so the "+5 distinct" price below is the same either way.)

Top OS packages by finding count in today's image:

package	findings
linux-libc-dev	1200
binutils and its 7 sibling packages	63
jq + libjq1	10
patch	3
everything else combined	52
total OS findings	1328

"1k+ on steps 6 and 7" reproduces — 1340 findings / 1248 distinct — but it is not a base-image problem. 1200 of the 1328 OS findings are one package, linux-libc-dev, pulled in transitively by build-essential (build-essential → libc6-dev → linux-libc-dev, confirmed with apt-cache depends in the image). That package is 1015 files of which 1008 are under /usr/include — kernel headers, no executable code. The CVEs attributed to it are Linux kernel CVEs, and the kernel a Core runs is the host's, not the image's. Removing build-essential alone takes the image from 1248 to 38 distinct on an unchanged ubuntu:24.04 base. Changing the base cannot touch that 1200; dropping one apt package eliminates it.

"13 on the base" does not reproduce. ubuntu:24.04 scans at 42 findings / 21 distinct (0 CRITICAL, 0 HIGH, 15 fixable) on Trivy 0.73.0 with today's DB, on both arm64 and amd64. 13 is plausibly a different scanner — Docker Scout suppresses unfixed by default, and Grype maps severities differently — or an older DB. Whatever produced it, it is not this scanner, and it should not be carried forward without one.

---

Three gates that are not CVE counts

1. musl cannot host a Core. scripts/lib/harness-tarball.mjs bundles the official nodejs.org tarball (BUNDLED_NODE_VERSION = 24.15.0) into every Harness release and bin/actana execs it directly; better-sqlite3 and node-pty are copied from the glibc build host and never cross-compiled. Running that exact runtime in each base:

base	libc	bundled node --version
debian:13-slim	glibc	v24.15.0 ✅
wolfi-base	glibc	v24.15.0 ✅
ubi9-minimal	glibc	v24.15.0 ✅
alpine:3.22	musl	not found, exit 127 ❌
node:24-alpine	musl	not found, exit 127 ❌

Exit 127 is the missing ELF interpreter. This is consistent with nodejs.org publishing zero musl artifacts for v24.18.1 and Node's own BUILDING.md listing musl as Experimental against glibc's Tier 1. Alpine and node:24-alpine are out unless the Harness ships a musl build and musl-built native modules — a far bigger change than picking a base. Alpine 3.23 does have Node 24 in its archive, but that does not help: the gate is libc, not the Node version.

2. wolfi-base has no bash, and three of four vendor installers are bash scripts. Measured on wolfi-base + git + Node 24:

bash: MISSING
--- claude:   sh: bash: not found
--- opencode: sh: bash: not found
--- cursor:   sh: bash: not found
--- codex:    added 2 packages in 18s      (npm, so it works)

Fixed by apk add bash, but it has to be an explicit line — and a Core whose job is spawning interactive shells wants bash regardless.

3. Chainguard's free tier has no pinnable tag — on the anonymous path. Measured anonymously against cgr.dev:

tag	result
chainguard/wolfi-base:latest	pullable (its full anonymous tag list is exactly ["latest"])
chainguard/node:latest-dev	pullable — but Node 26.5.1
chainguard/node:24-dev	denied
chainguard/node:24.18-dev	denied

Chainguard's docs say Free Containers are "limited to the latest build … always tagged as latest and latest-dev", rebuilt nightly — which matches what I measured. One caveat #8 should resolve before relying on this: Chainguard's pricing page describes its free plan as "5 images of your choice, including previous versions", which is a different claim from the docs, and the support article that would reconcile the two returned 403. What I verified is the anonymous path. Whether registering an account unlocks version-pinned tags for free is unconfirmed. Digest pinning works today regardless, but there is no published retention guarantee, and pinning forfeits the nightly rebuilds that produce the 0 in the first place.

---

Which apt packages does a Core actually need?

Measured, not reasoned. I installed all four agent CLIs on debian:13-slim + git + Node 24 + curl + ca-certificates — an image with none of build-essential, python3, unzip, zip, jq, ripgrep, vim-tiny:

agent CLI	vendor install command	result	actually needs	ships
Claude Code 2.1.220	curl -fsSL https://claude.ai/install.sh | bash	✅ installs, --version runs	curl, bash	one 272 MB native binary — no Node at all
Codex 0.146.0	npm install -g @openai/codex@latest	✅	Node + npm	prebuilt binary; no node-gyp, no compiler
Cursor CLI 2026.07.23	curl https://cursor.com/install -fsS | bash	✅	curl, bash	its own rg, and its own node_modules incl. a prebuilt better-sqlite3
OpenCode 1.18.11	curl -fsSL https://opencode.ai/install | bash	✅	curl, bash	native binary

Nothing needed unzip; no install path invoked node-gyp, python3 or a compiler.

The daemon's own external-process surface, from source: shell-env.ts (the operator's login shell), actana-service.ts (systemctl --user, loginctl), pty-manager.ts (lsof, degrading to an empty result when absent). The daemon never spawns git — grepping for a git invocation across packages/harness/src, packages/panel/src/server and packages/shared/src returns nothing. And it never needs a system Node: the tarball brings its own.

So, the split the ticket asked for:

Daemon needs — none of the seven. glibc, a login shell, a systemd user session (systemctl --user, loginctl enable-linger), optionally lsof. Note lsof is not in today's apt list, so the port-conflict probe in pty-manager.ts is silently a no-op in the dev Core right now.

Agent CLIs need — none of the seven either. Their union is bash, curl, ca-certificates, and Node 24 + npm (for Codex alone). git is not needed to install any of them.

Nobody needs, of the seven:

package	daemon	any agent CLI	notes
build-essential	no	no	+1205 distinct CVEs, +260 MB. Nothing measured invoked a compiler
python3	no	no	no installer touched it
unzip	no	no	all four installers handle their own archives
zip	no	no	nothing references it
jq	no	no	+10 findings; the daemon parses JSON in Node
ripgrep	no	no — Cursor ships its own rg	see caveat
vim-tiny	no	no	git log / git diff work with no pager and no editor (measured)

The honest caveat. What I measured is "not required to install or start the daemon or any agent CLI". That is not "no user will ever want them". A Core is, per #6, a machine you do work on: an agent told to npm install a package with a native addon wants a compiler, a Python repo wants python3, an operator shelled in wants an editor (git commit with no -m needs one). Whether the image pre-installs that toolchain or lets the operator apt install it on a running Core is a call for #8. What the scan settles is the price: build-essential is ~96% of today's CVE number; the other six together are +5 distinct.

One thing I could not verify: whether Claude Code's internal search degrades without a system ripgrep. Its 272 MB single-file binary contains no separate rg, strings found no ripgrep marker, and --version extracts nothing to disk — but --version does not exercise search and I could not run an authenticated session. Treat "Claude Code does not need ripgrep" as unverified. Cursor shipping its own rg is verified.

For scale: what a Core actually weighs

Both layers with all four agent CLIs installed:

image	size	findings	distinct
wolfi-base + git + Node 24 + bash + 4 agent CLIs	1347 MB	1	1
debian:13-slim + git + Node 24 + 4 agent CLIs	1555 MB	313	120

The agent CLIs are ~1.15 GB on either base and add ~1 finding. Whatever #8 picks, a Core is a 1.3–1.6 GB image; the base-plus-toolchain layer is 15–26% of it and the agent CLIs are the rest. The spread between the best and worst base here is ~210 MB on a 1.4 GB image.

---

For #10: the Panel's two runtime bases, same scanner

#10 asks for a before/after "so the 74 has a number to be compared against". That is a different image from everything above, but it should be measured with the same scanner and DB or the delta means nothing. Here are its two candidate runtime bases under this run's exact scanner — this is the base contribution only, not the built Panel:

image	size	findings	distinct	C/H/M/L/U (distinct)	fixable	shell
node:24.15.0-bookworm-slim (today's Panel runtime stage)	250 MB	190	107	8/16/42/39/2	30	sh + bash
gcr.io/distroless/nodejs24-debian12:latest	156 MB	38	35	1/5/10/19/0	21	none
gcr.io/distroless/nodejs24-debian12:nonroot	156 MB	38	35	1/5/10/19/0	21	none

Base-level delta: 107 → 35 distinct, −94 MB. :latest and :nonroot are identical in CVE and size terms; they differ only in the default USER, so the :nonroot choice #6 lists as unsettled costs nothing on this axis. #10 still needs to measure the built Panel at both ends — the app's own node_modules are not in these numbers.

---

Dockerfiles

All of these are committed under docs/research/core-base-measure/ctx/.

Debian/Ubuntu layer, built with BASE=debian:13-slim, debian:12-slim, ubuntu:24.04:

ARG BASE
FROM ${BASE}
ARG NODE_VERSION=24.18.1
ARG NODE_ARCH=arm64
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update \
 && apt-get install -y --no-install-recommends git ca-certificates curl xz-utils \
 && rm -rf /var/lib/apt/lists/*
# Node 24 from the official nodejs.org tarball, checksum-verified against the
# release's own SHASUMS256.txt. No third-party apt repo, no `curl | bash`.
RUN set -eux; \
    d="node-v${NODE_VERSION}-linux-${NODE_ARCH}"; \
    cd /tmp; \
    curl -fsSLO "https://nodejs.org/dist/v${NODE_VERSION}/${d}.tar.xz"; \
    curl -fsSLO "https://nodejs.org/dist/v${NODE_VERSION}/SHASUMS256.txt"; \
    grep " ${d}.tar.xz\$" SHASUMS256.txt | sha256sum -c -; \
    tar -xJf "${d}.tar.xz" -C /usr/local --strip-components=1 --no-same-owner \
        --exclude=CHANGELOG.md --exclude=LICENSE --exclude=README.md; \
    rm -rf /tmp/*; \
    node --version; npm --version; git --version

Wolfi:

FROM cgr.dev/chainguard/wolfi-base:latest
USER root
RUN apk add --no-cache nodejs-24 npm git ca-certificates curl \
 && node --version && npm --version && git --version
# NOTE for #8: wolfi-base ships no bash, and three of the four vendor agent-CLI
# installers are bash scripts. A real Core layer needs `bash` added here.

Alpine (measured for completeness; apk add nodejs on 3.22 gives 22.23.2, and musl fails the runtime gate above):

FROM alpine:3.22
RUN apk add --no-cache nodejs npm git ca-certificates curl \
 && node --version && npm --version && git --version

UBI 9 minimal, Node 24 from UBI's own AppStream — no subscription, no tarball:

FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
RUN microdnf module enable -y nodejs:24 \
 && microdnf install -y nodejs npm git-core ca-certificates \
 && microdnf clean all \
 && node --version && npm --version && git --version

UBI 9 minimal, tarball route (the row that compares like-for-like with Debian/Ubuntu):

FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
ARG NODE_VERSION=24.18.1
ARG NODE_ARCH=arm64
RUN microdnf install -y git-core ca-certificates tar xz shadow-utils && microdnf clean all
RUN set -eux; \
    d="node-v${NODE_VERSION}-linux-${NODE_ARCH}"; \
    cd /tmp; \
    curl -fsSLO "https://nodejs.org/dist/v${NODE_VERSION}/${d}.tar.xz"; \
    curl -fsSLO "https://nodejs.org/dist/v${NODE_VERSION}/SHASUMS256.txt"; \
    grep " ${d}.tar.xz\$" SHASUMS256.txt | sha256sum -c -; \
    tar -xJf "${d}.tar.xz" -C /usr/local --strip-components=1 --no-same-owner \
        --exclude=CHANGELOG.md --exclude=LICENSE --exclude=README.md; \
    rm -rf /tmp/*; \
    node --version; npm --version; git --version

Official node:24-* images only need git added:

ARG BASE                       # node:24-trixie-slim | node:24-bookworm-slim | node:24-alpine
FROM ${BASE}
RUN if command -v apk >/dev/null 2>&1; then \
      apk add --no-cache git ca-certificates curl; \
    else \
      export DEBIAN_FRONTEND=noninteractive; \
      apt-get update && apt-get install -y --no-install-recommends git ca-certificates curl \
      && rm -rf /var/lib/apt/lists/*; \
    fi \
 && node --version && npm --version && git --version

Isolation probes, on top of the built ubuntu:24.04 layer:

FROM measure/ubuntu24
RUN apt-get update && apt-get install -y --no-install-recommends build-essential \
 && rm -rf /var/lib/apt/lists/*

FROM measure/ubuntu24
RUN apt-get update && apt-get install -y --no-install-recommends \
      python3 unzip zip jq ripgrep vim-tiny \
 && rm -rf /var/lib/apt/lists/*

Full Core, all four agent CLIs, on top of any of the layers above:

ARG BASE
FROM ${BASE}
USER root
ENV HOME=/root
RUN (command -v bash >/dev/null 2>&1) || (command -v apk >/dev/null 2>&1 && apk add --no-cache bash)
RUN curl -fsSL https://claude.ai/install.sh | bash \
 && curl -fsSL https://opencode.ai/install | bash \
 && curl https://cursor.com/install -fsS | bash \
 && npm install -g @openai/codex@latest

---

What I did not measure

• Whether the whole Harness tarball boots on each base — only that its bundled Node runtime execs, which is the gate that actually differs between bases.
• Agent CLI behaviour beyond --version; none was authenticated.
• Compressed registry download size, as opposed to on-disk size.
• Anything on linux/amd64 beyond the bare bases. The layers were built arm64-only; the bare-base cross-check found no arch delta, so I expect none, but I did not build them.
• The built Panel image at either end — that is Panel on distroless: prove it works and measure the delta #10's job; I measured only its two runtime bases so the scanner matches.

[qcentic-dev]

Closed — outcome recorded on #6. Decisions locked in ADR 0016 D5–D9 (evidence); the work is #37, #38.

The measurement stands as the evidence base for the whole Core-image decision, and #8 picked ubuntu:24.04 off it without needing a second round.

Two of its findings outlived the base pick and are written into the ADR rather than left in a scan table:

• The reframe. build-essential → libc6-dev → linux-libc-dev is 1200 of 1328 OS findings — kernel headers, 1008 of 1015 files under /usr/include, no executable code. Dropping that one package takes an unchanged ubuntu:24.04 build from 1248 to 38. Anyone summarising this as "the base fixed the CVE count" is wrong, and D6 says so in those words.
• The gates that are not CVE counts. musl exits 127 on the bundled glibc Node — that eliminated Alpine and node:24-alpine on a fact, not a preference. wolfi-base ships no bash while three of four vendor installers are bash scripts.

The one thing you flagged as unverified — whether Claude Code's search degrades without a system ripgrep — is neutralised rather than resolved: ripgrep ships, for ~1 distinct finding. Recorded as still-open in the ADR so nobody mistakes it for tested.

docs/research/core-base-measure/ and core-base-image-constraints.md both survive the docs restructure (#59) — they are the only reproducible record of how the base was chosen.