A lab has a device message that the application does not yet understand. The first step is a small, testable extension. In this walkthrough we use a fictional Acme device, the public author kit, and the existing plugin skill.
This is an engineering example, not a hardware certification. The Acme protocol is fictional. Passing these tests proves the declared software contract for these inputs. It does not establish clinical suitability, delivery to a physical device, or safe treatment decisions.
Start on the developer guide and download the complete author kit. It contains exact local SDK packages, a lockfile, the worked Acme example, and the plugin skill. You do not need access to the private implementation repository to follow this path.
Extract the whole folder into a new development location. Keep it separate from a live lab and its data. Node twenty two or twenty four and npm are prerequisites. Keep the SDK folder beside the package files so their local references remain valid.
Run node setup dot m j s from the extracted folder. The setup checks the download manifest before installing dependencies with lifecycle scripts disabled. First party SDK packages come from the included archives; pinned public third party dependencies come from the npm registry.
Now run the verification command shown. This is actual output from the extracted kit. The same literal samples are checked through the mapping and plugin paths, with independent expectations. Keep this baseline passing before changing the example for a real protocol.
Open the sample messages beside the cases. A blood pressure message produces two new readings. Heart rate is a display broadcast. Battery is a device event. These are different message kinds, so do not flatten them into one generic observation.
The example also checks repeated readings. Two equal numeric values can still be two legitimate measurements, with different reading identities. Preserve the supplied timestamp and scope. A classifier or language model should not invent those facts when the protocol supplies them.
Read the data only mapping before writing code. It makes field names, units and message kinds explicit. If that mapping expresses the actual protocol, keep the simpler solution. A code plugin is useful when the behavior needs a contract the mapping cannot represent.
The plugin declares the services it needs and registers its codec and device type through the public context. It does not reach into another plugin's source or private database, and it does not secretly open a second transport connection.
Registrations belong to the contributor's lifetime. When configuration changes or a plugin is replaced, old listeners and registrations must retire. An awaited operation must confirm that its owner is still current before publishing a result. This matters during a running lab.
Run the kit's type check and tests. These are actual successful results from this isolated copy. The tests include configuration and replacement behavior, not only a happy path. They are evidence for the tested contract, rather than a claim that every browser or operating system was exercised.
Give your coding agent the included i two l sim plugin skill and the public contract references. The public product name is Open Health Sim; the existing package and command names remain unchanged. Let the skill guide implementation, verification and an isolated development installation.
Make the request concrete. Supply the literal protocol samples, expected message kinds and units, malformed examples, and the behavior required on unload. Ask the agent to preserve the baseline tests and report any untested hardware or host integration. Avoid a request that only says make it work.
For a new extension, run the scaffold command shown with a new folder name and the appropriate kind. This creates an interface starting point inside the extracted kit, where it can resolve the exact SDK dependencies already installed in the parent folder.
The generated greeting is a starting point, not the finished device integration. Keep the manifest, configuration schema, lifecycle test and minimal contract host while implementing the real feature. Do not replace those boundaries with a hidden kernel patch or an unreviewed network call.
Run the generated project's type check and test from its own folder. There is no separate install in this example: the parent kit supplies the SDK. If you later move the project, bind its dependencies to the correct distribution rather than assuming unpublished packages exist on a registry.
Inspect the package before installing it anywhere. Read the requested services and permissions, and check that its entry points and license match the code you intend to ship. A coding agent can explain this report, but it should not silently approve new privileges for a lab.
Use the dry run to inspect what the archive would contain. Development data, recordings and secrets do not belong in a plugin package. The actual package needs the implementation, its manifest and required attribution. Review that artifact, not only the source folder you worked in.
A real development host check is a separate step when the feature relies on that boundary. Use an owned development profile and data directory, verify behavior and cleanup, and stop only that host. This video has shown SDK checks; it has not installed this scaffold into the demonstration lab.
For a lab installation, review requirements and permissions through the ordinary administrator workflow. Installation, configuration and activation are deliberate operations. A passing test suite or a generated archive does not bypass that approval, and a local example does not imply a public hosted store is deployed.
You now have a reproducible example, an isolated scaffold and concrete engineering evidence. Continue with the written plugin guide and the included skill, adapt one small contract at a time, and keep the untested boundaries visible when you hand the extension to a lab.