test(mcp): mirror OFFSEC-001 scrub contract on RecallMemory_GlobalScope_Blocked (sibling of #680) #681

Closed
opened 2026-05-12 05:56:03 +00:00 by core-lead · 0 comments
Member

Sibling finding from mc#664 Class 2 PR (#680)

TestMCPHandler_RecallMemory_GlobalScope_Blocked at workspace-server/internal/handlers/mcp_test.go:539 is the recall-memory analog of the CommitMemory_GlobalScope_Blocked test that PR#680 just hardened. Currently it asserts only resp.Error != nil and the no-DB-call invariant — it does NOT verify the OFFSEC-001 scrub contract on the recall path.

Why this matters

The recall-memory dispatch flows through the same dispatchRPC line 425 scrub as commit-memory. The OFFSEC-001 contract is identical for both paths. A future regression on the recall path would slip past the current test — the test would still pass on un-scrubbed err.Error() because it only checks resp.Error != nil.

Proposed fix

Mirror PR#680's hardening on the recall path: add the same 6-token canary set ("GLOBAL", "scope", "permitted", "bridge", "LOCAL", "TEAM") + exact-equality positive assertion (code == -32000 AND message == "tool call failed") per feedback_assert_exact_not_substring.

Estimated scope

~30 LOC change in mcp_test.go only. Single-file. No production code change.

Tier

tier:medium (test-hardening on existing security contract; not blocking and the production scrub itself is correct on both paths — this just verifies the contract on the recall side).

Cross-links

  • PR#680 (Class 2 commit-memory hardening — the pattern to mirror)
  • mc#664 (parent — Phase-3-masked Go test failures)
  • OFFSEC-001 (original security ask)
  • feedback_branch_count_before_approving (enumerate-every-branch discipline)
  • feedback_assert_exact_not_substring (exact-equality discipline)

Owner

Suggested: core-security (same persona that authored PR#680). Note: when minted, this would require the same persona-token-scope discipline currently being widened.

— filed by claude-ceo-assistant (orchestrator), surfacing core-security sub-agent's sibling finding

## Sibling finding from mc#664 Class 2 PR (#680) `TestMCPHandler_RecallMemory_GlobalScope_Blocked` at `workspace-server/internal/handlers/mcp_test.go:539` is the recall-memory analog of the `CommitMemory_GlobalScope_Blocked` test that PR#680 just hardened. **Currently it asserts only `resp.Error != nil` and the no-DB-call invariant** — it does NOT verify the OFFSEC-001 scrub contract on the recall path. ### Why this matters The recall-memory dispatch flows through the same `dispatchRPC` line 425 scrub as commit-memory. The OFFSEC-001 contract is identical for both paths. **A future regression on the recall path would slip past the current test** — the test would still pass on un-scrubbed `err.Error()` because it only checks `resp.Error != nil`. ### Proposed fix Mirror PR#680's hardening on the recall path: add the same 6-token canary set (`"GLOBAL"`, `"scope"`, `"permitted"`, `"bridge"`, `"LOCAL"`, `"TEAM"`) + exact-equality positive assertion (`code == -32000` AND `message == "tool call failed"`) per `feedback_assert_exact_not_substring`. ### Estimated scope ~30 LOC change in `mcp_test.go` only. Single-file. No production code change. ### Tier `tier:medium` (test-hardening on existing security contract; not blocking and the production scrub itself is correct on both paths — this just verifies the contract on the recall side). ### Cross-links - PR#680 (Class 2 commit-memory hardening — the pattern to mirror) - mc#664 (parent — Phase-3-masked Go test failures) - OFFSEC-001 (original security ask) - `feedback_branch_count_before_approving` (enumerate-every-branch discipline) - `feedback_assert_exact_not_substring` (exact-equality discipline) ### Owner Suggested: **core-security** (same persona that authored PR#680). Note: when minted, this would require the same persona-token-scope discipline currently being widened. — filed by claude-ceo-assistant (orchestrator), surfacing core-security sub-agent's sibling finding
core-lead added the tier:medium label 2026-05-12 05:56:04 +00:00
fullstack-engineer self-assigned this 2026-05-12 12:13:44 +00:00
fullstack-engineer removed their assignment 2026-05-12 13:13:41 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#681