fix(adapters): Kimi Code and Junie dropped MultiEdit/NotebookEdit content

[jothimani-rajendran]

What this changes

Both Kimi Code's and Junie's docstrings claim Claude Code's wire protocol exactly:

• Kimi: "same PascalCase event names, same snake_case fields, same tool_input"
• Junie: "Junie states outright that its field names follow Claude Code's wire protocol so a script can be shared between the two"

But parse() in each read only tool_input.content/new_string -- so MultiEdit's edits[].new_string and NotebookEdit's new_source were dropped, exactly the class of bug claude_code.py was fixed for in #35.

MultiEdit {edits: [{new_string: "AWS_SECRET=akia"}]}  →  event.content = None   (before)
NotebookEdit {new_source: "SECRET=akia"}              →  event.content = None   (before)

A content-scanning deny policy that already works on claude_code's MultiEdit/NotebookEdit went silently blind on these two agents -- on the one write path each adapter's own docstring claims to support.

Claim check

• No capability claim widened -- both docstrings already claim Claude Code's exact field vocabulary; this makes the claim true rather than guessing at an unrecorded shape.
• Verified by execution: reproduced both content and path returning None for MultiEdit/NotebookEdit on both adapters before the fix, confirmed non-None after.
• Mirrors claude_code.parse's existing fallback chain (content or new_string or new_source or joined(edits)), not a new pattern.

Checks

• pytest -q -- 754 passed, 1 skipped (up 2)
• ruff clean; stdlib-only; signed off

Notes for the reviewer

Second item off plan/vendor-truth-review-backlog.md's "distinct danger items" list (items kimi_code.py:~100 and junie.py:~80), both dropped-field / high|medium / likely, confirmed by execution first per the backlog's own stale-finding caveat.

---

Generated by Claude Code