Best possible solution:

Merge a scoped-unavailability repair after maintainers confirm the retention boundary and the contributor adds a redacted terminal or live-runtime transcript demonstrating both preservation during an outage and pruning after a reachable deletion.

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

Yes, from source inspection: current main converts failed stat or readdir calls into no artifacts and unconditionally prunes inactive unsafe-local state; the linked report supplies a concrete rename/unmount reproduction path.

Is this the best way to solve the issue?

Yes. Retaining only entries belonging to unavailable configured scopes is narrower than globally skipping pruning, because it preserves outage-affected pages while retaining cleanup for files missing from reachable scopes.

AGENTS.md: found and applied where relevant.

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

Label changes:

• add P0: This PR addresses an established path that can permanently remove imported pages and user-authored human notes when an everyday mount or permission outage occurs.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.

Label justifications:

• P0: This PR addresses an established path that can permanently remove imported pages and user-authored human notes when an everyday mount or permission outage occurs.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.

PR surface:

Source +30, Tests +64. Total +94 across 2 files.

What I checked:

• Current-main data-loss path: Current main suppresses failed directory reads as an empty file list and suppresses failed stats as absent paths; the unsafe-local sync then builds active keys only from collected artifacts and unconditionally calls the state-prune helper, which deletes every unsafe-local entry not in that set. (extensions/memory-wiki/src/unsafe-local.ts:48, 4362e1a4fe39)
• Destructive state contract: The shared pruning helper removes the stored page file and deletes its sync-state entry for every inactive key, so a transiently unavailable source can destroy the page that carries the human-notes block. (extensions/memory-wiki/src/source-sync-state.ts:261, 4362e1a4fe39)
• Branch fixes at the scope boundary: The proposed collection result records unavailable configured paths rather than treating them as empty; the branch retains their matching state keys and computes capacity from the collected-plus-retained key union, avoiding double-counting for overlapping configured paths. (extensions/memory-wiki/src/unsafe-local.ts:30, 96fafc68d3f7)
• Regression coverage: The new regression test sets up one unavailable and one available configured directory, verifies preservation of the unavailable page and its human notes, and still exercises deletion pruning for the reachable directory. (extensions/memory-wiki/src/unsafe-local.test.ts:108, 96fafc68d3f7)
• Canonical tracker: The PR explicitly targets the open report whose reproduction describes the same unsafe-local transient-mount deletion and human-notes loss; it is an implementation candidate, not a reason to close the issue before merge. (96fafc68d3f7)

Likely related people:

• steipete: Authored the focused source-sync repair and the accompanying regression coverage for the affected Memory Wiki path; repository history and release metadata also associate this account with active memory-wiki work. (role: recent Memory Wiki contributor; confidence: medium; commits: 96fafc68d3f7; files: extensions/memory-wiki/src/unsafe-local.ts, extensions/memory-wiki/src/unsafe-local.test.ts)
• yetval: Provided the concrete current-main reproduction, identified the collection-to-prune path, and documented the irreversible human-notes loss that this PR targets. (role: behavior reporter; confidence: high; files: extensions/memory-wiki/src/unsafe-local.ts, extensions/memory-wiki/src/source-sync-state.ts)

• 🦀 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.

• 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.