Manifest and Targets

manifest.tap.json is the host-validated contract for a miniapp package. It describes what the package contributes without executing package code.

Use the published JSON Schema in your editor:

{
  "$schema": "./node_modules/@theaiplatform/miniapp-sdk/config-schema.json"
}

Package Identity

The package object contains identifiers assigned to the publisher and package:

  • packageId is the durable package identity.
  • publisherId identifies the signing or publishing authority.
  • organizationId associates the package with an organization when applicable.
  • namespace separates the package's events and other named resources.
  • slug is a human-readable package route segment.

Treat these values as persistent data keys. Changing a display name does not require changing package identity.

Release Identity

The release object distinguishes an immutable build of the package. Before a build, contentDigest is normally pending. The build derives the final content digest from verified target locks and writes it into the emitted descriptor.

Do not reuse a release ID for different bytes. Promotion and rollback select an existing immutable release; they do not rebuild it.

Compatibility

Declare both tapSdk and tapHost ranges:

{
  "compatibility": {
    "tapSdk": ">=0.1.0 <1",
    "tapHost": ">=0.1.0"
  }
}

The host verifies these ranges before it imports a remote. Keep the range as narrow as the behavior you have tested.

Target Graphs

Each key under targets identifies one independently compiled runtime graph. A target records:

  • its unique Module Federation remote name;
  • the remote entry and optional Federation manifest;
  • the asset lock for the complete emitted graph;
  • integrity values for the entry, manifest, lock, and each expose; and
  • the runtime selected for each expose.

The SDK build owns integrity fields. Source descriptors use pending, and published descriptors contain final values.

Use different remote names and build directories for different targets. A desktop and mobile target can expose different modules while retaining the same package and release identity.

Contributions

Contributions connect a stable contribution ID to one or more target exposes. Common kinds include:

KindPurpose
ui.surfaceMount an interactive platform surface
ui.renderer and chat.blockRender declared content in a supported host location
tool, action.command, prompt, and skillRun host-invoked behavior
specialist and workflowProvide reusable agent or workflow behavior
mcp.*Provide supported Model Context Protocol contributions
miniappGroup related contribution IDs into one installable app
permission.catalogDeclare assignable actions and consent policy

The JSON Schema is authoritative for all supported kinds and their options.

Every target selected by a contribution must exist in the package target map, and every expose must exist in that target's locked Federation graph. A mismatch fails before activation.

Authorization

Use authorization.allOf for named permission actions and authorization.effects to describe protected effects. Keep requested access specific to the contribution and scope.

Manifest declarations do not give code direct access. They let the host evaluate policy and consent when the contribution requests an SDK operation.

Events

Declare events under the top-level events object and list contribution-specific event names in publishes or subscribes. Match event payloads to the declared schema and version.

Use context.events from the surface mount contract to publish and subscribe. Undeclared event names can be rejected by the host.

Presentation Assets

Declare passive SVG or PNG presentation assets with their media type, package-relative path, sizes, and theme. Build tooling verifies and locks the bytes.

Package code should resolve runtime assets through resolvePackageAssetUrl. Do not build asset URLs from a host origin or an absolute filesystem path.