cordis-plugin-development

# Develop Dynamic Cordis Plugins First determine whether a capability belongs on Host or Client, then query the real interface before writing code. Never infer a complete API from a Service name, Event payload, Slot props, theme token, or example. ## Standard workflow 1. Call `cordis_inspect_list` to obtain the Providers, methods, and schemas currently registered on Host and Client. 2. Select the smallest set of `cordis_inspect_query` calls needed to read the exact Services, Events, Builtins, Slots, Theme tokens, or Tools that the implementation will use. 3. For a new Plugin, design its first Package. To modify an existing Plugin, first use `cordis_inspect_self(pluginId, packageId)` to read the base source and diagnostics. 4. Write plain JavaScript in `code.host`, `code.client`, or both, then call `cordis_define`. 5. Call `cordis_run` with the final `pluginId` and `packageId` returned by define. 6. Handle approval, waiting, Client loading, and render failures from the Run card, steering messages, or `cordis_inspect_self`. 7. Use `cordis_stop` to disable the Plugin temporarily. Use `cordis_undefine` only when it is no longer needed. Do not wait in the same turn for user approval or asynchronous browser results. After `cordis_run` returns `awaiting-approval` or `starting`, end the current Tool flow and wait for the system to report the final outcome through state updates and steering. ## Tool usage guidance | Tool | Use it when | Do not | | --- | --- | --- | | `cordis_ins...