propose-security-hardeninglisted

# Propose Security Hardening ## Objective Turn a collection of security evidence into a decision-ready portfolio of structural or architectural hardening opportunities. The evidence may be a Codex Security scan that is still in final reporting or is already complete, ordinary vulnerability disclosure documents, supplied findings, incident or assessment material, relevant source code, or a mixture of these. Use the evidence as support and as leads for further source inspection. Produce proposals that a principal security engineer could circulate for design review, with meaningful options, before-and-after diagrams, explicit tradeoffs, migration plans, and an implementation handoff. Do not require a Codex Security scan. A directory of disclosure documents is a valid input collection and should be analyzed directly. Do not require a scan seal before beginning: during automatic final reporting the canonical scan documents have not been sealed yet. When completed scan integrity metadata is available, use it as additional evidence and report any mismatch or missing artifact as a limitation rather than rejecting otherwise useful inputs. Keep three products distinct: - canonical scan artifacts and other supplied evidence remain read-only; - the hardening analysis is a derived, revisable design product; - implementation changes happen only after the user selects an option and explicitly asks Codex to modify the repository. Do not turn the hardening analysis into another vulnerab