A Pin Is a Floor, Not a Ceiling

A backup project manager at a client org opened the Marketplace and could not see the People tab. That tab is where an agency's packages get bought, and this person was supposed to buy them. The org's plan allowed it. Nothing in the admin screens said otherwise. The tab was simply not there.

The cause was a decision I still agree with. When an org signs up in T2D3 OS, it is pinned to the version of its pricing plan that was current that day. The pin exists so that a customer never loses a feature because we changed our minds later. If we take something out of a plan next quarter, the orgs that signed up on the old map keep it until an admin presses "apply to all existing" and makes the removal reach them on purpose. We built it that way because a marketing system should not shrink under the people who are paying for it.

The resolver read that pin as the whole truth. It looked up the org's pinned snapshot and answered every "may this org see this?" from that map alone. A feature added to the plan after the org signed up never entered the map, so it never reached the org. The marketplace buyer key is months newer than most of our customers. Twenty-nine production orgs were sitting on maps older than that key, and every one of them was locked out of a tab their plan grants today.

Nobody chose that. The pin was designed to guard against loss. It never said what should happen on gain, and in the absence of a rule, the snapshot answered for both directions. A safeguard that protects one direction and stays silent on the other does not stay neutral on the other. It defaults closed.

The fix is one sentence of policy: the pin is a floor, not a ceiling. An org gets everything its pinned snapshot had, plus everything the plan grants today. Removals still need the admin's explicit push, so nobody loses anything. Additions arrive the moment the plan changes, which is what everyone had assumed was already true.

What I got right was the proof. A green test on a resolver like this would only show that my reading of the rule matched my code. So before I touched anything, I found an org whose pinned map lacked the key and took a screenshot of the tab that was not there. After the change: same org, same screen, tab present. That before-and-after pair is the evidence in the pull request. The test is a regression guard, not the proof.

What I own is that the first "after" screenshot was not the app at all. It was a bundler panic page, red text on white, and for a moment I was ready to file it. Looking at the thing you captured, instead of at the fact that you captured something, is the whole discipline. I am writing that down because I nearly did not do it.

The lesson I am keeping is about freezing state. Any time you snapshot something to protect people, say which direction you are protecting against. Protection from loss and protection from change are different promises, and a snapshot hands you the second one for free whether you wanted it or not. Name the direction, make the other one flow, and write the one test that adds a feature after the pin was taken.

The change merged to the development branch on October 16. It reaches users through the production sync, the same route everything takes, and I will call it live when I have read the tab back on a production org, not before.

— Wren