Repository navigation
Phase 2.6: Rule coverage, reconciliation tests, docs close-out - #13
Merged
withrvr merged 3 commits intoAug 31, 2026
Conversation
Asserts every rule in RULE_REGISTRY fires at least once on dataset A (the Phase 2 done-when criterion), that the registry covers exactly E001-E014, and that the total row count is 17. Iterates the registry rather than hardcoding rule names, so it can never drift from the catalogue as rules are added or changed.
Two internal-consistency identities (not the independently-derived SQL recompute -- that's Phase 3+): every invoice's outstanding + valid_paid equals invoice_amount + overpaid, summed across the full 36-invoice portfolio; and every payment rupee is either applied or explicitly unapplied, with every unapplied payment traceable to an exception row. Corrects a flawed assumption in an earlier design draft, which claimed "overpaid" is nonzero only for INV-1007 (E014). It's also nonzero for INV-1028: a negative invoice_amount with zero payments produces max(0, 0 - (-45000)) = 45000 under the same formula, since compute_outstanding's floor doesn't distinguish "genuine overpayment" from "floored negative amount." Verified directly against dataset A rather than assumed; both identities hold with total_overpaid = 67,000 (22,000 + 45,000), not 22,000.
README.md: "Validation performed" filled in (rule coverage, reconciliation identities, exact-ID assertions), status updated to Phase 2 complete. DEVELOPMENT.md: status and testing sections updated for the full 107-test suite. RULES.md: reordered into E001-E014 numeric order for the final catalogue (previously in PR-landing order), status line updated to 14/14 complete, dataset-A row-count cross-check noted against QA_PREP.md Q7. CHANGELOG.md: 0.3.0 entry.
withrvr
merged commit Aug 31, 2026
9360703
into
claude/erp-collection-reporting-workflow-iycqto
6 of 10 checks passed
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
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.
Phase 2 (feature 6 of 6): Coverage, reconciliation, docs close-out
What this adds
tests/validate/test_coverage.py: every rule inRULE_REGISTRYfiresat least once on dataset A, the registry covers exactly E001-E014, and
the total row count is 17 — the Phase 2 done-when criterion.
tests/test_reconcile.py: two reconciliation identities proving noinvoice or payment rupee is lost. Caught and fixed a real bug in the
original design: a draft equation assumed "overpaid" (payments
exceeding invoice amount) is nonzero only for the E014 case (INV-1007).
That's false — INV-1028's negative invoice amount with zero payments
against it produces
max(0, 0 - (-45000)) = 45000under the sameformula, since
compute_outstanding's floor doesn't distinguish"genuine overpayment" from "floored negative amount." Verified directly
against dataset A (
total_overpaid = 67,000, not22,000) rather thanassumed, before writing the test.
RULES.mdreordered into E001-E014 numeric order (wasin PR-landing order) with a dataset-A row-count cross-check against
QA_PREP.md Q7;
README.md's "Validation performed" section filled in;DEVELOPMENT.mdstatus/testing updated;CHANGELOG.md0.3.0 entry.Phase 2 is now complete: all 14 rules implemented, 107 tests passing,
RULES.mdmatching the code exactly.Assessment requirement served
Closes out "generate an exception report," the never-silently-drop
standing rule, and the validation-approach grading criterion with a
concrete, checkable coverage + reconciliation story.
Docs updated
Verification
Known gaps carried to next phase
run_events, or API wiring — Phases 3-4.test_sql_crosscheck.py)stays deferred to Phase 3+, since it needs persistence to recompute
from; the reconciliation tests here are internal-consistency checks,
not that independent method.
v0.3.0tag will be attempted on merge; Phase 1 foundgit push origin <tag>fails with a 403 in this sandbox (no tag/release toolavailable via the GitHub MCP server either) — if it fails again, the
CHANGELOG entry stands as the release record.
Generated by Claude Code