* fix(report): neutralize CSV formula injection in vulnerabilities.csv
write_vulnerabilities() wrote finding titles straight into vulnerabilities.csv.
The csv module escapes CSV syntax but has no notion of spreadsheet formula
triggers, so a title beginning with =, +, -, @, tab or CR reached the cell
intact and was evaluated when a human opened the file (CWE-1236).
That input is attacker-influenced by design: Strix scans untrusted targets and
the agent quotes target content verbatim into finding titles, so a scanned page
can dictate a cell's literal contents. _validate_required_text only checks the
title is non-blank.
Add csv_safe() and apply it to every cell written. A value starting with a
formula trigger is prefixed with an apostrophe, the standard mitigation:
spreadsheets render the rest as literal text and hide the apostrophe.
This follows the module's existing safe_fence() precedent, which already guards
the markdown path against the same class of attacker-influenced content.
Adds regression tests covering the six trigger characters, that the payload
survives intact behind the guard, and that benign titles are untouched.
* report: single-line titles, exact CSV bytes, accurate csv_safe docstring
Strip control characters from finding titles at the ReportState choke point so
the guard in the CSV writer is defense-in-depth rather than the only layer, and
write artifacts with newline="" so the CSV's own \r\n terminators are not
rewritten to \r\r\n on Windows.
* report: normalize hydrated titles on resume
* report: rewrite finding markdown when resume cleans its title
---------
Co-authored-by: itzzdev09 <devved90@gmail.com>
* Treat literal 'null'/'none' strings as absent for optional tool args
Models routinely pass the literal string "null" or "none" instead of
omitting an optional argument. Taken at face value it becomes a filter
that matches nothing, so tools like list_notes / list_reports /
list_requests silently return no results.
Coerce such values to None in the central argument-coercion layer, but
only for parameters the schema allows to be null (or that are absent from
a declared "required" list), so required strings keep the literal value.
The list/filter helpers normalize the same values too, so a direct call
can't regress.
* Limit nullish coercion to query tools and keep literal tags
A literal "null"/"none" is only a mistake where the argument is a filter, so
gate the coercion on read-only query tools; a tool that writes keeps the value,
which stops update_note(content="none") from being read as "leave unchanged".
Stop dropping nullish entries from a notes tag filter too: tags are free-form,
so a literal "none" tag stays filterable and mixed tag queries keep every
branch.
