How to publish the proof without publishing the private work
A working repository contains more than the finished product. It accumulates design arguments, abandoned directions, issue history, private project names, and the useful mess that helps a real build move forward. That history can be excellent evidence of engineering judgment. It can also be exactly what should not become public.
The easy portfolio move is to tidy the current files and change the repository visibility. That only cleans the latest snapshot. Git still carries the earlier versions, and issue history may carry another trail entirely. Once published, that history has been copied, indexed, and made somebody else’s cache problem. The visibility switch is small; its blast radius is not.
DaftPlate takes a different route. Its private working repository stays private. A purpose-built publication script creates the public portfolio repository as a one-way, curated export with fresh history.
The export starts with an allowlist. Base templates, project profiles, standards, tests, selected scripts, and a fixed documentation set are named explicitly. A new top-level directory is private by default because the publisher does not know it exists. That is safer than trying to list every sensitive path after the fact: an allowlist fails closed, while a forgotten denylist entry fails publicly.
There is still a denylist behind it. Private design records, the original decision files, internal publication data, and known private project names are blocked even if somebody later widens the allowlist. The exported content is then scanned for those names, and secret scanning runs before publication. This is defense in depth for a job that is usually treated as copying a folder.
The awkward part is that the most interesting proof often lives in the material that cannot travel. The design history explains why an external templating engine was rejected. The decision records show why standards remain canonical, why skills install at user level, and why publication is an export rather than a visibility change. Removing all of that would make the public repository safe and strangely unconvincing.
DaftPlate solves that with two public-safe documents written for the export: a development history and a sanitized decision log. They preserve the reasoning, tradeoffs, phase metrics, and revisit conditions without copying the private context that originally surrounded them. The public reader gets the engineering argument, not the unrelated project names that happened to be in the room.
Fresh history does not have to mean fake history. The exporter lays down phase-labelled commits with meaningful messages and its own release tags. That shows the progression from the first two profiles and 82 tests through the context-efficiency work, eight profiles, 279 tests, documentation, and publication. It preserves the shape of the development process without transplanting the working repository’s unsafe Git objects.
For a prospective client or employer, that distinction matters. A polished snapshot proves that something exists. Tests, decisions, phased history, and threat-aware publication show how it was built and how risk was handled. The portfolio artifact can be inspected without asking anyone to trust that the private parts were probably removed.
The model has a tradeoff: the public repository is an artifact, not the source of truth. A fix made directly to the export does not flow back into private development, and a new release must pass through the publisher again. That is less convenient than treating one repository as both workshop and showroom. It is also a much clearer security boundary.
Portfolio publishing is still a production operation. It moves information across a trust boundary and creates a durable public record. Giving that step an allowlist, content scans, secret checks, and an explicit history model is not paranoia. It is the same engineering habit the portfolio is meant to prove.