Problem
Source omissions are redacted before publication, but their redactions occur after the report's privacy audit has already been snapshotted. The audit therefore understates the work performed and omits the affected structural paths. This is an accounting defect, not a demonstrated secret leak.
Evidence
An independent coding-agent review during #561 reproduced the ordering on source files byte-matched to main c079864e8a37209a7712d74197fd1cf1b4ebf06e. It used the duplicate MCP declaration shape in tests/test_mcp_manifest.py (around line 426), a synthetic secret-shaped server name and the actual inputs/mcp_manifest.py::_merge_server_declarations producer.
Replaying the production sanitization order yielded privacy_audit.redacted_occurrence_count == 1, while the shared RedactionStats.occurrence_count became 4 after omission sanitization. The audit lacked source_omissions[].subject, source_omissions[].detail and source_omissions[].warning. The public omission subject was safely redacted to pkg_b/.mcp.json#/mcpServers/[REDACTED:github_token]; the raw probe value did not survive.
cli/scan/sanitization.py::_sanitize_for_output calls build_privacy_audit before sanitizing inputs.loaded_sources[].omissions inside the returned _SanitizedSurfaces constructor. #561 places its new recovery sanitization before the audit; it does not expand into this inherited ordering defect.
Scope
Finish sanitizing all public source-omission fields before building the final privacy audit. Check the other fields constructed after that snapshot for the same ordering problem. Keep audit paths/counts free of raw values and hashes; do not double-count by redacting the same projection twice.
Acceptance
Sequencing
Deferred from #561 under the requested new-issue discipline. Related privacy reliability work; no new release authority or qualification threshold is introduced.
Problem
Source omissions are redacted before publication, but their redactions occur after the report's privacy audit has already been snapshotted. The audit therefore understates the work performed and omits the affected structural paths. This is an accounting defect, not a demonstrated secret leak.
Evidence
An independent coding-agent review during #561 reproduced the ordering on source files byte-matched to main
c079864e8a37209a7712d74197fd1cf1b4ebf06e. It used the duplicate MCP declaration shape intests/test_mcp_manifest.py(around line 426), a synthetic secret-shaped server name and the actualinputs/mcp_manifest.py::_merge_server_declarationsproducer.Replaying the production sanitization order yielded
privacy_audit.redacted_occurrence_count == 1, while the sharedRedactionStats.occurrence_countbecame 4 after omission sanitization. The audit lackedsource_omissions[].subject,source_omissions[].detailandsource_omissions[].warning. The public omission subject was safely redacted topkg_b/.mcp.json#/mcpServers/[REDACTED:github_token]; the raw probe value did not survive.cli/scan/sanitization.py::_sanitize_for_outputcallsbuild_privacy_auditbefore sanitizinginputs.loaded_sources[].omissionsinside the returned_SanitizedSurfacesconstructor. #561 places its new recovery sanitization before the audit; it does not expand into this inherited ordering defect.Scope
Finish sanitizing all public source-omission fields before building the final privacy audit. Check the other fields constructed after that snapshot for the same ordering problem. Keep audit paths/counts free of raw values and hashes; do not double-count by redacting the same projection twice.
Acceptance
Sequencing
Deferred from #561 under the requested new-issue discipline. Related privacy reliability work; no new release authority or qualification threshold is introduced.