fix: delete_entry IDOR — uniform response for single-entry deletes (#193)

[cmeans-claude-dev]

Summary

• Single-entry delete_entry(entry_id=...) now returns "status": "acknowledged" with no trashed count — prevents entry existence enumeration across tenants
• Includes "note": "If the entry was not found, no action was taken." — honest without revealing why
• Bulk deletes (tags, source) unchanged — counts are already owner-scoped

Closes #193

QA

Prerequisites

• pip install -e ".[dev]"
• Deploy to test instance on alternate port (AWARENESS_PORT=8421)

Manual tests (via MCP tools)

1. • Delete existing entry returns acknowledged

   remember(source="test", tags=["qa"], description="idor test")
   

   Note the ID, then:

   delete_entry(entry_id="<id>")
   

   Expected: {"status": "acknowledged", "entry_id": "...", "recoverable_days": 30, "note": "..."}

2. • Delete nonexistent entry returns same shape

   delete_entry(entry_id="00000000-0000-0000-0000-000000000000")
   

   Expected: identical response shape — acknowledged, no trashed field

3. • Bulk delete by tags still shows count

   delete_entry(tags=["qa"], confirm=true)
   

   Expected: {"status": "ok", "trashed": <N>, ...} — bulk path unchanged

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[cmeans]

Adding QA Active — starting code review and manual testing of IDOR fix.

[cmeans]

QA Review — PR #234: delete_entry IDOR fix

Code Review

Changes reviewed: tools.py, test_server.py, CHANGELOG.md (3 files, +13/−7)

The fix is minimal and correct:

• Single-entry delete_entry(entry_id=...) now discards the soft_delete_by_id return value and returns a uniform "acknowledged" response regardless of whether the entry existed
• No trashed count is exposed, eliminating the IDOR vector (attacker could previously enumerate entry existence by observing trashed: 0 vs trashed: 1)
• Bulk paths (tags, source) are unchanged — their counts are safe since they're already owner-scoped via _owner_id()
• SQL layer (soft_delete_by_id.sql) properly scopes by owner_id AND deleted IS NULL — no cross-tenant access possible even at the store level
• Store method still returns bool — the change is purely at the tool layer, which is the right boundary

No findings.

Automated Tests

Suite	Result
pytest	763/763 passed (21.8s)
ruff	Clean
mypy	Clean

Manual MCP Tests (via docker-compose.qa.yaml stack)

#	Test	Result
1	Delete existing entry returns acknowledged	PASS
2	Delete nonexistent entry returns identical shape	PASS
3	Bulk delete by tags still shows count	PASS

All 3/3 manual tests pass. PR checkboxes updated.

Verdict

Zero findings. Clean fix at the right abstraction layer. Ready for signoff.

[cmeans]

All checks pass, zero findings on code review and manual testing. Adding Ready for QA Signoff.

[cmeans]

LGTM