Recursive-delete: two of four "DeletedPaths" exception-Data writers spell the bare literal instead of DeletedPathsDataKey #7348

Incidental finding while working MeshWeaver core issue 1198 (area:mesh). Not blocking that work and not actively harmful today, but it is a latent defect and it already produced one wrong claim in a code comment.

WHAT: In MeshWeaver core, the recursive-delete pipeline attaches the list of paths it removed to the failing exception's Data dictionary under the key "DeletedPaths". The key has a declared constant, DeletedPathsDataKey, in src/MeshWeaver.Mesh.Contract/MeshExtensions.cs line 3156. Four sites write that key. TWO of them go through the constant (MeshExtensions.cs line 3813, the commit stage's TimeoutAtStage arm; and line 4288, the drain-pass fold). TWO spell the bare literal instead: MeshExtensions.cs line 4340 (the max-pass branch) and src/MeshWeaver.Mesh.Contract/HierarchicalPathDeletion.cs line 83.

WHY IT MATTERS: renaming or re-scoping the constant would leave the two literal writers silently writing to the old key, so the reader at MeshExtensions.cs line 3953 would stop seeing their contribution. The failure mode is a partial-deleted count that under-reports with no error and nothing to grep, which is exactly the class of defect issue 1198 exists to close.

HOW I FOUND IT, because the instrument is part of the finding: I grepped for the CONSTANT name to inventory the writers, concluded there were two, and wrote that into a code comment. A Copilot review on pull request 5170 caught it and named both literal sites. So the divergence is already demonstrably capable of misleading a reader who uses the obvious search.

SUGGESTED FIX: route the two literal sites through the constant. HierarchicalPathDeletion is in the same assembly and namespace as the constant's declaring class, so this is a visibility change at most (the constant is currently private). Its XML doc at line 66 also states the key as a literal in prose and would want the same treatment.

WHAT I DID NOT ESTABLISH: I did not check whether any other exception-data key in this repo has the same split (I only enumerated this one key). I did not check for literal spellings of DeleteStageDataKey or DeleteUnansweredDataKey, the two sibling keys read in the same handler. I did not measure any production impact; nothing is broken today because all four spellings agree.

Triage context

• Received 2026-10-18 as uncategorised feedback on instance memex.systemorph.com.
• Verdict: defect (latent). Two of the four writers of the "DeletedPaths" exception-Data key spell the bare literal instead of the declared constant DeletedPathsDataKey, so a rename or re-scope of the constant would silently split the key. Already produced one wrong claim in a code comment on MeshWeaver core PR fix(#1198): an unattributed delete timeout reports what it actually removed #5170. No production impact today — all four spellings agree.
• Severity: sev:L — latent maintainability defect, no user-visible or production impact while the spellings agree.
• Owner resolution: the feedback names files under src/MeshWeaver.Mesh.Contract in "MeshWeaver core" (issue 1198, PR 5170); core issues and PRs live in Systemorph/MeshWeaver (e.g. PR fix(auth): RevokeToken writes once, off the router, and a refusal faults (#6026) #6286, issue CLI: tighten client-side argument validation in dynamic MCP commands (edge cases from #7301) #7332), so Systemorph/MeshWeaver owns this finding.

Origin: https://memex.systemorph.com/Feedback/_Submissions/fb-85c9928a9539b8d5a5ad4518c0e48109

filed by the triage agent on behalf of the submitter (no name provided) via systemorph-com

Triage routing: filed in Systemorph/MeshWeaver — agent: Systemorph/MeshWeaver — The feedback names files under src/MeshWeaver.Mesh.Contract in "MeshWeaver core" (issue 1198, pull request 5170); the fleet's triage records place core issues and PRs in Systemorph/MeshWeaver (e.g. PR #6286, issue #7332), so the core repository Systemorph/MeshWeaver owns this finding..