ZeroClaw
ZeroClaw records a replacement-first rule for shrinking its built-in toolset
ZeroClaw merged documentation requiring a working, documented and independently reviewed replacement before an existing integration is removed or migrated. The September 22 change records an August decision; it removes no tools and grants no blanket exception for Schema V4 cleanup.
ZeroClaw merged a standing documentation rule on September 22 for a familiar agent-platform tension: make the core smaller without quietly removing capabilities operators depend on. The replacement-first policy says a working built-in integration stays available until its replacement is real, documented and independently reviewed. PR #11042 records an earlier core decision from August 20 rather than approving a fresh removal program.
The policy now lives beside the built-in tool inventory's migration questions. A proposed replacement must preserve configuration migration, security policy, receipts or audit behavior where relevant, compatibility and rollback. Every concrete removal, feature gate or migration still needs its own issue and pull request. The original RFC does not pre-approve those changes, and Schema V4 cleanup remains separate rather than becoming a blanket exception.
The inventory itself distinguishes tools to keep in the core, candidates for explicit gating, capabilities to externalize later and cases with insufficient evidence for action. Its introduction calls the table a classification map, not a removal plan. The September merge supplies a citable decision for reviewers and links it from the tools overview; no runtime registry or configuration was changed by this documentation patch.
The facts
- PR #11042 merged on September 22, 2026; the underlying RFC decision dates to August 20. - Working built-in integrations must remain until a replacement is real, documented and independently reviewed. - Review must cover migration, security policy, relevant receipts or audits, compatibility and rollback. - Each removal, feature gate or migration requires its own issue and PR rather than blanket RFC approval. - Schema V4 cleanup under issue #8310 remains separate from this policy. - The change touches standing documentation and overview links, with no tool removal, runtime or configuration change.
Why it matters
Moving a capability into a plugin can reduce core complexity while exporting operational risk to users. A replacement that answers the same prompt may still lose permission checks, logs, migration support or rollback. ZeroClaw's rule makes that hidden work part of the acceptance criteria. The policy's practical value will depend on enforcement in later removal reviews, not on the presence of a documentation heading.
Current
Checked September 23, 2026. The inspected release baseline is v0.8.5. The primary source is merged 2026-09-22T11:59:58Z. Tagged release availability and development-source state are separate: a release baseline does not establish that a proposed setting or newly merged feature is in an installed package.
Evidence
Primary: zeroclaw-labs/zeroclaw PR #11042 (https://github.com/zeroclaw-labs/zeroclaw/pull/11042). Context and implementation: zeroclaw-labs/zeroclaw issue #6165 (https://github.com/zeroclaw-labs/zeroclaw/issues/6165); zeroclaw-labs/zeroclaw — tool-inventory.md (source) (https://github.com/zeroclaw-labs/zeroclaw/blob/master/docs/book/src/developing/tool-inventory.md); zeroclaw-labs/zeroclaw issue #11016 (https://github.com/zeroclaw-labs/zeroclaw/issues/11016). The linked source text was inspected; reported experiments and test results remain attributed to their authors.
Operator take
Use the inventory to identify candidate boundaries, then evaluate each migration separately. A replacement should demonstrate the old operator contract, including a failed call and a rollback, before the original is withdrawn. Keep classification discussions separate from release decisions: describing an integration as externalizable is not evidence that its replacement exists. For maintainers, link the concrete review back to this standing rule instead of re-deriving the same policy in every thread.
Caveat
This is a new documentation record of an earlier accepted policy, not a new runtime capability or an announced removal. The author did not run a local mdBook render and relies partly on CI documentation checks. Later integration migrations still require their own evidence and approval.
This is a new documentation record of an earlier accepted policy, not a new runtime capability or an announced removal. The author did not run a local mdBook render and relies partly on CI documentation checks. Later integration migrations still require their own evidence and approval.