refactor(pipeline): route comparison identity through typed constructors

[Sinity]

Summary

Makes it structurally impossible for non-content data to enter a session's
comparison-identity value: message/attachment/event identity now go through
four fixed keyword-only constructors instead of a dict-key-list projection.

Problem

session_revision_projection (polylogue-aggz Invariant 1, landed in #3401)
built comparison identity by slicing an already-constructed hash-stable
payload dict against a tuple of allowed field names
(_MESSAGE_IDENTITY_FIELDS, _ATTACHMENT_IDENTITY_FIELDS,
_EVENT_BASE_IDENTITY_FIELDS). Two real, expensive defects were exactly a
non-content field reaching that value: polylogue-bu1i folded attachment
acquisition state (inline_bytes/size_bytes) into identity (151
aistudio-drive cohorts wrongly ambiguous, 14 sessions absent, a day of
investigation), and polylogue-nuec folded a provider-reported measurement
(elapsed_duration_ms) into event identity (135 chatgpt cohorts read as
divergent despite byte-identical content). Both were fixed by hand, per
field. Nothing prevented a third occurrence: any code could still call
hash_payload() on an arbitrary dict and call it "identity" — the
allowlist was a convention encoded in a tuple of strings, not enforced by
the type system.

docs/plans/hash-boundary-registry.yaml — a machine-checked census of every
hash-producer call site in polylogue/ — exists as a workaround for the
missing chokepoint: since anyone could compute an identity hash anywhere,
the repo keeps a list of where they did.

Solution

polylogue/pipeline/ids.py now exposes the sole path into each
comparison-identity value as a fixed keyword-only function:

• message_identity_hash(*, id: str) -> bytes
• attachment_identity_hash(*, message_id, name, mime_type) -> bytes
• event_base_identity_hash(*, event_type, source_message_provider_id) -> bytes
• event_canonical_identity_hash(*, base_identity, content_hash) -> bytes

Passing any other field — or spreading a whole payload dict as **kwargs —
is a TypeError at the call boundary, not a value someone has to remember
to strip. session_revision_projection now calls these instead of the
removed _message_identity_payload/_attachment_identity_payload/
_event_base_identity_payload dict-slice helpers, which are deleted along
with their backing field-name tuples.

Every stored/pinned hash stays byte-identical. The constructors build
the exact same dict shapes the removed helpers did (same keys, same values,
hash_payload sorts keys so order is irrelevant), and
test_session_revision_projection_golden_hashes (which pins exact digest
bytes) and the independent-recomputation test both pass unchanged with no
golden updates. This is a pure re-plumbing of an existing correct
computation, not a semantic or schema change — the "if you find yourself
editing the goldens, stop" tripwire never fired.

docs/plans/hash-boundary-registry.yaml is NOT retired. It governs all
198 hashlib/core.hashing call sites across polylogue/ (58+ files:
blob-store content-addressing, HMAC signatures, redaction digests,
cache/dedup keys, judgment-run identifiers, sinex material adapters, ...),
of which only ~12 (in pipeline/ids.py) are the session/message/
attachment/event comparison-identity axis this bead targets. Claiming the
registry's whole purpose is now covered would not survive a diff-grep. The
registry's pipeline/ids.py entries were updated to match the new call
sites (four new <module>.<constructor> entries replacing four
session_revision_projection occurrences); devtools verify hash-boundary-census is clean. Filed polylogue-ubwg to audit whether any of
the registry's other 91 identifier-classified sites share the aggz
failure shape (a mutable/acquisition-state field folded into a value used
for equality/dedup comparison) and would benefit from the same constructor
pattern — only once every site is provably covered or provably out of class
can the registry itself be deleted.

Tests

Added to tests/unit/pipeline/test_pipeline_ids.py:

• test_message_identity_hash_rejects_non_content_fields — passing text
  raises TypeError.
• test_attachment_identity_hash_rejects_acquisition_state — passing
  size_bytes/inline_content_hash raises TypeError.
• test_attachment_identity_hash_rejects_full_payload_spread — simulates a
  future parser adding a brand-new field to the hash-stable payload and
  spreads the entire payload dict (including that new field) into the
  constructor; rejected outright, proving a new field can't silently enter
  identity by construction, not by someone remembering to exclude it.
• test_event_base_identity_hash_rejects_measurement_fields — passing
  payload={"elapsed_duration_ms": ...} raises TypeError.
• test_identity_constructors_ignore_new_payload_fields_when_called_correctly
  — two attachments differing only in acquisition state produce identical
  identity.
• test_event_canonical_identity_hash_folds_base_and_content — sanity check
  on the fold.

Verification

• devtools test tests/unit/pipeline/test_pipeline_ids.py tests/unit/archive/test_session_revision_membership.py → 56 passed
• uv run mypy --strict polylogue/pipeline/ids.py polylogue/archive/session_revision_membership.py tests/unit/pipeline/test_pipeline_ids.py → Success, no issues found
• devtools verify --quick → exit_code 0 (includes verify hash-boundary-census)
• Not run: devtools verify --all / full integration suite (out of scope
  per repo convention — per-PR CI skips the heavy test suite; targeted
  devtools test above covers every affected module).

Ref polylogue-aggz.

Co-Authored-By: Claude noreply@anthropic.com

[coderabbitai]

Warning

Review limit reached

@Sinity, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 8 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 6c902d71-553f-4030-be3c-4a1e5e4bd73d

📥 Commits

Reviewing files that changed from the base of the PR and between 32266af and 8253c56.

📒 Files selected for processing (4)

• docs/plans/hash-boundary-registry.yaml
• polylogue/archive/session_revision_membership.py
• polylogue/pipeline/ids.py
• tests/unit/pipeline/test_pipeline_ids.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}