docs: align scan write-up filenames with the findings schema

sdk/typescript/_bundled_plugin/skills/vulnerability-writeup/SKILL.md

@@ -91,8 +91,8 @@ If the source contradicts the finding, stop presenting it as a vulnerability. Ex
 2. Read `references/report-format.md` completely. Require each drafting sub-agent to read it before writing.
 3. When the vulnerable source is available, pin and inspect it. Independently check the decisive entry point, security check, state change, sink and available fix. Trace the introducing change and inspect affected and fixed release tags only when the relevant history is available; otherwise record that limitation without blocking a source-backed report. When the user explicitly accepted a report-only assessment, record the unavailable source and require every source-dependent conclusion to remain conditional.
 4. Record the one-sentence attack and non-claims, available verified release history or explicit release-history limitations, named actors, complete tested topology, defaults versus configured prerequisites, meaningful positive and negative controls, exact validation basis and testing boundary before assigning the finding.
-5. Create one descriptively named Markdown report per vulnerability and a sibling `poc/` directory only when real PoC artefacts exist or can safely be developed.
-6. Launch exactly one sub-agent for each distinct vulnerability. Provide only that vulnerability's raw material, available pinned source or explicitly accepted report-only limitation, PoC artefacts, output directory, report-format reference and authorisation boundary.
+5. During Codex Security final reporting, write each detailed report to `findings/<slug>/<slug>.md`, using the identical lowercase slug for its directory and filename, and record that exact safe relative path as `writeup.reportPath`. Outside Codex Security final reporting, preserve the user-requested report directory and filename; use a descriptive `<slug>.md` only when no filename was requested. Create a sibling `poc/` directory only when real PoC artefacts exist or can safely be developed.
+6. Launch exactly one sub-agent for each distinct vulnerability. Provide only that vulnerability's raw material, available pinned source or explicitly accepted report-only limitation, PoC artefacts, output directory, exact report path, report-format reference and authorisation boundary.
 7. Independently read the returned report against the raw artefacts and any available pinned source and release history. Check each important claim, excerpt, transition, affected-version statement, impact, fix and reported observation; keep source-dependent conclusions conditional when source inspection was unavailable and the user accepted a report-only assessment.
 8. Reject a draft that smooths over missing evidence, invents a run, inflates impact, guesses affected versions, leaks an author-machine-specific absolute path, calls an unexplained piece of evidence a "witness", overloads the prose with hashes or jargon, mistakes configuration existence for prevalence, or uses named actors or first-person language as decoration.
 9. If the draft needs substantive repair, launch a fresh sub-agent for that same finding with the original artefacts and specific review failures. Do not cover an evidentiary failure with cosmetic edits.
@@ -121,6 +121,7 @@ Inputs:
 - Named actors and usernames: <Alice/alice, Bob/bob, Mallory/mallory or Eve/eve as appropriate>
 - Testing authorisation and disposable lab: <boundary>
 - Report and PoC output directory: <directory>
+- Exact report output path: <user-requested report path; during Codex Security final reporting use <scan_dir>/findings/<slug>/<slug>.md>
 
 Treat the supplied finding as a hypothesis. Inspect the exact source revision yourself when available. If the user explicitly accepted a report-only assessment without source, identify that limitation, keep every source-dependent conclusion visibly conditional and never invent an excerpt or line citation. Otherwise, trace the actual attacker-controlled entry point, the reported state change, existing checks and the real sink. Reopen any source excerpt that ends before the decisive line. Do not substitute a different event, object, revision or test harness for the claimed trigger.
 

sdk/typescript/_bundled_plugin/skills/vulnerability-writeup/references/report-format.md

@@ -4,7 +4,7 @@ Write one self-contained Markdown report for a technically experienced security
 
 Use the language and locale requested by the user, or their normal default when unstated, with a warm professional voice and direct technical language. Let `we` guide real reasoning: carry the same input, object or state between relevant excerpts and explain why each step matters. Use `I` only for what the author actually reviewed, built, ran, observed or could not test. Explain the expected behaviour and the actual failure in plain language.
 
-Use a specific report filename, such as `freebsd-shm-ftruncate-uaf.md`. Cite repository-relative paths, functions and verified release versions. Give fenced source excerpts the correct language. Use one natural source line per instruction paragraph or list item; do not hard-wrap Markdown prose in the middle of a sentence.
+During Codex Security final reporting, use `findings/<slug>/<slug>.md`, matching directory and filename exactly so `writeup.reportPath` satisfies the findings schema. Outside Codex Security final reporting, preserve the user's requested report directory and filename; when no filename is specified, choose a descriptive name such as `freebsd-shm-ftruncate-uaf.md`. Cite repository-relative paths, functions and verified release versions. Give fenced source excerpts the correct language. Use one natural source line per instruction paragraph or list item; do not hard-wrap Markdown prose in the middle of a sentence.
 
 ## Evidence and voice