acceptance.missing

A change could break someone else or widen who can do what, and no acceptance this change adds says a person agreed to it.

Area 14, Tools; not declinable; the next step is usually the human's.

Why Jadpo refuses it

Some changes can hurt someone outside the code: removing a field a client reads, opening a route to anyone, adding a caller to a grant, reaching a new outside host, declining a security rule, creating a domain, installing a package from git, a migration removing data (Removing data), or sending personal data to a connection that can't erase it. Whether such a change is safe depends on who relies on the old behaviour, which the code can't know.

So a person decides. jadpo check compares the change with the default branch where this branch left it, and fails on each such change until an acceptance the change adds lists it. An acceptance is a small file in acceptances/ that lists the changes and says why, in a person's words.

What it looks like

A book catalogue's BookView stops sending each book's author, and jadpo api update rewrites the API record without it. Then:

jadpo check

   |21 | output BookView   | ^^^^^^^^^^^^^^^ ApiChange.output_field_removed

(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 whether your API's clients lose the author field.

One kind isn't a change a branch makes. A connection that receives personal data and can't erase it needs a person for as long as that is so, whichever branch first finds it:

  |9 |         couriers: {  |         ^^^^^^^^ ErasureNotPossible.data_stays

How to fix it

The question is whether the change should happen at all.

If it shouldn't, put back what it removed: Book.author in BookView's pick:, and author: book.author in what add_book returns. Then rewrite the API record and check again:

jadpo api updatejadpo check

The API record matches the default branch's again, so there is nothing to accept and the check passes.

If it should, draft the acceptance. An agent may run this:

jadpo acceptance new remove_book_author

Wrote acceptances/20261020T1400_remove_book_author.jadpo    main.BookView.author  ApiChange.output_field_removeddecision: 1 change waits for a person's reason --> acceptances/20261020T1400_remove_book_author.jadpo:1  next: Stop and hand over: a person reads the changes and writes why they are accepted on a `///` line above `acceptance`. (human)

The draft lists every change this branch makes that needs a person, each as subject: Kind.change. Then the agent stops, because jadpo check fails with acceptance.no_reason until a person writes why on the /// line above acceptance, such as "No client reads a book's author: the catalogue pages stopped showing it in version 2."

Once the reason is written, jadpo check passes. The acceptance is committed with the change, and the pull request's review is where an owner of acceptances/ approves it. Once merged, it is history.

If a provider can erase what its connection receives, its package declares the call, and the connection names the field holding the person's key:

// shared/providers/acme_couriers/v1/provider.jadpoprovider {    ...    erasure: {        call: customers.delete        by: CustomerId    }}// app.jadpocouriers: {    package: AcmeCouriers.v1    erasure: {        key: User.couriers_customer_id    }}

The connection can then erase its copy, so it needs no acceptance (Erasure at providers).

If the data has to stay at the provider, draft the acceptance, and say why on its /// line:

jadpo acceptance new invoices_at_couriers

Once merged it goes on allowing it, and removing the file brings the error back.

Related

• Acceptances
• The public API record
• Review and sign-off
• jadpo acceptance new
• Get a person's sign-off