The manifest

jadpo check writes one manifest for your project, build/manifest.json, whether the project has errors or not. It is the compiler's graph as versioned JSON: every declaration and field with its stable identity, source file and lines, content digest, /// description, calls, reads, writes, events and failures. It also holds the routes, schedules, subscribers, connections and their hosts, policy grants, personal fields, thresholds, the control flow that path numbers are decoded against, and each deployable's build id.

{  "format": 2,  "source": { "commit": "8d113e6", "modified": false },  "compiler": "0.4.0",  "deployables": { "api": { "target": "wasm", "build": "b_9a1f03c6d2e4" } },  "nodes": [    {      "id": "action complete_todo",      "kind": "action",      "domain": "planning",      "file": "domains/planning/actions/complete_todo.jadpo",      "lines": [4, 22],      "digest": "9f2c41d0",      "calls": ["Todo.get", "Todo.update"],      "fails": ["TodoNotFound", "TodoMutationConflict"]    }  ]}

Every report is a view of it. The permissions, personal-data, network, database and query reports, the catalogues, OpenAPI and the monitoring rules are all made from the manifest, so they can't disagree with each other.

A build id is a digest of everything that decides a deployable's behaviour: the source it reaches, the compiler version, the target and the locked packages. The same build id means the same build. The source is the deployable's program as it is compiled from what it reaches: its Rust and its plan, with its name and its stores' migrations. So a change to what only another deployable reaches, or to a test, leaves its id alone (design notes, "What a build id digests"). A project with errors builds nothing, so the manifest gives its deployables no build.

The format. The JSON is canonical: sorted, with relative paths and no timestamps. The format number changes only when a field is removed or changes meaning; additions keep the number. Manifests are never stored, so no tool ever reads an old format. jadpo help --json documents the schema, with every node and edge kind and whether it is built yet.

Its size doesn't matter, because it is never shipped. An agent asks for one node with jadpo inspect <name> --json rather than reading the whole file.

What a node holds

The manifest is at format 2, with compiler, errors and nodes. A node has id, kind, name, file, lines and digest. Where they apply, it also has:

• domain, parent, public and doc;
• a type's base, rules and failure;
• a field's type;
• a callable's signature;
• an action's or fixture's isolation, read_committed or repeatable_read (Isolation levels);
• its edges, as sorted lists by kind: calls, uses, and raises for the failures that can leave a callable (the fails above).

The build stamp is in source, deployables and their build ids.

Other parts of the language add their own nodes:

• Integrations, identity, configuration, jobs and events add a node for each connection, package, resource, operation, capability mapping, host and lock line, each kind of caller, sign-in method, way of signing in and route the runtime answers itself, each setting, the locale set, the rate limits, and each schedule and subscriber. Their edges are emits, subscribes, runs and provides.
• Policy adds a grant node for each list an entity's policy: writes, and a field_restriction for each field's own policy (serverOnly, or who: each effect's list). It adds a tenancy for each entity that belongs to the tenant, and an action_exception for each line under root policy { actions: }. grants edges go to what each decides, and scopes edges go from each tenancy to its entity.
• Prompts each add a prompt node, placed at its .prompt file, with its type as its parent and its version: its name and the first 8 hex characters of a SHA-256 over its two files, answer_question@864ad76b.

Which parts of the language have nodes so far is in What is built.