Reconcile KB build status (and correct an assessment I contradicted) - #109
Merged
Conversation
…adicted Four README claims said §65.9 income-purification was NOT BUILT and deferred to go-live. It was built today (PR #107). Corrected in place, with the superseded reasoning kept rather than deleted.⚠️ THE UNCOMFORTABLE PART, RECORDED RATHER THAN SMOOTHED: memory carried §65.9 as 'the only NEW machine-verifiable compliance obligation… highest priority'; this README carried a LATER assessment saying the opposite, with four reasons. They contradicted each other, and the item was built from the memory framing WITHOUT the README row being checked. The outcome was defensible -- two of the four deferral reasons were wrong or inapplicable: (c) 'not machine-computable on this venue' assumed API balance-delta INFERENCE, and missed that the imported transaction ledger already carries TYPED reward rows (Reward Income, Incentives Rewards Payout) -- 19 in our own real history, no inference needed; (d) 'auto-purification violates equity.py's detect-but-never-adjust rule' does not apply to a REPORT-ONLY build that adjusts nothing -- and that objection is respected, not overridden. (a) 'P&L half already handled' was correct but INCIDENTAL, and is now pinned by a test. But all of that was found AFTER building, not before. Had the reasons held, the work would have been wasted and a recorded decision silently reversed. Also marks §65.4 (rail 17, PR #108) and §28.4's haram_sector screen (PR #104) as built, and adds a process note: read the README row before building a KB item, correct overturned assessments IN PLACE, and keep build status in the row -- a KB that disagrees with itself is worse than one that is wrong. Co-Authored-By: Claude Opus 4.8 (1M context) <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
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.
Doc-only. No code changed.
What this fixes
Four README claims said §65.9 income-purification was NOT BUILT / deferred to go-live. It was built today in #107. Corrected in place, with the superseded reasoning kept rather than deleted. Also marks §65.4 (rail 17, #108) and §28.4's
haram_sectorscreen (#104) as built.Memory carried §65.9 as "the only NEW machine-verifiable compliance obligation… highest priority". The README carried a later assessment saying the opposite, with four reasons. They contradicted each other, and I built the item from the memory framing without checking the README row first.
The outcome was defensible — two of the four deferral reasons don't hold:
Reward Income,Incentives Rewards Payout, 19 in our own real history. No inference needed.equity.py's detect-but-never-adjust rule" doesn't apply to a report-only build that adjusts nothing — and that objection is respected, not overridden.But all of that was found after building, not before. Had the reasons held, the work would have been wasted and a recorded decision silently reversed. The process was wrong even though the result was right.
Rules added
Verification
1229 tests pass (unchanged — doc-only).
🤖 Generated with Claude Code