fix(memory-wiki): keep claim freshness tied to evidence timestamps by ly-wang19 · Pull Request #97465 · openclaw/openclaw

ly-wang19 · 2026-06-28T09:58:20Z

What Problem This Solves

Memory-wiki claim freshness should prefer explicit claim/evidence timestamps. The old path could fall back to page-level freshness even when a claim carried malformed timestamp data, which can hide bad claim metadata as a page-level stale/fresh result.

This replaces the earlier attempt in #97420, which was closed only by the author queue limit after review pressure, not because the patch was invalid.

Why This Change Was Made

The fix keeps page updatedAt as a fallback only for claims with no explicit claim/evidence timestamp fields. If the claim provides timestamp metadata but it is malformed, the result stays unknown instead of silently using page freshness.

User Impact

Memory-wiki health reports better distinguish untimestamped claims from claims with broken timestamp metadata. That makes freshness signals more trustworthy without changing the healthy explicit-timestamp path.

Evidence

git diff --check
node scripts/run-vitest.mjs extensions/memory-wiki/src/claim-health.test.ts
.agents/skills/autoreview/scripts/autoreview --mode local

Autoreview result: clean; no accepted/actionable findings. The reviewer confirmed explicit claim/evidence timestamps remain authoritative, malformed explicit timestamps stay unknown, and page freshness is only a fallback when timestamps are absent.

After-fix Real Behavior Proof

Ran a real memory-wiki compile against a temporary vault on this PR branch. The vault had two claims on a page with fresh page-level updatedAt:

claim.malformed-explicit: claim/evidence timestamp fields present but malformed.
claim.untimestamped: no claim/evidence timestamp fields, so it should still use page freshness.

Command shape: node --import tsx ... compileMemoryWikiVault(config) with render.createDashboards=true, then read reports/claim-health.md and .openclaw-wiki/cache/claims.jsonl from the compiled vault.

Redacted terminal output:

{
  "rootDir": "<redacted-temp-vault>",
  "compiledClaimCount": 2,
  "reportPath": "reports/claim-health.md",
  "reportClaimHealthLines": [
    "- Stale or unknown claims: 1",
    "- [Claim Freshness Proof](../entities/claims.md): `claim.malformed-explicit`: Malformed explicit timestamp should not inherit page freshness. (status supported, 1 evidence, missing updatedAt)"
  ]
}

This proves the generated claim-health report path now surfaces the malformed explicit timestamp as unknown while the untimestamped claim is not listed as stale/unknown and continues to inherit the fresh page timestamp.

…mped claims

clawsweeper · 2026-06-28T09:59:16Z

Codex review: needs maintainer review before merge. Reviewed June 28, 2026, 6:12 AM ET / 10:12 UTC.

Summary
The branch changes memory-wiki claim freshness so claim/evidence timestamps win over page freshness, page updatedAt is only an untimestamped-claim fallback, and focused unit coverage is added.

PR surface: Source +13, Tests +100. Total +113 across 2 files.

Reproducibility: yes. Current main passes page updatedAt into claim freshness candidates, and the PR body provides after-fix live output from a real memory-wiki compile showing the changed malformed-versus-untimestamped behavior.

Review metrics: 1 noteworthy metric.

Claim freshness fallback: 1 fallback narrowed. Page updatedAt now remains a fallback only when claim/evidence timestamp fields are absent, which changes generated health semantics for malformed explicit metadata.

Stored data model
Persistent data-model change detected: unknown-data-model-change: extensions/memory-wiki/src/claim-health.test.ts, vector/embedding metadata: extensions/memory-wiki/src/claim-health.test.ts, vector/embedding metadata: extensions/memory-wiki/src/claim-health.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: canonical
Canonical: #97465
Summary: This PR is the active replacement for an earlier closed, unmerged same-author attempt at the memory-wiki claim freshness behavior.

Members:

superseded: fix(memory-wiki): keep claim freshness tied to evidence #97420 - The earlier PR was closed unmerged by author queue-limit automation and is explicitly replaced by this PR.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🦞 diamond lobster
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

none.

Risk before merge

[P1] Existing memory-wiki claims with malformed explicit claim/evidence updatedAt fields will become unknown instead of inheriting page freshness, which can add health/lint warnings and affect query or digest ordering.

Maintainer options:

Accept stricter malformed metadata handling (recommended)
Maintainers can intentionally accept that malformed explicit claim/evidence timestamp metadata now surfaces as unknown freshness while untimestamped claims still inherit page freshness.
Pause for compatibility policy
If existing malformed metadata should keep page freshness during upgrade, pause this PR and ask for an explicit migration or compatibility design.

Next step before merge

[P2] No narrow automated repair is identified; the remaining action is maintainer review of the compatibility-sensitive freshness behavior before merge.

Security
Cleared: The diff only changes memory-wiki TypeScript freshness logic and colocated unit tests; it does not touch dependencies, workflows, secrets, package metadata, or code-download paths.

Review details

Best possible solution:

Land the claim-health-local fix after maintainers accept the stricter malformed-timestamp semantics; keep page freshness as the fallback only for truly untimestamped claims.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main passes page updatedAt into claim freshness candidates, and the PR body provides after-fix live output from a real memory-wiki compile showing the changed malformed-versus-untimestamped behavior.

Is this the best way to solve the issue?

Yes. assessClaimFreshness is the shared classifier used by reports, lint, query ranking, and digests, so fixing the timestamp precedence there avoids duplicated policy in callers.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 8d168c836af3.

Label changes

Label changes:

add proof: sufficient: Contributor real behavior proof is sufficient. Sufficient live output is present: the PR body shows a redacted real memory-wiki compile where malformed explicit timestamps become unknown and untimestamped claims still use page freshness.
add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): Sufficient live output is present: the PR body shows a redacted real memory-wiki compile where malformed explicit timestamps become unknown and untimestamped claims still use page freshness.
remove rating: 🦪 silver shellfish: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.
remove status: 📣 needs proof: Current PR status label is status: 👀 ready for maintainer look.

Label justifications:

P2: This is a normal-priority memory-wiki correctness fix with limited blast radius across claim health, lint, query ranking, and digest output.
merge-risk: 🚨 compatibility: The PR changes existing malformed claim/evidence timestamp metadata from page-freshness fallback to unknown freshness, changing generated health and lint output for those users.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🦞 diamond lobster.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): Sufficient live output is present: the PR body shows a redacted real memory-wiki compile where malformed explicit timestamps become unknown and untimestamped claims still use page freshness.
proof: sufficient: Contributor real behavior proof is sufficient. Sufficient live output is present: the PR body shows a redacted real memory-wiki compile where malformed explicit timestamps become unknown and untimestamped claims still use page freshness.

Evidence reviewed

PR surface:

Source +13, Tests +100. Total +113 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	19	6	+13
Tests	1	102	2	+100
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	121	8	+113

What I checked:

Repository policy applied: Root and extensions-scoped AGENTS.md were read fully; the fallback behavior is compatibility-sensitive under the review policy and the patch stays inside the bundled plugin boundary. (AGENTS.md:31, 8d168c836af3)
Current main fallback behavior: Current main includes params.page.updatedAt in the claim freshness candidates, so page freshness can mask older or malformed claim/evidence timestamp metadata. (extensions/memory-wiki/src/claim-health.ts:139, 8d168c836af3)
PR head fix shape: The PR head tracks whether claim/evidence timestamp fields are present and only falls back to params.page.updatedAt when none are present. (extensions/memory-wiki/src/claim-health.ts:139, 2831f2a94467)
Regression coverage: The added tests cover latest evidence timestamps, stale explicit evidence hidden by a newer page timestamp, untimestamped fallback, and malformed explicit timestamp classification as unknown. (extensions/memory-wiki/src/claim-health.test.ts:68, 2831f2a94467)
Shared runtime surface: Claim freshness feeds the generated claim-health report and stale-or-unknown report count, so the classification change is user-visible in memory-wiki output. (extensions/memory-wiki/src/compile.ts:169, 8d168c836af3)
Lint and query impact: Memory-wiki lint warns on stale or unknown claims and query ranking scores matches through assessClaimFreshness, confirming the fallback change affects more than one report path. (extensions/memory-wiki/src/lint.ts:257, 8d168c836af3)

Likely related people:

giodl73-repo: Current-main blame for assessClaimFreshness points to the merged refactor commit 4010b81a77f40c17ebfc55a6b47571dc1ef92902, and live PR metadata shows that change came through Refactor external plugin catalog toward feeds #95846. (role: recent area contributor; confidence: high; commits: 4010b81a77f4; files: extensions/memory-wiki/src/claim-health.ts, extensions/memory-wiki/src/compile.ts, extensions/memory-wiki/src/lint.ts)
vincentkoc: Commit 44fd8b0d6e38fcc371cb367ca5972297928331c6 introduced the claim-health report and the memory-wiki freshness consumers that this PR changes. (role: feature introducer; confidence: high; commits: 44fd8b0d6e38; files: extensions/memory-wiki/src/claim-health.ts, extensions/memory-wiki/src/compile.ts, extensions/memory-wiki/src/lint.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

ly-wang19 · 2026-06-28T10:07:53Z

@clawsweeper re-review

clawsweeper · 2026-06-28T10:07:56Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

…penclaw#97465) * fix(memory-wiki): keep claim freshness tied to evidence * fix(memory-wiki): preserve page freshness fallback only for untimestamped claims --------- Co-authored-by: ly-wang19 <ly-wang19@users.noreply.github.com>

…penclaw#97465) * fix(memory-wiki): keep claim freshness tied to evidence * fix(memory-wiki): preserve page freshness fallback only for untimestamped claims --------- Co-authored-by: ly-wang19 <ly-wang19@users.noreply.github.com> (cherry picked from commit 630034e)

ly-wang19 added 2 commits June 27, 2026 20:41

fix(memory-wiki): keep claim freshness tied to evidence

22dc422

fix(memory-wiki): preserve page freshness fallback only for untimesta…

2831f2a

…mped claims

openclaw-barnacle Bot added extensions: memory-wiki size: S labels Jun 28, 2026

vincentkoc merged commit 630034e into openclaw:main Jun 28, 2026
162 of 175 checks passed

github-actions Bot mentioned this pull request Jun 28, 2026

📡 Upstream Digest — 2026-06-28 19:05 UTC curtismercier/openclaw-mods#1168

Open

Navigation Menu

Uh oh!

fix(memory-wiki): keep claim freshness tied to evidence timestamps - #97465

fix(memory-wiki): keep claim freshness tied to evidence timestamps#97465
vincentkoc merged 2 commits into
openclaw:mainfrom
ly-wang19:fix/memory-wiki-claim-freshness-fallback

ly-wang19 commented Jun 28, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 28, 2026 •

edited

Loading

Uh oh!

ly-wang19 commented Jun 28, 2026

Uh oh!

clawsweeper Bot commented Jun 28, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

ly-wang19 commented Jun 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

After-fix Real Behavior Proof

Uh oh!

clawsweeper Bot commented Jun 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ly-wang19 commented Jun 28, 2026

Uh oh!

clawsweeper Bot commented Jun 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ly-wang19 commented Jun 28, 2026 •

edited

Loading

clawsweeper Bot commented Jun 28, 2026 •

edited

Loading

clawsweeper Bot commented Jun 28, 2026 •

edited

Loading