Host support: Qoder — native plugin projection with explicit CLI and IDE capability profiles

[ScriptedAlchemy]

Scope / evidence

P2 feature expansion. Research date 2026-09-06; Agent Bundle baseline 5fc8de37c9695b816d55bdcf18a6bcb1dfee69f5. Official documentation was read; no Qoder host was installed or run. One Qoder issue owns the product family, but CLI, IDE/JetBrains and QoderWork contracts must not be silently conflated.

Official documentation and specs

• CLI plugin authoring, manifest, scopes, management, marketplace
• CLI hook guide
• IDE plugin capabilities
• IDE/JetBrains hook contract
• Current Qoder plugin UX
• Custom extension publishing/import guide
• Documentation index for exact reference pages
• Qoder-owned harness reference
• Ponytail native manifest example — example, not the specification

Confirmed native shape

The CLI recommends .qoder-plugin/plugin.json with stable name/version metadata. It can discover commands, agents, skills, output styles, binaries, hooks and bundled MCP configuration by convention. Explicit manifest paths can override several convention directories. Configuration scope is user/project/local; plugin management operates on installed identifiers, not just display names.

The IDE hook page explicitly distinguishes its capabilities from CLI/QoderWork. Its documented events and command/HTTP handler support must be treated as a separate profile. It uses JSON input, exit/output decisions, and different blockability by event. Hook configurations from user/project/local files can combine; restart behavior also differs from the CLI. Do not reuse a Claude codec merely because event names overlap.

The newer Qoder product pages describe UI import/create workflows. A supported CLI command is not proof of a compatible IDE automation endpoint, nor proof that regional/product distributions accept an identical manifest.

Proposed generated artifact

composite-root/
  .qoder-plugin/plugin.json
  skills/review/SKILL.md
  commands/review.md
  hooks/qoder-hooks.json       # explicit pointer, if the pinned parser supports it
  hooks/tool-before.qoder.mjs
  .mcp.json                   # convention; replace only via proven native binding

Minimal manifest example:

{
  "name": "example-plugin",
  "version": "1.0.0",
  "description": "Project review tools",
  "skills": ["./skills"],
  "hooks": "./hooks/qoder-hooks.json"
}

All nontrivial path overrides in this example require native parser acceptance at the supported version. If an override is unavailable, use the documented convention and run composite collision checks rather than pretending it is relocatable.

A native hook document has a top-level hooks object. The CLI documents plugin-root and plugin-data variables QODER_PLUGIN_ROOT and QODER_PLUGIN_DATA; generated wrappers must distinguish code from writable data and preserve quoting. Do not put a build-checkout absolute path into published hook commands.

Operator setup

The CLI documents this lifecycle:

qoder plugins validate ./composite-root
qoder plugins install ./composite-root --scope project
qoder plugins list --json
qoder plugins disable example-plugin --scope project
qoder plugins enable example-plugin --scope project
qoder plugins uninstall example-plugin --scope project --keep-data

Apply installation changes with the documented restart or /plugins reload. Exact installed IDs may include @local; use host inventory rather than deriving them. A validation command can report an empty directory without proving it is installable, so acceptance must perform real installation and resource discovery.

For IDE distribution, document Extensions/Plugins import or marketplace installation separately. Never overwrite ~/.qoder/settings.json, project settings, permissions, or connector credentials to simulate installation.

Agent Bundle work

1. Define the first supported Qoder profile and pin native version, parser/schema and hook reference revision. Add a capability table for the other entry points rather than enabling every event globally.
2. Emit native documents from existing skill/command/rule/operation declarations. Keep operation implementations shared and hook wrappers host-specific.
3. Model before-tool blocking, prompt context, after-tool observation and lifecycle notification individually. Missing native control semantics must produce unsupported diagnostics.
4. Connect declared MCP servers through the documented native contract; reuse executable records and environment handling. Keep optional MCP absent for content-only plugins.
5. Use receipt-owned registration/state lifecycle for the new installer. Validate scope and native identifiers before removal; do not reinterpret an arbitrary configured data directory as purge authority.
6. Respect .mcp.json, hooks/hooks.json, commands and rule auto-discovery collisions with the existing composite. Prefer proven explicit paths; otherwise reject an incompatible selection.

Acceptance

• Pin and label CLI versus IDE/JB capabilities and unsupported entry points.
• Native validation plus installation finds exactly the declared skills/commands/hooks/MCP entries.
• Test command/HTTP differences without requiring HTTP handlers for the initial adapter.
• Hook JSON, exit codes, deny/continue, context injection, errors and timeouts match the chosen profile.
• Reload/restart does not duplicate hooks; disabled installed plugins remain disabled.
• Project/local/user scopes and installation IDs survive replacement and cleanup.
• Packed and relocated artifacts contain all referenced hidden directories; no source checkout required.
• Composite negative-discovery tests prevent Qoder from loading another host's conventional hook map.
• Static plugin adds no unused Flight/MCP/state process.
• Documentation includes real successful native proof separately from parser/fixture checks.

Boundaries

Reuse existing src/adapters, canonical manifest, install receipts, build-compose.test.ts and packed small-plugin tests. No global permission edits, native approval bypass, new orchestration service, automatic sharing of incompatible IDE/CLI contracts, or broad relaxation of AB4106.

[ScriptedAlchemy]

Resolved by #721 (72a8857ebe).

Qoder CLI — observed docs retrieved 2026-09-06; no CLI version is published on any page. Supported at the skills tier: the emitted skill tree loads; the manifest does not.

Surface	State	Evidence
manifest	unavailable	2026-09-06: https://docs.qoder.com/cli/plugins-reference states the manifest "must not be placed in the plugin root directory", so the emitted root plugin.json is not a recognized manifest and the plugin is identified only by its directory name.
skills	supported	2026-09-06: https://docs.qoder.com/cli/Skills documents plugin skills/ with the same structure as ~/.qoder/skills/, requiring frontmatter name (lowercase, numbers, hyphens, max 64) and description (max 1024) — both emitted, within both bounds, by the pinned Agent Skills lowering.
mcp	supported	2026-09-06: https://docs.qoder.com/cli/mcp-reference states Qoder is "Compatible with mcp.json (without a leading dot) as a fallback for .mcp.json", reads the top-level mcpServers key, and accepts type values stdio and http/streamable-http — the transports this projection emits.
placeholders	unavailable	2026-09-06: QODER_PLUGIN_ROOT and QODER_PLUGIN_DATA are documented only for hooks (https://docs.qoder.com/cli/hooks-reference), and no ${...} placeholder is documented for MCP server configuration, so the emitted ${PLUGIN_ROOT} and ${PLUGIN_DATA} tokens are not proven to expand.
hooks	unavailable	2026-09-06: Qoder reads plugin hooks from hooks/hooks.json and requires the extra { "hooks": ... } wrapper (https://docs.qoder.com/cli/hooks-reference); Agent Plugins 1.0.0 defines no hooks, so this projection emits no hooks document for it to read.

Paths it reads: mcp.json, skills.
Per-file precedence: .mcp.json (mcp).
Install: qoder plugins install <plugin directory> --scope user.

Every row above is pinned to that client's own documentation on the date shown, is validated on every build, and renders in INSTALL.md and the generated hosts reference. A surface recorded unavailable or degraded names exactly what the client would need; no unsupported feature is projected silently.