Skip to content

fix(memory-wiki): don't prune unsafe-local pages when a source path is transiently unavailable#97560

Closed
LEXES7 wants to merge 4 commits into
openclaw:mainfrom
LEXES7:fix/memory-wiki-unsafe-local-transient-prune
Closed

fix(memory-wiki): don't prune unsafe-local pages when a source path is transiently unavailable#97560
LEXES7 wants to merge 4 commits into
openclaw:mainfrom
LEXES7:fix/memory-wiki-unsafe-local-transient-prune

Conversation

@LEXES7

@LEXES7 LEXES7 commented Jun 28, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Closes #97523

What Problem This Solves

Fixes an issue where memory-wiki users running vaultMode: "unsafe-local" would permanently lose imported pages and their hand-written human-notes blocks when a configured source path became transiently unavailable (an undocked external drive, a rebooting NAS, or a cloud-synced folder that is not mounted yet). Any wiki_* tool that triggered a sync while the path was gone deleted every imported page for that path; when the path came back, pages were recreated empty and the user's notes were unrecoverable.

Why This Change Was Made

A transiently unreadable source collects zero artifacts in exactly the same way a real deletion does, and the unsafe-local sync pruned unconditionally on that signal. The fix makes the prune aware of the exact unreadable subtree:

  • collectUnsafeLocalArtifacts now records the precise paths that could not be read — fs.stat failing on a configured path, a missing explicit file, or fs.readdir failing on the configured directory or any nested subdirectory (each failing directory is reported individually).
  • syncMemoryWikiUnsafeLocalSources preserves only the imported entries that live under those unreadable paths (keeps their keys active), then prunes normally. So a transient outage never deletes a page or its human-notes, while readable siblings — even a deleted file in a readable directory under the same configured root as an unreadable nested mount, or another configured source entirely — still get their stale pages cleaned up.

This is the narrowed, source-scope-aware behavior ClawSweeper recommended. An explicit configured file that vanishes is indistinguishable from an unmounted one, so its page is conservatively kept (data-safety first) until it returns.

User Impact

Users with unsafe-local notes on removable, network, or cloud-synced storage no longer lose imported pages or their manually authored human-notes when a source path (or a nested mount inside it) is briefly offline. Healthy sources keep cleaning up deleted files normally. After the source returns, the next sync reconciles cleanly with notes intact. No config changes required.

Evidence

Real workflow run (standalone, non-test) — Node 24

Drove the real syncMemoryWikiUnsafeLocalSources from a standalone script (node --import tsx) against a real on-disk vault — not the test harness. The outage is a real directory fs.rename (ENOENT), the way an undocked drive / unmounted NAS presents. Steps per run: (1) sync imports the source page, (2) write a hand-written note into the page's human-notes block on disk, (3) take the source dir offline and sync, (4) remount and sync.

BEFORE — pristine base 7ac8b48a08 (current main):

[1] sync: imported=1 removed=0 page=sources/unsafe-local-notes-…-ideas-md-….md
[2] wrote user note into the page's human-notes block
[3] sync during outage: removed=1 pageStillOnDisk=false userNoteSurvived=false
[4] sync after remount: removed=0 userNoteSurvived=false

RESULT: FAIL — data was lost

AFTER — this branch, identical steps:

[1] sync: imported=1 removed=0 page=sources/unsafe-local-notes-…-ideas-md-….md
[2] wrote user note into the page's human-notes block
[3] sync during outage: removed=0 pageStillOnDisk=true userNoteSurvived=true
[4] sync after remount: removed=0 userNoteSurvived=true

RESULT: PASS — page + user note survived the transient outage

Regression tests (real on-disk vault, pristine base vs this branch)

These drive the real syncMemoryWikiUnsafeLocalSources against a real on-disk vault, with the outage produced by a real fs.rename / fs.chmod on the source path (nothing in the collect/prune path is stubbed; only the plugin state store is the in-memory test store, which is incidental to the prune logic).

BEFORE — pristine base 7ac8b48a08, same tests, the bug reproduces:

 ✓ prunes stale unsafe-local pages when a file inside a readable directory is deleted
 × keeps imported pages and human notes when a configured directory is transiently unreadable
 × does not prune when a nested subdirectory is transiently unreadable
 × prunes a deleted readable sibling while a nested directory is unreadable
 × keeps the imported page when an explicit configured file is transiently unavailable
 × prunes a readable source even when another configured source is unreadable

 Tests  5 failed | 3 passed (8)

AFTER — this branch, identical inputs:

 ✓ imports explicit private paths and preserves unsafe-local provenance
 ✓ prunes stale unsafe-local pages when a file inside a readable directory is deleted
 ✓ keeps imported pages and human notes when a configured directory is transiently unreadable
 ✓ does not prune when a nested subdirectory is transiently unreadable
 ✓ prunes a deleted readable sibling while a nested directory is unreadable
 ✓ keeps the imported page when an explicit configured file is transiently unavailable
 ✓ prunes a readable source even when another configured source is unreadable
 ✓ caps composed unsafe-local filenames to the filesystem component limit

 Tests  8 passed (8)

What the new/updated tests prove:

  • keeps imported pages and human notes when a configured directory is transiently unreadable — imports a page, writes a real user note into its human-notes block, takes the source directory offline with a real fs.rename outage, syncs (asserts removedCount 0 and page + note survive), then re-mounts and syncs again (clean, note intact).
  • does not prune when a nested subdirectory is transiently unreadable — a nested subdirectory made unreadable mid-sync no longer prunes its page (removedCount 0).
  • prunes a deleted readable sibling while a nested directory is unreadable — proves the precise-subtree scope: only the unavailable subtree is preserved; a genuinely deleted readable sibling under the same configured root still prunes (removedCount 1).
  • keeps the imported page when an explicit configured file is transiently unavailable — explicit-file (unsafeLocal.paths file shape) coverage: a vanished explicit file is preserved (removedCount 0, page still on disk).
  • prunes a readable source even when another configured source is unreadable — one source offline, the other deletes a file → the healthy source still prunes (removedCount 1) while the offline source's page is preserved.

oxlint and oxfmt --check are clean on both changed files.

Note: the local full extension lane shows 4 failures in source-sync-state.test.ts / doctor-contract-api.test.ts with TypeError: statement.columns is not a function. These reproduce identically on a clean checkout with my changes stashed; they are a node:sqlite incompatibility with local Node 23 (non-LTS) and are unrelated to this change. CI runs on Linux Node 24.

AI-assisted (Claude Code); change reviewed and understood by the author.

@openclaw-barnacle openclaw-barnacle Bot added extensions: memory-wiki size: S triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. labels Jun 28, 2026
@clawsweeper

clawsweeper Bot commented Jun 28, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs maintainer review before merge. Reviewed June 28, 2026, 5:27 PM ET / 21:27 UTC.

Summary
The PR changes memory-wiki unsafe-local sync to record unreadable source paths, preserve matching imported-source entries during prune, and add regression tests for transient outages plus ordinary deletions.

PR surface: Source +59, Tests +187. Total +246 across 2 files.

Reproducibility: yes. source-backed. The canonical issue and PR body provide a production-function repro, and current main plus v2026.6.10 still drop missing configured paths before the destructive prune runs.

Review metrics: 1 noteworthy metric.

  • Explicit configured-file cleanup: 1 behavior changed, 0 config added. A missing configured file is now treated as transiently unavailable, which favors data safety but changes existing stale-page cleanup semantics.

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

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #97523
Summary: This PR is the stronger candidate fix for the canonical unsafe-local transient outage data-loss issue; another open PR attempts the same root cause, and adjacent memory-wiki work covers related but distinct human-note preservation.

Members:

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

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
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:

  • [P2] Get maintainer acceptance for the explicit configured-file retention tradeoff before merge.

Risk before merge

  • [P1] A missing explicitly configured file now retains its imported page while that file remains configured; maintainers should explicitly accept the data-safety versus stale-page cleanup tradeoff before merge.

Maintainer options:

  1. Accept Conservative Explicit-File Retention (recommended)
    Maintainers can land the current behavior if they accept that a configured file deleted while still listed in config leaves its source page until the source returns, config changes, or a later cleanup path handles it.
  2. Require Explicit-File Disambiguation
    Ask for a narrower rule or proof that distinguishes intentional explicit-file deletion from transient unavailability without reintroducing note loss.

Next step before merge

  • The remaining blocker is maintainer acceptance of the explicit-file cleanup compatibility tradeoff and choosing this stronger PR over the competing candidate.

Security
Cleared: No concrete security or supply-chain concern was found; the diff stays within existing memory-wiki local filesystem sync code and tests.

Review details

Best possible solution:

Land the scoped unreadable-path preservation fix once maintainers accept conservative explicit-file retention, then close the canonical issue and supersede the weaker competing PR.

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

Yes, source-backed. The canonical issue and PR body provide a production-function repro, and current main plus v2026.6.10 still drop missing configured paths before the destructive prune runs.

Is this the best way to solve the issue?

Yes, with maintainer acceptance of the explicit-file retention tradeoff. The latest head preserves only exact unreadable paths before pruning, which is the narrow owner-boundary fix for the data-loss path.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

  • P0: The PR targets a confirmed path that can permanently delete imported memory-wiki pages and user-authored human-notes blocks during routine storage outages.
  • merge-risk: 🚨 compatibility: The diff changes unsafe-local cleanup semantics for missing explicit files, so existing users may retain stale imported pages after upgrade.
  • rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
  • status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body includes standalone terminal output from a real on-disk unsafe-local workflow showing before-fix data loss and after-fix page plus note preservation.
  • proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes standalone terminal output from a real on-disk unsafe-local workflow showing before-fix data loss and after-fix page plus note preservation.
Evidence reviewed

PR surface:

Source +59, Tests +187. Total +246 across 2 files.

View PR surface stats
Area Files Added Removed Net
Source 1 68 9 +59
Tests 1 197 10 +187
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 2 265 19 +246

What I checked:

Likely related people:

  • vincentkoc: Introduced unsafe-local source sync and the later incremental imported-source pruning path that this PR changes. (role: introduced behavior; confidence: high; commits: 7b62fcd87da8, a78c4de737c5; files: extensions/memory-wiki/src/unsafe-local.ts, extensions/memory-wiki/src/source-sync-state.ts, extensions/memory-wiki/src/bridge.ts)
  • steipete: Refactored memory-wiki source sync state into SQLite, adjacent to the state entries this prune path preserves or deletes. (role: recent area contributor; confidence: medium; commits: a4236bd6faf6; files: extensions/memory-wiki/src/source-sync-state.ts)
  • yetval: Authored the merged human-notes preservation fix; this PR protects that preserved content from being bypassed by destructive prune deletion. (role: recent adjacent contributor; confidence: medium; commits: 0ec12df24512; files: extensions/memory-wiki/src/source-page-shared.ts, extensions/memory-wiki/src/markdown.ts, extensions/memory-wiki/src/source-page-shared.test.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.

@openclaw-barnacle openclaw-barnacle Bot removed the triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. label Jun 28, 2026
@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P0 Emergency: data loss, security bypass, crash loop, or unusable core runtime. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. labels Jun 28, 2026
@LEXES7 LEXES7 changed the title fix : don't prune unsafe local pages when a source path is transiently unavailable fix(memory-wiki): don't prune unsafe-local pages when a source path is transiently unavailable Jun 28, 2026
@LEXES7

LEXES7 commented Jun 28, 2026

Copy link
Copy Markdown
Contributor Author

Codex review: needs real behavior proof before merge. Reviewed June 28, 2026, 4:44 PM ET / 20:44 UTC.

Summary The PR changes memory-wiki unsafe-local sync to detect unreadable configured paths or nested directories, skip imported-source pruning during those outages, and add regression coverage for transient outages plus readable-directory deletion.

PR surface: Source +34, Tests +82. Total +116 across 2 files.

Reproducibility: yes. source-backed. The linked issue includes a production-function current-main repro, and current main still drops missing configured paths before the shared prune deletes inactive unsafe-local entries.

Review metrics: 2 noteworthy metrics.

  • Unsafe-local prune decision: 1 group-wide fallback changed. The diff changes when imported unsafe-local pages are pruned, which affects both data-loss prevention and stale-page cleanup.
  • Configured-file deletion coverage: 1 removed, 0 replacement. The previous explicit configured-file deletion regression is replaced by directory deletion coverage, leaving a supported unsafeLocal.paths shape unproved.

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

Root-cause cluster Relationship: fixed_by_candidate Canonical: #97523 Summary: This PR is a candidate fix for the canonical unsafe-local transient source outage data-loss issue, with another open same-root candidate and adjacent already-merged human-notes work.

Members:

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

Merge readiness Overall: 🧂 unranked krab Proof: 🧂 unranked krab Patch quality: 🦪 silver shellfish Result: blocked until real behavior proof from a real setup is added.

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

Rank-up moves:

  • [P0] Add redacted terminal output, logs, or a recording showing a real unsafe-local transient outage preserving the page and human notes on this branch.
  • Restore or replace coverage for explicit configured-file deletion while keeping transient outage protection.
  • Make the prune guard source-scope aware, or get maintainer approval for the broader stale-page behavior.

Proof guidance:

  • [P1] Needs real behavior proof before merge: The PR body provides targeted test output only, so the external contributor still needs redacted terminal output, logs, or a recording from a real unsafe-local workflow on this branch. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

  • [P1] The PR body proof is unit-test output only; the external contributor still needs redacted terminal output, logs, or a recording from a real unsafe-local workflow on this branch.
  • [P1] The group-wide prune skip changes existing cleanup semantics for configured file paths: a deleted configured file is always unreadable, so its imported page can linger indefinitely unless the config changes or pruning becomes source-scope aware.

Maintainer options:

  1. Scope Pruning Before Merge (recommended)
    Make the prune decision source-scope aware so unavailable configured paths preserve their entries while available directories and explicit file deletion behavior remain covered.
  2. Accept Conservative Stale Pages
    Maintainers can intentionally accept group-wide skip behavior, but the configured-file cleanup tradeoff should be explicit and tested before landing.

Next step before merge

  • [P1] Contributor real behavior proof is still missing, and the remaining prune-scope compatibility decision needs author or maintainer revision before merge.

Security Cleared: No concrete security or supply-chain concern was found; the diff stays within existing memory-wiki local filesystem sync code and tests.

Review findings

  • [P1] Preserve configured-file pruning — extensions/memory-wiki/src/unsafe-local.ts:271-278

Review details
Label changes
Evidence reviewed
What the crustacean ranks mean
How this review workflow works

Addressed the review:

  • Implemented the recommended "Scope Pruning" option: the prune is now
    per-source-root. Unreadable roots (undocked drive, unmounted nested mount,
    missing explicit file) preserve their entries, while readable roots still
    clean up genuinely deleted files — even when another configured source is
    offline at the same time.
  • Re-added explicit-file (unsafeLocal.paths file shape) coverage that the
    metric flagged.
  • Added real after-fix terminal proof to the PR body (7 passing unsafe-local
    tests, including a multi-path partial-outage case and the human-notes survival
    case).

No config/state migration: this only changes which imported pages are pruned
during a sync; it reads/writes the same source-sync state shape.

@LEXES7

LEXES7 commented Jun 28, 2026

Copy link
Copy Markdown
Contributor Author

@clawsweeper re-review

Added real before/after behavior proof to the PR body: on pristine base 7ac8b48 the transient outage prunes/deletes the page and human-notes (4 cases fail), and on this branch the same real fs.rename/chmod outages preserve them (7 pass). These drive the real syncMemoryWikiUnsafeLocalSources against a real on-disk vault; nothing in the collect/prune path is stubbed.

Also implemented the recommended scope-aware prune: unreadable roots preserve their entries while readable roots still clean up genuinely deleted files (proven by the multi-path partial-outage case). No state/data-model migration — same source-sync state shape.

Note on the cluster: this is distinct from the merged #95614. That fix preserves notes on page re-ingest, but it only runs while the page still exists; this bug is the prune-delete path that removes the page file outright during an outage, before any re-ingest preservation can run.

@clawsweeper

clawsweeper Bot commented Jun 28, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🦞🧹
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.

@LEXES7

LEXES7 commented Jun 28, 2026

Copy link
Copy Markdown
Contributor Author

@clawsweeper re-review

Added a standalone NON-TEST real-workflow log to the PR body (Node 24, real on-disk vault, real fs.rename outage), driving the real syncMemoryWikiUnsafeLocalSources outside the test harness:

  • BEFORE (pristine base 7ac8b48): during the outage removed=1, the page is deleted and the user note is gone (RESULT: FAIL — data lost).
  • AFTER (this branch): during the outage removed=0, the page and user note survive, and the post-remount sync stays clean (RESULT: PASS).

This is in addition to the fs-backed regression suite. The standalone run uses the in-memory source-sync fallback store (the SQLite store is unrelated to the prune logic). Remaining explicit-file retention is the intentional data-safety tradeoff under "Accept Conservative Explicit-File Retention".

@clawsweeper clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. and removed rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. labels Jun 28, 2026
@LEXES7

LEXES7 commented Jun 28, 2026

Copy link
Copy Markdown
Contributor Author

@clawsweeper re-review

Addressed the nested-outage scope finding: the prune now preserves only the EXACT unreadable subtree, not the whole configured root. collectUnsafeLocalArtifacts reports each unreadable directory individually, and only entries under those exact paths are kept active.

Added the requested regression "prunes a deleted readable sibling while a nested directory is unreadable": with a nested dir offline AND a readable sibling file deleted under the same root, the sibling's stale page is still pruned (removedCount 1) while the unavailable subtree is preserved. 8/8 unsafe-local tests pass; before/after on pristine base 7ac8b48 is in the PR body (5 fail on base, 8 pass here).

Remaining explicit-file retention is the intentional data-safety tradeoff (Accept Conservative Explicit-File Retention).

@clawsweeper

clawsweeper Bot commented Jun 28, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🦞🧹
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.

@clawsweeper clawsweeper Bot added rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. and removed rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: ⏳ waiting on author ClawSweeper has contributor-facing work open and is waiting for author action. labels Jun 28, 2026
@clawsweeper clawsweeper Bot added the status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. label Jun 28, 2026
@clawsweeper clawsweeper Bot mentioned this pull request Jun 29, 2026
Closed
@yetval yetval mentioned this pull request Jul 1, 2026
Closed
@zhangqueping zhangqueping mentioned this pull request Jul 1, 2026
Closed
@clawsweeper clawsweeper Bot mentioned this pull request Jul 1, 2026
Merged
@yetval yetval mentioned this pull request Jul 8, 2026
Open
@clawsweeper clawsweeper Bot mentioned this pull request Jul 8, 2026
Open
3 tasks
@openclaw-barnacle

openclaw-barnacle Bot commented Jul 17, 2026

Copy link
Copy Markdown

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

@openclaw-barnacle openclaw-barnacle Bot added the stale Marked as stale due to inactivity label Jul 17, 2026
@clawsweeper

clawsweeper Bot commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

ClawSweeper status: review started.

I am starting a fresh review of this pull request: fix(memory-wiki): don't prune unsafe-local pages when a source path is transiently unavailable This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

@openclaw-barnacle

openclaw-barnacle Bot commented Jul 25, 2026

Copy link
Copy Markdown

Closing due to inactivity.
If you believe this PR should be revived, post in #clawtributors on Discord to talk to a maintainer.
That channel is the escape hatch for high-quality PRs that get auto-closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

extensions: memory-wiki merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. P0 Emergency: data loss, security bypass, crash loop, or unusable core runtime. proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. size: M stale Marked as stale due to inactivity status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

memory-wiki unsafe-local sync deletes imported pages and user human-notes blocks when a configured source path is transiently unavailable

1 participant

@LEXES7