Dev Log: deleting code and breaking the build on purpose

A developer building Munchausen v1.0, a mock-data generator for .NET, started by deleting the existing prototype and deliberately breaking the build to test new guardrails. The project uses PublicApiAnalyzers to enforce a deliberate public API contract, and a canary class was used to verify the analyzer catches unintended public symbols. The initial milestone (M0) established the project scaffold with zero public API, while future milestones will tackle determinism and cycle detection.

Day one of building Munchausen v1.0 started with deleting the existing implementation and deliberately breaking its replacement. Munchausen is a mock-data generator for .NET that infers realistic values from your types. Before writing v1.0, I spent time designing the API and architecture, then captured the result in a single design document. At the end, I divided the implementation into stages: M0 for the repository scaffold, M1 for determinism, and later milestones for metadata, inference, compilation, and runtime behavior. The plan gives me a route through the project. Implementation is where I find out whether those ideas actually hold together, and M0 was the first test. The repo already had a prototype from years ago, an early Lie / ModelGenerator / ValuesGenerator trio and a .travis.yml pinned to a dotnet-1.0 preview. My first instinct was to keep it nearby. Some of it might be useful, and deleting code always feels more dramatic than leaving it alone. Reading it changed my mind. The prototype reflected an earlier idea of the library, and keeping its types invited me to preserve decisions I had already reconsidered. Removing it gave me a clean place to test the new design without negotiating with the old one. The history is still there if I need it. One idea from the design was that the public API should be a deliberate contract, not whatever happens to escape from the assembly. I added PublicApiAnalyzers , which tracks every public symbol in two text files. At M0 those files contain no API entries. The public surface starts at zero and grows only when I consciously add to it. Configuring the analyzer was easy. Trusting it was different. I could see that the package was installed and the build was green, but that did not prove it would catch the mistake I cared about. So I added a mistake on purpose. I wrote a throwaway Canary class with one public property and no XML comments, then committed it. The build went red with exactly the errors I hoped to see: RS0016 this public symbol isn't declared in the API files for the type, its getter, and even its implicit constructor, plus CS1591 for the missing comments. One little class tripped both wires at once. Then I removed the canary commit, rebuilt, and watched the build go green again. I expected a quick configuration check. Instead, I learned that a green build only shows the current code passes. A deliberate failure proves the build can protect a boundary I care about. When later milestones introduce public API, I know accidental additions cannot quietly slip through. The rest of M0 turned design choices into places where future work can happen: net8.0 , nullable reference types, warnings treated as errors, required XML comments, and a Directory.Build.props that keeps those choices consistent. I added CI and created six projects for the package, unit tests, acceptance tests, determinism tests, benchmarks, and shared test models. The shared models include Car , Owner , Customer / Order / Item , a positional record, an init-only type, and Employee whose Manager is another Employee . That last model is a question waiting for a later milestone: what happens when generation encounters a cycle? I do not need the answer yet, but putting the model in place now means I cannot conveniently forget the problem when recursion and cycle detection arrive. Zero features. Zero public API. A green build, a CI pipeline, and a guardrail I've personally watched fail and recover. More importantly, I finished M0 with a better understanding of the design than I had when it existed only on paper. Starting from zero is not empty progress when the boundaries themselves are part of what you are building. M1 takes on the determinism core. Munchausen promises that the same seed produces the same data forever, across machines, OSes, and .NET versions. .NET doesn't guarantee that System.Random will preserve its algorithm across versions, so I'm building an owned PRNG xoshiro256 seeded by SplitMix64 and validating it against published reference vectors. If my numbers don't match the ones the algorithm's authors published, my code is wrong, full stop. That's the kind of unambiguous test I love. More soon.