file-a-findinglisted

A finding is filed, never swept into the current change: scope grows by surfacing follow-ups. And the report is the deliverable — the Architect that shapes a bug **may not rewrite its body**, so whatever you write is the only grounding the fixer gets. A thin report is not repaired downstream; it is rejected as unusable. ## 1. Decide what it is | it is | when | where it goes | |---|---|---| | **bug** | something behaves wrong and you can say how | `bug` label; one branch, one PR, usually one task | | **security finding** | a boundary is reachable that should not be | `bug` label; the ceiling stated (see below) | | **spike** | you found a question, not an answer | `Spike:` title or `spike` label — no branch, ships nothing | | **a rule that is wrong** | the code is right and the instruction is not | the repo owning the rule, naming the rule and what it cost | ⚠️ **If you cannot state a reproduction or a measurement, it is a spike, not a bug.** Filing an unmeasured hunch as a bug hands a fixer nothing to work from. ## 2. Establish it in the repo that owns it ⚠️ **The repo that owns the fix, not the one where you noticed it.** A workflow defect noticed in a consumer belongs to the engine; a data defect noticed by the engine belongs to the data repo. ⚠️ `Closes owner/repo#N` does not fire across repositories — cross-repo trackers get closed by hand, so prefer one issue in the owning repo over a pair. ## 3. Write what a fixer needs - **What is wrong**, stated so a reader can