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