@yaklabs-ai/plugin-protocol

The kay.plugin.v1 manifest schema — the same Zod schema Bonsai's daemon uses to parse kay-plugin.json at load time.

Published to the public npm registry under the MIT licence, always at the same version as @yaklabs-ai/plugin-sdk. No registry configuration and no access token are needed. See @yaklabs-ai/plugin-sdk's README for the full authoring flow.

{
  "dependencies": {
    "@bonsai/plugin-protocol": "npm:@yaklabs-ai/plugin-protocol@^0.13.4"
  }
}

Why you want this

Validate your manifest in your own CI, against the real schema, instead of a hand-written approximation:

import { KayPluginManifestV1 } from "@bonsai/plugin-protocol";

const parsed = KayPluginManifestV1.safeParse(
  JSON.parse(await readFile("kay-plugin.json", "utf8")),
);
if (!parsed.success) {
  for (const issue of parsed.error.issues) {
    console.error(`${issue.path.join(".") || "<root>"}: ${issue.message}`);
  }
  process.exit(1);
}

A hand-rolled field check drifts from the contract it claims to enforce and passes while the host rejects the plugin at load. This is the host's own schema, so it cannot drift — and unlike resolving it out of a Bonsai checkout, it needs no clone, no build, and no KAY_REPO environment variable.

Version it against your Bonsai app

The schema changes over time — it gains fields, and it can also remove one. Three skews follow, and only the first two fail on your machine:

• Validating against a newer schema than your Bonsai app runs can accept a manifest the host will reject.
• Validating against an older schema can reject a manifest the host would happily load.
• Validating against an older schema can also accept a field the host has since removed. KayPluginManifestV1 parses with strictObject, so an unrecognized key is a hard rejection: your local validation goes green, and Bonsai drops the plugin at load with a diagnostic you never see.

Keep this package in step with the Bonsai version you target — the third skew is the one a green local run will not warn you about.