Skip to main content

Publish to your organization

A personal plugin lives only on your computer. To let colleagues use it, or to run it from tasks and automations, upload it to your organization. An admin reviews it before anyone else can see it.

Create in the client → local pre-check → install and try privately
  → Upload to company (optional)
  → quarantine → admin review and release
  → the whole company or chosen members find it and install it
  → an admin binds it to a project or the organization for tasks and automations

What stays personal​

  • Personal plugins are stored in the client's data directory with the identity local:<uuid>. They work offline.
  • Removing or disabling your local version doesn't affect a published organization version. Publishing never overwrites your draft.
  • Uploading doesn't sync personal plugin data to the organization.

1. Upload​

Open the plugin in the client and choose Upload to company. Pick the audience: the whole company, or specific members of your organization.

The first time you upload from a computer, the client signs the immutable package with an Ed25519 key held in the system's secure storage and sends the public key with the candidate.

2. Quarantine​

The Hub runs the pre-check again and creates an immutable candidate version. It is stored in quarantine. Nothing is executed, trusted or bound.

3. Review​

In the admin console, open Plugins and apps. A plugin admin:

  • checks the Key ID and SHA-256 fingerprint of the signing key and registers the publisher explicitly. The Hub then verifies the package against it. Registering a publisher doesn't publish anything;
  • reads the generated report: components, dependencies, permission summary and entry points;
  • runs the release evaluations, if the version declares them;
  • releases the version.

Admins can also import a package directly with Import and submit. The admin console reviews and governs plugins; it isn't a plugin editor.

Release evaluations​

A manifest can declare up to 20 evaluations. Each has a representative instruction, credential-free inputs, criteria that can be judged, and expectedOutputs. They are stored with the version; changing them needs a new review.

  • An admin chooses the harness (runtime), model, runner tags and secret references for the evaluation. It runs in an isolated working directory.
  • The Hub keeps a snapshot of each case, where it ran, and the size and SHA-256 of each artifact.
  • After the outputs meet the result contract, a person still gives the pass verdict. Re-running a case replaces its earlier verdict.
  • A version that declares evaluations can be enabled only when all of them pass. A version without evaluations can be released only after an admin explicitly accepts the risk. The employee catalog labels versions as Verified or Reviewed.
  • Evaluations run with no side effects. Prefer file, evidence and decision outputs. If a required output is git or url and no sandbox can produce real evidence, the gate blocks; "not run" never counts as passed.

4. Install and bind​

  • People find the released version in the company catalog and install it in their own chat toolbox. Their install follows their account across clients and stays on the version they accepted. When the company switches versions, they confirm the upgrade.
  • Tasks and automations use the version an admin binds to a project or the organization. Personal installs don't affect them.

Plugins published and bound by a parent organization can be used by its departments, within their permissions. Project limits, chosen audiences and isolation between companies still apply.

5. Simulate before running​

Binding simulation checks the real project: repository, environment, secret references, online runners and each AI node's route. You can save a binding before everything is ready; the simulation lists the blockers. A run that reaches a step with missing configuration stops there. After the configuration is fixed, the run continues from that step without redoing earlier AI work.

At start, the run locks the plugin version, binding, node settings and inputs. Later upgrades don't change a run in progress.

Checklist before you upload​

  • key is stable, and version went up if the content changed.
  • Every AI node has a clear prompt, a time limit of 60 to 86,400 seconds, and explicit minimal capabilities.
  • Information between agents goes through outputs and inputs, not "remember the earlier chat".
  • Engineering results are declared as git; file results have exact relative paths.
  • AI review and implementation are separate nodes. People only accept the business result or authorize high-risk steps.
  • No environments, ports, machines, models, accounts or secrets are hard-coded.
  • Quality commands use argv arrays, with working directories inside the repository.
  • The pre-check passes, and a simulation on a real project shows no blockers.
  • You checked the impact of upgrading existing bindings.
  • You ran it end to end at least once successfully, and once with a failure that you fixed and resumed.
harness harnesses runtime runtimes 底座
Edit this page