Gaps

Not yet generally available. Blast Radius ships in Shipmoor CLI 0.9.0, which is still in the release process. This page describes shipped behavior on the release candidate; the command is not on the stable channel yet.

What gaps mode is for

--gaps reports what was never governed. It has two distinct jobs depending on where your repo is:

• On a bare repo, it is the first-run product: here is what nothing covers.
• On a governed repo, it is the authoring demand signal: the graph telling you where it is thin.

This is the deliberate other half of the no-lexical-inference law. Because Blast Radius refuses to guess a link, a repo that has adopted neither authoring nor Claim Check has a sparse graph. Gaps mode is what turns that sparseness from a silent weakness into a visible, workable list.

shipmoor blast --gaps

Gaps  4 lists · honest buckets disclosed

  changed code with no links      1
    - config/limits.py
  obligations with no check       1
    - AC-01
  obligations with no realizes    0
  documented surface unmatched    not checked (this list arrives with docs verification)

  not checkable: 0

The four lists

Changed code with no links

Code you touched in this change that no link pins. It is scoped to the change surface, not the whole repo, so it answers “did I just edit something ungoverned?” rather than “how much of this codebase is ungoverned?” — use --all if you want the second question.

Matching is exact path equality. A path that merely resembles a governed one is ungoverned, for the same reason nothing else in the feature does fuzzy matching.

Shipmoor’s own control artifacts — the link store, the config, the report, the ledger — are classed as such and never appear here.

Obligations with no check

Obligations that no tagged check claimed through the tag join. The obligation exists and is approved; nothing mechanically verifies it.

This is the list Claim Check’s authoring loop is designed to work down: its fix packet hands your agent the exact check to write, tagged so the join binds it on the next round.

Obligations with no realizes

Obligations in the frozen acceptance set that no realizes entry names. The promise exists; nothing records which code keeps it.

Working this list down is the highest-value authoring you can do, because a realizes link is what makes the code side of the graph classify at all. Every entry here is an obligation that can never produce a suspect, no matter what changes.

Documented surface unmatched

Fed by docs verification, which is not yet shipped. It is disclosed as not checked rather than rendered as an empty list.

That distinction matters more than it looks. An empty list claims the run looked and found nothing. This list has not looked. Printing 0 here would be the single most misleading number the feature could produce, because a reader would reasonably conclude their documentation is fully governed.

Every list prints its count, including zero

An omitted list and an empty one are indistinguishable to a reader. A fully governed repo therefore renders zeros rather than silence, so you can tell the difference between “nothing to report” and “this was not part of the report.”

The fourth list is the one exception, and it is disclosed rather than counted, for the reason above.

The not-checkable bucket

Anything the run could not resolve lands in the disclosed not checkable bucket with its reason, never a silent skip.

A link naming an obligation id the acceptance set does not contain, or a path that is not in the repo, cannot be classified — but it also must not vanish. It keeps its committed place and shows up here carrying unknown item id, absent path, or missing acceptance file. See Troubleshooting.

Not-checkable entries never affect the exit code under any threshold.

Working the list down

There is no scoring and no target percentage, deliberately. A coverage number invites gaming and tells you nothing about whether the links you have are the ones that matter.

A practical order:

1. Obligations with no realizes, for the obligations you actually care about. This is what makes the code side classify.
2. Obligations with no check — or let Claim Check’s authoring loop work these down as a by-product of gating changes.
3. Changed code with no links, treated as a prompt rather than a backlog: when you touch ungoverned code and it turns out to matter, that is the cheapest moment to record the link, because the relationship is in your head right now.

Not every path needs governing. A repo where every file is linked to an obligation is a repo that has written a lot of links nobody will maintain. The list is a prompt, not a quota.

Next

• The link model — how to author the links that close these gaps.
• Configuration and exit semantics — gaps never affect the exit code, and why.