record.format_newer

A record file in the project was written by a newer Jadpo, in a format this one can't read.

Area 18, Review and records; not declinable; the next step is usually the human's.

Why Jadpo refuses it

A record is a file Jadpo writes and you commit, such as the identity registry, which keeps every rename. Each kind of record has a format number, raised whenever what it holds or its layout changes. A record in a newer format than this Jadpo knows may hold lines it can't read, and reading it anyway, or writing it again, could lose them.

So Jadpo never guesses. It stops jadpo check, and jadpo test and jadpo dev too, until the project runs with a Jadpo that reads the record.

What it looks like

Format 2 of the identity registry, written by a later release:

database/identities.jadpo_record (written by jadpo rename, jadpo domain or jadpo fmt --layout):

// Generated by Jadpo from renames and moves; update it with `jadpo rename`, `jadpo domain` or `jadpo fmt --layout`, never by hand.record identities 2entity Todo -> Task

  |2 | record identities 2  | ^^^^^^^^^^^^^^^^^^^ newer format

(human) at the end of the next: line tells your coding agent to stop and ask you which fix you want, because the choice is yours to make: it decides which release of Jadpo everyone on the project runs.

How to fix it

If the project should run with the newer Jadpo that wrote the record, pin that release. Whoever has it runs this in the project, then commits jadpo.lock:

jadpo toolchain pin

The lock's first line now names that release, such as jadpo version 0.1.2. Your own jadpo then runs the pinned release for this project, fetching it once, so it reads the record. Run the command that failed again.

Never edit the record back to an older format by hand. A newer format can hold lines an older Jadpo doesn't know, and they would be lost.

Related

• How jadpo check keeps records up to date
• The record format
• Which jadpo runs