The publish checklist

This page lists everything an app must pass before Brydio publishes it (A8-F04-S03). It covers Brydio's own apps and everyone else's, with no exceptions.

brydio validate runs these checks on your own machine. brydio publish runs brydio build and brydio validate before it uploads anything. Then Brydio's publish route (POST /api/v1/apps/publish) checks the upload again, because an older or edited command line is still just a client. Every check reports a code and one sentence, one item per failure. Warnings don't stop a build or a publish; errors do.

The columns:

• validate: whether brydio validate (and so brydio publish, before uploading) runs the check.
• server: whether Brydio runs it again. "publish" means the publish route refuses the version. "runtime" means Brydio refuses the thing when a screen does it, but still publishes the version. "no" means only the command line checks it.
• Refused with: the sentence you see. <angle brackets> stand for your app's names. Where the server runs the same check, it uses the same sentence unless the row says otherwise.

packages/cli/test/checklist-doc.test.ts fails if a code exists in the SDK and not on this page, or the other way round.

1. The manifest parses, and every placement names a screen

The manifest is .brydio/app.json (or app.json), read with Brydio's own schema (@brydio/manifest). validate and the publish route refuse the same way: the check's own code (manifest_invalid for a field of the wrong shape) and the sentence behind app.json: "<path>": , or behind app.json: when the problem isn't about one field. The sentences below are what follows that prefix. validate lists every problem; the route answers with the first.

2. Screens use only catalogue elements and the settings each one takes

Checked by reading each screen's source with TypeScript's parser, against @brydio/ui's catalogue, which is a copy of Brydio's own. Only what the source writes out is checked: a value or an element name worked out while the screen runs isn't guessed at. Brydio refuses anything that gets past this check, node by node, while drawing (tree/refused), using the same sentences. The publish route can't check compiled code for this.

3. No element carries a style, a class or raw HTML

A screen also runs in a worker with no page, no network, no storage and no other workers, and it may import only @brydio/*, Preact and its own files:

4. Every collection has a schema, and a version that changes one declares its migration

Every collection must have a schema; the manifest checks in section 1 refuse one without. A version whose collections differ from the version published before it must list migrations steps for its own version number (add, rename, drop, dropCollection, replace), in Brydio's A3-F07 shape.

validate compares against the previous version when it can see it:

• --previous <app.json or folder>, pointing at the manifest of the version published before this one, or
• a dist/app.json built from a lower version, when no --previous is given.

When neither is there, only the publish route runs this check. It compares against the highest version already published below this one.

The reasons behind migration_missing, from @brydio/manifest's copy of Brydio's migrations.ts:

5. Every tool the manifest exposes is generated or has a handler

An app's tools are the ones Brydio generates for its collections (create_, update_, get_, list_, search_, delete_). tools.custom must be empty until handler scripts arrive (Phase 3), so a declared tool with no handler is manifest_invalid ("Custom tools are not available yet."). Screens may call only tools that exist:

6. The bundle is under the cap, and holds only scripts and the manifest

7. No secret-looking string in the bundle

This is Brydio's existing scan (extensions/apps/secret-scan.ts), copied exactly. It looks at the value keys (value, secret, token, apiKey, …) anywhere in the bundle's app.json, and in servers.json and integrations/*.json, and skips placeholders like ${user_config.key} or <your key>. app.json is served to every screen that opens the app, so it holds nothing private. Scripts aren't scanned, on purpose: a pattern scan of minified code misses real keys and refuses innocent strings.

8. The grants list everything the screens call, and nothing they don't

A tool counts as granted when its name, *, or its collection's name is in grants.tools, as long as its collection is also granted. That is how Brydio reads grants (apps/api/src/apps/manifest/grants.ts). validate checks the calls a screen writes out: tools.call('…'), tools.result('…'), data.get('…'), data.list('…'), useList('…'), the bridge's callTool, getDocument and listDocuments, and navigate(…). Asking for too little is an error. Asking for too much is a warning: a tool grant may be meant for the assistant rather than a screen.

Only at publish

The publish route runs these; the command line can't, or checks them in its own step.