docs(web): fix stale '/api/add does not invoke privacy.scan' comments#786
Merged
docs(web): fix stale '/api/add does not invoke privacy.scan' comments#786
Conversation
… in app.js The two comment blocks around the Add Memory submit handler claimed that ``/api/add`` did not invoke ``privacy.scan`` — describing the client-side regex check as the only gate. That has not been true since the trust- boundary write guard was wired to the web add path: ``POST /api/add`` calls ``privacy.enforce_write_guard()`` at ``web/routes/system.py:1203`` (which scans server-side via ``privacy.scan()`` and rejects on hit). Update both comment blocks to reflect the current invariant: - The server route is the trust boundary, via ``enforce_write_guard``. - The client-side regex is defense-in-depth: a UX-time warning before submit so a flagged paste does not have to round-trip. - The scan-window asymmetry note is reframed: the client scans the entire textarea while the server caps at ``_SCAN_WINDOW`` (10K), so the client is the more permissive side (warns on more positions); the server remains the source of truth. Comment-only change. No behavior change, no lint impact (ruff does not cover JS), and the file's i18n / static-asset cache-bust keys are untouched. Co-Authored-By: Claude <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix two stale comment blocks around the Add Memory submit handler in
web/static/app.jsthat claimedPOST /api/adddid not invokeprivacy.scan. That has not been true since the trust-boundary write guard was wired to the web add path —web/routes/system.py:1203callsprivacy.enforce_write_guard(), which scans server-side and rejects on hit.Updated both blocks to describe the current invariant:
/api/addis the trust boundary viaenforce_write_guard._SCAN_WINDOW(10K), so the client is the more permissive side (warns on more positions); the server stays the source of truth.Context
Discovered while spot-checking
docs/reports/security-hardening-plan-2026-05-05.mdagainst the source — the plan's claim that/api/addwas missing the redaction guard was already-fixed code, but the JS comment had drifted in the same direction and gave a false read of the trust model. Comment-only change; no behavior, no API, no test surface impact.Per
feedback_deictic_pr_references.md— exactly the kind of "today moot" / "if X ever lands" prose that rots after the gate actually lands.Test plan
// ...blocks?v=Ninindex.htmlunchanged (no JS body changes that downstream cache would need to bust)🤖 Generated with Claude Code