24 files we are not allowed to edit

Twenty-four files in TyreStack’s platform repository are, by design, nobody’s to edit. Not a typo fix, not a tidy rename, not even a well-meaning refactor. They are a scheduling engine and its fixtures, carried in from a colleague’s own repository and frozen there behind a sha-256 hash. Change one byte and the next run of the gate fails before a single feature test runs.

Why freeze code you already have the rights to

TyreStack is one monorepo: an app, a handful of services, and a stack of shared packages underneath them. Ed built the scheduling engine separately, in his own repository, fitting-scheduler: the solver that decides which van goes where, in what order, with closed days, bay capacity and travel time all weighed against each other. Before any talk of importing it, he had already proved it. Run against ten thousand simulated worlds of bookings, cancellations and van breakdowns, scored against an independent oracle, it matched that oracle, as TyreStack’s decision log records the result.

That proof lives in his tests, in his repository. The moment TyreStack’s copy of the engine drifts from his, even by one corrected typo, the proof stops describing what TyreStack actually runs. Nobody would notice straight away. The first sign would be a scheduling decision that looked wrong in front of a real fitter, weeks later, with no way back to which version of the logic produced it.

So the engine was imported unchanged at a specific commit of Ed’s repository and left alone. The decision record is blunt about why: his engine stays unchanged because it is proven equal to his oracle on ten thousand worlds, and editing it would void that. Everything TyreStack needed on top, bays treated as zero-travel lanes, services that need a duration and an equipment match, stock that needs a date filter, was built one layer up, in a separate package, rather than inside the engine itself.

Why not just copy the files and move on

The obvious objection is that this is a lot of ceremony for code one company already has full rights to use. Why not copy the files into the platform once, the way teams have always borrowed code, and let each side maintain its own version from there?

Because copy-paste’s real cost is not the copying. It is the drift nobody notices. Two copies of the same logic, kept by two people under two different sets of pressure, will diverge the first time either side needs a fast fix, and from that point on there is no single file anyone can point to and say this is the one that was proven. The option TyreStack actually weighed was narrower than a fresh copy: editing the already-imported engine directly, inside the platform, to bend it toward TyreStack’s own ideas sooner.

A shared package carries its own risk, and it is a real one: a bad re-import could change scheduling for every tenant on the platform in the same afternoon, because the app and every service build directly on these packages. That risk is why the import is never automatic. A person runs it at a named commit, a scan has to pass first, and the hash manifest only changes when someone deliberately rewrites it, never to make a failure go away. The manifest’s diff then sits in the pull request like any other change, so a bad bump is visible before it merges, not discovered on a live schedule board.

What is frozen and what is TyreStack’s own

The re-import that set the current pin did not bring across one tidy package. It brought across four, each a different size.

147 files in all. The first two packages hold 44 files between them; the 24 in their source folders (the rest are tests) are pinned byte for byte and checked forever. The other 123, chiefly the store and the UI component, are allowed to differ from Ed’s repository on purpose, and every difference is written down rather than left for someone to stumble on: the package name in every import line, each workspace’s own build and test config, one small migration TyreStack added for its own message-sent marker, two renamed comments, and a handful of files that exist only on TyreStack’s side.

TyreStack got one of those differences wrong, in our own log, and fixed it rather than hiding it. The first import had quietly changed the place names in Ed’s demo fixtures. When the later re-import carried that change forward, it broke seventy-one of Ed’s own tests, because his engine, store and UI tests all assert his own fixture places. The fix was to drop TyreStack’s change and take the fixtures back exactly as Ed wrote them. A local edit that looked harmless, sitting inside data rather than logic, turned out to be exactly the kind of drift the whole pinning exercise exists to catch.

The afternoon it got checked

The gate that enforces the pin did not arrive with the import. It followed on 17 October, five days later, and it was proven the hard way: a one-character edit was made to the engine on purpose, to watch the gate turn red and name the changed file, then reverted to watch it turn green again. Only after that did anyone trust it to run unattended on every push.

On 18 October, six days after the 12 October re-import, the whole thing was independently audited rather than taken on trust. The audit found Ed’s repository still sitting at the same commit the pin named, the hash manifest matching it exactly, and the engine and fixture source byte for byte identical to his repository at that commit. Every difference anywhere else in the imported packages was accounted for by the delta already written down. Nothing had been missed.

The one place this cut a corner is worth saying plainly, even though it belongs to an earlier moment than the re-import above. The first time Ed’s engine came into the platform at all, weeks before this pin existed, it arrived through a one-off script rather than the platform’s standard importer, because a solo partner’s proprietary repository did not fit what that importer already knew how to pull from. That was fine once, for one source, with no client signed yet and one engineer’s code to trust. It was logged at the time as something to build properly if a fourth import source ever needed the same one-off treatment. By the re-import that set today’s pin, the importer had learned fitting-scheduler as a source in its own right, so that run went through the ordinary path. That is the honest shape of a decision sized to the stage TyreStack was actually at: right for one partner’s engine before the first customer, and already outgrown a few weeks later.