Example plugins

These plugins live under external-plugins/ — outside apps/api, outside the workspace — to demonstrate what "delivered separately" means: each builds to a self-contained bundle and loads from PLUGINS_PATH or a registry, exactly like a third-party plugin would (see Bundling and distribution). Read them as worked examples of the contribution points documented in the developing area. Contributions below are the facts from each plugin.yaml; on a running instance, the console's Plugins page shows the events and manifest of each loaded plugin (see Inspect loaded plugins).

@posos/demo

dependsOn: @posos/clinical

The demonstration use case (nephrology / critical result): use-case-specific clinical computations, their result resources, and the associated validations and notifications. Everything specific to the demo scenarios lives here — the foundation (core + common + clinical) stays independent of it. A good first example of a compute-and-notify plugin.

@posos/geriatrie

dependsOn: @posos/common, @posos/clinical, @posos/demo

A geriatrics extension — the example of a multi-agent plugin. It exposes business types and five chained agents for deprescribing, patient communication, and post-withdrawal follow-up.

@posos/posos

dependsOn: @posos/clinical

Integration with the Posos APIs (AORT v3): clinical calculators, contraindication analysis (SNOMED conditions + LOINC observations), drug-interaction analysis, and adverse effects. The example of a plugin wrapping an external authenticated API (Google IAP service-account): it contributes the connection type posos-api (parameters audience, region; scheme ambient), which all its nodes require, and its client resolves the process identity through GOOGLE_APPLICATION_CREDENTIALS.

@posos/demo-softway

An integration demo for Softway Medical (an EHR): tools that analyse data captured in the record. The smallest example — a single-agent plugin whose one tool extracts observed symptoms from a nursing handover comment. Designed to grow.

@posos/aero-demo — cross-domain proof (aviation)

Self-contained demonstration that the core is domain-neutral: loaded ALONE (no clinical plugin, pnpm run dev:aero with instance.aero.yaml), it brings a complete domain — the flight context kind, its types and haul-type value set, the flightlog port (contract + Ports augmentation in ports.ts, in-memory reference adapter declared record: { contextKind: flight }, so GET /api/records/flight/<id> serves the logbook, plus a simulation sandbox), an ADS-B event source adsb-poll (adsb.fi open API, anonymous polling of aircraft states within a radius, landing = airborne→ground transition; an inbound connection type with the parameters lat, lon, distNm, intervalSeconds and apiUrl) with its declarative binding, the declared event FlightLanded (context flight) that the binding produces, and five nodes, among them the trigger aero.flight-landed, which references FlightLanded with event: and keeps a coded behavior. The companion workflow (content/aero-demo/, seeded by the instance seed: field) journals every observed landing and, when the logbook knows the flight plan, computes the flight's carbon estimate (distance × per-haul emission factor × seats — factors overridable in config, the method travels inside the report) and writes it to the logbook. apps/api/tests/unit/aero-demo.test.ts pins the self-sufficiency: the plugin loads alone and the shipped workflow validates against that catalog only.