Thanks, I'd missed those readme updates. They're also pushed now. One question before we move on: what other kinds of wrapper should we be thinking about for the future? I wondered about one for some subset of back-end and API type services but I'm not sure if those have sufficient generic properties to be handled with the wrapper pattern.
Good question to ask now, because the answer clarifies what the wrapper abstraction is really for. My take: a wrapper is viable whenever an ecosystem gives you two things by convention — a way to turn source into a runnable artifact, and a runtime contract (how it starts, what port it listens on, how config gets in). The buildpack ecosystems (Heroku, CNB, Nixpacks) are a useful map here, since what they support is essentially the empirical answer to "what's generic enough."
On backend/API services specifically: I think they're more tractable than they first appear, because the objection that usually kills the idea — "backends have databases, migrations, queues, sidecars" — is answered by your architecture. The wrapper only has to containerize one repo; composition is the stack's job, and the stack already does it (including pre_start_command for things like migrations). A 12-factor-style HTTP service has exactly the same runtime shape as a webapp: one process, one port, config via environment. What varies by ecosystem is only the build step and entrypoint discovery:
package.json is a genuine contract — dependencies, engines, and crucially scripts.start. A node-service wrapper is mostly the existing webapp-base with a different start behavior (npm start + PORT env instead of serving build output). Cheap to build, immediately useful.go.mod + go build yields one static binary, and the result is a tiny image. Entrypoint ambiguity (which cmd/?) is the only wrinkle.main:app for uvicorn/gunicorn. Doable, but needs the app to declare one line.The entrypoint problem suggests a small future extension worth keeping in mind: letting the stack.yml container entry pass parameters to the wrapper (e.g. wrapper-config: {start-command: ..., port: ...}). That keeps the app repo pristine — the deployer declares the one ambiguous fact — and it would unlock several ecosystems without inventing per-repo config files.
Two other families that are arguably better candidates than backends:
hugo wrapper would be ~the static-content wrapper plus one build stage.Poor fits, for the record: anything needing system-level native dependencies (that's where buildpack systems sprawl into composition complexity — your escape hatch is "add a Dockerfile," which stack already handles as the ordinary route), and stateful infrastructure like databases, where there's no user source to build and a plain image reference is already the right tool.
If I were sequencing: node-service first (smallest delta, tests the wrapper pattern against the API-service question directly), then a static-site-generator wrapper (probably Hugo or MkDocs, whichever you'd actually use), and let real repos drive the rest — the pattern is cheap enough per-wrapper that speculative ones aren't worth building.
Ok that's a useful summary. Perhaps we can see what comes up in internal use that looks like it merits a new wrapper. That's actually how the static content requirement arose -- we needed to re-deploy a web site onto modern infrastructure from an old wordpress setup.
That's the right filter — demand-driven, exactly how static-content earned its place. Let me capture the thinking so it's on hand when the next candidate shows up:
--- name: future-wrapper-candidates description: Assessment of future wrapper types; new wrappers are added demand-driven from internal use metadata: type: project --- Policy (David, 2026-07-24): new wrappers get built when internal use surfaces a need, not speculatively — static-content itself arose from re-deploying an old WordPress site onto modern infrastructure. Assessment when a candidate appears: a wrapper is viable when the ecosystem gives (a) a conventional build and (b) a runtime contract (start command, port, env config). Composition (DBs, migrations, sidecars) is the stack's job, not the wrapper's — so 12-factor HTTP backends ARE viable. Ranked candidates: `node-service` (package.json scripts.start — smallest delta from webapp-base), static site generators (Hugo/MkDocs — static-content plus a build stage), `go-service` (go.mod → static binary). Python services need a declared entrypoint (no ecosystem convention). Poor fits: native system deps (escape hatch: repo provides a Dockerfile), stateful infra (plain image is right). Likely enabling extension when needed: `wrapper-config` on the stack.yml container entry to pass parameters (start command, port) so the deployer, not the app repo, resolves entrypoint ambiguity. See also [[container-wrapper-schemes]].
File created successfully at: /home/david/.claude/projects/-home-david-projects-bpi-stack/memory/future-wrapper-candidates.md
- [docs live in project, not PRs](docs-live-in-project-not-prs.md) — feature docs go in docs/ as part of the PR; PR descriptions stay short
- [docs live in project, not PRs](docs-live-in-project-not-prs.md) — feature docs go in docs/ as part of the PR; PR descriptions stay short - [future wrapper candidates](future-wrapper-candidates.md) — wrappers added demand-driven; ranked candidates and viability criteria
The file /home/david/.claude/projects/-home-david-projects-bpi-stack/memory/MEMORY.md has been updated successfully. (file state is current in your context — no need to Read it back)
{
"file_path": "/home/david/.claude/projects/-home-david-projects-bpi-stack/memory/MEMORY.md"
}1 - [delete-volumes semantics](delete-volumes-semantics.md) — --delete-volumes removes Docker volume objects only, never underlying data; don't change that 2 - [avoid pinning image versions](avoid-pinning-image-versions.md) — don't pin image tags to fix drift; project has a versioning scheme + lock file for that 3 - [backup test CI heisenbug](backup-test-ci-heisenbug.md) — rare unreproducible SeaweedFS init failure in Backup Test; on recurrence read the dumped s3 logs first 4 - [user handles git operations](user-handles-git-operations.md) — David branches/commits/pushes/PRs himself; leave work in the working tree 5 - [docs live in project, not PRs](docs-live-in-project-not-prs.md) — feature docs go in docs/ as part of the PR; PR descriptions stay short 6 - [future wrapper candidates](future-wrapper-candidates.md) — wrappers added demand-driven; ranked candidates and viability criteria 7
- [future wrapper candidates](future-wrapper-candidates.md) — wrappers added demand-driven; ranked candidates and viability criteria
- [container wrapper schemes](container-wrapper-schemes.md) — wrapper system landscape across the 5 repos (PRs #160–163, complete); remaining: fetch/lock test coverage - [future wrapper candidates](future-wrapper-candidates.md) — wrappers added demand-driven; ranked candidates and viability criteria
The file /home/david/.claude/projects/-home-david-projects-bpi-stack/memory/MEMORY.md has been updated successfully. (file state is current in your context — no need to Read it back)
All noted. Nice arc, from "make the middle route more generic" to a shipped, documented, locked, registry-backed wrapper system in four PRs — and a WordPress rescue as the origin story. When the next internal need surfaces (or you want the fetch/lock test coverage done), I'll have the context ready.
Likewise — a pleasure! This was a model collaboration: clear vision from you, tests as the contract at every step, and clean handoffs on the git side. Everything's shipped and the follow-ups are captured in memory for next time. Enjoy the rest of your day!