docs(readme): 70 → 92 on-chain writes, and publish the outage that sits between them

[DealAppSeo]

Description

The README claimed 70 lifetime on-chain reputation writes, verified 2026-07-08. Re-measured 2026-08-29 against erc8004_reputation_writes: 92.

The old figure is marked superseded, not withdrawn, so a reader sees the series rather than only its current value.

What the number hides, now stated

There have been two pauses, and the second is the more instructive:

window	cause
2026-06-22 → 2026-07-08	settlement path re-wired (already documented)
2026-08-17 → 2026-08-29	an upstream provider retired the model our peer-validation step called, so every validator errored — and the aggregation counted an unreachable validator as a score of zero rather than as not measured

The second produced a confident failing verdict about work nobody had assessed, and disputed twelve consecutive daily runs. Both halves are fixed upstream in repid-engine (#529): the model is configuration rather than a literal, and a validator that does not answer is excluded from the aggregate instead of counted against the provider.

Publishing the gap rather than the average is the point. A trust protocol that reports only its good weeks is making the same category of claim it exists to detect. The count going up across an outage is exactly why a bigger number is not evidence of health.

Fixes # (no issue)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

• Count re-measured live: select count(*) from erc8004_reputation_writes → 92 (was 91 before the fix landed; 70 at the 2026-07-08 snapshot).
• The cited transaction is real and was chain-verified, not database-verified. 0xdaf4863b… at 2026-08-29 12:01:34 UTC. The minter re-reads the receipt from Base Sepolia (status 0x1, sent to the ReputationRegistry) and exits non-zero rather than record an unverified write — so every row counted here was confirmed against the chain.
• The settling contract behind it: escrowed → fulfilled → satisfied → settled, verdict PASS at confidence 0.95, buyer_satisfaction_score 1. The 08-28 run for comparison: FAIL, confidence 0, provider_at_fault.
• check:drift reads clean on this repo after the change — and getting there exposed a real gap in that check itself, fixed in the companion trinity-ecosystem PR: markdown emphasis between the verb and the date (re-measured **2026-08-29**) made the claim invisible to its own gate.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (this is the documentation change)
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules (repid-engine #529 is merged and deployed as b7cc201)

---

Generated by Claude Code