AI calls the capability as a tool; people use it as a UI — from the same declaration.
manifest (capability declaration) + backend (executor execution) + frontend (desktop rendering). The contract is language-neutral, so Python can validate the same JSON Schema too.
@tueo/plugin-sdk is the single source of capability truth across the four-layer architecture, depended on by the desktop, the server and the capability platform. The same input yields byte-identical output — locked in by the load-bearing-wall acceptance.
Ed25519 cryptographic signatures derive three trust tiers: official / partner / community. Tampering with the manifest — changing permissions or capability declarations — fails signature verification and installation is refused as tamper-evident.
Inputs are read from inputs.json, results are written to result.json, and large-file artifacts are uploaded to object storage by the sandbox. Authors simply need to serve({capabilityId: handler}); the SDK normalizes I/O and errors as the safety net.
For light scenarios, the host renders forms and previews from the schema with no UI code to write; rich UIs run in a sandboxed iframe. The frontend never touches the sandbox or credentials directly.
17 layouts plus 4 design languages; the same DSL produces an HTML preview and an editable .pptx — preview matches export, so "looks great in preview, breaks in export" never happens. Existing PPTs inherit colors and fonts in one click.
Drug delivery-note recognition: AI handles extraction while a rules engine handles deterministic validation (approval-number format / date relationships / quantities), with green-yellow-red review previews — with human review reserved for <1% of cases.
A broken page becomes a placeholder without destroying the deck; unavailable data renders "—" rather than being invented; charts plot real values and nothing else. AI produces the content and the system does not draw pixels — fixes are done right, no wasted cycles.
skillplugins (write plugins), the capability platform (register + govern), executor (backend sandbox) and desktop (frontend rendering) each do their own job, with all calls through one path and three layers of isolation.
desktop → server validates and dispatches → Executor executes → back to desktop for rendering.
Write a manifest with the SDK, declaring the capability and its permissions.
Register the manifest into Capabilities to become a purchasable capability.
The backend runs under control inside the Executor sandbox.
The frontend renders UI for humans in the Cohort desktop.
See the architecture for how the four layers work together, or book a demo to discuss your capability idea.