publish.stale_files

A commit's surface.jadpo_record or changelog list isn't what the package's code gives.

Area 14, Tooling; not declinable; the next step is usually the agent's.

Why Jadpo refuses it

A release shows what its code gives, never what its publisher says. jadpo package check writes surface.jadpo_record and the new version's list in CHANGELOG.md from the code, and they are committed so that a reviewer reads them in the pull request.

jadpo package verify checks a commit as it stands, as the registry does, and writes nothing. A file that disagrees with the code would show a reader something other than what the release does, so it is refused. It usually means the code changed after jadpo package check last ran, or the file was edited by hand.

What it looks like

Postcodes.v2 gained a public type after jadpo package check last ran, and the commit was verified as it stood:

jadpo package verify . --previous ../postcodes-2.0.0

The publishing bar's surface row fails with "doesn't match its code", or its changelog row with "2.1.0's list is out of date" for CHANGELOG.md.

(agent) at the end of the next: line means your coding agent can make the fix itself: nothing is being decided, since both files come from the code.

How to fix it

If the file is out of date, write it again and commit it, then move the tag to that commit if it hasn't been released:

jadpo package checkgit add surface.jadpo_record CHANGELOG.mdgit commit -m "chore: write the surface for 2.1.0"

The surface and the list then match the code, and jadpo package verify passes those rows. The reason you wrote beneath the list stays.

Related

• The verifier
• How a release's facts, change record and fingerprints are worked out
• The surface
• jadpo package verify