# What is built

| Feature | Status |
|---|---|
| Manifest | Built: `jadpo check` writes `build/manifest.json` at `format` 2, with nodes for [project layout and modules](/docs/project-layout-and-modules.md), [values and types](/docs/values-and-types.md), [logic](/docs/logic.md) and [failures](/docs/failures.md) and their `calls`, `uses` and `raises` edges, policy's grants, field restrictions, tenancies and listed actions with `grants` and `scopes` edges, prompts, and the connections, packages, operations, hosts, lock lines, principals, sign-in, generated routes, settings, locale set, rate limits, schedules and subscribers of [Sign-in and identity](/docs/identity.md), [Configuration](/docs/configuration.md), [External services](/docs/external-services.md) and [Background work](/docs/jobs-and-events.md), and the build stamp, a `person` node for each [person entity](/docs/person-entities.md), listing the references its records belong through and the fields erasure keeps of their record, and a `retention` node for each [retention](/docs/retention.md), under its field or entity, with its period and `since:` field. The graph's diff classifies their changes as [Package upgrades](/docs/package-upgrades.md) and the [acceptances](/docs/acceptances.md) table say (`PackageChange`, `PolicyChange`). Each threshold is a `threshold` node with what it watches and its limits, and each disk store's floor one too ([What Jadpo generates from thresholds](/docs/monitoring-thresholds-generated.md)). Caches, OAuth scopes and personal fields join as their parts of the language are built. |
| Views of it | Partly built: the library and failure catalogues are built, one OpenAPI document per API in `build/openapi/`, and the monitoring rules in `build/monitoring/`; the other reports come with their parts of the language. |
| Migrations | Built: `jadpo migrate new` writes each folder, and `jadpo check` fails while the entities and the latest snapshot disagree. Each folder is a `migration_snapshot` node in the manifest. |
| Stable identity | Built: a key is the kind and the born name, a function or type declared in a domain carries its domain, and a test's key is the file it sits beside and its sentence. `jadpo check` reads the registry and promotion with `jadpo fmt --layout` writes it; `jadpo rename` and the `jadpo domain` commands, which write it too, have rows of their own ([Tools](/docs/tooling.md)). |
| API record | Built: `jadpo api update` writes `api/<api>.jadpo_record` for each API with routes, `jadpo check` fails with `record.out_of_date` while one disagrees with the routes, naming what changed, and a breaking change needs an [acceptance](/docs/acceptances.md). |
| `.jadpo_record` files | Partly built: every record in the record format, the API record without `version:`, the registry as `database/identities.jadpo_record`, the header check, `record.out_of_date`, `record.edited` and `record.format_newer`, `jadpo records` and `jadpo records update`, and the `.gitattributes` lines `jadpo new` writes. Not built yet: telling a careful hand edit of a view from a stale one, which needs `jadpo check` to build the base as `jadpo approval` does; the editor grammar and `jadpo lsp` serving records. |
| Event records | Built: one view per domain with events, `domains/<domain>/events/events.jadpo_record`, written by `jadpo records update` and checked as the API record is; what [The event record](/docs/declaring-an-event.md#the-event-record) records, and its breaking changes need an [acceptance](/docs/acceptances.md). |
| Access and network records | Built: `access.jadpo_record` and `network.jadpo_record` at the root, written by `jadpo records update` and checked as the API record is ([Acceptances](/docs/acceptances.md)). |
| Acceptances | Partly built: `jadpo acceptance new <purpose>`, the before side read from git (`--before` on `jadpo check`), matching, the `///` reason and history, for `ApiChange` (the API and event records), `PolicyChange` (widenings, routes made public, security declines, sign-in settings past their limit), `DomainChange.created`, `NetworkChange.host_added`, `PackageChange.git_source`, an upgrade's `PackageChange`s ([Package upgrades](/docs/package-upgrades.md)), `ThresholdChange` (each domain's `monitoring.jadpo` and `app.jadpo`'s disk floors read from git) and `DataChange` (read from the migrations a change adds, [Removing data](/docs/migrations.md#removing-data)). And `ErasureNotPossible`, which says how things stand rather than what changed, read from [where personal data goes](/docs/the-personal-data-report.md#where-personal-data-goes). Not built yet: `PackageChange.service_image`, which comes with services; and a domain renamed, which shows as one created until `jadpo domain rename` writes the registry. |
| Lock and package surfaces | Built. The lock is a ledger read and checked like the others, and `jadpo check` holds each installed package to its line and digest ([External services](/docs/external-services.md) gives the digest), and its `jadpo version` pin to the line `app.jadpo` names. `jadpo toolchain pin` and `unpin` write the pin, and the package commands and `jadpo records update` keep it. `jadpo package add`, `update`, `remove`, `link` and `unlink` write it, each line through the ledger's writer, sorted; `git` lines record the repository as written, the tag and the tag's commit, `path` lines a folder relative to the root, and a `link` line replaces the package's line while the replaced one waits in `.jadpo/links` (git-ignored, in the lock's own format) for `unlink`. Two versions of one package are locked side by side, each on its own line, and `update` names the version while two are held. A package surface is `record surface 1`, a view written by `jadpo package check` in a package's own repository, verified at install against its package's code, and read by `jadpo package show`; installed, a surface is held by its package's digest rather than regenerated, so `jadpo records` doesn't list it, and an own integration's is written to `build/providers/` ([External services](/docs/external-services.md)). `jadpo package update` prints the surface's changes, each entry the app uses marked `used by the app`, and this page's review under `Needs a person`, the same list `jadpo check` asks an acceptance for; a package installed from git needs `PackageChange.git_source`. |
| Build stamp | Built for native and Workers deployables: `jadpo build` writes the build id (`b_` and twelve hex digits of a SHA-256 over the deployable's program digest, the compiler, the target and `jadpo.lock`), the commit, whether the tree was modified, the compiler, the deployable and the target into the binary or module as a constant, and every event it logs carries them ([A native deployable](/docs/a-native-deployable.md), [A Workers deployable](/docs/a-workers-deployable.md)). `jadpo check` writes the manifest's `source` (`commit`, left out when git doesn't track the project, and `modified`) and `deployables`, each deployable's target, build id and the disk stores that keep it on one server (`one_server`), which digests a declared deployable's declaration too, so two deployables of one app never share one ([Declared deployables](/docs/declared-deployables.md)); a project with errors has none. |
| Approval | Built: `jadpo approval` builds the before side, keeps its manifest and writes [the report](/docs/reviewing-a-change.md) to `build/review/`. |
| Package upgrade plans, `jadpo incident`, `jadpo inspect` and `jadpo test new --from-event` | Not built yet. |