Document from/into reassignment counts in merge preview

[marcmlc]

What Changed

The merge-preview response now reports two counts for each object type rather than one:
from — how many records are on the contact being merged away and would move to the
surviving contact — and into — how many the surviving contact already has.

merge_preview_reassignments now defines conversations, tickets, phone_calls,
tags and notes as objects with required from and into integer properties, and the
inline 200 example is nested to match. The endpoint description is updated to describe
the paired counts.

API Versions Affected

• Preview

Tracks intercom/intercom#548033

[shrek-intercom]

❌ PR Review Summary: NEEDS HUMAN REVIEW

	Summary
✅	🎯 Problem — The description clearly documents what changed (from/into counts in merge preview) but only implies the why, lacks an explicit problem statement, and is somewhat verbose with implementation details.
✅	📝 Alignment — The PR description accurately and completely reflects all code changes, including the schema type changes, updated inline example, and endpoint description update.
ℹ️	🧠 Correctness — Disabled for this repository.
❌	🦺 Safety — The PR makes a breaking type change (integer → object) on existing fields in merge_preview_reassignments, which is never auto-approved regardless of API tier and requires human review.
✅	🚦 Auto-approval — Within size limit (0/150 LOC).

Per-criterion details

Problem

The description clearly documents WHAT changed (from/into counts in merge preview) but only implies the WHY - that users need to see both the source and destination counts separately rather than a single count. The problem being solved (presumably clarity about what's moving vs what exists) isn't explicitly stated. It's well-structured but verbose with implementation details.

Alignment

The PR description states that the merge-preview response now reports two counts (from and into) for each object type instead of one, that merge_preview_reassignments defines conversations, tickets, phone_calls, tags, and notes as objects with required from and into integer properties, that the inline 200 example is updated to match, and that the endpoint description is updated.

The diff confirms all of these claims:

1. The endpoint description (line ~8251) is updated to describe the paired from/into counts — matches the claim about updating the endpoint description.
2. The inline response example changes from flat integers (e.g., conversations: 12) to nested objects (e.g., conversations: { from: 12, into: 5 }) — matches the claim about updating the inline 200 example.
3. The merge_preview_reassignments schema changes each property from type: integer to type: object with from and into integer sub-properties, each with required: [from, into] — matches the claim about defining properties as objects with required from and into integers.
4. The only file changed is descriptions/0/api.intercom.io.yaml, which is the Preview version — matches the stated "API Versions Affected: Preview."

There are no omissions of significant changes, no phantom claims, and no scope mismatch. The description accurately and completely reflects what the code changes do.

Safety

The PR modifies only descriptions/0/api.intercom.io.yaml (the Unstable/Preview tier), which is generally the safe zone for additive changes. However, this is not an additive change — it changes the type of existing fields in the merge_preview_reassignments schema. Specifically, conversations, tickets, phone_calls, tags, and notes are changed from type: integer to type: object (with from and into sub-properties). This is a type change on existing fields, which constitutes a breaking change. Any client currently consuming this endpoint's response would break because the shape of the data fundamentally changes (integers become objects).

The safety criteria explicitly state that breaking changes — including "changing a type" — are never auto-approved "regardless of tier," meaning even Preview/Unstable tier type changes require human review.

<violated_criteria>
Breaking changes in any version — changing a type (integer → object for conversations, tickets, phone_calls, tags, and notes fields in merge_preview_reassignments schema). Breaking changes to the public contract are never auto-approved regardless of tier.
</violated_criteria>

_{Rate this comment 👍 / 👎 to help us improve 🙏 · Disagree with assessment? Establish ground truth here}