Review a worker’s build context before builder access

Review the input boundary before reviewing the image

An AI preprocessing worker needs public application code and a small public readme. Its project directory also contains an ordinary private review note. The proposed image does not copy that note into its final filesystem, so a reviewer marks the build safe to share with an external builder. That conclusion answers the wrong release question: the builder’s eligible input set needs its own admission decision.

This worksheet selects one owned local directory context, one independently trusted Dockerfile and one already authorized builder recipient. It supplies no build command or configuration. The existing build-input retention guide still owns persistent image environment versus temporary instruction inputs. Here the decision happens earlier: which ordinary files belong in the reviewed input set?

Separate context eligibility from image membership

Docker’s context documentation defines the context as files a build can access; local files are loaded when needed. Matching root .dockerignore entries are removed before sending. A Dockerfile-specific ignore file takes precedence over the root file when both exist. Within the applicable rules, the last matching line decides inclusion, including negated exceptions. Dockerfile and .dockerignore remain sent when excluded, but cannot then be copied into the image by ADD, COPY or bind mounts.

The exact requested documentation route automatically redirected to Docker’s current context page during reading. No displayed numeric builder version or documentation update established an installed environment. Those are documentation facts, not observations about our worker. Actual transfer, supported filtering and retained copies remain unexamined.

Do not turn the available-input question into a claim that every unused file necessarily crossed a network. Equally, an image inventory showing only approved runtime files cannot settle which input scope the builder was permitted to access. Keep those two evidence fields separate.

Bind the selected recipe to its actual input policy

Invent review C-A for a directory containing public app-A, public readme-A and private note-A. These are editorial labels, not filenames, file contents or a context created on disk. Builder B-A is authorized for the two public inputs and separately admitted build metadata; it is not authorized for note-A.

Record the selected context identity, selected Dockerfile identity, complete ordinary-file inventory and independently established effective filtering interpretation together. A root policy approved yesterday is insufficient when today’s selected recipe has additional policy evidence that has not been reviewed. Do not guess whether two policy files are merged, replaced or otherwise combined beyond the supported effective interpretation.

The original operating rule is simple: compare the complete resulting ordinary-input set with B-A’s current allowed data set. Every eligible item needs a purpose and permission. An unexplained item holds the plan. A missing required public input also holds it; silently broadening the context to make a build work is a changed proposal.

Use an input-admission sheet with a useful positive

The conditional positive admits the fixed C-A input plan when its established ordinary-input set contains the two approved public inputs, excludes note-A, and separately admits the metadata. It authorizes neither execution nor distribution of a resulting image. This is an original review policy, not a Docker enforcement feature.

Actual directory completeness, special-file handling, supported builder/frontend, filter interpretation, recipient ownership, input stability and current rights are unimplemented or unknown here. Any unresolved prerequisite blocks a real positive. A reviewer should name the missing field rather than convert “not inspected” into “not present.”

Walk eight inert context decisions

All eight cards are PROPOSED_UNRUN. They compare proposed evidence; no context, Dockerfile, ignore file or builder request was constructed.

Preserve the limits of the decision

This profile excludes remote, Git, archive and additional named contexts, symlinks, complex wildcard interpretation and custom filter implementations. It provides no pattern parser, automatic exclusion generator, build recipe or fallback. It does not reopen the earlier runtime bind-mount review; producer-input eligibility and runtime mount authority remain different questions.

If an earlier build may have exposed private input, follow the owner’s authorized incident process. A corrected future plan does not recall copies. No Docker, image, registry, secret, runtime, model or candidate API was exercised. Only documentation and editorial work occurred. Boundary remains prelaunch with planned request-path checks; its synthetic policy evidence does not implement or verify this build-context admission sheet.