PR #73722: fix: normalise wiki lint links

• Repository: openclaw/openclaw
• Author: IshanG97
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/73722

Description (problem / solution / changelog)

Summary

• Problem: openclaw wiki lint can report existing imported wiki pages as broken-wikilink when links use page titles, slug variants, fragments, or original source-path suffixes.
• Why it matters: imported evidence should not need provenance-damaging rewrites just to satisfy lint.
• What changed: memory-wiki lint now indexes pages by normalised path, basename, title, slug variants, and imported source-path suffixes, and strips fragments/query strings before checking link targets.
• What did NOT change (scope boundary): wiki compile, ingest, page rendering, and markdown link extraction remain unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #73574
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: memory-wiki lint compared raw link targets against only exact extensionless relative paths and basenames.
• Missing detection / guardrail: lint coverage did not include title-style, slug-style, fragment, or imported source-path link variants.
• Contributing context (if known): imported evidence can preserve source-authored link forms that differ from generated wiki filenames.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/memory-wiki/src/lint.test.ts
• Scenario the test should lock in: existing pages linked by title, slug, fragment-bearing path, and imported source-path suffix do not produce broken-wikilink issues.
• Why this is the smallest reliable guardrail: the bug is isolated to lint target normalisation.
• Existing test that already covers this (if any): none.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

openclaw wiki lint should produce fewer false-positive broken-wikilink warnings for imported wiki pages whose links already resolve by title, slug, fragment-stripped path, or imported source-path suffix.

Diagram (if applicable)

Before:
[[Alpha Database#Evidence]] -> raw target check -> false broken-wikilink

After:
[[Alpha Database#Evidence]] -> normalised lookup -> existing page match

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local source checkout
• Model/provider: N/A
• Integration/channel (if any): memory-wiki
• Relevant config (redacted): N/A

Steps

1. Compile or create memory-wiki pages containing links such as [[Alpha Database#Evidence]], [[alpha-database]], and source-path suffix links.
2. Run memory-wiki lint.
3. Inspect broken-wikilink results.

Expected

• Existing pages are not reported as broken links when referenced by title, slug, fragment-stripped path, or imported source-path suffix.

Actual

• Current main only compares raw targets against exact extensionless relative paths and basenames, so valid imported links can be reported as broken.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Local command evidence:

• git diff --check HEAD~1..HEAD passed.
• Added-line scan for unwanted tool-name references returned no matches.
• pnpm exec oxfmt --write --threads=1 extensions/memory-wiki/src/lint.ts extensions/memory-wiki/src/lint.test.ts was attempted locally and with elevated permissions, but Corepack timed out downloading pnpm 10.33.0 from the registry.
• pnpm test extensions/memory-wiki/src/lint.test.ts was attempted locally and with elevated permissions, but Corepack timed out downloading pnpm 10.33.0 from the registry.

Human Verification (required)

• Verified scenarios: source-level resolver now strips fragments/query suffixes and indexes title, slug, relative-path, basename, and imported source-path suffix keys.
• Edge cases checked: missing targets still flow through the existing warning path; source-path suffixes do not require changing stored provenance.
• What you did not verify: local formatter or Vitest execution, because this machine cannot download the required pnpm version through Corepack. CI should run the focused regression.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: lint could accept links that are ambiguous across multiple pages.
  • Mitigation: this only suppresses broken-link warnings when a normalised target matches an existing page key; it does not change compile output or page routing.

Changed files

• extensions/memory-wiki/src/lint.test.ts (modified, +58/-0)
• extensions/memory-wiki/src/lint.ts (modified, +51/-5)