Data-model scan flags broad memory-* subsystem paths as persistent storage

[LLagoon3]

Problem

ClawSweeper can classify prompt/tool-contract files under extensions/memory-core/ as persistent vector or embedding data solely because the path contains memory-. If the hydrated pull-file patch is missing, empty, or truncated, the deterministic data-model scan emits an unknown-data-model-change surface and a blocking migration-proof checklist even when the review correctly concludes that no stored-data contract changed.

Observed on openclaw/openclaw#157089 at head 5fe5a45e4c0ded94e6297e369d8ddcf7caec5bc6:

unknown-data-model-change: extensions/memory-core/src/memory-tool-contract.ts

The only production change in that file replaces static agent-facing prompt and tool-description strings. Search schemas, corpus result structures, SQLite tables, migrations, configuration schemas, and stored values are unchanged. The same durable review says migration compatibility is not applicable, but the deterministic checklist still retains Add data-model compatibility proof and a blocked review-state marker.

Cause

dataModelPathOwner() treats any path matching (?:^|/)memory(?:/|[-_.]) as a strong vector/embedding metadata owner. That includes broad subsystem names such as extensions/memory-core/, even when the file is a prompt contract rather than a persistence owner. The missing/empty/truncated-patch fallback then turns this path-only hint into unknown-data-model-change.

Reproduction

Call the exported production classifier with a GitHub pull-file entry whose path is extensions/memory-core/src/memory-tool-contract.ts and whose patch is unavailable. Current main returns:

{
  "change": true,
  "surfaces": [
    "unknown-data-model-change: extensions/memory-core/src/memory-tool-contract.ts"
  ]
}

The same fallback should remain active for genuine persistence owners such as
src/memory/vector-store.ts, extensions/memory-core/src/standing-intents.ts,
and extensions/memory-core/src/dreaming-dreams-file.ts.

Expected

Subsystem paths containing memory- should not become strong persistent-data
owners without a narrower storage/vector/schema owner signal. Real
memory/vector persistence paths, including established owner files whose names
do not contain a generic storage token, and semantic patch evidence must
continue to require compatibility proof.

Related work

• Data-model scan flags test-helpers/ fixtures as persistent storage #1660 covers a different classifier bug for test-helpers/ directories.
• fix: completed data-model proof still renders a blocking checklist item #1563 and fix: accepted data-model proof still shows a blocker #1583 fixed accepted-proof parsing, not path ownership.
• Prior stored-data false-positive repairs address other path and content heuristics, not memory-core.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 24, 2026, 9:02 AM ET / 13:02 UTC.

Summary
Current main still produces the reported false positive. The open #1678 explicitly targets this issue, so the issue should remain open while that fix is reviewed. The related test-helper and accepted-proof reports address different causes.

Reproducibility: yes. The current path expression and missing-patch fallback establish a focused reproduction with the reported pull-file entry; I did not execute the classifier.

Root-cause cluster
Relationship: canonical
Canonical: #1677
Summary: The linked open PR is the candidate fix; the other cited reports involve distinct classifier or proof-parsing causes.

Members:

• fixed_by_candidate: fix: scope memory data-model path ownership #1678 - Its body explicitly closes this issue and describes the memory path-owner repair.
• adjacent_distinct: Data-model scan flags test-helpers/ fixtures as persistent storage #1660 - It concerns test-helper directory classification rather than memory subsystem ownership.
• adjacent_distinct: fix: completed data-model proof still renders a blocking checklist item #1563 - It concerned recognition of accepted compatibility proof after detection.

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

Next step
The linked open #1678 already owns the focused repair; review that PR rather than dispatching a second fix.

Review details

Best possible solution:

Accept a narrowly scoped classifier fix that excludes memory subsystem names alone while retaining protection for actual persistence owners and semantic patch evidence.

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

Yes. The current path expression and missing-patch fallback establish a focused reproduction with the reported pull-file entry; I did not execute the classifier.

Is this the best way to solve the issue?

Yes. Narrowing path ownership while keeping semantic patch detection and known persistence-owner coverage is a focused repair.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against f4322a854213.

Label changes

Label changes:

• add P2: A bounded classifier bug adds unnecessary compatibility-proof work to affected PR reviews.
• add impact:ux-friction: Contributors can encounter a misleading review blocker for non-persistent edits.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.

Label justifications:

• P2: A bounded classifier bug adds unnecessary compatibility-proof work to affected PR reviews.
• impact:ux-friction: Contributors can encounter a misleading review blocker for non-persistent edits.

Evidence reviewed

What I checked:

• Current classifier: The memory path expression treats any memory-prefixed path segment as a strong vector or embedding owner. (src/clawsweeper-change-detection.ts:648, f4322a854213)
• Missing-patch consequence: A likely stored-data path with an unavailable, empty, or truncated patch receives an unknown-data-model-change surface. (src/clawsweeper-change-detection.ts:104, f4322a854213)
• Review blocker: A detected data-model surface without sufficient upgrade proof causes the compatibility-proof checklist item. (src/clawsweeper-report-comment-helpers.ts:564, f4322a854213)
• Existing test boundary: Current tests protect genuine SQLite owners and check that runtime state names alone do not establish stored data; they do not cover the reported memory-tool-contract path. (test/pr-surface-policy.test.ts:646, f4322a854213)
• Linked candidate fix: Provided GitHub context identifies fix: scope memory data-model path ownership #1678 as an open PR with closing syntax for this issue and a focused classifier proof claim; it has not merged.
• Area history: Recent changes to the detector include stored-data false-positive repairs by Peter Steinberger and Jason (Json). Older source-line introduction could not be verified because the partial checkout's promisor fetch failed. (src/clawsweeper-change-detection.ts, 5ae902bf0a0f)

Likely related people:

• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Jason (Json): Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.