OpenHealthSim

Install community plugins

Inspect an exact release, review its access, install it inactive and enable it separately.

Inspect before enabling#

Lab administration → Community plugins is the Store interface when the lab enables it. Browsing and local installation do not require sharing reports or usage. A deployed official registry and real external account linking are separate operational gates; this local MVP does not establish that a public registry is available.

An enabled plugin has full host access. A review result is evidence for a human decision, not a sandbox or a safety certificate.

Prepare, review, install, enable#

  1. Search the catalog and select an exact release. Read its source/pinned commit, licence, compatibility, archive digest, reports and advisories. Missing or cached evidence is labelled.
  2. Choose Prepare & inspect. The host checks bounded package bytes without running the plugin. Inspect code as text and read declared access.
  3. Save or discard configuration edits explicitly. A changed configuration produces a changed plan and invalidates the earlier approval/review.
  4. Optionally request AI review after reading the provider/input/cost disclosure. Review the findings, excluded files and incomplete coverage. You can also make the documented manual decision.
  5. Acknowledge Full host access, approve that exact plan and choose Install inactive. This stores the candidate without activating it.
  6. Choose Enable in this profile separately. The host rechecks the approved subject, configuration, profile revision, session gate and eligibility before importing code.

Updates follow the same sequence. They are not automatic. A running or paused session blocks ordinary Store mutations. Existing Plugins management retains its documented emergency disable path.

Interrupted requests and offline use#

If an action’s reply is unconfirmed, inspect its operation status before starting another one. The host reserves operation identities so the same request can be checked after a reload. A cancelled preparation/review is different from undoing an installation already in progress.

Cached archive bytes do not automatically establish current eligibility. The host may require fresh status or a separate short-lived stale-status consent for the exact subject. A known blocked or withdrawn release is not overridden. An unchanged completed installed receipt can reload independently of registry availability.

Reports, accounts and deletion#

Reviews remain local until you explicitly share the previewed public payload. Account linking and usage sharing are separate opt-ins. Usage totals describe participating hosts that reported a release, not verified downloads or clinical success.

Delete local review removes that plan’s local review content/history through a separate confirmation. It leaves installed code and public reports unchanged. Public withdrawal, shared usage deletion, account revocation and local disconnect each have their own status; offline pending work is not shown as completed remote deletion.

Removing an installation retires its code reference while retaining plugin data and the verified archive for recovery. Recovery can restore a verified reference disabled; inspect it before another explicit enable.

Troubleshooting#

ProblemNext action
Community plugins page is absentAsk the administrator whether the Store bundle and page are enabled for your role.
Registry unavailableInspect cached/unavailable labels; do not treat unknown reports or usage as zero.
Previous approval no longer appliesCompare the exact release/configuration/profile revision and prepare/review the new plan.
Enable blocked by a sessionEnd the intended running/paused session deliberately before ordinary changes.
Review incompleteRead excluded files and findings; record the required explicit reason rather than claiming complete coverage.
Deletion pendingCheck the original operation and its recovery/status controls; do not resend blindly.

Build an extension · Lab administration