The open defect ledger
Honesty without flattery is the whole point, so the defects we know about are listed here — plainly, with their causes — and each stays listed until a future baseline resolves it — and with the project mothballed after V3, the open entries below now wait for whoever cuts that baseline. The frozen 1.0 numbers are never edited in place; a fix always means a new, fully re-run baseline.
Five divergences found while V1 and V2 were live — the acquisition gate’s forward-pricing gap (caught by the living farm), the uncharged lead deleading, plan-dependent determinism, the unadjusted rent basis, and the fractional-bath overpricing — were fixed in V3; each fix ships with the regression test that proves it. Their full histories live in the project repository’s issue register.
A result dataset’s run records carry no fingerprint of the property universe that produced them — so a reproduction check pointed at the wrong universe fails loudly but can’t say why. The shipped mitigation: the reproduction gate refuses to run without an explicit universe declaration. The real fix — a universe fingerprint stamped into every dataset’s metadata — was scoped for the version after this one — for whoever cuts it.
Public parcel data publishes no bathroom counts, so every unit in the shipped universe defaults to one bath — and the engine’s bath-pricing code path never exercises. Its regression gates skip loudly rather than pass silently. The fix, for whoever picks it up: a deliberately awkward synthetic fixture (multi-bath units, two towns, messy labels) that restores full gating on any universe.
Three configuration knobs look load-bearing and aren’t: the late-fee percentage is structurally unreachable (the trigger counts only fully missed payments), the credit hardship-redemption cap names a ceiling that never binds under shipped values, and the grant/EIP parameters are read by nothing — those programs stayed on the roadmap. None of this moves any published number; it’s named so nobody tunes a dead dial.
Full engineering detail for every issue lives in the project's development tracker and the baseline-of-record documents shipped in the repository. Nothing is ever removed from this ledger, and every issue keeps a version history: what was wrong in the version that shipped it, and what fixed it in the version that did. When a new baseline resolves an issue, its card keeps a note showing how to reproduce the defect on the old version and how to verify the fix on the new one — the fix claim ships only when it is checkable.