Create a bundle View

Goal

Author one durable, self-contained View that launches from both the local Superbee UI and an MCP Apps host. This how-to is for bundle authors who already have a valid bundle and understand what information the View should present.

View behavior is verified against the current stable release.

Decide whether a View is warranted

Use an ordinary document for durable prose, decisions, or instructions that render well as Markdown. Use a View when interaction, visual grouping, live queries, or a bounded proposal flow materially improves the human task.

Choose the least capable access level:

Every bundle-propose mutation is presented by trusted shell chrome and requires a separate human Apply decision against the current target version. The View cannot commit directly.

Prerequisites

• Confirm superbee kinds declares View. Install a View-bearing recipe if it does not.

• Keep HTML, CSS, and JavaScript in one file with no external resources.

• Design for narrow and expanded host panels.

• Bound queries and show loading, empty, partial, over-limit, stale, and error states.

1. Start from a working View

List installed View blobs and export a relevant example:

superbee blobs --prefix views/
superbee pull \
  --doc-key views/review-workflow/reviews.html \
  --out my-view.html

For bundle-read and bundle-propose, use Superbee's postMessage bridge. Request canonical document rendering with render-document; do not embed a second Markdown parser. Treat change events as invalidation signals and refetch current data.

2. Promote the exact HTML bytes

superbee promote my-view.html --doc-key views/my-view.html

Keep the returned blob version. The registry binds that exact byte version to the View identity. Updating the HTML later requires promote --expected-version <current-version>.

3. Create the registry document

superbee new "View" my-view \
  --title "My view" \
  --entry views/my-view.html \
  --access bundle-read \
  --description "A live, bounded view of this bundle."

The View Kind places the document beneath views-registry/ and records entry_version. Use type: View, entry, entry_version, and access; the retired Page and bridge names do not register current Views.

4. Validate and launch locally

superbee status
superbee view list
superbee ui --open

Confirm the View appears in the expected access group, loads with no external network dependency, and remains usable at narrow and wide sizes. For a proposal View, start the UI with an actor:

superbee ui --open --actor openai/codex/root

Exercise one proposal and confirm the trusted shell shows before and after values, rejects a stale target, and applies only after human confirmation.

5. Verify the same registry in an MCP host

Run host setup until the MCP capability is ready, then restart the host if setup requires it. Ask the host to list the exact workspace's Views and show views-registry/my-view. The MCP launcher and local UI must use the same registry ID, HTML bytes, access, and bridge contract.

Panel presentation is controlled by the host. If the host returns text without an App panel, use superbee ui --open to verify the View while separately checking host integration status.

Trust and runtime model

The local UI serves the iframe with sandbox="allow-scripts" and no same-origin privilege. A strict View content security policy blocks ordinary direct network connections. The iframe receives a short-lived nonce for its own admitted HTML, never the UI session credential. Data passes only through the shell's bounded bridge.

Approval is tied to the View identity, exact HTML version, and declared access. Changed bytes or a broader access declaration require a new decision. Closing the UI process revokes its session and nonce. Persistent, ambient write grants are outside the View contract.

Recovery

Evidence and next actions

The full message protocol travels with the tagged View authoring reference. See View contract and access for lookup details and View lifecycle and trust for the system boundary.