Clean Room: A Refactor That Answered a Legal Question, Not an Architectural One

 · 2 min read

Code born inside the core engine rarely has to stay there forever. This specific move started with a question about legal boundaries. We needed a hard line between our own original logic and knowledge acquired from an external format. One of Flude’s renderer families—the one built to precisely mirror an outside documentation tool—sat dangerously close to that line.

Two Risks a Refactor-in-Place Misses

Tangled data streams

Carving out a module inside the same repository does practically nothing here. A shared commit history leaves the biggest vulnerabilities wide open.

Authorship is the first major headache. Code mirroring an external format gets thoroughly mixed up with the rest of the engine. Proving independent development after the fact becomes incredibly messy. You build a credible evidence trail through total separation—a dedicated repository and a fresh commit history.

The logic itself carries its own risks. The way code bends to match an external format is highly specific knowledge. Tightly weaving it into the engine blurs the line between a general tool and client-specific insights.

A physical split cleanly shuts down both risks. A simple folder rename just papers over the cracks.

How It Played Out in Practice

Clean Room plugin

We pulled the renderer family into a standalone git repository. It plugs into the main project as a private submodule. The engine interacts with it through the standard renderer interface. The class simply lives in a new zip code. The rest of the system barely noticed the change.

Standing up the new repository brought plenty of friction. The test harness relies heavily on the engine’s core models. We had to check out the main engine inside the new CI pipeline. Shared relative paths completely broke down. Nailing the dependency paths took a few frustrating attempts. We temporarily dropped the markdownlint gate before restoring it to maintain project standards. Turning the CI pipeline green took some serious trial and error.

The quality checks moved right alongside the code. The entire infrastructure for comparing results against reference documents shifted over. Leaving it behind would have made it impossible to spot rendering drift.

The Result

Core and Module separated

The main engine feels much leaner now. The core and the remaining renderer family can evolve at their own natural pace. The extracted code operates completely independently. It boasts its own CI and a bulletproof line of provenance. We no longer have to worry about proving its origins retroactively.