RFC 0004 had ruled `build` out because it would need "writable rootfs
snapshots per step and `pull` for FROM". `pull` arrived in 0.3.0, and
per-step snapshots turned out to be what a build *cache* needs, not what
a build needs: one writable tree over the base is enough.

RFC 0006 decides the build model, cuts the one version-dependent
interface, and records what was measured on a Debian trixie rootfs with
bwrap 0.11.1 and a single-uid map: a writable root bind works
unprivileged, CapEff is 0 so the sandbox can mount nothing itself, apt
needs APT::Sandbox::User=root, fakeroot alone does not fix dpkg's chown
but fakeroot plus FAKEROOTDONTTRYCHOWN=1 does, and overlay stacks with
its upper directory already being a layer diff. It also separates the
three things "no layers" has been made to mean, so the README's formula
stops carrying more than it supports.

Implemented: stage 1 on the copy backend. `werkdock build [-f
Dockerfile] -t IMAGE CONTEXT` with FROM, RUN, COPY and the metadata
instructions ApplyChange already knew, committing through the staging
and locking mechanics import has used since 0.11.0. The overlay backend
is deliberately not implemented — only the interface is cut so it fits.

Measured end to end: a 143 MB debian:trixie base with fakeroot, a
Dockerfile with `apt-get install -y nginx jq` in it, 6.8 s for the whole
build; nginx-common configures, dpkg-query in the result reports
"install ok installed", and `werkdock run --rm` executes its CMD.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@@ -12,0 +12,4 @@
+## 0.12.0 (2026-10-17)
+
+Theme: the verb that was "not planned". `werkdock build` builds an image from
+a Dockerfile on the target itself — no second machine, no upload. RFC 0004

@@ -12,0 +24,4 @@
+  `FROM` resolves through the store and pulls on a miss, one writable work
+  tree is created over the base, the steps run against it, and the result is
+  an ordinary flat werkdock image — `images`, `inspect`, `rmi`, `run` and
+  `--mount type=image` apply to it unchanged. Staging is the mechanism

@@ -12,0 +32,4 @@
+  metadata instructions `import -c` already knew — `ENTRYPOINT`, `CMD`,
+  `ENV`, `WORKDIR`, `USER`, `VOLUME`, `LABEL` — through the same
+  `store.ApplyChange`, so a Dockerfile line and a `--change` line are parsed
+  by one piece of code. Line continuations with `\`, comments and blank

@@ -12,0 +35,4 @@
+  by one piece of code. Line continuations with `\`, comments and blank
+  lines are handled; `RUN` takes the shell and the exec form.
+- **Both uid levers are werkdock's business, not the Dockerfile's**, so the
+  same Dockerfile still builds under docker. Measured on a Debian trixie

@@ -12,0 +45,4 @@
+  calls the real syscall and reports its `EINVAL`. `fakeroot` plus
+  `FAKEROOTDONTTRYCHOWN=1` does, so `RUN` steps are wrapped in `fakeroot`
+  when the base image has one, and `build` says so up front when it has not.
+- **Two backends behind one interface, of which one is implemented.** The

@@ -12,0 +47,4 @@
+  when the base image has one, and `build` says so up front when it has not.
+- **Two backends behind one interface, of which one is implemented.** The
+  copy backend (a real full copy of the base, root bound read-write) works on
+  the bwrap 0.8 the webspaces run today. The overlay backend is designed, not

@@ -12,0 +50,4 @@
+  the bwrap 0.8 the webspaces run today. The overlay backend is designed, not
+  written: `--overlay-src` stacks unprivileged on bwrap 0.11 and its upper
+  directory is already a layer diff — measured, including deletions appearing
+  as character devices 0:0, which is what OCI writes as `.wh.NAME`. It is

@@ -12,0 +52,4 @@
+  directory is already a layer diff — measured, including deletions appearing
+  as character devices 0:0, which is what OCI writes as `.wh.NAME`. It is
+  what the per-step cache waits for; without a union mount a cached step
+  would cost a whole tree copy. The copy backend stays as the fallback.

@@ -12,0 +59,4 @@
+### Changed
+
+- **`engine.RunSpec` has `WritableRoot`**: the rootfs is bound with `--bind`
+  instead of `--ro-bind`. Only build steps set it. A sandbox with a writable

@@ -12,0 +62,4 @@
+  instead of `--ro-bind`. Only build steps set it. A sandbox with a writable
+  root also gets **no implicit tmpfs** over `/tmp`, `/root` and `/run` — it
+  does not need one, and with one, what a `RUN` step writes there would be
+  gone in the next step while docker keeps it in the image. Runs are

@@ -0,0 +311,4 @@
+	return nil
+}
+
+func (b *builder) removeAptFragment(rootfs string) error {

@@ -99,0 +130,4 @@
+	r.pass("a writable root bind works (werkdock build uses the %s backend)", BuildBackend)
+}
+
+// BuildBackend is the name of the build backend this host gets. It is

@@ -0,0 +235,4 @@
+// runCommand is the RUN instruction's command: a JSON array is the
+// exec form and runs as given, anything else is the shell form, which
+// docker runs through /bin/sh -c (SHELL is stage 2).
+func runCommand(args string) ([]string, error) {

@@ -0,0 +251,4 @@
+// file exists in practically every base image, so the bind leaves no
+// mountpoint behind in the finished tree — which it would, since bwrap
+// creates a missing one in the writable root and it stays (measured).
+func resolvConfMount() []engine.Mount {

@@ -97,0 +105,4 @@
+// the host is touched. The backend named here is what build will pick;
+// an overlay backend, once bwrap on the target is new enough and not
+// installed setuid, is reported in its place.
+func buildChecks(r *Report, run Runner) {

@@ -8,3 +8,3 @@
 
 - An *image* is a rootfs archive; an *instance* is an unpacked, writable directory tree and corresponds to a docker container.
-- `import` takes a plain rootfs archive, as `docker import` does; `load` takes a `docker save` archive or an OCI image layout, flattens the layers (whiteouts honored, paths resolved inside the rootfs as in a chroot) and keeps the OCI config — so a Dockerfile-built image lands with its ENTRYPOINT, CMD, ENV, and WORKDIR ([RFC 0004](docs/rfcs/0004-docker-compatible-image-creation.md)). `load -i … --name` still routes a rootfs archive to `import`, for callers that predate it. `pull` fetches an image from a registry the same way, with the registry side (auth, manifest lists, blobs) delegated to the [crane](https://github.com/google/go-containerregistry) binary — a single unprivileged executable found in `PATH`, beside `werkdock`, or at `WERKDOCK_CRANE`; it reads `~/.docker/config.json` (`DOCKER_CONFIG`) for credentials as docker does. `images` lists one reference per line by default (what a script matches against) and takes docker's `--format`, with `--format table` giving docker's columns; `rmi IMAGE...` removes images.
+- `import` takes a plain rootfs archive, as `docker import` does; `load` takes a `docker save` archive or an OCI image layout, flattens the layers (whiteouts honored, paths resolved inside the rootfs as in a chroot) and keeps the OCI config — so a Dockerfile-built image lands with its ENTRYPOINT, CMD, ENV, and WORKDIR ([RFC 0004](docs/rfcs/0004-docker-compatible-image-creation.md)). `load -i … --name` still routes a rootfs archive to `import`, for callers that predate it. `pull` fetches an image from a registry the same way, with the registry side (auth, manifest lists, blobs) delegated to the [crane](https://github.com/google/go-containerregistry) binary — a single unprivileged executable found in `PATH`, beside `werkdock`, or at `WERKDOCK_CRANE`; it reads `~/.docker/config.json` (`DOCKER_CONFIG`) for credentials as docker does. `images` lists one reference per line by default (what a script matches against) and takes docker's `--format`, with `--format table` giving docker's columns; `rmi IMAGE...` removes images.- `build` builds an image from a Dockerfile on this host — `werkdock build [-f Dockerfile] -t IMAGE CONTEXT`, docker's flags ([RFC 0006](docs/rfcs/0006-dockerfile-builds.md)). `FROM` resolves through the store and pulls on a miss, one writable work tree is created over the base, the steps run against it, and the result is an ordinary flat image. Stage 1 is `FROM`, `RUN`, `COPY` plus the metadata instructions `import -c` already knew; `ARG`, `SHELL`, `ADD` and multi-stage builds name the stage of RFC 0006 that brings them, and `EXPOSE`, `HEALTHCHECK`, `STOPSIGNAL`, `ONBUILD` and BuildKit's `RUN --mount` are refused with the reason at parse time. Werkdock sets the two levers an unprivileged single-uid sandbox needs itself, so the Dockerfile stays portable: `APT::Sandbox::User root` for the duration of the build, and `fakeroot` with `FAKEROOTDONTTRYCHOWN=1` around every `RUN` step — which means **the base image needs `fakeroot` installed**, or a package whose postinst chowns fails. There is **no build cache**: every build starts at `FROM`, because caching a step without a union mount would cost a whole tree copy. That changes with the overlay backend, after the webspaces move to Debian 13 (bwrap 0.11).

@@ -0,0 +83,4 @@
+Two details the implementation forced, both worth writing down because they change behaviour:
+
+- **A build step gets no implicit tmpfs.** Every `run` mounts a tmpfs over `/tmp`, `/root` and `/run`, because a read-only root has no writable place otherwise (RFC 0005). A build step's root *is* writable, so it needs none — and must not have them, or what a `RUN` step writes to `/tmp` or `/root` would be gone in the next step while docker keeps it in the image. `~/.npmrc` written in one step and read in the next is a common enough idiom that the alternative is a bug factory. So the implicit tmpfs mounts are tied to the read-only root.
+- **A build binds as little as possible.** With a writable root bwrap creates a missing bind mountpoint itself, and the mountpoint stays in the tree (measured). The only bind a `RUN` step gets is the host's `/etc/resolv.conf`, read-only, as `run` does — and only where the tree already has the file, so nothing is left behind; a step over a base without one, e.g. `FROM scratch`, runs without the host's resolver. Anything else a build step might want mounted would have to earn a `build` flag first.

@@ -8,6 +8,8 @@ Semantics — docker-compatible as far as the filesystem-only contract allows (s
 
 - An *image* is a rootfs archive; an *instance* is an unpacked, writable directory tree and corresponds to a docker container.
 - `import` takes a plain rootfs archive, as `docker import` does; `load` takes a `docker save` archive or an OCI image layout, flattens the layers (whiteouts honored, paths resolved inside the rootfs as in a chroot) and keeps the OCI config — so a Dockerfile-built image lands with its ENTRYPOINT, CMD, ENV, and WORKDIR ([RFC 0004](docs/rfcs/0004-docker-compatible-image-creation.md)). `load -i … --name` still routes a rootfs archive to `import`, for callers that predate it. `pull` fetches an image from a registry the same way, with the registry side (auth, manifest lists, blobs) delegated to the [crane](https://github.com/google/go-containerregistry) binary — a single unprivileged executable found in `PATH`, beside `werkdock`, or at `WERKDOCK_CRANE`; it reads `~/.docker/config.json` (`DOCKER_CONFIG`) for credentials as docker does. `images` lists one reference per line by default (what a script matches against) and takes docker's `--format`, with `--format table` giving docker's columns; `rmi IMAGE...` removes images.
+- `build` builds an image from a Dockerfile on this host — `werkdock build [-f Dockerfile] -t IMAGE CONTEXT`, docker's flags ([RFC 0006](docs/rfcs/0006-dockerfile-builds.md)). `FROM` resolves through the store and pulls on a miss, one writable work tree is created over the base, the steps run against it, and the result is an ordinary flat image. Stage 1 is `FROM`, `RUN`, `COPY` plus the metadata instructions `import -c` already knew; `ARG`, `SHELL`, `ADD` and multi-stage builds name the stage of RFC 0006 that brings them, and `EXPOSE`, `HEALTHCHECK`, `STOPSIGNAL`, `ONBUILD` and BuildKit's `RUN --mount` are refused with the reason at parse time. Werkdock sets the two levers an unprivileged single-uid sandbox needs itself, so the Dockerfile stays portable: `APT::Sandbox::User root` for the duration of the build, and `fakeroot` with `FAKEROOTDONTTRYCHOWN=1` around every `RUN` step — which means **the base image needs `fakeroot` installed**, or a package whose postinst chowns fails. There is **no build cache**: every build starts at `FROM`, because caching a step without a union mount would cost a whole tree copy. That changes with the overlay backend, after the webspaces move to Debian 13 (bwrap 0.11).

@@ -0,0 +175,4 @@
+// apply executes one instruction. n counts the instructions after
+// FROM, which is what a backend keys its steps by.
+func (b *builder) apply(tree Tree, n int, instruction Instruction) error {
+	if !instruction.changesTree() {

@@ -0,0 +141,4 @@
+		if !within(context, candidate) {
+			return nil, fmt.Errorf("COPY source %s leaves the build context", source)
+		}
+		matches, err := filepath.Glob(candidate)

@@ -0,0 +123,4 @@
+// `docker build` pulls a base it does not have. Without a registry
+// client the error names the two verbs that would put the image there.
+func resolveBase(st store.Store) func(string) (string, store.ImageMeta, error) {
+	return func(reference string) (string, store.ImageMeta, error) {

@@ -18,3 +18,3 @@
 // bumps it here and titles its CHANGELOG section with it; there is no
 // separate release step.
-var Version = "0.12.1"
+var Version = "0.13.0"