Studio · Cody’s build bench

Plugin Studio

Plugin Studio is a focused authoring bench for a sandboxed Zimac add-on: define its manifest, edit three web files, preview it, review Cody’s proposed changes, verify the bundle, and choose whether to install or commit it.

Draft first, effect later. Drafts live on this device. Nothing is installed and no Git commit is created until you click the corresponding release action.

λ Local drafts

Keep up to 30 workbench drafts in the app’s local browser storage.

◇ Sandboxed preview

Run the page in a script-enabled opaque iframe without host privileges.

± Reviewable diffs

Cody proposes file changes; you inspect before applying them.

✓ Canonical gates

Use the same decoder, manifest validation, and scanner as installation.

Open it from the Studio picker, say “open Plugin Studio,” or type /plugin-studio. Add an idea after the slash command to seed a new draft.

What it is#

A Studio draft contains plugin metadata plus index.html, style.css, and app.js. You can create it in the Studio or ask Cody to create a plugin in chat and open the resulting draft card here. Saving persists the draft locally; deleting a draft does not uninstall a separately installed copy.

Plugin Studio is the authoring surface. The Plugins panel is the runtime management surface for installed bundles, approvals, updates, enablement, export, and uninstall.

Define the contract#

The left rail builds plugin.json from controlled fields: stable lowercase ID, name, semantic version, description, author, icon, hue, page label/navigation, slash commands, Store tags, requested capabilities, and—when HTTP is requested—allowed HTTPS origins.

The Studio only accepts known capability names. Slash commands must use a safe /lowercase-name shape, tags are bounded, and the packed bundle must stay at or below 5 MB.

Edit & preview#

The central editor switches among the three source files and refreshes a sandbox preview. The preview iframe uses sandbox="allow-scripts" without same-origin privileges. Direct host APIs, another plugin’s state, cookies, and native bridges are outside the frame.

The injected __zimac__.js SDK is the intended bridge. In preview, capabilities may be simulated or unavailable; installed behavior still depends on the manifest and the capabilities a user approves.

Develop with Cody#

Cody Develop receives the current draft files and one instruction. It is confined to this draft: no shell, network, host workspace, secrets, native API, or repository access. Cody cannot silently edit the manifest; if a capability change is needed, it must be explained for you to make.

The result is a proposal with per-file before/after content, notes, and checks. You choose Apply or Discard. Applying updates only the Studio draft and still does not install or commit it.

Checks & preflight#

Local gates check manifest identity and metadata, runnable HTML, known capability and network rules, forbidden bridge patterns, bundle size, tags, and slash-command discoverability. Advisory patterns such as eval or window.top are surfaced even when they do not form the same hard block as a forbidden native bridge.

Before an effect, the backend decodes the actual .zplugin bundle and runs the canonical manifest validator and static scanner. Passing local JavaScript checks alone is not enough.

Static checks reduce risk; they do not prove a plugin is safe or correct. Read the code, requested capabilities, network origins, and server findings before approving an installed plugin.

Install locally#

Install draft sends the verified bundle through the ordinary plugin installer. A successful install lands disabled. Open the Plugins panel to review scan findings and requested capabilities, then explicitly approve and enable the current content hash.

If an installed plugin already uses the same ID, replacement is a separate decision and clears the prior approval. Studio installation never preserves an old approval across changed bytes.

Commit a Store release#

Commit to Store is a developer-only path available from a clean Zimac source checkout. It packs deterministic artifacts, calculates and verifies a SHA-256 checksum, checks the scoped Git diff, and creates one local commit containing the release changes.

No push and no publication happen here. A local Git commit is not a Store release, deployment, pull request, or approval from Zimac. Those remain separate repository and release steps.

Capability boundary#

Current draftable capabilities include notifications, private plugin storage, visible-chat send, isolated chat request, limited context, people-name/role search, allowlisted HTTPS, Change Management scoring, text extraction, document composition, and file download. Each crosses a host broker only when declared and approved.

The http capability is additionally restricted to the manifest’s HTTPS origins. Declaring a capability does not grant it; the installed plugin receives only the subset the user approves.

What it does not do#

No arbitrary project scaffolding, package manager, build command, or multi-language runtime.
No editing outside the one draft’s HTML, CSS, and JavaScript files.
No direct shell, filesystem, repository, credential, cookie, or native-bridge access from the preview.
No automatic install, enable, capability approval, Git push, pull request, Store publication, or deployment.
No guarantee that a sandbox preview matches every installed runtime condition.