fix(client): publish the revocations an xfer-full states by omission

[XieX]

Stacks on #93 -> #87

This should be the last of the python SDK fixes, ported over from the Typescript SDK work.

The gap

_ProtocolReader._server_intent builds a fresh empty _pending for xfer-full, so a skill the full transfer omits is correctly dropped from the committed set at _payload_transferred. But _changes only ever accumulated from _put_object and _delete_object, so nothing was published for an omitted skill.

Verified against the reader directly before the fix: after a full transfer carrying a put for pdf:3, a second xfer-full carrying no objects emptied the store while outcome.changes was [] and diagnostics.objects_revoked stayed 0.

A full transfer that carries other puts still wakes a watcher through those puts, so the observable gap is the transfer carrying no puts at all — the environment's last skill revoked. watch_skills then never reconciles and the skill's SKILL.md stays on disk until some unrelated change, which contradicts TESTING.md §3.26 ("a revocation delivered over a live stream prunes the skill's files within debounce of arriving") in exactly the case pruning exists for.

The fix

Ports the shape TypeScript already has (revocationsBetween / keysFullyRevoked in typescript/packages/client/src/skills-fdv2.ts, called from payloadTransferred under intent === INTENT_TRANSFER_FULL):

• _identity_of, _revocations_between, _keys_fully_revoked — module-level, placed where TypeScript has them, just above _ProtocolReader.
• _payload_transferred diffs the committed set against the incoming one before the swap when the intent is xfer-full, extends _changes with the tombstones, and adds _keys_fully_revoked(...) to objects_revoked.
• The diff is at (key, version) granularity to match delete-object, so a key whose version moved yields both a put for the arrival and a tombstone for the departure.

The two counting rules stay consistent: per key for the omission diff (a version move counts zero), per applied revocation for delete-object (#93's change, where objects_revoked only increments when _SkillObjectSet.delete actually removed something). _keys_fully_revoked's docstring names that as the shared rule.

One doc touch: add_listener now says both ways of stating a revocation arrive as a tombstone — a delete-object, and a full transfer that stopped carrying the object.

Tests

Four protocol-reader cases:

• a full transfer omitting a previously-held skill publishes a {key, version} tombstone and increments objects_revoked;
• an omitted version-less object is reported with version: None, the way a delete-object naming no version spells it;
• a version move publishes both ends and increments objects_revoked by zero;
• an xfer-changes that mentions nothing revokes nothing — diffing a delta would drop every skill it simply had no reason to mention.

Plus an end-to-end test_a_full_transfer_that_omits_every_skill_prunes over the fake FDv2 endpoint: queue a put, then full_payload(state="basis-2") with no objects, and assert the SKILL.md is pruned.

These discriminate — with the source reverted, all four of the new cases fail. (The xfer-changes guard passes either way, as it should; it guards against applying the diff to the wrong intent.) The e2e case was run five times for flakiness.

Gate

From python/: make test (1872 passed, 11 skipped), make typecheck (clean, 51 source files), make lint, make format-check — all clean.

🤖 Generated with Claude Code, edited by @XieX

---

Note

Overview
Ports TypeScript-aligned fixes into the Python skills client so full FDv2 transfers (xfer-full) emit tombstones for skills dropped by omission, not only for explicit delete-object events. On payload-transferred, the reader diffs committed vs pending at (key, version) granularity, extends listener changes with those tombstones, and updates objects_revoked per key (version moves count as zero). watch_skills can prune when the last skill disappears via an empty full transfer, which previously emptied the in-memory store silently.

FDv2 polling/resume behavior is tightened: ignored foreign/none payloads no longer advance the stream basis, ETags are sent only when they match the current basis (_etag_basis), and response ETags are stored only after a payload fully applies—avoiding stale 304s and “healthy” diagnostics while updates stop.

Separately, when a store returns verified content whose object key ≠ the requested key, retrieval now logs ld.skills.integrity_failure with reason_code: key_mismatch and served_key via record_key_mismatch, without the product integrity signal (documented in README/agents.md). Tests cover tombstones, basis/ETag wire cases, end-to-end prune, and the log-only mismatch path.

^{Reviewed by Cursor Bugbot for commit b9b05de. Bugbot is set up for automated code reviews on this repo. Configure here.}