modelith deps check compares the content its origin serves against the digest the copy's header records, at the ref that header names. On a branch that works: the branch moves, the content changes, the check reports it.
On a tag it never fires. A copy pinned to v2.1.0 is reported as up to date for as long as v2.1.0 points where it did, which for a well-behaved tag is forever. v2.3.0 can ship and nothing says so.
That is the correct answer to the question the command asks, and it is not the question a user with a pinned copy has. Today the output at least names the ref on every line, so the verdict reads as a statement about the pin rather than about the world, but naming the limit is not the same as fixing it.
Why it was left out
Deciding which tags count as newer means guessing at a versioning scheme. Semver ordering, prerelease handling, projects that tag 2026-07-27 or release-14 or nothing at all. Every one of those is a judgment modelith has no basis to make, and getting it wrong is worse than staying quiet: a tool that tells you v2.10.0 is older than v2.9.0 teaches you to stop reading it.
Recorded as a consequence in ADR-0016.
Shapes worth considering
- Report tags, order nothing.
deps check lists the tags the origin has that are not the pinned one, newest by creation date, and leaves the choice to the user. No version parsing, and the date ordering comes from the API rather than from a guess about the naming scheme.
- Semver when it applies. Attempt a semver parse; if the pinned ref and the candidates all parse, order them and name the newest. If any does not parse, fall back to the shape above. The cost is two behaviors to explain.
- A flag rather than a default.
deps check --releases makes it opt-in, which keeps the common path at one API call per copy. Chasing tags is a second call at minimum, and for a large repository the tag list is not small.
Prerequisites
Whatever the shape, it needs a way to tell a tag from a branch. The header stores a bare ref string and modelith deliberately does not guess from its spelling, so this means asking the origin. That is a real API call and a real design decision about when to spend it.
What would settle it
A user with a pinned copy who missed a release they wanted. The current behavior is a limitation rather than a bug, so the shape should be chosen against a real case rather than in the abstract.
modelith deps checkcompares the content its origin serves against the digest the copy's header records, at the ref that header names. On a branch that works: the branch moves, the content changes, the check reports it.On a tag it never fires. A copy pinned to
v2.1.0is reported as up to date for as long asv2.1.0points where it did, which for a well-behaved tag is forever.v2.3.0can ship and nothing says so.That is the correct answer to the question the command asks, and it is not the question a user with a pinned copy has. Today the output at least names the ref on every line, so the verdict reads as a statement about the pin rather than about the world, but naming the limit is not the same as fixing it.
Why it was left out
Deciding which tags count as newer means guessing at a versioning scheme. Semver ordering, prerelease handling, projects that tag
2026-07-27orrelease-14or nothing at all. Every one of those is a judgment modelith has no basis to make, and getting it wrong is worse than staying quiet: a tool that tells youv2.10.0is older thanv2.9.0teaches you to stop reading it.Recorded as a consequence in ADR-0016.
Shapes worth considering
deps checklists the tags the origin has that are not the pinned one, newest by creation date, and leaves the choice to the user. No version parsing, and the date ordering comes from the API rather than from a guess about the naming scheme.deps check --releasesmakes it opt-in, which keeps the common path at one API call per copy. Chasing tags is a second call at minimum, and for a large repository the tag list is not small.Prerequisites
Whatever the shape, it needs a way to tell a tag from a branch. The header stores a bare ref string and modelith deliberately does not guess from its spelling, so this means asking the origin. That is a real API call and a real design decision about when to spend it.
What would settle it
A user with a pinned copy who missed a release they wanted. The current behavior is a limitation rather than a bug, so the shape should be chosen against a real case rather than in the abstract.