🔴 AGENTS.md violation: skills/lossless-claw/references/config.md not updated with rollupDebugEnabled

The PR adds the rollupDebugEnabled config option to src/db/config.ts:94-95, openclaw.plugin.json:196-199, docs/configuration.md:115, and README.md:186, but does not update skills/lossless-claw/references/config.md. The AGENTS.md rule explicitly states: "Keep skills/lossless-claw/references/config.md consistent with docs/configuration.md, openclaw.plugin.json, and the runtime defaults in src/db/config.ts. When config keys, aliases, defaults, or precedence rules change, update that bundled skill reference in the same change."

The AGENTS.md rule requires updating skills/lossless-claw/references/config.md whenever config keys change. The new rollupDebugEnabled config option was added to src/db/config.ts, openclaw.plugin.json, docs/configuration.md, and README.md but is missing from skills/lossless-claw/references/config.md. Add a section for rollupDebugEnabled to that file, following the same structure as existing entries (e.g. the transcriptGcEnabled or proactiveThresholdCompactionMode sections). Include the key name, type (boolean), default (false), env override (LCM_ROLLUP_DEBUG_ENABLED), and a brief description of its purpose (registers the operator-facing lcm_rollup_debug inspection tool).

Was this helpful? React with 👍 or 👎 to provide feedback.

🔴 AGENTS.md violation: docs/configuration.md full example block missing rollupDebugEnabled

The reference table at docs/configuration.md:115 correctly adds rollupDebugEnabled, but the "Complete plugins.entries.lossless-claw.config example" block at lines 15–65 of the same file was not updated. The AGENTS.md rule states: "update the reference tables and the full example plugins.entries.lossless-claw.config block at the top of that file in the same change." Other boolean defaults like transcriptGcEnabled: false (line 47) are shown in the example, so rollupDebugEnabled: false should appear there as well.

Add rollupDebugEnabled: false to the full JSON example block at the top of docs/configuration.md (lines 15-65). It should be placed after transcriptGcEnabled: false (line 47), consistent with the key ordering in src/db/config.ts and openclaw.plugin.json. The entry should be: "rollupDebugEnabled": false

Was this helpful? React with 👍 or 👎 to provide feedback.

🔴 AGENTS.md violation: no regression test for new rollupDebugEnabled config option

The PR adds rollupDebugEnabled as a new config option with env override LCM_ROLLUP_DEBUG_ENABLED and default false, but does not add or update any test in test/config.test.ts. The AGENTS.md rule states: "Add or update a regression test when changing config options so schema drift is caught before release." The existing config tests (e.g. expect(config.transcriptGcEnabled).toBe(false) at test/config.test.ts:41) follow a clear pattern: the defaults test verifies the default, the env-override test verifies env takes precedence, and the manifest test verifies the schema entry exists. None of these exist for rollupDebugEnabled.

Add regression tests for the new rollupDebugEnabled config option in test/config.test.ts. Following the existing patterns:

1. In the defaults test (around line 41), add: expect(config.rollupDebugEnabled).toBe(false)

2. In the env-override test (around line 71), add rollupDebugEnabled: true to the plugin config fixture and LCM_ROLLUP_DEBUG_ENABLED: 'true' to the env, then verify: expect(config.rollupDebugEnabled).toBe(true)

3. In the manifest schema test (around line 551), add: expect(manifest.configSchema.properties.rollupDebugEnabled).toEqual({ type: 'boolean' })

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: startOfWeekKey ignores its timezone parameter — correct because day-of-week is timezone-invariant for date strings

The startOfWeekKey function at src/rollup-builder.ts:1101 accepts a timezone parameter but explicitly ignores it with void timezone. This is correct: a date key like 2026-04-27 represents Monday regardless of timezone — the day-of-week calculation only needs the calendar date, not the timezone. The Date.UTC() construction and getUTCDay() call correctly determine the weekday for any YYYY-MM-DD string. The void timezone is presumably intentional to match the function signature pattern used elsewhere while documenting the deliberate omission.

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: Cross-midnight sub-day windows are intentionally rejected

The parseExplicitWindow function in src/tools/lcm-recent-tool.ts:470-499 returns null when endMinutes <= startMinutes, which means windows like "9pm-2am" (crossing midnight) are not supported. This falls through to the error message listing valid period formats.

This appears deliberate — a cross-midnight window would need to span two calendar days, complicating the day-boundary logic. Users can work around this by specifying two separate queries (e.g., "yesterday 9pm-24:00" and "today 0:00-2am").

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: Rollup recall policy prompt significantly changes tool escalation ordering

The LOSSLESS_RECALL_POLICY_PROMPT in src/plugin/index.ts:161-206 reorders the tool escalation chain. lcm_recent is now listed as step 1, with lcm_grep demoted to step 2. The prompt also adds 6 new lines of routing guidance specifically for lcm_recent. This is a user-facing behavioral change — models will now prefer temporal retrieval over free-text search for compacted history questions. This matches the PR's intent but operators should be aware the recall heuristic changed.

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: buildDailyRollups race condition with concurrent ingest handled via scannedAt guard

In src/rollup-builder.ts:350-461, buildDailyRollups reads state, processes days, then re-reads state before updating. A concurrent ingest could set pending_rebuild: 1 and update last_message_at between the scan start and the final state write. The code correctly guards against this: shouldClearPending at line 451-453 uses isTimestampAtOrBefore(latestState?.last_message_at, scannedAt), which only clears pending_rebuild if no new messages arrived after the scan began. The last_rollup_check_at update uses laterDate() to prevent backwards movement. This is a well-designed optimistic concurrency pattern.

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: Unrecognized window suffix on date:YYYY-MM-DD produces a slightly misleading error

When a user passes period: 'date:2026-04-27 foobar', resolveWindowPeriod at src/tools/lcm-recent-tool.ts:565 matches group1=date:2026-04-27 and group2=foobar, but parseNamedWindow('foobar') and parseExplicitWindow('foobar') both return null, so resolveWindowPeriod returns null. Control falls to line 632 where normalized.startsWith('date:') matches, and day = 'date:2026-04-27 foobar'.slice(5) = '2026-04-27 foobar'. The assertValidPlainDate check fails, throwing 'period date must be in the form "date:YYYY-MM-DD" with a real calendar date.' — the date IS valid, it's the window that's unrecognized. The user still gets a clear error, just with a slightly imprecise message.

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: Current-day freshness guard prevents stale rollup serving

The lcm_recent tool at src/tools/lcm-recent-tool.ts:1222-1228 implements a freshness guard: canUseStoredCurrentDay is false when the resolved period's key matches today's date, preventing use of a stored (potentially stale) daily rollup for the current day. For multi-day periods like 7d, the code at lines 1302-1358 separately handles the current day via live fallback (getRecentSummaryFallback) while using stored rollups for completed prior days. For weekly/monthly stored rollups, canUseStoredResolvedRollup additionally checks !hasPendingRebuild to avoid serving stale aggregates when daily rollups need rebuilding. This three-layer freshness strategy is well-designed.

Was this helpful? React with 👍 or 👎 to provide feedback.

📝 Info: Relative time windows ('last Nh/Nm') always use fallback path — never stored rollups

When resolvePeriod processes "last 3h" or "last 90m", the returned PeriodResolution has kind = undefined and periodKey = undefined (src/tools/lcm-recent-tool.ts:541-546). This causes both stored-rollup branches in the execute function (lines 1200-1204 and 1221-1224) to be skipped, always falling through to the leaf-summary SQL fallback. This is correct behavior — relative windows are anchored to new Date() and cannot match pre-built period-keyed rollups.

Was this helpful? React with 👍 or 👎 to provide feedback.