Context
Discovered during Feature #295 (F-292 post-merge verification runs, US1/T017/SC-003) while investigating the fresh-vs-anchor comparison. F-292's ID-prefix carve-out was intended to move a subset of LLM-*-prefixed output-handling findings to a dedicated OI-* prefix (per specs/292-output-integrity-cross-sink-refinement/). The committed examples/agentic-app/sample-report/threats.md at HEAD shows this carve-out added the new OI-1..OI-4 rows without removing the three pre-existing LLM-5/LLM-6/LLM-7 rows describing the same underlying threats — the three threats are now represented twice, under two different ID families, across every table that enumerates findings.
Evidence (grep, HEAD, examples/agentic-app/sample-report/threats.md)
Main findings table — near-identical content under both ID sets:
- Line 315:
LLM-5 — client-side XSS via Orchestrator's HTTPS response rendered in browser
- Line 316:
LLM-6 — server-side execution via Tool Call Request parameters
- Line 317:
LLM-7 — SSRF via LLM-synthesized URL in Tool Call Request
- Line 334:
OI-1 — client-side XSS via LLM response rendered in user browser (same mechanism as LLM-5)
- Line 335:
OI-2 — server-side execution via Tool Call Request (same mechanism as LLM-6)
- Line 336:
OI-3 — SSRF via LLM-synthesized URL in Tool Call Request (same mechanism as LLM-7)
- Line 337:
OI-4 — Clinical Advisory Sub-Agent finding (no legacy LLM-* counterpart — appears to be a genuinely new addition, not a duplicate)
Correlated / cross-reference table — both ID sets listed as separate rows for the same threats:
- Lines 638-639 (
LLM-5, LLM-6), 646-647 (OI-1, OI-2)
- Lines 672 (
LLM-7), 676-677 (OI-3, OI-4)
Affected Assets table — both ID sets listed as separate rows:
- Lines 756-757 (
LLM-5, LLM-6), 764-765 (OI-1, OI-2)
- Line 790 (
LLM-7), 794-795 (OI-3, OI-4)
Baseline registry count (line 63) explicitly counts both ranges as additive rather than one superseding the other:
Baseline registry: 84 findings (... LLM-1 through LLM-14, OI-1 through OI-4, MI-1 through MI-3, AGP-01)
If OI-1/OI-2/OI-3 truly supersede LLM-5/LLM-6/LLM-7, the true unique count is 3 lower than the registry states.
Disposition (fix-vs-file, no inline edit)
Per Feature #295's scope (FR-020 fence — no detection-tier or example-corpus edits beyond this feature's own committed artifacts), this defect is filed rather than fixed inline. Remediation is likely: remove the superseded LLM-5/LLM-6/LLM-7 rows from all three tables (main findings, correlated/cross-reference, Affected Assets) and correct the baseline registry count — or, if the duplication is intentional (e.g. deliberately preserving both an old and new ID for backward-referencing consumers), document that rationale explicitly in the file so it doesn't read as an oversight.
Evidence path
Full grep output captured in this feature's SC-003 verification record: specs/295-f292-verification-runs/sc-003-verification-record.md (Feature #295).
Context
Discovered during Feature #295 (F-292 post-merge verification runs, US1/T017/SC-003) while investigating the fresh-vs-anchor comparison. F-292's ID-prefix carve-out was intended to move a subset of
LLM-*-prefixed output-handling findings to a dedicatedOI-*prefix (perspecs/292-output-integrity-cross-sink-refinement/). The committedexamples/agentic-app/sample-report/threats.mdat HEAD shows this carve-out added the newOI-1..OI-4rows without removing the three pre-existingLLM-5/LLM-6/LLM-7rows describing the same underlying threats — the three threats are now represented twice, under two different ID families, across every table that enumerates findings.Evidence (grep, HEAD,
examples/agentic-app/sample-report/threats.md)Main findings table — near-identical content under both ID sets:
LLM-5— client-side XSS via Orchestrator's HTTPS response rendered in browserLLM-6— server-side execution via Tool Call Request parametersLLM-7— SSRF via LLM-synthesized URL in Tool Call RequestOI-1— client-side XSS via LLM response rendered in user browser (same mechanism as LLM-5)OI-2— server-side execution via Tool Call Request (same mechanism as LLM-6)OI-3— SSRF via LLM-synthesized URL in Tool Call Request (same mechanism as LLM-7)OI-4— Clinical Advisory Sub-Agent finding (no legacyLLM-*counterpart — appears to be a genuinely new addition, not a duplicate)Correlated / cross-reference table — both ID sets listed as separate rows for the same threats:
LLM-5,LLM-6), 646-647 (OI-1,OI-2)LLM-7), 676-677 (OI-3,OI-4)Affected Assets table — both ID sets listed as separate rows:
LLM-5,LLM-6), 764-765 (OI-1,OI-2)LLM-7), 794-795 (OI-3,OI-4)Baseline registry count (line 63) explicitly counts both ranges as additive rather than one superseding the other:
If
OI-1/OI-2/OI-3truly supersedeLLM-5/LLM-6/LLM-7, the true unique count is 3 lower than the registry states.Disposition (fix-vs-file, no inline edit)
Per Feature #295's scope (FR-020 fence — no detection-tier or example-corpus edits beyond this feature's own committed artifacts), this defect is filed rather than fixed inline. Remediation is likely: remove the superseded
LLM-5/LLM-6/LLM-7rows from all three tables (main findings, correlated/cross-reference, Affected Assets) and correct the baseline registry count — or, if the duplication is intentional (e.g. deliberately preserving both an old and new ID for backward-referencing consumers), document that rationale explicitly in the file so it doesn't read as an oversight.Evidence path
Full grep output captured in this feature's SC-003 verification record:
specs/295-f292-verification-runs/sc-003-verification-record.md(Feature #295).