Feat/structured comparison result - #21
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 40b601d9ea
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| positive_pair_count: int | ||
| positive_pair_rate: float |
There was a problem hiding this comment.
Reject impossible positive-pair statistics
When a result is constructed or deserialized with values such as positive_pair_count=-1 or positive_pair_rate=1.5, strict Pydantic validation still accepts it because these fields have no range or consistency constraints. Since the milestone defines them as the count of positive improvements and its rate over pairs, the result model can currently represent impossible evidence as valid; validate the count and rate against their domains and the supplied pairs.
Useful? React with 👍 / 👎.
| @@ -0,0 +1,122 @@ | |||
| # ADR-0004: Define Comparison Value Semantics and Evidence Requirements | |||
There was a problem hiding this comment.
Give the comparison decision a unique ADR number
This introduces an accepted ADR-0004, but ROADMAP.md:335-339 already reserves ADR-0004 for the findings-schema decision. Once that planned ADR is written, references to ADR-0004 will be ambiguous or one document will need to be renumbered retroactively; assign this decision an unused number or update the roadmap's planned numbering in the same change.
Useful? React with 👍 / 👎.
Problem
What situation existed before this change? Why did it need to change?
Change
What did you actually do? Summarize the change, not the diff line-by-line.
Design Decisions
Any non-obvious choices made while implementing this — trade-offs, rejected
alternatives, or anything a future reader would ask "why did you do it this
way?" about.
Validation
pytestpassesruff check .passesmypy srcpassesRisks
What could this break? What wasn't tested? What assumptions might not hold
for other inputs or backends?
Related