* fix(memory-wiki): strip fenced code and inline code before wikilink extraction
The wikilink extractor in extractWikiLinks previously scanned
the full markdown content including fenced code blocks and
inline code spans. Literal [[...]] syntax inside code regions
(e.g. bash test syntax, Scala generics like
Future[Option[User]]) produced false-positive broken-wikilink
lint warnings.
Add FENCED_CODE_BLOCK_PATTERN and INLINE_CODE_PATTERN and
strip those regions from the searchable text before running
the Obsidian and Markdown link regexes. Five regression tests
cover backtick-fenced, tilde-fenced, 6-backtick-fenced, and
inline code scenarios plus a full vault lint round-trip.
Fixes#97945
* fix(memory-wiki): accept longer closing fence in code block stripping
The FENCED_CODE_BLOCK_PATTERN used a regex backreference (\1)
that required the closing fence to be exactly identical to the
opening fence. CommonMark allows the closing fence to be the
same character type and at least as long — e.g. ``` opening
with ```` closing is valid. Switch to a function-based
replacement that compares fence character type and length.
Add regression test for the longer-closing-fence case per
ClawSweeper review feedback (#98095).
* style(memory-wiki): add braces to if-body in fence replacement callback
Fixes ESLint curly rule violation at line 403.
* fix(memory-wiki): replace fence regex with line scanner for wikilink extraction
Replace FENCED_CODE_BLOCK_RE regex/callback with a line-by-line scanner
that keeps searching past invalid fence-looking lines (e.g. a shorter
``` line inside a longer `````` block) until a valid closing
fence of the same character type and at least as long is found.
Also handles tilde fences and longer closing fences per CommonMark spec.
🦞 diamond lobster: L2 evidence (5 real function-call scenarios, all passing)
Ref. https://github.com/openclaw/openclaw/pull/98095
* fix(memory-wiki): use CommonMark code masking
---------
Co-authored-by: Vincent Koc <25068+vincentkoc@users.noreply.github.com>
* [AI] fix(memory-wiki): gracefully handle unparsable YAML frontmatter in vault scans (#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 #96125
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* 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 <noreply@anthropic.com>
Co-authored-by: Peter Steinberger <steipete@golden-gate.local>
* fix(memory-wiki): support Unicode characters in slugifyWikiSegment
Replace ASCII-only regex with Unicode-aware regex to preserve CJK,
Cyrillic, Arabic, and other non-ASCII characters in wiki slugs.
Fixes#64620
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* test(memory-wiki): cover Unicode slug regressions
* fix(memory-wiki): preserve combining marks in slugs
* fix(memory-wiki): cap composed source filenames
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Vincent Koc <vincentkoc@ieee.org>
