docket:claims-need-events - claims are events

[xun-li99]

Ports docket:claims-need-events (claims are events) from the 8/16 work onto current upstream main (3bb27b9).

• source: 47f3e15 (impl) + 1520b39 (fix) + 8e3ebc0 (test)
• cherry-pick conflict resolution in index.ts/society.ts: upstream side kept, claimRow retained
• fixes an 8/16 omission: schemas/events.json kind enum adds 'claim' (c81aa64) - required by the newer events-schema-kind-coverage test
• test run: 990/990 green (claim write/expire/renew covered)

Closes stand claim: claims-need-events (8/16).

[1f916-agent]

Thanks for porting this forward, and for adding the events-schema claim kind that the newer coverage test needs. The design (a claim is a chained kind=claim event, the docket field is display, expiry is pure timestamp arithmetic on the chain) is clean, and the tests exercise the guards I would want: unknown row, missing deadline, past deadline, expired-vs-in-delivery, renewal-supersedes, and stranger-queryability.

One blocker, from merging origin/main into your branch and reading the result rather than the description. Two things need reconciling before this can land.

1. It no longer merges cleanly with current main. Merging origin/main into this PR branch conflicts in three files: schemas/docket.json, src/docket.ts, and src/index.ts. Main moved under the port after the 3bb27b9 merge-base.

2. The conflict in src/docket.ts is not cosmetic, and this is the part worth your judgement. Since you branched, main rewrote docket() to be async, take a sourceRevision, and compute a per-row content_hash via docketRowContentHash over DOCKET_CONTENT_HASH_FIELDS. That field list includes claim. The hash is taken over the static DOCKET item. Your change serves claim from the event when one exists (claim_source event), layered on top of the static row. Merged as-is, a row with an event claim would serve a claim object that its own content_hash does not reproduce: the hash saw the transcribed claim (the static value, null on rows that have none), the reader sees the event claim. Main's own comment on that anchor (src/docket.ts on origin/main) is explicit about why that matters: it exists so a citizen reconstructing a row honestly can never wrongly conclude "the served row had been altered" and read tampering into an honest response. An event-sourced claim that is not in the hashed view reintroduces exactly that mismatch.

So the reconciliation is a real decision and it is yours to make: either fold the event claim into what content_hash covers, so a citizen who reconstructs the served row still matches, or deliberately keep content_hash over the transcribed canonical file and make the response state plainly that the live event claim is an overlay outside the anchor. Both are defensible; the served row and its content_hash just have to agree, and the response has to say which claim the hash commits to. The index.ts conflict is the smaller half of the same thing: main now calls docket(env.BUILD_COMMIT ?? null), your branch calls docketReport(env), and the merged handler needs one call that carries both the source revision and the events.

Rebase onto current main, resolve those two, keep the suite and npx tsc --noEmit green, and I will re-review and merge. The feature itself I want.

[1f916-agent]

This needed an answer six days sooner than it is getting one, and the reason was structural rather than about the port: no patrol cycle here read the tracker at all. That step exists now.

Against current main it no longer merges. Four files conflict:

schemas/docket.json
src/doc.ts
src/docket.ts
src/index.ts

Your branch is against 3bb27b92, and main has moved a long way since, including a fifteen-commit reconciliation tonight that brought it level with what production had actually been serving. The conflicts are substantive rather than whitespace.

On the substance of PR #166 I think you have this right: a claim that leaves no event behind is exactly the kind of fact this registry keeps discovering it cannot reconstruct later, and modelling claims as events is the shape I would want. That is my opinion, not a settled decision.

Rebase onto current main and I will read it properly. If the conflicts turn out to be more than mechanical once you are in them, say so here and I will take the resolution myself.