DAN-860: unlock's Seal identity moves to the fulfillment — main goes green

[Danny-Devs]

Closes the 3.5-week red main. 154 passed in Python (was 2 failed / 152 passed); TypeScript 1102 passed, unchanged.

What was actually wrong

Not "a test disagrees with a decoder." Python and TypeScript implemented disjoint requirements field sets for the same scheme — the intersection was empty.

A Seal threshold key-server model replaced the encryptionId model on 2026-07-20. It reached the conformance vectors and the TS runtime; it did not reach Python or docs/specification.md. Python was faithfully implementing a stale spec, which is why making CI green by editing a vector would have made the spec bug permanent.

The ruling, and the test that settles it

Seal is canonical. encryptionId belongs in neither requirements nor payload — it travels in the fulfillment (s402UnlockFulfillment, which already existed).

Can the server know this value at the moment it must send it?

Requirements ship in the 402, before payment exists. packageId / keyServers / threshold / contentDigest are properties of how the seller already encrypted — knowable. The Seal identity is receiptId ‖ nonce, and that receipt is minted by a transaction the buyer constructs in response to that 402.

So encryptionId in requirements was never merely stale — it was unsatisfiable by the party required to populate it. Recorded as ADR-012.

⚠️ Precision that matters for the next reader: the reason is not "the escrow doesn't exist yet." Under seal_policy.move's escrow flow the escrow_id is deterministic from signed TX1 bytes. unlock was rebuilt as a single-transaction scheme with no escrow at all; its anchor is the receipt's own object ID. REVIEW-NOTES.md contains both statements — §3 item C and §6b — and §6b is the later and correct one.

Changed — three files

File	Why
python/src/s402/http.py	unlock requirements + payload key sets and validate_unlock_shape brought to the vectors; payload encryptionId check deleted
docs/specification.md	§4.9, the unlock payload table, and both known-key lists. The payload table also stopped describing a two-stage TX1/TX2 flow
docs/adr/012-…md	the decision and the reusable test

Not touched, deliberately: the conformance vectors and the TS runtime. No vector was edited. .github/workflows/ci.yml is byte-identical to main.

Two of the ticket's premises did not survive checking

1 · types.ts needed no change. The ticket cites typescript/src/types.ts:436 as a required requirements field. That line is inside s402UnlockFulfillment — where encryptionId correctly belongs. s402UnlockExtra and s402UnlockPayload were already right. Three of five surfaces needed nothing; the real scope was two.

2 · CI was never the gap. Criterion 5 says "Nothing was merged, so nothing ran." CI runs on push: branches: [main] and it did run — run 29811549631, completed failure, 44s, on the exact commit, 2026-07-21T07:44Z. It reported red on time and nobody looked. Adding a scheduled run would produce a second unwatched red. The encoding is notification or a required check — left for @Danny-Devs, since it is a repo setting rather than code.

Criterion 4, and a correction to my own first pass

Criterion 4 asks to delete typescript/test/conformance/vectors/ as "an unread duplicate ... a trap with no upside."

It is not stale, not a duplicate, and not hand-maintained. It is gitignored build output: typescript/scripts/prepare-publish.sh copies spec/vectors/*.json into it during prepublishOnly, and hard-fails if the source is missing. It is in package.json's files array so npm consumers receive the contract. It cannot drift — cp has no opinions — and it is correctly absent from a clean checkout. Deleting it would strip the vectors from the published package.

An earlier revision of this PR added a drift check on it. That was wrong and has been removed. I had read the two directories as copies kept in sync by discipline. They are not; one is generated from the other at publish time. Worse, the check failed on the CI runner with published dir missing — because a clean checkout correctly does not have it — which would have made CI red on every commit. That is precisely how a correct guard gets switched off (DAN-719), and I built the thing I had flagged as the hazard.

The exit-2 "cannot check" path is what surfaced this, so the failure was loud rather than silent — but the right outcome is no check here at all.

The real uncovered gap, recorded in ADR-012 rather than patched: spec/vectors/ is itself generated, by test/conformance/generate-vecters.ts running the live encode/decode functions. Nothing asserts the tracked vectors still match what the current code produces. That check is worth building; it is not built here because tsx is not an installed dependency, so it could not be watched green — and an unverified gate is worse than an absent one.

Verify: cd python && uv run --extra dev pytest -v → 154 passed on this branch.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
s402-docs	Ready	Preview	Aug 16, 2026 7:12am