Pair the handler with context editing, and catch the rule nothing was watching

[aoreshkov]

Reviewed the module against the current
memory-tool and
context-editing
documentation.

Most of the answer was that nothing needed doing: every response string still matches the
specification, including the ones it has tightened since this was written (the 999,999-line limit,
the str_replace snippet, the 16,000-character view cap, the empty-root listing); all four of its
security asks already have both an implementation and a public explanation; and anthropic-java,
rabosh-api, Kotlin and Dokka are each pinned at the current stable release. None of that changed.

Two things were missing.

Context editing

clear_tool_uses_20250919 alongside the memory tool is the configuration a durable store exists
for, and the README said nothing about it — the word "compaction" appeared four times in this
repository and meant the engine's LSM compaction every time.

The new section shows the configuration on the example already in the file, and then carries the
three consequences that belong to this implementation rather than to the feature:

• The pre-clearing flush is bursty and produces create errors. It meets
  createOverwrites = false head-on. The model recovers by reading the file back and editing it, so
  the default is unchanged — but that is the shape to expect in a transcript, not a bug to report.
• memory does not belong in exclude_tools. That option is for results expensive to obtain
  again. Memory results are the cheapest thing in a transcript to discard, because each one can be
  read back off disk with a view.
• The burst is still one writing thread, under the same maxMemoryBytes cap.

Every SDK symbol in the snippet was read out of the pinned 2.54.0 sources rather than recalled, and
the one claim that was an inference — that betas and contextManagement reach the API through the
runner — was checked before it went in: BetaToolRunner rebuilds each request from
params.initialMessageParams.toBuilder().

checkDeleteDoesNotCompact

CLAUDE.md lists the design rules that fail silently, and each one names the instrument that
catches it. Exactly one named its absence instead: delete must not call compact(), and a breach
would show up as latency rather than a wrong answer, so no assertion about behaviour can see it. It
is also the rule most likely to be broken in good faith — "delete should free space" is the
intuitive position, and the correct code for it lives in the same file.

The task fails check if compact() appears anywhere but expireBefore, in the same shape as
checkNoNioPath. It was verified against a deliberate breach rather than assumed to work: with
database.compact() inserted into doDelete it failed naming the exact line, and that was then
reverted. CLAUDE.md no longer claims the rule is unguarded.

Also

• Say which half of the tool is beta. The tool is generally available; only the handler and
  runner helpers are not. A reader could reasonably have concluded from the example that adopting
  this handler meant adopting a beta API.
• Write out the manual loop that has always been named as the escape hatch for is_error
  fidelity and never shown. It was compiled before it was published, and it names what keying
  is_error off the Error: prefix misses — view's deliberately unprefixed missing-path string.
• Document a .png path as the text memory it is, since Claude's tool description promises
  view renders image files and create only takes file_text.
• -Drabosh.memory.smoke.model, so a release can spend one canary run on a larger model without
  editing the file. The default is unchanged.
• JUnit 6.1.3. The catalogue's own header claims every entry is the latest stable release, and
  that claim had gone stale.
• A project .claude/settings.json allowlisting the documented ./gradlew invocations. The
  live smoke test and bundleForCentral are deliberately not on it — one spends money, the other
  is the last step before an irreversible upload.

Verification

./gradlew build passes on the branch, with checkNoNioPath, checkDeleteDoesNotCompact and
checkKotlinAbi all running under check. No main source changed, no behaviour changed, and no
public signature moved, so api/rabosh-memory.api is untouched.

Two things worth a reviewer's judgement rather than a rubber stamp:

1. .claude/settings.json is not covered by .gitignore — only settings.local.json is — so this
   publishes contributor tooling into the tree. That is what a project-scoped settings file is for,
   but it is a new kind of file for this repository.
2. There is a pre-existing Gradle 10 incompatibility at build.gradle.kts:142
   (val crashDemo by tasks.registering(...)), found while verifying the new task and unrelated to
   it. Left alone deliberately; it is one line whenever the Gradle 10 bump is taken.

🤖 Generated with Claude Code