Backed by: the manifest, joined against the release feed. Scope: manifest:read.
What it answers
What each module you compose is running, what has been released since, and whether any of it was security-relevant.
Capabilities and versions is where the version comes from, versions and upgrades is what the numbers mean, and pithy upgrade is what moves one.
The record leads with your version
A module’s record opens on what you run: a Version table first, then the gap.
- Current version is read from the running code, through the manifest your browser fetched. There is no file anybody maintains and nothing to keep in step.
- Latest version and Security are rows only when there is a gap to state them about.
- A module with nothing newer still states what it runs. That is the one case where the reader most wants to see the number, and the record used to show only Nothing newer recorded.
The three things somebody opens a record for used to sit in a narrow aside in the margin, offset against the release list beside them. One column, version first.
A capability name is not a package name
A version is only actionable joined against a release feed, and a feed is keyed by package name. controlplane ships inside @pithy-sh/core, so deriving @pithy-sh/<name> from a capability name asks about a package that has never existed — and is told nothing, which reads exactly like up to date, for the most-released package in the feed.
So the manifest carries the package beside the version, as the capability’s own claim about itself, and that is what is read.
- A capability naming a
@pithy-sh/*package: that is the answer. A kit capability shipped after this dashboard was written is recorded correctly with no edit here. - A capability naming anything else: nothing. A third party’s capability called
auththat reports@acme/authhas said it is not ours, and recording it under the package it disowned would be worse than recording it under nothing. - A capability naming none: a closed map of the kit’s own names, which is what a Worker deployed before the field still gets.
What leaves your browser, and what does not
A manifest response never touches our origin. The dashboard mints a single-use token and your browser spends it against your own Worker, so the only party holding a parsed manifest is a browser.
What the browser reports back is the name, the package and the version per capability. Nothing else. A capability descriptor also carries health counts drawn from your own rows and its resolved configuration — those are yours, and they stay in the browser. A test asserts on the serialized request body that neither leaves.
Security is a judgment somebody made at the time
A release carries a semver bump and a note, and neither says whether it matters. A patch closing a token-reuse hole and a patch fixing a log typo are both patch.
So the flag comes from the release itself, written by whoever wrote the change — the note says what changed, and a separate line says what was wrong before. How releases are cut is that convention.
A release from before the convention carries no flag, and the pane says unknown rather than clean. Nothing is backfilled: retroactively deciding whether a two-year-old patch was security-relevant produces a dataset where a wrong no reads as an assurance.
An empty feed says nothing, not “nothing newer”
Before this pane recorded what a project composes, the join ran against an empty table in every deployed environment and every module was badged No releases known — which is worse than silence, because it states there is nothing newer.