What survives a port is the asset

The weather API exists twice in the same repository. The original is TypeScript on NestJS; under java/ sits a Spring Boot port — same version number, mirrored package tree, tests and all — serving the same hand-written openapi.yaml. Duplicating a service across stacks is supposed to be waste. I'd call it a measurement.

Two trees, one contract

The port mirrors the original down to its seams: api, common/http, config, domain, service, upstream/arso, web, with end-to-end tests that mock the upstream the way the TypeScript suite does — WireMock standing where nock stood. What the Java tree does not contain is a second contract or a second set of decisions. Both implementations serve the one committed openapi.yaml at the repo root, and both answer to the same decision records beside it. Porting turned out to mean re-projecting those fixed points onto a second runtime — not re-deriving them, because there was nothing left to derive. The deciding had already happened somewhere the TypeScript couldn't keep it.

What transferred and what didn't

Sort the repo's artifacts by what the port did to them. Transferred untouched: the contract, the decision records, and the shape of the test suite — which behaviors get verified, which upstream failures get simulated. Rewritten entirely: every line of application code. That sorting is the insight. Code is the projection of decisions onto one runtime, so changing the runtime rewrites the projection and leaves the decisions standing. What a port preserves is exactly what was never stack-shaped to begin with.

I won't tell you the port was cheap, because I didn't measure it in hours. What I can enumerate is what it did not require: no new contract, no new decisions, no new ideas about what to test. Everything expensive had already been paid for in stack-independent currency.

The measurement

I argued in Disposable by default that most code an agent produces is meant to be thrown away, and the pushback is always the same: surely the codebase is the asset. The port is the experiment that answers it. Call it the port test: port your system to a second stack — on paper, if not in code — and watch what survives. Whatever transfers unchanged is the asset. Whatever must be rewritten was scaffolding for that asset, however much it cost to write. A codebase that would survive a port only as ideas — contract, decisions, test intent — was always just those ideas wearing one syntax.

The test only measures systems that have artifacts capable of surviving. A service whose behavior lives nowhere but its code has nothing to port except the code, and the test's verdict on it is not kind — though it is useful, because it tells you what to write down next.

The port crossed a runtime boundary and the assets held. There's a boundary I don't think they'd cross: change what the API is about — not the stack under it, the domain in front of it — and even the contract burns; the decisions dissolve into context for a problem that no longer exists. Something presumably carries an engineer across that boundary too. I haven't figured out what to call it, or whether it can live in a repository at all.