[bokelley]

Implements #8992 for 3.3 rc.0. A creator's Instagram, Facebook, Snapchat and X channels can now be listed in collection.distribution[].identifiers with their own types, instead of the generic platform_channel_id. That type only works inside a distribution entry and can't be used in bare identifier contexts, such as exclude filters.

Closes #8992.

What changes

Eight enum values in enums/distribution-identifier-type.json, each with an enumDescriptions entry, following the YouTube pattern. The stable ID is canonical, and the handle is a discovery alias that should resolve to it.

Platform	Canonical ID	Handle alias
Instagram	instagram_account_id	instagram_handle
Facebook	facebook_page_id	facebook_page_handle
Snapchat	snapchat_profile_id	snapchat_handle
X	x_user_id	x_handle

The enum description notes the values were added in AdCP 3.3, the convention tests/x-added-in-3-3-sweep.test.cjs checks for added enum values. The test now asserts it.

Registry normalization. server/src/services/collection-identifier-normalization.ts adds the values to DISTRIBUTION_IDENTIFIER_TYPE_VALUES. The four new handle types normalize the way youtube_channel_handle already did, as @ plus the lowercased name, so JuniperVale and @junipervale match. The YouTube-only helper becomes one handle helper over a set of handle types. IDs are kept as sent, trimmed.

Platform-agnostic lint. instagram and facebook are vendor tokens in tests/check-platform-agnostic.cjs, so the four values that carry them are allowlisted for this enum only. The justification is the same one already given for roku_channel_id: each is the platform's own ID namespace for a channel. snapchat and x aren't vendor tokens.

Docs. collections-and-installments.mdx lists the social types next to the podcast and video ones, with the same canonical-versus-alias rule and the handle comparison rule.

Why 3.3

Adding enum values is additive, and #8704 allows it in a minor. The values only appear in identifier lists that already accepted platform_channel_id, so nothing that validated before stops validating. Creator cards (#8094, #8098, #8141) are new in 3.3, so this is the release that needs them. The adopter is Availnet's creator marketplace, through Apostra.

Tests

• New server/tests/unit/services/collection-identifier-normalization.test.ts: 14 cases. Each new type is valid, every handle type normalizes with and without @, and IDs are kept as sent.
• node tests/check-platform-agnostic.cjs: no violations.
• node --test tests/x-added-in-3-3-sweep.test.cjs: 6 of 6.
• node --test tests/lint-schema-enum-drift.test.cjs tests/collection-copies-vectors.test.cjs tests/collection-catalog.test.cjs: 80 passed, 0 failed.
• npx tsc --noEmit -p server/tsconfig.json: clean.
• node scripts/check-changeset-protocol-scope.cjs origin/main and changesets status: pass, minor bump.
• node tests/schema-validation.test.cjs: still running locally when this was opened. CI runs it.

🤖 Generated with Claude Code

[aao-secretariat]

Ladon verdict: Escalate to human review

Escalate — gated path requires human/CODEOWNERS approval.

This is a clean additive PR: it adds 8 social distribution-identifier-type enum values (Instagram, Facebook, Snapchat, X) with a correct minor changeset. The reviewer verified full coherence across the schema enum, enumDescriptions, docs ("Available social types" in collections-and-installments.mdx), the service mirror DISTRIBUTION_IDENTIFIER_TYPE_VALUES, and the normalizeHandle/HANDLE_IDENTIFIER_TYPES path — all five list the same 8 values in the same order. The platform-agnostic allowlist adds exactly the 4 vendor-token matches (instagram_*, facebook_*) with snapchat_*/x_* correctly omitted. New unit tests and the 3.3 description sweep cover the change. No Critical/High/Medium findings.

However, this PR modifies static/schemas/source/enums/distribution-identifier-type.json, which matches the deterministic gated-path glob static/schemas/source/** (gated_paths: true). Because review_decision is REVIEW_REQUIRED (not APPROVED), the hard approval gate (decision table row 2) is not satisfied and the outcome cannot be approve.

Escalation reasons:

• Modifies gated path static/schemas/source/enums/distribution-identifier-type.json (matches static/schemas/source/**); human/CODEOWNERS review is required before merge. The change itself is additive, non-breaking, and clean — this is a mechanical approval gate, not a code concern.

Why human review

• Modifies gated path static/schemas/source/enums/distribution-identifier-type.json (matches static/schemas/source/**) while review_decision is REVIEW_REQUIRED — human/CODEOWNERS approval required (decision table row 2).
• This PR touches a path under a hard, non-overridable approval gate (static/schemas/source/enums/distribution-identifier-type.json (modified) matches static/schemas/source/**) and the current GitHub review decision is 'REVIEW_REQUIRED', not APPROVED. This is a hard gate enforced in code — Ladon cannot auto-approve until a human/CODEOWNERS approval is recorded, regardless of how clean the diff is.