fix(memory-wiki): gracefully handle unparsable YAML frontmatter in vault scans (#96125) by SunnyShu0925 · Pull Request #97177 · openclaw/openclaw

SunnyShu0925 · 2026-06-27T04:15:33Z

Related to #96125. Supersedes #96177.

What Problem This Solves

A single memory-wiki page with malformed YAML frontmatter caused vault-wide compile, query, lint, status, and apply workflows to throw. Returning a degraded empty-metadata summary would avoid the crash but contaminate derived indexes, digests, counts, and query results, and could let writers erase metadata.

Why This Change Was Made

The final implementation separates tolerant scans from strict writes:

scanWikiPageSummary returns a closed valid / invalid-frontmatter / ignored result.
Compile, query, and status consume only valid summaries; lint receives structured parse failures separately.
Syntax-invalid YAML and parseable non-mapping roots are both invalid frontmatter.
parseWikiMarkdown remains strict for direct edits, dashboards, lint reports, and generated root/directory indexes, preserving malformed targets byte-for-byte.

This keeps one bad page from disabling read-only vault workflows without manufacturing a valid-looking page or weakening write safety.

User Impact

Healthy pages continue to compile, search, lint, and count when another page has invalid frontmatter.
Invalid pages are excluded from indexes, digests, counts, related-block writes, and query results.
Lint reports the invalid file and parse reason.
Apply and every managed Markdown writer fail closed when their own target is invalid.

Evidence

node scripts/run-vitest.mjs extensions/memory-wiki/src/markdown.test.ts extensions/memory-wiki/src/compile.test.ts extensions/memory-wiki/src/lint.test.ts extensions/memory-wiki/src/query.test.ts extensions/memory-wiki/src/status.test.ts extensions/memory-wiki/src/apply.test.ts — 6 files, 98 tests passed.
Blacksmith Testbox-through-Crabbox tbx_01kwdez3sef8w1dqe4m4v40c6j: env CI=1 corepack pnpm test extensions/memory-wiki — 31 files, 209 tests passed.
Same Testbox: env OPENCLAW_CHECK_CHANGED_REMOTE_CHILD=1 OPENCLAW_CHANGED_LANES_RAW_SYNC=1 CI=1 corepack pnpm check:changed — passed extension typecheck/lint and repository guards.
Azure Crabbox lease cbx_06c4ea5d0f42, run run_64bc6a1334b3: real CLI init/compile/search/lint/status/apply scenario passed, including malformed-target byte preservation.
Final exact-head autoreview on e9d0dccff3 — no findings; patch correct at 0.94 confidence.

What Was Not Tested

No external provider credentials or network service are involved in this plugin-local parser and filesystem behavior. No proof gap remains for the changed surface.

clawsweeper · 2026-06-27T04:16:44Z

Codex review: needs real behavior proof before merge. Reviewed June 30, 2026, 8:17 PM ET / 00:17 UTC.

Summary
The PR changes memory-wiki vault scanning so malformed frontmatter is isolated and reported instead of aborting compile, lint, query, status, or apply flows.

PR surface: Source +68, Tests +432. Total +500 across 10 files.

Reproducibility: yes. Source inspection on current main shows malformed frontmatter reaches YAML.parse, then readPageSummaries uses errorMode stop and rethrows through compileMemoryWikiVault; I did not run a local repro because this review is read-only.

Review metrics: 2 noteworthy metrics.

Parser compatibility surface: 1 existing parser case tightened. Empty frontmatter blocks were accepted as empty metadata on current main and are rejected by the PR guard.
Current-head real proof: 0 current-head examples in PR body. The visible terminal proof predates later force-pushes that changed parser and generated-index behavior.

Stored data model
Persistent data-model change detected: persistent cache schema: extensions/memory-wiki/src/compile.test.ts, serialized state: extensions/memory-wiki/src/apply.test.ts, serialized state: extensions/memory-wiki/src/compile.test.ts, serialized state: extensions/memory-wiki/src/lint.test.ts, serialized state: extensions/memory-wiki/src/query.test.ts, serialized state: extensions/memory-wiki/src/status.test.ts, and 18 more. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #96125
Summary: This PR is the active candidate fix for the canonical malformed memory-wiki frontmatter issue; earlier same-root candidate PRs are closed unmerged.

Members:

canonical: [Bug]: wiki_apply & wiki_lint YAML 解析错误 #96125 - The issue reports the same wiki_apply/wiki_lint YAML frontmatter failure and remains open until a fix lands.
superseded: fix(memory-wiki): wiki_apply errors when another page has bad frontmatter #96177 - This earlier candidate targeted the same root cause and was closed unmerged after this branch became the active path.
superseded: fix(memory-wiki): tolerate YAML parse errors in wiki frontmatter #96130 - This earlier parser-level fallback targeted the same bug but was closed unmerged after review found the global parser catch unsafe.

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: 🧂 unranked krab
Result: blocked until stronger real behavior proof is added.

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

Rank-up moves:

Preserve empty frontmatter as empty metadata while keeping scalar and sequence roots strict.
Update the PR body with redacted current-head terminal output or logs for the affected memory-wiki paths.

Proof guidance:

[P1] Needs stronger real behavior proof before merge: The PR body includes terminal output, but it predates the latest head and does not prove the final after-fix behavior; refreshed redacted terminal output, copied live output, or logs are needed before merge. 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] Merging current head would make empty frontmatter blocks invalid, so existing pages that current main treated as empty metadata can be excluded from scans or fail write/index updates.
[P1] The PR body proof predates later force-pushed commits, so the latest apply, compile, lint, query, status, and generated-index behavior is not yet proven in a real setup.

Maintainer options:

Fix empty frontmatter and refresh proof (recommended)
Treat truly empty frontmatter as empty metadata while still rejecting scalar and sequence roots, then update the PR body with current-head redacted terminal output or logs.
Accept stricter empty frontmatter parsing
Maintainers can intentionally make empty frontmatter invalid, but the PR should document that compatibility choice and show upgrade impact before merge.
Keep in human review
Pause the branch if the compatibility direction or current-head proof cannot be settled now.

Next step before merge

[P1] Contributor or maintainer follow-up is needed because the branch has a narrow compatibility defect plus missing current-head real behavior proof, and automation cannot supply the contributor's proof for them.

Security
Cleared: No concrete security or supply-chain concern was found; the diff is limited to memory-wiki TypeScript and tests with no dependency, workflow, lockfile, script, or credential handling changes.

Review findings

[P1] Keep empty frontmatter blocks valid — extensions/memory-wiki/src/markdown.ts:192-195

Review details

Best possible solution:

Land the scan-boundary fix only after preserving empty-frontmatter compatibility, keeping scalar and sequence roots strict, and refreshing current-head redacted terminal proof.

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

Yes. Source inspection on current main shows malformed frontmatter reaches YAML.parse, then readPageSummaries uses errorMode stop and rethrows through compileMemoryWikiVault; I did not run a local repro because this review is read-only.

Is this the best way to solve the issue?

No, not yet. The scan-boundary approach is the right layer, but the current non-mapping guard is too broad for empty frontmatter and the latest head still needs real behavior proof.

Full review comments:

[P1] Keep empty frontmatter blocks valid — extensions/memory-wiki/src/markdown.ts:192-195
This guard rejects YAML.parse('') because it returns null, so a page with a valid empty --- ... --- block that current main treated as empty metadata is now excluded from scans or rejected on write/index updates. Preserve empty frontmatter as {} while still rejecting scalar and sequence roots, and add a regression test for that case.
Confidence: 0.9

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

P2: The PR targets a concrete memory-wiki regression affecting apply, lint, query, and status paths with limited blast radius to memory-wiki vaults.
merge-risk: 🚨 compatibility: The diff changes frontmatter parsing so existing pages with empty frontmatter can become invalid or excluded after upgrade.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🧂 unranked krab.
status: 🚀 automerge armed: This PR is in ClawSweeper's automerge lane. Needs stronger real behavior proof before merge: The PR body includes terminal output, but it predates the latest head and does not prove the final after-fix behavior; refreshed redacted terminal output, copied live output, or logs are needed before merge. 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.

Evidence reviewed

PR surface:

Source +68, Tests +432. Total +500 across 10 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	4	156	88	+68
Tests	6	432	0	+432
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	10	588	88	+500

What I checked:

Current main parser behavior: Current main calls YAML.parse for frontmatter and maps falsy, array, or non-object parsed roots to empty frontmatter, so an empty frontmatter block is accepted as empty metadata. (extensions/memory-wiki/src/markdown.ts:181, 5e572dcf781a)
Current main compile failure path: Current main reads every page through toWikiPageSummary inside readPageSummaries with errorMode: stop, so a YAML parse exception aborts compileMemoryWikiVault. (extensions/memory-wiki/src/compile.ts:392, 5e572dcf781a)
PR head scan-boundary implementation: At PR head, compile calls scanWikiPageSummary and collects invalid-frontmatter errors instead of throwing through the whole page-summary scan. (extensions/memory-wiki/src/compile.ts:397, e9d0dccff30c)
PR head compatibility regression: At PR head, parseWikiMarkdown throws for any falsy parsed root; because empty frontmatter parses to null, existing empty frontmatter blocks become invalid. (extensions/memory-wiki/src/markdown.ts:192, e9d0dccff30c)
YAML dependency contract: The yaml v2.9.0 upstream test suite explicitly expects YAML.parse('') to return null, which is the value rejected by the PR guard. (tests/doc/parse.ts:353)
Linked canonical issue: Live issue data shows the linked user report is still open and describes the same wiki_apply/wiki_lint malformed frontmatter failure.

Likely related people:

vincentkoc: Git history shows Vincent Koc introduced and restored the memory-wiki markdown, compile, and lint stack that this PR changes. (role: feature owner and area contributor; confidence: high; commits: 516a43f9f28c, 5716d83336fd, c73aeed929d1; files: extensions/memory-wiki/src/markdown.ts, extensions/memory-wiki/src/compile.ts, extensions/memory-wiki/src/lint.ts)
steipete: History shows recent memory-wiki refactor work, and live PR commits show Peter Steinberger authored the later scan isolation, fail-closed, non-mapping, and generated-index changes on this branch. (role: recent adjacent contributor and current branch contributor; confidence: medium; commits: 4fa961d4f149, dffa88f39615, 7b43ed1158b1; files: extensions/memory-wiki/src/markdown.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.

Takhoffman · 2026-06-27T12:26:40Z

@clawsweeper automerge

clawsweeper · 2026-06-27T12:26:43Z

🦞🧹
ClawSweeper automerge is enabled.

Head: 022f37bf6983
Label: clawsweeper:automerge
Action: exact-head review queued (workflow sweep.yml, event repository_dispatch).
Flow: review this head, repair/rebase only if needed, then re-review the exact repaired head before merge.

Draft PRs stay fix-only until GitHub marks them ready for review. Pause with /clawsweeper stop.

Automerge progress:

2026-06-27 12:28:37 UTC review queued 022f37bf6983 (queued)

clawsweeper · 2026-06-27T12:35:12Z

🦞✅
ClawSweeper is pausing this repair loop for human review.

Source: clawsweeper[bot]
Reason: - [P2] No repair lane is needed; this PR already contains the focused fix and is opted into automerge, with only sibling-PR reconciliation left for the normal maintainer flow.; Cleared: No concrete security or supply-chain concern was found; the diff is limited to memory-wiki parsing, lint reporting, and colocated tests. (sha=022f37bf6983beb205f24350d6558a0c014d5ab1)

Why human review is needed:
This item has security-sensitive risk. ClawSweeper is pausing instead of making an autonomous change that could affect trust, credentials, permissions, or exposure.

What the maintainer can do as a next step:
If the maintainer accepts the current risk and wants ClawSweeper to continue merge gates, comment @clawsweeper approve. If the security-sensitive detail still needs changes, describe the safe path or push the fix, then comment @clawsweeper automerge. If the risk should not be automated, keep the PR paused for manual review or comment @clawsweeper stop.

I added clawsweeper:human-review and left the final call with a maintainer.

clawsweeper · 2026-06-30T23:43:42Z

🦞✅
ClawSweeper is pausing this repair loop for human review.

Source: clawsweeper[bot]
Reason: - [P1] Maintainer follow-up is needed because the branch has clawsweeper:human-review and the current PR body/proof is stale after a maintainer force-push; there is no narrow code repair to queue.; Cleared: No concrete security or supply-chain concern was found; the diff is limited to memory-wiki TypeScript and tests with no dependency, workflow, lockfile, script, or credential handling changes. (sha=50c353e3217e9e31e1f4db065c24bb32617d76a0)

Why human review is needed:
This item has security-sensitive risk. ClawSweeper is pausing instead of making an autonomous change that could affect trust, credentials, permissions, or exposure.

What the maintainer can do as a next step:
If the maintainer accepts the current risk and wants ClawSweeper to continue merge gates, comment @clawsweeper approve. If the security-sensitive detail still needs changes, describe the safe path or push the fix, then comment @clawsweeper automerge. If the risk should not be automated, keep the PR paused for manual review or comment @clawsweeper stop.

I added clawsweeper:human-review and left the final call with a maintainer.

…in vault scans (openclaw#96125) toWikiPageSummary now catches YAML parse errors during vault-wide scans (compile/lint/query/status) and returns a degraded WikiPageSummary with frontmatterError set instead of letting the error propagate through readPageSummaries -> compileMemoryWikiVault, which previously caused one bad page to crash the entire vault. Edit paths (apply, chatgpt-import) still throw on bad frontmatter to prevent silent metadata loss on write. - markdown.ts: add frontmatterError field to WikiPageSummary, extract splitWikiFrontmatterBlock, catch YAML.parse in toWikiPageSummary - lint.ts: add invalid-frontmatter lint code, skip frontmatter-derived checks when frontmatterError is present - markdown.test.ts: test degraded parse preserves body, empty frontmatter - lint.test.ts: test invalid-frontmatter lint on broken page, healthy page unaffected Related to openclaw#96125 Co-Authored-By: Claude Opus 4.8 <[email protected]>

clawsweeper · 2026-06-30T23:59:04Z

🦞✅
ClawSweeper is pausing this repair loop for human review.

Source: clawsweeper[bot]
Reason: - [P1] Maintainer follow-up is needed because the branch has clawsweeper:human-review and the proof in the PR body is stale after the force-pushed current-head implementation.; Cleared: No concrete security or supply-chain concern was found; the diff is limited to memory-wiki TypeScript and tests with no dependency, workflow, lockfile, script, or credential handling changes. (sha=31f68c13cd8c28ccc76758cc33e8c3458ac6b21a)

Why human review is needed:
This item has security-sensitive risk. ClawSweeper is pausing instead of making an autonomous change that could affect trust, credentials, permissions, or exposure.

What the maintainer can do as a next step:
If the maintainer accepts the current risk and wants ClawSweeper to continue merge gates, comment @clawsweeper approve. If the security-sensitive detail still needs changes, describe the safe path or push the fix, then comment @clawsweeper automerge. If the risk should not be automated, keep the PR paused for manual review or comment @clawsweeper stop.

I added clawsweeper:human-review and left the final call with a maintainer.

steipete · 2026-07-01T00:21:00Z

Land-ready maintainer proof for exact head e9d0dccff30c1cf44f9ade11a9e6a170fbff063a:

Focused local regression shard:
node scripts/run-vitest.mjs extensions/memory-wiki/src/markdown.test.ts extensions/memory-wiki/src/compile.test.ts extensions/memory-wiki/src/lint.test.ts extensions/memory-wiki/src/query.test.ts extensions/memory-wiki/src/status.test.ts extensions/memory-wiki/src/apply.test.ts
— 6 files, 98 tests passed.
Blacksmith Testbox-through-Crabbox tbx_01kwdez3sef8w1dqe4m4v40c6j:
env CI=1 corepack pnpm test extensions/memory-wiki
— 31 files, 209 tests passed.
Same Testbox:
env OPENCLAW_CHECK_CHANGED_REMOTE_CHILD=1 OPENCLAW_CHANGED_LANES_RAW_SYNC=1 CI=1 corepack pnpm check:changed
— extension production/test typechecks, extension lint (0 warnings/errors), database-first, media-helper, runtime-sidecar, and import-cycle guards passed.
Azure Crabbox lease cbx_06c4ea5d0f42, run run_64bc6a1334b3: real CLI wiki init / compile / search / lint / status / apply scenario passed. Invalid pages stayed out of indexes, results, and counts; unrelated apply succeeded; malformed direct targets failed with exact-byte preservation.
Exact-head CI: run 28484185157 passed.
Final autoreview --mode branch --base origin/main on e9d0dccff3: no accepted/actionable findings; patch correct at 0.94 confidence. Earlier lint-report, non-mapping-root, and generated-index findings were fixed and re-reviewed.
OPENCLAW_TESTBOX=1 scripts/pr prepare-run 97177 passed and verified the remote PR tree.

Result: malformed YAML is isolated from compile/query/lint/status derived state, including parseable non-mapping roots, while ordinary pages, apply targets, dashboards, lint reports, and root/directory index writes remain fail-closed. No known proof gaps.

steipete · 2026-07-01T00:21:23Z

Merged via squash.

Prepared head SHA: e9d0dccff30c1cf44f9ade11a9e6a170fbff063a
Landed commit: 1289abddcb966cfa1535c7b82a08f555d9848445

…ult scans (openclaw#96125) (openclaw#97177) * [AI] fix(memory-wiki): gracefully handle unparsable YAML frontmatter in vault scans (openclaw#96125) toWikiPageSummary now catches YAML parse errors during vault-wide scans (compile/lint/query/status) and returns a degraded WikiPageSummary with frontmatterError set instead of letting the error propagate through readPageSummaries -> compileMemoryWikiVault, which previously caused one bad page to crash the entire vault. Edit paths (apply, chatgpt-import) still throw on bad frontmatter to prevent silent metadata loss on write. - markdown.ts: add frontmatterError field to WikiPageSummary, extract splitWikiFrontmatterBlock, catch YAML.parse in toWikiPageSummary - lint.ts: add invalid-frontmatter lint code, skip frontmatter-derived checks when frontmatterError is present - markdown.test.ts: test degraded parse preserves body, empty frontmatter - lint.test.ts: test invalid-frontmatter lint on broken page, healthy page unaffected Related to openclaw#96125 Co-Authored-By: Claude Opus 4.8 <[email protected]> * fix(memory-wiki): isolate invalid frontmatter scans * fix(memory-wiki): keep malformed lint reports fail-closed * fix(memory-wiki): reject non-mapping frontmatter * fix(memory-wiki): validate generated index targets --------- Co-authored-by: Claude Opus 4.8 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

…ult scans (openclaw#96125) (openclaw#97177) * [AI] fix(memory-wiki): gracefully handle unparsable YAML frontmatter in vault scans (openclaw#96125) toWikiPageSummary now catches YAML parse errors during vault-wide scans (compile/lint/query/status) and returns a degraded WikiPageSummary with frontmatterError set instead of letting the error propagate through readPageSummaries -> compileMemoryWikiVault, which previously caused one bad page to crash the entire vault. Edit paths (apply, chatgpt-import) still throw on bad frontmatter to prevent silent metadata loss on write. - markdown.ts: add frontmatterError field to WikiPageSummary, extract splitWikiFrontmatterBlock, catch YAML.parse in toWikiPageSummary - lint.ts: add invalid-frontmatter lint code, skip frontmatter-derived checks when frontmatterError is present - markdown.test.ts: test degraded parse preserves body, empty frontmatter - lint.test.ts: test invalid-frontmatter lint on broken page, healthy page unaffected Related to openclaw#96125 Co-Authored-By: Claude Opus 4.8 <[email protected]> * fix(memory-wiki): isolate invalid frontmatter scans * fix(memory-wiki): keep malformed lint reports fail-closed * fix(memory-wiki): reject non-mapping frontmatter * fix(memory-wiki): validate generated index targets --------- Co-authored-by: Claude Opus 4.8 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]> (cherry picked from commit 1289abd)

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

clawsweeper Bot mentioned this pull request Jun 30, 2026

fix(memory-wiki): wiki_apply errors when another page has bad frontmatter #96177

Closed

steipete self-assigned this Jun 30, 2026

steipete force-pushed the fix/wiki-frontmatter-yaml-parse-96125 branch from 022f37b to 50c353e Compare June 30, 2026 23:37

openclaw-barnacle Bot added size: L and removed size: S labels Jun 30, 2026

SunnyShu0925 and others added 3 commits June 30, 2026 16:48

fix(memory-wiki): isolate invalid frontmatter scans

6b24005

fix(memory-wiki): keep malformed lint reports fail-closed

31f68c1

steipete force-pushed the fix/wiki-frontmatter-yaml-parse-96125 branch from 50c353e to 31f68c1 Compare June 30, 2026 23:48

clawsweeper Bot added rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. and removed rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. labels Jun 30, 2026

fix(memory-wiki): reject non-mapping frontmatter

7b43ed1

fix(memory-wiki): validate generated index targets

e9d0dcc

steipete merged commit 1289abd into openclaw:main Jul 1, 2026
93 checks passed

This was referenced Jul 1, 2026

[Bug]: wiki_apply & wiki_lint YAML 解析错误 #96125

Closed

fix(memory-wiki): tolerate YAML parse errors in wiki frontmatter #96130

Closed

github-actions Bot mentioned this pull request Jul 1, 2026

🦞 OpenClaw 生态日报 2026-07-01 zx0828/big_model_radar#205

Open

SunnyShu0925 deleted the fix/wiki-frontmatter-yaml-parse-96125 branch July 2, 2026 03:35

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(memory-wiki): gracefully handle unparsable YAML frontmatter in vault scans (#96125)#97177

fix(memory-wiki): gracefully handle unparsable YAML frontmatter in vault scans (#96125)#97177
steipete merged 5 commits into
openclaw:mainfrom
SunnyShu0925:fix/wiki-frontmatter-yaml-parse-96125

SunnyShu0925 commented Jun 27, 2026 •

edited by steipete

Loading

Uh oh!

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading

Uh oh!

Takhoffman commented Jun 27, 2026

Uh oh!

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 30, 2026

Uh oh!

clawsweeper Bot commented Jun 30, 2026

Uh oh!

steipete commented Jul 1, 2026

Uh oh!

Uh oh!

steipete commented Jul 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

SunnyShu0925 commented Jun 27, 2026 • edited by steipete 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

What Was Not Tested

Uh oh!

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

Uh oh!

Uh oh!

Takhoffman commented Jun 27, 2026

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

clawsweeper Bot commented Jun 30, 2026

Uh oh!

clawsweeper Bot commented Jun 30, 2026

Uh oh!

steipete commented Jul 1, 2026

Uh oh!

Uh oh!

steipete commented Jul 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

SunnyShu0925 commented Jun 27, 2026 •

edited by steipete

Loading

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading

clawsweeper Bot commented Jun 27, 2026 •

edited

Loading