v0.1.148

Added

• ?contract=1&schema=1 now says what is still stored, not only what may be purged. A purge
  block counts the rows that still carry a reader IP or a raw User-Agent, per table, with a
  three-state vide: true (nothing of that legacy is left on this instance's live rows — the
  condition under which those columns can eventually be dropped), false (rows remain), and
  null when a probe did not answer — a failed probe must never read as a zero, because zero
  is the answer that authorises a deletion. Why it exists: our tables live in the host's
  database, and a host's audit enumerates its own tables — a dependency's schema occupies a zone
  nobody's inventory visits. Two integrating hosts found 2361 rows still carrying these columns,
  and found them because a third party asked a question about its own database, not because
  anything told them. retentionSweep said "I can purge"; nothing said what had piled up. Counts
  are bounded and read one small column, so the bound reads as at least, never as exactly; and
  the cost runs opposite to intuition — cheap while much remains, a full scan once nothing does —
  which is stated in the code rather than hidden, the expensive case being the terminal one where
  the counter has finished its work. A column an operator has since dropped counts zero, not
  null: that is a known state, not a failure, and reading it as unknown would blind the counter
  at the exact moment its subject is settled. Only PostgreSQL's 42703 is read that way; any other
  error stays null, and so does a host whose db capability does not return a parsed body.

Changed

• docs/RETENTION.md no longer promises to drop the three purged columns in a later release —
  a statement that was misleading in a way worth naming: we cannot know which player version runs
  against a host's database, and the host can. Shipping that DROP in supabase/migrations/,
  which every host replays, would hand an irreversible gesture to installations we have never seen;
  on 0.1.145 and earlier it would reject every session and view write, with an error naming a
  column rather than a version. The section now states the condition, hands over the three
  statements, and says plainly what they buy: tidiness, not erasure. The erasure already
  happened — 0026 and 0027 removed the values, and routine autovacuum removed them from the
  pages, measured on a real host at four seconds after the second migration, with no lock and
  nothing triggered by hand. It also warns what is lost with the column: the col_description()
  comment is what proves the purge was applied, and a count of zero does not, since it cannot
  tell "purged" from "never written".

What changed in the package, by zone — 0.1.147 → 0.1.148

Measured on the two tarballs, by the release workflow. Not written by hand.

Zone	What it is	Added	Removed	Changed
documents	what a human reads	0	0	2
manifest	package.json — version, exports, dependencies	0	0	1
server	the code the host executes	0	0	2
context	the injected-context implementations	0	0	0
browser-types	the declarations the host's tsc reads for « ./bridge » — breaks a build, never a page	0	0	0
browser	what the visitors' page executes	0	0	0
cli	the command-line entry point	0	0	0
types	declarations for the server and context entry points — breaks a build, never runtime	0	0	0
database	the schema and the migrations the host applies itself	0	0	0

The files themselves

~ docs/HOST-CONTRACT.md
~ docs/RETENTION.md
~ package.json
~ server/handler.js
~ server/retention.js