A broken scaffold is better than an almost-correct one
The most dangerous scaffolding failure is not a crash. A crash is honest. It stops the work, points at a problem, and gives nobody a repository they might mistake for finished.
The dangerous failure is a project that looks ready.
DaftPlate builds a repository from two sources: a shared base layer and one project profile. The base provides the files every project needs. The profile adds the material specific to a web app, CLI, userscript, Google Apps Script project, or one of the other supported shapes.
Early in the layer model, a profile could try to write a path the base had already written. The composition code would skip the collision. The scaffold could still pass its general repository checks because all of the expected files existed; one of them was simply the wrong file.
That is worse than a red build. It creates an ambiguity with excellent posture. The repository has a README, CI, docs, and instructions. Only later does someone discover that the profile-specific version never arrived, usually while debugging behavior far away from the scaffolder.
DaftPlate now makes any undeclared base/profile collision a hard failure. The scaffold exits nonzero, names the conflicting path, and points to the explicit override mechanism. It does not choose a winner, emit a warning into a busy terminal, or continue with whichever file happened to land first.
Profiles have two clear lanes. files/ is additive: its contents must be new.
files-override/ is for an intentional replacement of a base file, and the
profile documents why that replacement is needed. The template verifier also
rejects an override that does not correspond to a real base file. Declaring an
override is not a magic word for bypassing the model; it is a specific claim
the tooling can check.
The distinction matters because a generated repository is a promise. It says the project begins from a known standard and that its differences are intentional. If composition quietly negotiates between competing files, that promise is already broken before the first product commit.
Failing early is also cheaper. The template author sees the error at the point where the two sources meet, with the exact path and the supported fix. There is no need for a future developer to infer a template collision from a malformed CI job or the wrong agent instructions. The defect stays close to its cause.
There is a small cost in ceremony. A legitimate replacement needs its own location and justification, and a newly shared base file may reveal a profile collision that previously went unnoticed. That friction is useful. Replacing a shared standard should feel different from adding a profile-specific file.
A broken scaffold asks for attention once. An almost-correct scaffold asks for trust until the day it fails somewhere more expensive. I would rather have the honest error.