OpenSite/Reference/Features/Plugins

OpenSite 0.0.1 · DevelopmentSource scope and availability

Discover a native, Python, or mixed provider and run its command through the installed SDK.

Stable identifier

extensions.host

Status reported by source

Implemented in the reviewed development source. Historical test evidence is recorded by the repository; no test rerun or product release is claimed by this publication.

Units

A contributed calculation stores canonical SI quantities. The sample span doubles a 2 m length to 4 m.

Behavior

Discovery reads opensite-plugin.json in each child directory and does not load the implementation. The first command loads that provider and its required dependencies. Several providers stay loaded. A workbench stores command ids. A workspace stores commands from more than one provider and does not load those providers until a command runs. Recompute does not consult either id. Python providers load from their declared path under a unique module name. opensite-python --plugins and --command provider/name print the result value.

Errors

A missing required id returns command_unavailable. A cycle or a repeated plugin id leaves the previous catalog in place. An incompatible sdk_api returns unsupported_version before the library is mapped. An unterminated negotiate result returns unsupported_version after mapping and does not start the provider. A failed start removes that provider's commands, settings, and catalog keys. Production denies document.edit with account_unavailable. Calls after shutdown return command_unavailable. Another thread returns reentrant_call.

Limitations

A headless workbench descriptor is a command collection, not a graphical working environment. Object types, groups, templates and services are supplied by the extension-platform layer. Desktop GUI extensions use a separate in-tree GUI contract. Native libraries remain mapped until process exit; providers are trusted code. SDK/toolchain identity must match; the C++ API is not universally ABI-stable. Independent GUI SDK distribution remains pending.

Available hosts

Headless Windows console/Python SDK host, and desktop workflows using the common plugin platform. Graphical extensions additionally require the GUI SDK contract.

Licensing and access

In-process plugins are trusted. An entitlement check is not a sandbox. tool.span needs document.edit. The production host returns account_unavailable for that capability. The development host installs an allow-all policy, which is not production enforcement.

Verification evidence

Repository evidence references (not rerun for this publication): CTest sdk.relocated on Windows Debug and Release. ADR-0004, ADR-0022, and ADR-0027. docs/verification/Phase-7-Acceptance.md.

Try this workflow

Build a native plugin — a worked lesson with expected results.

Documentation basis

Source-reviewed against development commit 77c3fee13944bcc4b5d487c77eb1f82fbe4c6ea7, branch feature/phase-13c-properties-python-expressions. This review inspected the implementation and repository evidence; it did not run the Windows application or repeat CTest.

• src/plugins/plugin_host.cpp
• src/application/extension.cpp
• docs/development/Plugin-SDK.md

OpenSite overview · Reference · Guides

Previous: OpenSite/Getting started

Next: OpenSite/Guides

All guides