Request: cut a new release — critical fixes #354 & #579 merged but unreleased for 2 months

[Footree]

Summary

Requesting a new release to ship fixes that have been merged to main for 2+ months but are unavailable to users on the latest published release (v1.1.0-beta.10, 2026-03-23).

The gap

PR	Fix	Merged	In v1.1.0-beta.10?
#354	P0: smart-extractor writes state: "confirmed" instead of "pending"	2026-03-27	❌ (released 4 days earlier)
#579	P1: auto-recall query uses cached user message instead of event.prompt	2026-04-11	❌
#374	autoRecallMaxQueryLength configurable (hardcoded → config)	2026-03-27	❌

Users running the latest release are still hitting all three issues.

Real-world impact

We deployed memory-lancedb-pro as the memory backend for a production agent. Within the first night:

• 8 memories captured by smart-extractor about the deployment event
• All 8 blocked by the governance filter (meta.state !== "confirmed" → return false)
• 0 injected into agent context → the agent had complete amnesia about the deployment it was supposed to monitor

Additionally, the P1 recall query issue (#579) caused vector searches to embed the system prompt prefix (e.g. the agent identity/role description) instead of the user's actual question, degrading retrieval quality on every query.

P2 suggestion: default coherence

Even after #354 ships, there's a design gap: the pending/confirmed governance model (#312) was designed for a manual review workflow, but smart-extractor is an automated pipeline. With autoCapture: true + autoRecall: true (the recommended config), the system should be coherent out-of-the-box:

• If the extraction pipeline is automated (smart-extractor with LLM quality control + dedup), new memories should be confirmed by default (fix: auto-captured memories write confirmed state to unblock autoRecall #354 fixes this ✅)
• If a manual review gate is desired, there should be a config option (e.g. initialState: "pending" | "confirmed") rather than silently deadlocking the automated path
• For future consideration: an automatic promotion mechanism (e.g. confidence-based or access-frequency-based) could bridge the two models

What we did

We've applied local patches matching #354 + #579 to keep our deployment running. Happy to test any release candidate. 🙏

References

• Bug: Auto-captured memories stuck in pending state, blocked from auto-recall by governance filter #350 — original bug report (auto-captured memories stuck in pending)
• fix: auto-captured memories write confirmed state to unblock autoRecall #354 — P0 fix (merged)
• fix: use cached raw user message as auto-recall query #579 — P1 fix (merged)
• feat: harden memory governance defaults and tooling #312 — governance model design (where pending default was introduced)
• [BUG] bad_recall_count accumulates permanently — last_confirmed_use_at never written causes permanent memory suppression #633 — related bad_recall_count feedback loop (fixed by fix(auto-recall): Tier 1 memory counter fix (ms-based suppression + lazy-heal) #712)

[AliceLJY]

Acknowledged. This is a release-management request rather than a code bug.

Before cutting a new beta, I would want the maintainer pass to confirm whether any already-merged fixes since v1.1.0-beta.10 require migration notes or config callouts. The concrete release driver here is clear: #354 and #579 are merged but not available to package users, so the next beta should at least include those fixes in the changelog.

I am leaving this open as the release tracking issue.

[TurboTheTurtle]

@AliceLJY Thanks for keeping this open as release tracking. Since several user-impacting fixes are now merged but unreleased, happy to help test an RC or sanity-check a beta cut when maintainers are ready.

[AliceLJY]

Adding another release driver from #741: npm beta currently still points to 1.1.0-beta.9, and OpenClaw 2026.5.x rejects that package because the published artifact lacks compiled runtime output for index.ts / expected dist entrypoints. Current master is already 1.1.0-beta.11 with dist/index.js runtime entry and prepack verification, so a fresh beta publish would unblock those installs as well as the already-merged user fixes tracked above.

[TurboTheTurtle]

Current release state still looks blocked on publishing rather than code activity: GitHub latest is v1.1.0-beta.10 from 2026-03-23, npm latest is 1.0.32, npm beta is 1.1.0-beta.9, and master is already 1.1.0-beta.11.

#877 added the release checklist/readiness guardrails. The main pre-publish blocker I see now is #890 / #893, since publishing before the dist freshness fix risks shipping stale compiled output.

Happy to test the beta install on current OpenClaw once #893 is merged and a maintainer can publish 1.1.0-beta.11 under the beta dist-tag.