---
title: "One Missing minPkg Label and a Menu Entry With No Service Level"
canonical: https://dxdev.com/everyday-ai/page-that-showed-up-too-late/
datePublished: 2026-04-12
---
One menu entry for a higher-tier page was supposed to show an upgrade prompt, and it showed nothing at all. No warning, no broken screen. It was one menu item that never asked anyone to upgrade.

Every page on the site carried a label called `minPkg`, which told the menu the lowest service level to advertise for that page. We added the label with a guarded line, one that quietly skips a page if it does not exist yet. One page was created later, by a separate step of the site setup. Its line found nothing, did nothing, and left that entry with no service level.

## What the menu was supposed to do

The pages needed to show different menu choices depending on what level of service an organization had. If a page belonged to a higher level, the menu should not invite everyone in as if the page were already available. It should show the next step instead.

That sounds straightforward. It also sounds like the beginning of a much bigger project.

## The plan that would have doubled the list

Our first answer was a familiar one: make a catalog of every possible feature, build a separate place to check them, and keep a table that says which organizations get which things. On paper, that was three new pieces to make before the actual menu question was even answered.

That was the wrong fit. It would have created a second list of page rules next to the list the site already used, and every future change would mean remembering to update both. Anyone who has kept a grocery list on the refrigerator and another one in a phone knows how that ends. One list says milk. The other does not. Someone comes home without milk.

So we stopped before building it and looked at the menu itself.

## The answer was already on every page

The site already had the `minPkg` label. The name is not important. Its job was. It told the menu the lowest service level a page should advertise, and if an organization did not have that level, the menu showed an upgrade prompt instead of a working link.

There is a technical name for this kind of choice: **feature gating**. It means showing or holding back part of a service based on what someone has paid for. The menu already knew how to do the visible part of that job, so we did not need a new catalog to teach it again.

The change became small. For each affected page, we added one guarded line that put the proper service level on that page's existing label. Instead of building a new map of organizations and permissions, the page and its menu entry kept the same answer in the same place.

That mattered because a page and the menu item that points to it are really one promise. If the page is supposed to say "This belongs to the next level," the menu ought to say the same thing. Keeping those answers together is less exciting than building a new system, but it leaves fewer places for an old rule to hide.

## The line that did nothing

Most of the page labels worked the first time. One did not.

The reason was order. Most pages existed when the labels were added. This one was created afterward by a separate part of the site setup, so we had tried to put the label on a page before the page existed. The guarded line was polite about it. It saw nothing, did nothing, and moved on. When the site finally created the page, the chance to add its menu rule had passed.

That cost us time and patience, because the code looked like it should work. A single line is easy to trust when its neighbors all work. The saving grace was that this was still an experimental branch that nobody was using yet, so we found the miss before it became a confusing menu for anyone else.

The fix was undramatic. We added the same label after the step that created the late-arriving page. First assemble the pages. Then attach the labels that describe them. Then check the page that comes in late instead of assuming it followed the crowd.

## What the menu cannot lock

A menu can point someone away from a page, but it cannot be the only lock on something that must not be used without the right service level. Some actions do not match one menu page neatly. Those need their own checks, even when the visible menu and the behind-the-scenes rule rest on the same business decision.

This work did not become a finished, live way to decide access. It remained a prototype. The useful result was smaller: we found an existing piece of the site that already solved the menu problem, and we caught the one page that arrived too late for the first pass.

The `minPkg` label was already the one place that knew the lowest service level a page should advertise, and the whole change came down to putting the right value there, once, on each page. The label only works if every page has it, and we got that guarantee by attaching the labels after the step that creates the last page. If your service levels are tied to features, find out where that level is recorded and whether every page, including the ones created late in setup, actually carries it.