Memory wiki cache manifest and claim supersession#85055
Conversation
…e-scoped wiki.refresh
|
Codex review: found issues before merge. Reviewed July 1, 2026, 5:43 AM ET / 09:43 UTC. Summary PR surface: Source +2181, Tests +1254, Docs +43. Total +3478 across 30 files. Reproducibility: yes. for the review blockers by source inspection: the PR head's refresh path is local-only, prompt injection requires a new manifest absent from current caches, and claim-key inference hardcodes broad local-memory patterns. Review metrics: 2 noteworthy metrics.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Refresh the branch, route bridge-mode refresh through the Gateway-owned runtime, remove hardcoded local-domain claim inference, and land manifest/receipt gating only with an explicit upgrade and docs contract. Do we have a high-confidence way to reproduce the issue? Yes for the review blockers by source inspection: the PR head's refresh path is local-only, prompt injection requires a new manifest absent from current caches, and claim-key inference hardcodes broad local-memory patterns. Is this the best way to solve the issue? No as currently shaped. The manifest and receipt direction may be useful, but the best merge shape needs generic claim identity, bridge-safe refresh routing, and explicit upgrade/docs approval. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against cf2efbe5d515. Label changesLabel justifications:
Evidence reviewedPR surface: Source +2181, Tests +1254, Docs +43. Total +3478 across 30 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
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
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a9f5d8e1de
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| sortClaims(page).map((claim, index) => { | ||
| const claimId = buildStableClaimId(page, claim, index); |
There was a problem hiding this comment.
Derive fallback claim IDs from stable input order
Fallback claim_id generation currently depends on index from sortClaims(page), and that sort includes freshness ranking (assessClaimFreshness) that changes as wall-clock time advances. For id-less claims, an unchanged page can therefore emit different claim_id values across compiles, which breaks stable claim references and causes churn in supersession metadata and downstream claim-id lookups.
Useful? React with 👍 / 👎.
| const reconciledById = new Map( | ||
| reconcileClaims({ claims: raw.map((entry) => entry.input) }).map((claim) => [ | ||
| claim.claim_id, | ||
| claim, | ||
| ]), |
There was a problem hiding this comment.
Preserve distinct claims when claim_id values collide
Reconciled claims are indexed in a Map by claim_id only, so if two input claims share the same id (for example, copied frontmatter across pages), the later entry overwrites the earlier one. The subsequent lookup reuses that single reconciled object for both raw claims, which can assign the wrong statement/status/supersession fields to one record and corrupt claims.jsonl output.
Useful? React with 👍 / 👎.
|
ClawSweeper PR egg 🔥 Warming up: real-behavior proof passed; findings, security review, or rank-up moves are still in progress. Hatch commandComment Hatchability rules:
What is this egg doing here?
|
a9f5d8e to
ac2eb90
Compare
|
@clawsweeper hatch |
|
@clawsweeper re-review |
|
🦞👀 I queued a comment sync for this PR. If the egg is hatchable, ClawSweeper will generate the image once and update the existing review comment. |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
This pull request has been automatically marked as stale due to inactivity. |
|
Closing due to inactivity. |
Summary
wiki.statusread purity from write-scopedwiki.refreshwiki-cache-manifest.jsonatomically from wiki refresh/compileqa-labscenario fixtures in the optional Knip unused-file allowlist so the dependency gate reflects test-only scenario importsReal behavior proof
wiki.statusmust stay read-only,wiki.refreshmust own cache rebuild writes, and memory-wiki freshness/manifest behavior must be proven against a real WSL OpenClaw vault instead of only mocks.desktop-bg91j4g, clean OpenClaw worktree/tmp/openclaw-memory-wiki-sync-1779386309, live vault/cache under/home/chase/.openclaw/wiki/.openclaw-wiki/cache.pnpm tsgo, extension lint, plugin contract guardrail,git diff --check -- extensions/memory-wiki,pnpm deadcode:unused-files,node scripts/run-vitest.mjs run test/scripts/check-deadcode-unused-files.test.ts --maxWorkers=1, and then ran the patchedwiki refresh --jsonpath against the live vault followed by schema validation of the emitted manifest and all claim rows.manifest path /home/chase/.openclaw/wiki/.openclaw-wiki/cache/wiki-cache-manifest.json,pageCount: 1313,claimCount: 1933,updatedFilesCount: 3,manifestUpdated: true,source_import.updated_count: 5,source_import.skipped_count: 1260,missing_statement_count: 0,agent-digest.jsonhash prefixdddb9ac82de7, andclaims.jsonlhash prefix565137ebe75c. The follow-up live schema validation output wasmanifestValid: true,claimRowsChecked: 1933,invalidClaims: 0.wiki-cache-manifest.jsonwith cache hashes and metrics, the live manifest and 1,933 claim rows validated successfully, and local verification passed forpnpm exec vitest run --config test/vitest/vitest.extension-memory.config.ts extensions/memory-wiki(27 files / 135 tests),pnpm tsgo,pnpm lint -- extensions/memory-wiki, the plugin package contract guardrail,pnpm deadcode:unused-files, and the deadcode allowlist unit test.Verification
pnpm exec vitest run --config test/vitest/vitest.extension-memory.config.ts extensions/memory-wiki(27 files / 135 tests passed)pnpm tsgopnpm lint -- extensions/memory-wikinode scripts/run-vitest.mjs run --config test/vitest/vitest.contracts-plugin.config.ts src/plugins/contracts/plugin-sdk-package-contract-guardrails.test.ts --maxWorkers=1pnpm deadcode:unused-filesnode scripts/run-vitest.mjs run test/scripts/check-deadcode-unused-files.test.ts --maxWorkers=1git diff --check -- extensions/memory-wiki scripts/deadcode-unused-files.allowlist.mjs