feat(entity-client): publish the attribute-type allowlists

[josecarneiro]

Why

RELATION_ATTRIBUTE_TYPES and the overridable_attribute type allowlist are currently hand-copied across four repos, kept in sync by a comment:

Repo	File	Copy of
entity-api	.../schema/schema-attribute-service.ts:11, :98	both
epilot360-entity-builder	.../custom-configs/editModeUtils.ts:13	relation
epilot360-entity-builder	src/entity-builder/conditions/conditions-config.ts:321	overridable
epilot360-entity-builder-v2	src/lib/edit-mode.ts:33	relation
epilot360-integration-hub	.../config-schema-validation.ts:41	relation

conditions-config.ts even carries a comment saying it was "verified member-for-member" against entity-api — a manual sync contract, which is the thing worth deleting.

This is the follow-up to #464, which built the mechanism (a client's schema-model.ts reaching consumers as real runtime values) but didn't yet use it for the constants that motivated it.

What changed

clients/entity-client/src/schema-model.ts gains:

export type AttributeType = NonNullable<Attribute['type']>

export const RELATION_ATTRIBUTE_TYPE_LIST = [...] as const satisfies readonly AttributeType[]
export const OVERRIDABLE_ATTRIBUTE_TYPE_LIST = [...] as const satisfies readonly AttributeType[]

export const RELATION_ATTRIBUTE_TYPES: ReadonlySet<string> = new Set(RELATION_ATTRIBUTE_TYPE_LIST)
export const OVERRIDABLE_ATTRIBUTE_TYPES: ReadonlySet<string> = new Set(OVERRIDABLE_ATTRIBUTE_TYPE_LIST)

These reach consumers as @epilot/entity-client exports and, through the copyModels generator step from #464, as @epilot/sdk/entity exports too.

Three decisions worth a look

ReadonlySet<string>, not ReadonlySet<AttributeType>. Every consumer calls .has(attribute.type) on an unnarrowed string. A Set<AttributeType> would reject that and force a cast at all four call sites; typing the set as string keeps the migration import-only. The type safety lives on the arrays instead, where it costs nothing.

The anchor is Attribute['type'], not a hand-written union. Attribute is an anyOf of 35 variants, so that resolves to every type literal the spec declares (39 in total). Verified the guard bites — adding 'not_a_real_type' fails with TS1360.

Renamed VARIANT_OVERRIDABLE_ATTRIBUTE_TYPES → OVERRIDABLE_ATTRIBUTE_TYPES, matching the overridable_attribute flag it gates and what epilot360-entity-builder already calls its own copy. Easy to revert if you'd rather keep the old name.

Test plan

• pnpm build (tsup + dts) clean across all 51 APIs
• 11 tests pass in models.test.ts (2 new)
• New test parses the entity spec, resolves all 39 declared attribute types, and asserts every allowlist member is one of them — a runtime guard complementing the compile-time satisfies. It also pins ordered_list as declared-but-not-overridable, the case that made an allowlist necessary rather than a denylist
• Verified the values in the built bundle, not just source: dist/apis/entity.cjs exports both sets with the right members, and RelationAffinityMode still resolves
• Drift guard confirmed both ways: a member absent from the spec fails TS1360; the spec-parsing test is non-vacuous (39 types found, rejects a fake one)
• pnpm lint clean (524 files)

Note on releasing

This touches no clients/*/openapi.json, so the spec-gated auto-release job will not fire — the same thing that happened to #464, which only shipped when an unrelated spec PR swept it up ~90 minutes later. It needs the changesets flow (pnpm version-packages && publish-packages) or a manual @epilot/sdk@x.y.z tag. A changeset is included.

Worth considering separately whether the gate should also trip on clients/*/src/schema-model.ts and packages/epilot-sdk-v2/src/**.

Follow-up (not in this PR)

Once released, delete the four copies. entity-api is the awkward one — it has no @epilot/sdk dependency and is pinned to @epilot/entity-client@^4.25.1 while 7.4.0 is published, so it needs either a new dep or a three-major bump. Those are GitLab repos, so they'll be MRs rather than PRs.

---

Generated by Claude Code