v0.4.0

Added

• Cross-agent install — cmk install --ide <agent> (Task 50; the v0.4.0 differentiator). The kit can now install into agents beyond Claude Code. --ide kiro wires Kiro's surfaces in one step, covering both the IDE (GUI) and the kiro-cli terminal: MCP registration (.kiro/settings/mcp.json), steering (.kiro/steering/cmk.md, inclusion: always), the memory skills (.kiro/skills/memory-search + memory-write), automatic IDE hooks (.kiro/hooks/cmk-capture.kiro.hook on agentStop → deterministic cmk hook stop capture; cmk-inject.kiro.hook on promptSubmit → recall), and a CLI agent-config (~/.kiro/agents/cmk.json + a chat.defaultAgent pointer in ~/.kiro/settings/cli.json) carrying agentSpawn→inject and stop→capture hooks. (These fire live — verified against a real kiro-cli session.) The hook command is platform-correct (cmd.exe /c cmk hook … on Windows, where Kiro routes hooks through WSL). The CLI agent is registered as the default agent so its hooks auto-fire — but guarded: if you already have a default agent, the kit installs a named cmk agent instead and leaves your default untouched (the install notice tells you how to opt in). Both hook surfaces drive the same cmk hook dispatcher and the same capture/inject core. Restart Kiro to activate the hooks; steering/skills/MCP are immediate. A --ide kiro install also drops a managed AGENTS.md block at the project root — Kiro's always-loaded instruction file (per kiro.dev), which the CLI agent-config's prompt points at. It does not write Claude-Code-only files (CLAUDE.md, .claude/skills/) on a Kiro install — Kiro can't read them. --ide agents-md emits the same managed AGENTS.md block standalone — a portable memory-awareness rung for the many tools that read AGENTS.md. The memory core (store / search / compression / CLI) is identical across agents; only the per-agent wiring differs. Default remains claude-code (unchanged). Built on a shared, tested config-write primitive (mutateAgentConfig — touch-only-our-keys, refuses to clobber a corrupt config) so each future agent stays thin.
• Dual-agent projects — Claude Code and Kiro can share one repo. The installs are additive overlays: each cmk install [--ide <agent>] writes only its own agent's wiring and never clobbers the other's, and the shared memory brain (context/) is written once and reused. So a project used by both (two teammates, or one person switching tools) just runs both installs; --with-semantic set by either install is preserved by the other (it lives in the shared context/, not per-agent).
• cmk uninstall --ide kiro — uninstall is now agent-scoped for Claude Code + Kiro. cmk uninstall removes the Claude Code managed surface; cmk uninstall --ide kiro removes the Kiro surface (its .kiro/ managed blocks, skills, IDE hooks, the AGENTS.md block, and the guarded ~/.aws CLI agent). Both stay conservative — they never touch context/ (the shared brain) or any content outside the kit's markers.
• A memory delete-guardrail — the kit now blocks a command that would delete your memory before it runs. cmk install wires a PreToolUse hook (cmk-guard-memory) that inspects every shell command the agent is about to run and blocks it if it's a destructive command (rm, Remove-Item, git clean, git reset --hard, …) aimed at a memory path (context/, your ~/.claude-memory-kit persona tier, MEMORY.md/DECISIONS.md). A safe command, or a delete of anything else, runs normally — only a memory delete is stopped (with a clear reason). Wired for Claude Code (PreToolUse, Bash/PowerShell) — where it fires reliably. On Kiro, coverage depends on the surface: Kiro IDE and Kiro CLI V3 (2.9+) both rely on Kiro's own native "this is destructive, proceed?" confirmation (Kiro's IDE hooks can't be installed from a file, and Kiro CLI V3 redesigned its hook system — embedded preToolUse blocking was replaced by a permissions.yaml model; first-class V3 guardrail support is a planned follow-up). Fail-open by design: a broken guardrail never wedges your session, it just stops guarding. This came from a real data-loss incident — an accidental rm after a directory change deleted a repo's session/transcript memory; the guardrail makes that unrunnable.
• Kiro hooks auto-run — no more "Run / Reject" prompt every turn. A --ide kiro install now pre-trusts the kit's OWN hook commands so Kiro runs them silently instead of asking you to approve each one. On the IDE side it writes kiroAgent.trustedCommands into the workspace .vscode/settings.json; on the kiro-cli side it sets the agent-config's toolsSettings.shell.allowedCommands — both scoped to the kit's commands only (cmk hook *, cmk-guard-memory, plus cmk remember/cmk search for the kiro-cli explicit path), never a blanket wildcard. Without this, the inject/capture/guard hooks prompted on every fire and "automatic memory" wasn't automatic (found by the v0.4.0 Kiro live-test gate).
• Kiro IDE — MCP tools auto-approve so mk_remember and friends run prompt-free in chat. The IDE gates MCP tool calls through a different trust system than shell hooks, so the kit's memory tools (mk_remember, mk_search, …) used to pop a "Reject / Trust / Run" prompt every call. A --ide kiro install pre-approves the kit's 11 MCP tools via autoApprove in .kiro/settings/mcp.json. (mk_forget is safe to auto-approve: it previews and waits for a confirm token before deleting anything.)
• kiro-cli (the terminal client) — fully working, and no cmd.exe console-window popup. The terminal client differs from the IDE under the hood: the kit's kiro-cli agent (~/.kiro/agents/cmk.json) enables the shell tool (tools: ['*'] — without a tools capability set a custom agent can't run any command) and uses the kit's cmk remember / cmk search commands for explicit recall/capture (pre-trusted, so they run prompt-free), while the agentSpawn/stop hooks do automatic capture+inject every turn. Automatic capture reads kiro-cli's own session transcript (~/.kiro/sessions/cli/, a different location + format than the Kiro IDE) and runs the same extract→promote pipeline as Claude Code — so a cross-project rule you state in a kiro-cli chat ("always use uv, in every project") promotes to your persona automatically, with no command. The agent does not load an MCP server (includeMcpJson: false) — kiro-cli launches every stdio MCP server in a visible console window on Windows, so turning MCP off for the terminal agent removes that popup entirely (the terminal uses the shell commands instead of MCP tools). The memory core and behaviour are identical to the IDE/Claude Code; only the in-chat surface differs. All verified end-to-end against a real kiro-cli session (the cross-project rule landed in the persona tier live).
• Kiro now captures your prompts too — with the same privacy strip as Claude Code. On both Kiro surfaces, each prompt you send is now recorded to the session transcript (the searchable history tier) on the prompt-submit hook — matching Claude Code's behaviour — and anything inside <private>…</private> is stripped before it's written, so a secret you paste into a prompt never lands on disk. Previously the prompt-submit hook on Kiro only did recall (injected memory); it now does recall and capture.
• Kiro kiro-cli now records large file edits, like Claude Code. The kiro-cli agent wires a postToolUse hook (scoped to the fs_write file-write tool) that appends a one-line edit summary (file=… lines=…) to the session buffer when you make a substantial edit (>50 lines) — the same observation Claude Code records on PostToolUse. It feeds the same memory pipeline, so the kit notices what you're actively working on.
• Kiro IDE 1.0 — the kit's skills, hooks, and MCP tools run prompt-free, no per-tool approval. Kiro IDE 1.0 introduced a per-workspace trust store (~/.kiro/workspace-roots/<hash>/permissions.yaml). cmk install --ide kiro now pre-trusts the kit's own surfaces there — its shell hook commands, its 11 MCP tools, and its two skills (memory-write/memory-search) — so the agent never stops to ask "Load skill: memory-write — Allow?" or to approve a memory tool. Only the kit's own surfaces are added; your existing rules are preserved, and cmk uninstall --ide kiro removes only the kit's. (Verified live: the kit's full memory loop — inject, capture, observe, mk_remember, and the cross-project promotion — runs end-to-end on Kiro IDE 1.0 with no approval prompts.)
• Kiro IDE 1.0 support — new hook format + a memory delete-guard and edit-observation in the IDE. Kiro IDE 1.0 replaced the old .kiro.hook format with clean per-hook .kiro/hooks/*.json files (v1). cmk install --ide kiro now writes both — the v1 files cmk-{capture,inject,guard,observe}.json (for Kiro IDE 1.0+) and the legacy .kiro.hook files (so older Kiro keeps working; on 1.0 they sit inert as "legacy", no double-fire). The v1 format unlocks the full hook set in the IDE — recall, capture, a delete-guardrail (PreToolUse, which can block a destructive command), and large-edit observation (PostToolUse) — so the IDE now reaches parity with Claude Code and kiro-cli. The v1 schema + the capture Stop trigger are confirmed against Kiro IDE 1.0's own hook-migration output; the remaining firing details are verified in a live Kiro IDE 1.0 session at the cut-gate.

Fixed

• The Kiro CLI default-agent guard now tolerates a UTF-8 BOM in settings.json — it no longer clobbers your existing default agent. A ~/.kiro/settings/cli.json written by a Windows editor (or PowerShell Set-Content -Encoding utf8) carries a byte-order mark that broke the guard's JSON read, so it missed an existing chat.defaultAgent and overwrote the default with the kit's agent. Config reads are now BOM-tolerant kit-wide (a shared read-json helper, also applied to the mutate-agent-config path), so an existing default is correctly detected and preserved (the kit installs a named cmk agent instead).
• cmk doctor is now agent-aware — HC-1 no longer false-FAILs on a Kiro install. Before this, cmk doctor only knew about Claude Code: HC-1 hard-checked .claude/settings.json, so on a --ide kiro project it reported a scary FAIL with a wrong cmk repair --hooks hint — on the very feature this release ships. HC-1 now detects the install kind and treats Kiro's capture/inject as a capability check: it PASSes if either the IDE hooks (.kiro/hooks/cmk-capture + cmk-inject) or a cmk-owned CLI agent (~/.kiro/agents/) is present — so both a Kiro-IDE user and a kiro-cli-only user get a correct PASS — and FAILs (pointing at cmk install --ide kiro) only when neither surface exists. Claude Code installs are unchanged. (Found by the v0.4.0 Kiro live-test gate; the kiro-cli-only case caught by the two-pass code review.)
• The memory skills' YAML frontmatter is now valid, so Kiro accepts them. The memory-write skill's description contained an unquoted : (in the phrase "update memory: X is now Y"), which is invalid YAML — a strict parser reads it as a new key. Claude Code reads skill frontmatter leniently and never noticed, but Kiro strict-parses it and rejected the skill outright ("Invalid SKILL.md frontmatter"). Both memory skills' descriptions are now YAML block scalars (>-), immune to embedded colons/quotes/apostrophes, and a build-time validator strict-parses every skill's frontmatter so this can't recur. (Found by the v0.4.0 Kiro live-test gate.)

Fixed

• Background memory compression no longer fails needlessly when Claude is slow, so recent.md / the archive stay fresh. The lifecycle compression jobs that run with no time limit (daily distill, weekly curate, the session-start catch-up roll) were using the same 50-second budget as the in-session compressor, and retried too quickly — so a slow claude --print window could time them out and leave consolidated memory stale (a real case left recent.md 4 days behind). They now get a 120-second budget and wait between retries, matching the no-deadline nature of those background jobs. (#209)