Acceptances

Some changes can break someone else, such as removing a field clients read. jadpo check fails on them until a person accepts them. An acceptance is one file per decision, listing every change it allows, with the reason in a /// line. This one allows removing the priority field from what API main sends as a TodoView:

acceptances/20261020T1400_remove_todo_priority.jadpo:

/// Priority was never shown by any client; the mobile app stopped sending it in 3.2.acceptance {    changes: {        main.TodoView.priority: ApiChange.output_field_removed    }}

acceptance, changes: and ApiChange are built in. The rest of the entry comes from the compiler: each entry is subject: Kind.change, with the subject and the change copied from its message. A subject is a dotted name, or, for a route, its API, method and path in quotes, since a route has no name. You don't need to type one, since jadpo acceptance new drafts the file (below).

• It counts only in the change that adds it. Acceptances already on the before side are history, and editing one is an error (acceptance.edited). check fails when a change needs a person and no added acceptance lists it (acceptance.missing), when a listed entry matches nothing (acceptance.unmatched), or when the reason is missing (acceptance.no_reason). A file that isn't one acceptance with its changes: is acceptance.invalid. A quoted key anywhere else is a syntax error.
• Drafting is a command. jadpo acceptance new <purpose> writes a file listing every change not yet accepted, with no reason. An agent may run it, then stops: the missing reason keeps check failing until a person writes one.
• The git host is the gate. acceptances/, api/, access.jadpo_record and network.jadpo_record are owned in CODEOWNERS, so the owner's approval of the pull request is what lets a decision in, and the host records who gave it (Review and sign-off). jadpo new writes a CODEOWNERS listing them, for the project to name its owners.

Changes that only add need no acceptance: a new route, even one anyone may call, a new optional input field, a new output field, tightened policy, listing a query, a new entity that belongs to a tenant. The diff still shows them.

Each change the compiler reports, and the subject it names:

Two records give these checks a before side, and put what changed in front of the reviewer: access.jadpo_record, who can do what, from the permissions report, and network.jadpo_record, every outside host the app can reach, from the network report. jadpo check keeps them at the root beside api/, as it keeps the API record, and jadpo records update writes them. A project with nothing for one to hold has no such file, except that an app with a connections: block keeps network.jadpo_record, its header alone while it reaches no host.

// Generated by Jadpo from who can do what; update it with `jadpo records update`, never by hand.record access 1tenant Companyentity work.Project    create CompanyRole.editor    read CompanyRole.editor    read CompanyRole.viewer    tenant company_idfield work.Project.budget    read CompanyRole.editoraction todos.transfer_todo    who Todo.owner_iddecline policy.call_ungranted lending.borrowsign_in magic_link    code_attempts: 5    expires_after: 15m    failed_codes_per_day: 20

// Generated by Jadpo from the hosts the app can reach; update it with `jadpo records update`, never by hand.record network 1connection couriers    for AcmeCouriers.v1    host https://api.acme-couriers.example    host https://sandbox.acme-couriers.exampleconnection main    for database    host config.database_url

A field's own list that lets nobody in is written read nobody, so it reads apart from a field that follows its record's list. A route made public is read from the API record, whose route entry says authentication none.