Failure type
Hypatia findings need a first-class taxonomy and stable identifiers that are visible to GitHub code scanning, agents, and humans.
Evidence
The 2026-06-06 echidna code-scanning set contains many unrelated Hypatia alert families:
- 73
migration_rules/deprecated_api
- 44
workflow_audit/missing_timeout_minutes
- 27
code_scanning_alerts/CSA001
- 22
structural_drift/SD022
- 22
code_safety/unwrap_without_check
- 10
code_safety/unwrap_dangerous_default
- 9
code_safety/expect_in_hot_path
- 7
code_safety/unsafe_block
- 7
code_safety/as_ptr
GitHub currently groups mainly by SARIF ruleId, and many Hypatia results appear at line 1 with prose-heavy messages. That makes the surface feel like a raw scanner dump rather than Dependabot/CodeQL-style triage.
Expected behavior
Every public Hypatia finding should carry structured metadata:
- stable finding identifier, e.g.
HYP-<fingerprint-prefix>;
- category, e.g.
workflow-security, code-safety, language-migration, lifecycle-hygiene;
- class, e.g.
ci-cd-control, source-risk, modernisation;
- suggested route, e.g.
rhodibot, echidnabot, panicbot, private-farm, sustainabot;
- dispatch safety, e.g.
report-only, pr-only, pr-or-report, proof-or-review, manual-escalation;
- precise source line where available.
Route
Hypatia owns the rule registry and SARIF/JSON output. standards owns the deployed reusable converter until repos consume Hypatia's native SARIF renderer directly.
Safety notes
Metadata must not upgrade findings into actions. Dispatch should remain report-only unless a separate gate proves recipe confidence, canary behavior, and blast-radius limits.
Acceptance criteria
- SARIF
result.properties and rule.properties expose Hypatia identity/category/route/safety data.
- JSON output exposes the same fields or a documented superset.
- The taxonomy is centralized rather than duplicated across ad hoc converters.
- Existing consumers continue to parse old findings during transition.
Failure type
Hypatia findings need a first-class taxonomy and stable identifiers that are visible to GitHub code scanning, agents, and humans.
Evidence
The 2026-06-06
echidnacode-scanning set contains many unrelated Hypatia alert families:migration_rules/deprecated_apiworkflow_audit/missing_timeout_minutescode_scanning_alerts/CSA001structural_drift/SD022code_safety/unwrap_without_checkcode_safety/unwrap_dangerous_defaultcode_safety/expect_in_hot_pathcode_safety/unsafe_blockcode_safety/as_ptrGitHub currently groups mainly by SARIF
ruleId, and many Hypatia results appear at line1with prose-heavy messages. That makes the surface feel like a raw scanner dump rather than Dependabot/CodeQL-style triage.Expected behavior
Every public Hypatia finding should carry structured metadata:
HYP-<fingerprint-prefix>;workflow-security,code-safety,language-migration,lifecycle-hygiene;ci-cd-control,source-risk,modernisation;rhodibot,echidnabot,panicbot,private-farm,sustainabot;report-only,pr-only,pr-or-report,proof-or-review,manual-escalation;Route
Hypatia owns the rule registry and SARIF/JSON output.
standardsowns the deployed reusable converter until repos consume Hypatia's native SARIF renderer directly.Safety notes
Metadata must not upgrade findings into actions. Dispatch should remain report-only unless a separate gate proves recipe confidence, canary behavior, and blast-radius limits.
Acceptance criteria
result.propertiesandrule.propertiesexpose Hypatia identity/category/route/safety data.