# What is built

| Feature | Status |
|---|---|
| Manifest | Built: `jadpo check` writes `build/manifest.json` at `format` 2, with nodes for [project layout and modules](project-layout-and-modules.md), [values and types](values-and-types.md), [logic](logic.md) and [failures](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 [Identity](identity.md), [Configuration and time](configuration-and-time.md), [Integrations](external-services.md) and [Jobs and events](jobs-and-events.md), and the build stamp. The graph's diff classifies their changes as [Package upgrades](package-upgrades.md) and the [acceptances](acceptances.md) table say (`PackageChange`, `PolicyChange`). Caches, OAuth scopes, personal fields and thresholds join as their parts of the language are built. |
| Views of it | Partly built: the library and failure catalogues are built, and one OpenAPI document per API in `build/openapi/`; the other reports and the monitoring rules 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. The registry is read once `jadpo rename` writes it ([Tooling](tooling.md)). |
| API record | Partly built: `jadpo api update` writes `api/<api>.jadpo_record` for each API with routes, and `jadpo check` fails with `record.out_of_date` while one disagrees with the routes, naming what changed. Not built yet: breaking-change classification and acceptances. |
| `.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 the base build that comes with `jadpo approval`; 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](declaring-an-event.md#the-event-record) records. Acceptances come with the API record's. |
| 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 ([Integrations](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/` ([Integrations](external-services.md)). `jadpo package update` prints this page's review of the surface's changes, each entry marked `used by the app` and `needs a person`; the acceptance it calls for comes with `jadpo approval`. |
| 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](a-native-deployable.md), [A Workers deployable](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 and build id, which digests a declared deployable's declaration too, so two deployables of one app never share one ([Declared deployables](declared-deployables.md)); a project with errors has none. |
| Approval, acceptances, package upgrade plans, `jadpo incident` | Not built yet; see [the roadmap](https://github.com/jadpo-dev/jadpo/blob/main/docs/roadmap.md). |