1. Likely yes. Railpack 0.36.0 changed when .dockerignore applies ; patterns now hit "when the local source is first loaded into BuildKit" (PR #373). Before, everything loaded and got filtered later, so the COPY still found the file. Now docs is gone before COPY runs. Fits your timeline. Haven't read the diff, so it's a lead not a confirmed cause.

2. My opinion: yes, or at least the two should agree. Planner reads the git tree, context obeys .dockerignore ; any COPY for an excluded path is guaranteed to fail. Harmless before 0.36, load-bearing now.

3. Docs say it shouldn't. Node workspace detection reads the workspaces field or pnpm-workspace.yaml, not a filesystem glob ; and your root declares only packages/*. So something else pulled that file in. Worth checking if your lockfile still references docs/marketing, or if it came from the install-step file copy. That's one bug vs two.

4. Don't think it's a knob. Each railpack binary bakes its builder tag in at compile time from the pinned mise version in core/mise/version.txt, so mise-2026.8.4 is a label for which railpack built it, not a separate axis. Pinning the builder means pinning railpack.

Instead of untracking , negation should work, railpack passes patterns to BuildKit and BuildKit handles !:

docs/**

!docs/marketing/package.json

Keeps it in git, keeps the rest of docs out.

Confirmed on our side — and I could settle your point 3 with evidence. It's one bug, not two.

Root package.json declares only packages/*, and root package-lock.json has zero references to that path. So workspace detection and the lockfile are both clean. It's the install-step copy you suspected: SupportingInstallFiles() globs repo-wide, separate from workspace resolution, and picks up a non-workspace package.json. After #373 the context has already dropped that dir, so the COPY can't checksum it.

Your point 4 is a useful correction — the builder tag being baked in from core/mise/version.txt means the mise version was a red herring in my original report.

On the negation suggestion: worth noting the glob also matches lockfiles. Two of our builds failed on different files — one on package.json, one on package-lock.json — so it needs both negated, not just the first. Our current rule is also bare docs rather than docs/**, and the two forms resolve negation differently.

We went with untracking the two manifests instead, which is verified green in production. Negation is the better option for anyone who needs them version-controlled.

Thanks — that reframes it usefully. I'd been treating #373 as a regression; if the prior behaviour was the bug then there's nothing to wait out, and pinning below 0.36.0 is actively the wrong move since it just re-enables it. Good to know #707 covers the planner side.

For anyone finding this later: we fixed it by untracking the two non-workspace manifests, which turns out to be aligned with the corrected behaviour rather than a workaround. If you need them tracked, .dockerignore negation works — but note the install-file glob matches lockfiles too, so negate both package.json and package-lock.json, not just the first.