Skip to content

Release Notes: v0.4.0

Date: 2026-10-12

Version 0.4.0 makes the HTTP server the resident owner for each configured workspace, tightens resource bounds, and adds native structured evidence for event and temporal retrieval. It also updates the default segmented search router and includes security backports for the lru cache used by Tantivy.

Project rename: Lint-AI is now Membrick

This release adopts Membrick as the project and product name. The Rust crate, Python package, Node.js package, OpenClaw plugin, website, and repository use the new name. Existing users can continue to invoke the legacy lint-ai binary and use prior provider configuration; installers migrate old provider entries to membrick.

Resident multi-workspace server

  • Each canonical project root has one resident MemoryService, one staged writer, and one published search view. Workspace and provider-memory writes pass through that owner, and searches query its published view.
  • A single server can serve multiple projects. The primary --project-root is allowed by default; other roots require repeatable --workspace-root options. Roots are canonicalized and matched exactly.
  • The active-workspace limit defaults to eight and includes the primary workspace. A full registry returns 429; restart the server to release its resident workspaces. Idle workspace eviction is not implemented.
  • MCP adapters and hooks send workspace context so reads and writes for a project reach the same server-owned service.

Resource bounds and security

  • HTTP bodies are limited to 16 MiB, concurrent requests to 128, and request duration to 30 seconds. Memory requests also enforce message and identifier size limits.
  • Workspace routes reject roots outside the configured allowlist before opening or indexing them. Workspace-wide MCP operations remain unavailable in tenant mode.
  • Dashboard browser requests validate their origin, conversation-state and session-recording files use symlink-resistant access, and tenant identity is preserved through provider-memory retrieval.
  • Vendored lru 0.12.5 includes upstream security backports while retaining the API expected by Tantivy 0.25.0. Version-based audit tools can still report the upstream advisories; see the backport notes.

Structured evidence and temporal retrieval

  • Claims can represent subject, canonical predicate, object, assertion status, event time, and source evidence including text and turn or chunk location. Older records remain readable when optional claim fields are absent.
  • Native extraction and retrieval support event relationships without requiring beKIND. Temporal query ranges use the supplied reference date, and explicit closed intervals filter candidates before ranking. Ordered event questions return matching events chronologically.
  • Reasoning vocabulary is bundled as readable rules in data/reasoning_rules.json; typed Rust logic applies the rules, evidence checks, and temporal constraints.
  • The segmented server default is CoverageLocalDistinctiveness. Other strategies remain selectable with --segment-routing.

Benchmark results

The 2026-10-12 normal-depth native-event run evaluated all 500 LongMemEval-S questions with beKIND disabled. Any-hit Recall@5/@10/@20 was 96.4%/98.4%/99.0%; fractional Recall@5/@10/@20 was 89.38%/94.70%/95.93%. The separate four-times-document-depth diagnostic reached 100% Any-hit Recall@20; it changes benchmark retrieval depth and does not describe the production result depth. See the dated benchmark results and HTTP server measurements.

Operational notes

  • Keep the server bound to loopback for single-user local use. Non-loopback binds require explicit opt-in and authentication.
  • The server remains a single-process owner for each on-disk workspace store. Do not run multiple server processes against the same workspace data.
  • Provider-memory batch writes without workspace context target the primary workspace for compatibility; use workspace-aware MCP and hook routes for additional projects.