module-findingslisted

# Module: Reporting a Finding **Loaded by:** `code-review-architect` · `security-architect` · `accessibility-architect` · `documentation-architect` · `search-optimization-architect` · `maintenance-architect` · `debugging-architect`. Read it whenever a run emits findings; do not restate its content in a skill file. **What this exists to prevent:** a report nobody acts on. That happens two ways — the list is padded with things that are not real, so the reader learns to skim it; or the list is real but nothing in it says who fixes what, so it becomes a document instead of work. --- ## 1. The Shape of One Finding Every finding carries, in this order: 1. **Severity** — from §3. 2. **Category** — the dimension it belongs to, in the emitting skill's vocabulary. 3. **A location** — `path/to/file.ext:42`, or a `url` for a live-page finding. **No floating "consider improving X".** A finding you cannot point at is an opinion. 4. **Why it matters** — the consequence, not the rule it breaks. For a barrier, **name who it blocks**; for a vulnerability, **state reachability** or state that you could not establish it. A rule that is only a rule gets negotiated; a rule attached to a consequence gets fixed. 5. **The concrete fix** — a pointer specific enough to act on. 6. **Who owns the fix**, when the emitting skill does not write code. A security finding goes to `security-architect`, an accessibility barrier to `accessibility-architect`, a test gap to `testing-architect`, a doc defect t