`ObjectTrigger` and `ObjectRelationship` are orphaned hand-written exports after the ObjectSchemaMetadata derivation (#5362)

[os-sam]

Observation from #5362, filed unassigned. Not a defect — nothing is wrong at runtime — recording dead declaration surface.

Fact (at the #5362 branch, base da8db03a6)

packages/types/src/field-types.ts exports two hand-written interfaces whose only reason-for-being was the retired ObjectSchemaMetadata mirror's members:

• ObjectTrigger — was referenced solely by the mirror's triggers?: ObjectTrigger[]
• ObjectRelationship — solely by the mirror's relationships?: ObjectRelationship[]

With the mirror retired (derivation from @objectstack/spec/data's ServiceObject), both are exported from @object-ui/types (src/index.ts) with zero in-repo references outside their own declaration and the index re-export (repo-wide grep over packages/ apps/ examples/, *.ts/*.tsx, node_modules and dist excluded). The spec's object document declares neither a triggers nor a relationships member, so they do not correspond to any spec surface either.

#5362 deliberately did NOT remove them: they are published surface, and cutting exports is a separate decision from the ruled derivation. DataModelDesigner's relationships state is its own local model, not these types (checked).

Options

• A — retire both exports in a follow-up (breaking-ish for external consumers; changeset minor with the semantics stated, per the version-alignment convention).
• B — keep them with a comment stating they are client-side vocabulary awaiting a consumer, if one is expected.

No urgency either way; this exists so the dead surface is on the books rather than rediscovered.

---

Generated by Claude Code

[claude]

Finding concentration round (triage seat, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24, maintainer-invoked): promoted → pm:queue (domain:ui), Task (S). Delete the orphaned ObjectTrigger / ObjectRelationship exports (zero in-repo references, no spec correspondence). Published-surface removal: re-run the zero-importer measurement on current main first, changeset per this repo's minor-break policy.

---

Generated by Claude Code

[yinlianghui]

Claim: PM loop round 38 (refill slot)
Session: session_01CSoz9uGhaaSgiq3hshtN7L
Branch: claude/issue-5859-retire-orphaned-object-exports
Worktree: objectui-issue-5859
Domain: domain:ui
File surface: wherever ObjectTrigger / ObjectRelationship are declared and exported in packages/types + a changeset. ⛔ Nothing else.
Container & model: S, mode:subagent, model: opus
Clause-②: yes — a published surface removal. Declared; Opus under this seat's recorded Fable-quota exemption.
⚠️ Serial: packages/types had three PRs land or enqueue today — #6053 (objectql.ts + zod/objectql.zod.ts) MERGED, #6068 (base.ts + plugin-scope.ts) enqueued, and #6032 merged earlier. Branch from a merge-base containing what has landed, and ⛔ if your targets live in base.ts or plugin-scope.ts, stop and report rather than racing #6068. Other siblings: #5725 (app-shell/.../previews/), #5874 rework (app-shell/src/utils/), #5795 (app-shell/src/utils/deriveRelatedLists.ts, views/RecordDetailView.tsx, plugin-detail/src/synth/).

裁决 — triage's grade

Triage seat, 2026-08-24 (finding concentration round), → pm:queue / Task (S). Verbatim:

Delete the orphaned ObjectTrigger / ObjectRelationship exports (zero in-repo references, no spec correspondence). Published-surface removal: re-run the zero-importer measurement on current main first, changeset per this repo's minor-break policy.

They are orphans of the ObjectSchemaMetadata derivation (#5362) — hand-written exports the derivation left behind.

PM mechanism assumptions — measure, do not assume

1. ⛔ "Zero in-repo references" is the whole basis for deleting a published name. Re-measure it yourself, and give a counter-probe. Search packages/**, apps/**, examples/** for each name, and show a name you know is consumed found by the identical method. A zero without a control is not a measurement. ⚠️ Also check the objectstack checkout — a cross-repo consumer would change the answer, and [finding] ComponentMeta has two published declarations (base.ts + plugin-scope.ts), already diverged by tags/description, and the PluginComponentMeta alias has zero consumers #5893 did exactly that probe today and it was worth doing.
2. ⚠️ In-repo zero is NOT npm zero. This is a published removal and an external consumer cannot be measured from here. ⛔ The changeset must name both retired symbols verbatim so a host can search for them, and must state the external caveat rather than implying the removal is free.
3. ⚠️ "No spec correspondence" is the second half of the justification — verify it against the installed @objectstack/spec rather than inheriting it. If either name does correspond to something the spec declares, the card's premise breaks and you ⛔ stop and report.
4. ⚠️ Check whether a barrel re-exports them (packages/types/src/index.ts and any zod barrel). Deleting the declaration while a barrel still names it is a build break; deleting only the barrel entry leaves a dead declaration. Both halves, or neither.
5. Version policy: a public-type break ships minor by AGENTS.md §版本号策略, not major — check-changeset-no-major.mjs refuses major outright. feat(types)!: retire the ActionCondition branch shape from ActionSchema.condition #5981 and ObjectViewProps.views[].sort declares direction, but every sort consumer reads order — a host-supplied desc view silently sorts ascending #5293 are the precedents.

⚠️ Two-stage or one?

#5605's family established a two-stage retirement (deprecate, then delete in a later release) for a published key with zero measured consumers. ⚠️ Triage here said delete, not deprecate. Take the delete — but if your measurement finds any consumer at all, in either repo, ⛔ stop and report; that turns this into the two-stage shape and is a different card. ✅ Say explicitly in the report which of the two you concluded and on what evidence.

Verification

⚠️ A deletion's verification is the reverse of a feature's. Direction predicted before running: after the deletion, type-check across packages/types and the downstream prefix-form sweep must stay green — that is the positive evidence nothing consumed them. ⛔ And that green is weak on its own: it is equally consistent with a build that never looked. So also show the counter-probe: delete (or rename) a name you know is consumed and show the same sweep goes red. Without it, "the sweep is green" proves only that the sweep ran.

Prove every mutation on disk by grepping injected and separately removed text; ⚠️ print the landing site, ⚠️ assert anchor uniqueness before writing, ⚠️ restore under trap … EXIT INT TERM with a cwd-independent command (all three measured on cards in this round).

Gates by name with exit codes: pnpm --filter @object-ui/types type-check (⚠️ hyphenated; echo the script name; distinguish the unbuilt-closure red, Cannot find module @object-ui/..., from the missing-node_modules red), root-form vitest over packages/types/src, the downstream prefix-form sweep pnpm --filter '...@object-ui/types' with the contract direction stated (⚠️ known gotcha: it fails at apps/site and packages/components until @object-ui/react-runtime is built separately — not a finding), and eslint with merge-base delta (⚠️ plain eslint ., ⛔ no --no-inline-config). ⚠️ New standing rule from #5874 this round: run pnpm check:esm-specifiers if you add or move any relative import in a published package — it lives inside the Type Check CI job under a name that does not look like one, and a hand-derived gate set misses it.

Changeset required, minor, naming both symbols verbatim. Draft PR, Fixes #5859. ⛔ Do not mark ready, ⛔ do not enqueue, ⛔ no auto-merge — the PM lands it. Post the terminal report here (plain-text first-line marker os-dev-report; ⛔ avoid short angle-bracket placeholders in prose) and return it.

---

Generated by Claude Code