# Build manifest

URL: /docs/agents/build-manifest
Markdown: /docs/agents/build-manifest.md

> Inspect the trusted base and runtime contract obligations emitted by sakura build --manifest.

The source-built JS compiler supports:

```sh
sakura build --manifest src
```

A successful build writes JavaScript to `target/sakura/js` and the manifest to `target/sakura/manifest.json`, relative to the working directory. `--out-dir` changes the JavaScript directory; the manifest path stays `target/sakura/manifest.json`. A failed build does not write a new manifest, so check the exit status before consuming an existing file.

The manifest is one JSON object with:

- `schema_version: "1.0"` and the input `snapshot` hash.
- `compiler.version` and `compiler.git`; local builds may have a null git value.
- `trusted` entries for the compiler, emitted runtime (with SHA-256), std host bindings, user `@external` declarations, `@trust` reasons and `@total` declarations.
- `obligations` with an ID, symbol ID, clause, status and source span. Current contract records have status `runtime_checked`.

Obligation IDs use `o:` followed by a digest of the symbol, clause name and normalized predicate. A function-body edit that preserves these does not change its obligation ID. That identity is not a proof-cache validity guarantee: M4 verification must also track bodies and other dependencies.

This records assumptions and runtime obligations; it does not certify the program. [Compile-time literal evaluation](/docs/tour/contracts#literal-refinements-at-compile-time) already decides some introductions, while `sakura verify` and proof-driven check removal remain planned M4 integration. See the [roadmap](/docs/roadmap).