Test and publish
Review sandbox validation, publish a workspace plugin and verify installation.
Publication follows successful sandbox validation. Review the exact candidate and its tests before accepting it into the workspace catalog.
Inspect validation
The authoring flow writes the generated files into a sandbox, validates package structure and runs package commands. When package.json exists it installs dependencies using npm ci if a lockfile exists, otherwise npm install. It runs declared build, typecheck, test and spec scripts when present.
Missing scripts are not proof of a tested capability. Inspect which commands actually ran, their exit codes and output, and the tests’ assertions. Verify that tests exercise behavior rather than only mirroring a declaration.
The run statuses are queued, running, sandbox_validated, published, failed and canceled. The run report also records phases, attempts and errors. Only a successfully validated candidate is eligible for publication in the authoring flow.
Review the package
Check the canonical manifest, package exports, dependency versions, runtime entrypoints, parameter validation and handling of credentials. Compare the declared capabilities with the implementation. For transforms, inspect lineage; for writes, inspect effects, recovery and retries.
Rerun sandbox tests for a validated or published draft with plugin_authoring_test. A sandbox pass proves the executed tests passed; it does not prove access to your real database, storage account or remote API.
Publish
- Inspect the validated candidate and command results.
- Choose publication for the reviewed run and provide the publisher details.
- Confirm the package appears in the workspace catalog.
- Install that published version and configure its protected settings.
For an assistant, plugin_authoring_publish publishes the validated run. Inspect plugin_catalog_get and plugin_installation_create for version and capability selection.
Workspace publication makes a plugin available in that workspace; it is not a request to publish it into the shared official catalog or a public package registry.
Verify a real bounded operation
Use a dedicated test target and known input. Check the installation, bind a matching endpoint or pipeline node, validate and execute the operation, then compare the result with the expected external state. Inspect receipts, errors and evidence where available.
For a read, compare known rows and pagination. For a transform, check values and lineage. For a write, inspect the receiving system and retry/reconciliation path. Keep the scope small until these checks succeed.
Maintain and retire
Use a new authoring run for revisions and review the new candidate. Installed versions and dependent assets must be inspected before replacement. Removal of an installation and retirement of a plugin are separate actions; both can affect consumers.
Use plugin_authoring_stop to cancel a running authoring workflow. Use plugin_authoring_retire to retire an authored plugin after dependency checks.
FAQ
Why can’t I publish a failed run?
Its candidate has not passed the required validation. Inspect the error and correct the specification or implementation; do not treat a partially generated package as accepted.
Does publication approve every future write?
No. Execution still follows the capability contract, caller permissions, write policies and any required action approval.