Render adapters: Cursor, opencode, Copilot CLI (+ Gemini import parity)

[kelos-bot]

🤖 Kelos Worker Agent @gjkim42

Follow-up to the render-adapter roadmap in #7. PR #22 landed the first increment — the Gemini CLI adapter plus the opt-in agents: mechanism — and Closes #7 on merge. This issue tracks the remaining increments from that roadmap so they aren't lost.

Each follows the same pattern PR #22 established (register in allAdapters(), add an Agent* constant, implement Render, opt-in via agents:):

• Cursor — AGENTS.md + .cursor/mcp.json (mcpServers) + .cursor/hooks.json; skills under .cursor/skills/. Permissions are partly file-based via the Cursor CLI's .cursor/cli.json (permissions.allow/deny) per the strategist note on Grow beyond Codex + Claude: prioritized render-adapter roadmap (Gemini CLI, Cursor, opencode, Copilot CLI) #7 — but Kanon has no neutral permissions field yet, so that maps only once permissions exist in the schema.
• opencode — AGENTS.md + single opencode.json using the distinct mcp key (type: local|remote, not mcpServers) and a permission block.
• GitHub Copilot CLI — ~/.copilot/ layout (mcp-config.json, hooks/*.json, skills/, copilot-instructions.md).
• Gemini import parity — geminiAdapter.Import currently returns an empty no-op (render-only scope). Lift GEMINI.md + settings.json back into neutral config, reusing the existing sanitizeMap/normalize* machinery.

Note: opencode/Cursor permissions and Copilot's richer surface may need a neutral permissions schema first — see #18 (native passthrough) which is related.

Verify the version/schema uncertainties flagged in #7 (Gemini legacy-vs-nested keys, hook schemas, AGENTS.md auto-detection) against primary docs at implementation time.

[kelos-bot]

🤖 Kelos Task Status

Task kanon-triage-issues-3ddf9245d5a3 has succeeded. ✅

[kelos-bot]

🤖 Kelos Agent @gjkim42

Kanon Triage Report

Kind: kind/api — adds new accepted --agent flag values (cursor/opencode/copilot) and new agents: schema entries, and explicitly anticipates a neutral permissions schema. This is user-facing surface, consistent with the parent roadmap #7 (also kind/api).
Priority: priority/backlog — depends on other work: PR #22 (the Gemini adapter + agents: mechanism it builds on) has not merged yet, and the permissions-dependent parts (Cursor/opencode/Copilot) are gated on #18.
Actor: actor/human — kind/api issues introduce new user-facing surface (new --agent values, agents: schema, a prospective permissions schema) and must be reviewed with a maintainer before any PR; not handled autonomously.

Status: STILL VALID (as a tracking issue) — but blocked, and its stated premise is currently inaccurate.

Evidence:

• ⚠️ PR Add Gemini CLI render adapter with explicit agents opt-in #22 has not landed. The issue opens with "PR Add Gemini CLI render adapter with explicit agents opt-in #22 landed the first increment … and Closes #7 on merge," but PR Add Gemini CLI render adapter with explicit agents opt-in #22 is still OPEN (mergedAt: null) and main (HEAD 0b7d194) contains none of that work.
• The codebase has only Codex and Claude adapters. adaptersFor (internal/core/render.go:55) returns codexAdapter/claudeAdapter only; there is no allAdapters()/adapterByName registry, no AgentGemini constant (internal/core/types.go:6-8 defines only codex/claude/all), no Config.Agents/agents: field, and no gemini.go. The "pattern PR Add Gemini CLI render adapter with explicit agents opt-in #22 established (register in allAdapters(), add an Agent* constant, opt-in via agents:)" does not exist on main yet — it lives in unmerged Add Gemini CLI render adapter with explicit agents opt-in #22.
• The "Gemini import parity" item references geminiAdapter.Import returning a no-op; that adapter doesn't exist on main at all, so this sub-item is entirely contingent on Add Gemini CLI render adapter with explicit agents opt-in #22 merging first.
• Net: every checkbox here is downstream of Add Gemini CLI render adapter with explicit agents opt-in #22 landing, and the Cursor/opencode/Copilot permission surfaces are further gated on a neutral permissions schema (Add a 'native passthrough' managed-settings type to manage permissions (and other non-portable settings) without a lossy neutral schema #18).

Duplicates found: #7 (the parent render-adapter roadmap — kind/api, still open; #23 tracks exactly its remaining Cursor/opencode/Copilot/Gemini-import items, so they currently overlap heavily and #7 is not yet closed because #22 is unmerged). #18 (native-passthrough permissions — related, not a duplicate; a prerequisite for the permission-bearing adapters).

Recommendation: KEEP OPEN as a roadmap tracking issue, but treat as blocked on PR #22 (and partly on #18). Suggested next steps for a human: (1) get PR #22 merged so #7 actually closes and the adapter pattern exists on main; (2) once merged, reconcile the scope split between this issue and #7 to avoid duplicate tracking. No autonomous PR should be opened until #22 lands and the kind/api surface (new agent names + any permissions schema) is reviewed.