Reviewing a change

When an agent hands you a change, you should see it in the order it matters. jadpo approval --before <ref> writes a report in that order, as Markdown and JSON, and a static web view of the same report:

1. Decisions that need a person. Each change that needs an acceptance, a file in acceptances/ in which a person accepts it (Acceptances). Each is said in plain words, who can now do what to which data ("viewers can now read Project.budget"), with whether its acceptance file exists.
2. Paths. For each decision, the path that makes it true: actor → route → action or query → field → output. You can open it to see what surrounds it.
3. Newly reachable code. Declarations that didn't change but are now reached from a new place, which a line diff never shows.
4. Other behaviour. Changes to the public API record, the schema and migrations, failures, events and subscribers, integrations, and the differences in the permissions report and the personal-data report.
5. Source, grouped by declaration rather than by file.

$ jadpo approval --before main1 decision needs a person  viewers can now read Project.budget          acceptance missing    viewer → GET /projects/{id} → project_detail → ProjectView.budget2 declarations newly reachable  budgets.convert_currency   now reached from GET /projects/{id}Other changes: 1 route added, 1 migration, no failure codes changedSource: 6 declarations in 4 files

Packages and services that need a person

Packages add their own decisions to the first section, each needing a person's acceptance:

• A third party's package installed from git rather than the registry. It is marked unverified until a person accepts it.
• A package's service whose image is new or changed, shown with its image, digest and the hosts it asks to reach. It never starts until accepted.
• A new outside host a service is allowed to reach.
• A connection that receives personal data but can't erase it (Erasure at providers).
• Bot checks allowed to pass when their provider is down (Bot protection).

Wording not yet accepted

With translations: { review: TranslationReview.required }, wording that changed and hasn't been accepted with jadpo translations accept <locale> is listed under other behaviour too (Tooling for translations).

The web view

The web view adds what text can't: the graph of the change, the differences between an agent's successive revisions of it, and links from every line to its source. It is a file in build/review/, which you open on your machine or CI publishes beside the pull request. It holds no accounts and records no approvals. Acceptances stay files, reviewed on the git host like any other change.