Skip to content

Reconcile KB build status (and correct an assessment I contradicted) - #109

Merged
eaitbrahim merged 1 commit into
mainfrom
docs/kb-build-status
Jul 20, 2026
Merged

Reconcile KB build status (and correct an assessment I contradicted)#109
eaitbrahim merged 1 commit into
mainfrom
docs/kb-build-status

Conversation

@eaitbrahim

Copy link
Copy Markdown
Contributor

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_sector screen (#104) as built.

⚠️ The uncomfortable part, recorded rather than smoothed

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:

  • (c) "not machine-computable on this venue" assumed inferring riba from an API balance delta. It missed that the imported transaction ledger already carries typed reward rowsReward Income, Incentives Rewards Payout, 19 in our own real history. No inference needed.
  • (d) "auto-purification would violate 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.
  • (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. The process was wrong even though the result was right.

Rules added

  1. Read the README row before building a KB-derived item, not just the memory note — this file carries later assessments, because they're written when an item is checked against the code.
  2. Correct overturned assessments in place, not by appending a contradicting note elsewhere. A KB that disagrees with itself is worse than one that is wrong.
  3. Build status belongs in the README row. A row saying "not built" about built code misleads every future session, and this project's method depends on the KB being trustworthy.

Verification

1229 tests pass (unchanged — doc-only).

🤖 Generated with Claude Code

…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>
@eaitbrahim
eaitbrahim merged commit b3316df into main Jul 20, 2026
@eaitbrahim
eaitbrahim deleted the docs/kb-build-status branch July 20, 2026 19:13
@eaitbrahim eaitbrahim added the docs Documentation (Docs, CI & tooling) label Jul 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Documentation (Docs, CI & tooling)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant