cordis-plugin-development
Persistent Harness plugins
For implementation, use ordinary workspace files to author a bundle, then plugin_manager with action: install_bundle and the absolute package directory as target to install it in the current profile. Changes affect every session in that profile and survive restart. Load editing-cordis-compositions for agent preset changes.
Do not write the profile's package.json or cordis.patch.yml, create packages under $DSH_HOME, or run pnpm in the profile directory: install_bundle performs those steps, and each hand-made write outside the workspace needs its own approval. Every plugin_manager action, including list_plugins and list_bundles, also needs approval without Full access, so call it only when its result decides the next step.
Design or review
Read the applicable references below and inspect the proposed or existing plugin against current APIs. Report design choices or findings instead of following the installation workflow. Do not write files, install bundles, or change profile state unless the user requests implementation.
Enable a shipped plugin
A shipped bundle can resolve a plugin row and leave it disabled. The row id and its reason are in the shipped patch, packages/bundle/*/cordis.patch.yml in a source checkout. Write a workspace bundle whose patch overrides that row with disabled: false and inserts the Host rows it depends on; a source checkout's apps/cli/config/examples/<feature>/cordis.yml lists them for opt-in features. Packages shipped with dsh resolve from the dsh installation, so the bundle declares no dependencies on them. Install it with install_bundle.