Gantry's Gated Demo Edition
A try-before-you-buy build that checks in, refuses offline when exhausted, and unlocks to unlimited.
Gantry ships to paying users as a signed binary. There was no way to hand someone a limited trial that would enforce its own limits — a copy of the paid build runs forever, and nothing about it knows who received it or how many builds they have left. This job built a separate demo edition to close that gap.
Every Linux binary carries a small fixed slot that can be personalized for one recipient. The demo build reads its own stamped identity, checks in with a server before it starts a build, and reports a build as used only after it finishes cleanly. When the allowance is spent, or the machine is offline, or the binary was never personalized, the demo refuses with a plain message instead of running. A demo user who buys in runs the unlock verb with a code, which redeems a signed token that from then on disables the check-in entirely — offline, for as long as the token is valid.
The hard constraint throughout was that none of this may touch the ordinary paid build: no HTTP client, no signature-verification dependency, no gate. All of it is compiled in only for the demo edition.
Build
The decomposition's first move was a compile-time boundary that keeps every demo-only dependency out of the paid build. The gate was then built as a pure decision layer before being wired into a live build — and it was that decision core whose review forced the run's one re-plan.
The load-bearing boundary is the cargo feature that separates the demo edition from the paid one. Drawing it first — before any gate, client, or unlock code existed — meant the constraint that mattered most, a default build that pulls in no HTTP client and no signature crypto, could be asserted by a test on its own, and every later demo-only piece had a defined place to live behind that feature.
Inside the gate-and-unlock milestone the planner split the gate policy from the code that runs it. The decision core — accept a cached unlimited token without touching the network, otherwise require a stamped identity, call the server, and classify allowed, exhausted, offline, and unpersonalized outcomes — was built as pure functions testable with injected identity, cache state, and transport results, with no live build lifecycle in existence yet. Only the following sprint wired those decisions into real build execution, where they become visible to a user and must skip management verbs, attaches to a running job, and resumes that are already complete.
That decision core is where the difficulty concentrated. It is the one sprint whose review forced a re-plan of the milestone's remaining work — the boundary redrawn once the exact shape of the start-and-completion decisions was known. The wiring sprint that followed took a second execute pass after its review, and its brief carries the correction that drove it: completion must report usage from the identity carried by the allowed gate result, not from a separately preserved stamp. Nearly every sprint in the run failed the gate once and was repaired in place, which fits a feature that spans compile-time features, cryptography, a network client, and the build lifecycle — each a distinct way to be wrong, each caught where it lived.
Feature
Gantry had only a paid edition and no way to distribute a self-limiting trial. The job left a demo edition behind a cargo feature — a runtime gate, a blocking HTTP client, a token cache, and an unlock verb — and most of that machinery still stands at HEAD.
Before this job Gantry existed only as the paid edition, and a trial would have meant shipping a build that trusted the user to stop. The demo edition replaces that with enforcement the binary carries itself.
At today's HEAD the runtime is still three modules compiled only under the demo cargo feature: `demo_gate.rs` holds the start and completion decisions, `demo_http.rs` the minimal blocking JSON client that honours the demo API environment variable, and `demo_license.rs` the cached-token verification. The unlock verb is still registered in the command parser, the feature still pulls its cryptography and HTTP dependencies in only when enabled, the placeholder unlock key still lives under `config/`, and the local release builder still emits demo tarballs beside the paid artifacts.
The identity foundation has drifted since. The standalone binary personalization-stamp module the first milestone introduced is no longer present at HEAD, and the integration-test files added under `tests/` are gone with it; the surviving gate takes its demo identity as an input rather than reading a stamp module of its own. About half the lines the job introduced remain. What endured is the gate itself — the paid build stayed clean, and the demo path a user actually follows, check then build then report, or unlock and go offline, is the part still standing.