v0.3: YAML as source of truth for rule metadata (#1)#8
Merged
Conversation
Scope v0.3 to making the YAML the source of truth for rule *metadata* (id, severity, message template, description, rationale) while the per-finding-type evaluation logic stays in Python. No generic rule engine; exact behaviour parity required. ROADMAP gains a focused v0.3 section; ARCHITECTURE documents the metadata-in-YAML / evaluation-in-Python split. No code or behaviour change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Make rules/pfmea_control_plan_rules.yaml the single source of truth for rule metadata (id, severity, title, message_template, description, rationale). The checker now builds each Finding using the YAML severity and message template instead of hardcoding them; the per-finding-type detection logic stays in Python (not a generic rule engine). Loader (rules/__init__.py) validates required fields and fails clearly on missing id, missing field, invalid severity, duplicate id or empty ruleset. Messages and behaviour are byte-identical to v0.2, locked by new behaviour-parity tests (seeded example, clean case, warnings case) plus loader validation tests. No change to scoring, matching, finding types or the JSON schema. Closes #1. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements #1 — make the YAML the source of truth for rule metadata, with the detection logic staying in Python.
What changed
rules/pfmea_control_plan_rules.yamlnow carries full metadata per rule:id,severity,title,message_template,description,rationale(version bumped to 1).rules/__init__.py:parse_rule_specs()validates the metadata (clearRuleSpecErroron missing id, missing required field, invalid severity, duplicate id, empty ruleset);load_rule_specs()reads + validates the packaged file.modules/pfmea_control_plan.py: builds eachFindingfrom the YAML severity + formattedmessage_template; the per-finding-type detection logic is unchanged. Not a generic rule engine.Behaviour parity (hard requirement) ✅
Messages are byte-identical to v0.2; finding types, severities, count, score and verdict unchanged. Locked by new behaviour-parity tests:
Plus loader-validation tests (invalid severity, duplicate id, missing field/id, empty ruleset) and the existing consistency test.
Out of scope (unchanged)
No new rule engine, no change to scoring / matching / finding types / JSON schema; no CSV/UI/AI/PyPI/new modules.
Checklist
ruff+pytestgreen (72 tests), CI green 4/4Closes #1.