[finding] `ObjectLevelPermission` has no consumer left once `RoleDefinition.permissions` is retired — a published type nothing references

[yinlianghui]

Observation-class finding, no user-visible impact today. Surfaced while implementing #4288 inside sweep #4328; recorded rather than fixed, because retiring a second published type is its own judgement call and would have put a row in that PR's diff that its member table does not have.

What

ObjectLevelPermission (packages/types/src/permissions.ts) had exactly one structural referent in this repository: the RoleDefinition.permissions field. #4288 retires that field, so after it lands the type is referenced only by the two barrels that re-export it:

• packages/types/src/index.ts (the @object-ui/types public surface)
• packages/permissions/src/index.ts (re-export)

Nothing constructs one, nothing accepts one, nothing reads one. PermissionCondition is one step further out: its only referent is ObjectLevelPermission.conditions, so it inherits the same status transitively. (PermissionEffect is not in this set — FieldLevelPermission.effect still uses it, and that type is live.)

The grants the evaluator actually applies come from ObjectPermissionConfig.roles, whose inner shape is declared inline and does not use ObjectLevelPermission.

Why it is an observation and not a defect

An exported type with no consumers costs nobody a wrong answer. It is worth a card because it is the same declared-but-unread shape #4288 was, one hop out, and because leaving it named in the public surface invites the next author to reach for it as if role-attached grants were a thing the runtime honours — which is exactly what #4288 removed.

Directions (for triage, none advocated here)

1. Retire both (ObjectLevelPermission, PermissionCondition) as a follow-on dead-surface row. Same criterion as the sweep, and both are @object-ui/types exports so the changeset shape matches sweep: dead-surface deletions batch 3 — 3 zero-consumer items, one claim, one PR (findings-triage 2026-08-11) #4328's.
2. Keep as vocabulary if role-attached grants are a direction the platform intends to build, and let the types return with the reader. Worth an explicit note in that case, since "declared, no reader" is what got the field retired.

Deliberately not judged here: which of those is right depends on whether role-direct grants have a business pull, and that is a product call rather than a code one.

Dedupe

Searched open issues for ObjectLevelPermission, PermissionCondition, and role-permission type retirement: no existing card. #4288 covers the field only; its member row is closed by #4328's PR.

[yinlianghui]

CLAIM (pair) + RULINGS — PM seat session_017Qqyix2QcnpUC9XeYVDzx3, dispatching one dev agent for #4364 + #4368 (both post-retirement dead-surface rows, disjoint surfaces, one sweep-style PR per the #4328/#4366 pattern), branch claude/issue-4364-4368-dead-surface-pair, one PR with Fixes #4364 + Fixes #4368.

Rulings (delegated authority, veto window open):

• [finding] ObjectLevelPermission has no consumer left once RoleDefinition.permissions is retired — a published type nothing references #4364 — RETIRE both types (ObjectLevelPermission, PermissionCondition; PermissionEffect stays, it has the live FieldLevelPermission.effect reader). The enforce-or-remove default the maintainer applied to ActionEngine 的 event-mapping(addMapping / dispatch)零生产调用方,且 condition 求值与 visible 契约不一致 #3368 governs: zero-caller public export, no usage plan for role-attached grants, and the card's own warning — a named-but-unhonored type invites the next author to build against a contract the runtime removed — is the RoleDefinition.permissions is required and read by nothing — every consumer uses only name/inherits #4288 lesson one hop out. If role-direct grants gain business pull later, the types return WITH their reader.
• finding(console): metadataConverters.ts and MetadataService.ts lose their last importer with the object-detail retirement — two console-local duplicates of live app-shell modules #4368 — DELETE the console copies (apps/console/src/utils/metadataConverters.ts, apps/console/src/services/MetadataService.ts), not re-export: zero importers post-refactor(console): retire the dormant object-detail page factory and its seven widgets #4365 makes a re-export a dead surface with extra steps, and the app-shell copies are the live, tested ones. First step per the card: diff the copies for behavioral divergence — a divergence is EVIDENCE to record in the PR body (which behavior the live copy has), not a blocker. The dangling @object-ui/plugin-designer dependency + its lone vi.mock mention: measure and clean if the measurement confirms it dangles.

Veto window open as always; both retirements are one revert away.

---

Generated by Claude Code

[yinlianghui]

Half the ruling executed, half declined on measurement — dev seat session_017Qqyix2QcnpUC9XeYVDzx3, branch claude/issue-4364-4368-dead-surface-pair, draft PR #4410 (Part of #4364, not Fixes).

ObjectLevelPermission is retired as ruled — re-measured at 456aac831, its only referents were its own definition, the two barrel lines, and the prose of #4288's retirement note. PermissionEffect untouched, FieldLevelPermission.effect still reads it.

PermissionCondition is kept: the card's premise for it does not hold. The card says its "only referent is ObjectLevelPermission.conditions, so it inherits the same status transitively." It does not — and this is not drift, the referent predates the card:

packages/permissions/src/evaluator.ts:14:   PermissionCondition,              (import)
packages/permissions/src/evaluator.ts:116:  condition: PermissionCondition,   (parameter type)

evaluateCondition(condition, record) at evaluator.ts:115 implements all eleven operators the type declares plus a prototype-pollution guard, under 26 assertions in packages/permissions/src/__tests__/evaluator.test.ts:171-236. Deleting ObjectLevelPermission removes the conditions? field but leaves PermissionCondition typing a real reader, so it is not dead surface.

The decision this leaves you — not guessed, per the escalation rule. evaluateCondition is itself a dead-surface shape one hop further out: exported from evaluator.ts but not from the @object-ui/permissions barrel (which re-exports only evaluatePermission from that module), and its only importer in the repo is its own test file. Retiring it is what would free PermissionCondition.

• A — retire evaluateCondition too, then PermissionCondition follows and the card closes as originally ruled. Same enforce-or-remove logic: zero production callers, not reachable through the package entry point.
• B — keep both. Unlike a bare type, this is executable behaviour with a security guard and a real suite; the conditional-permission surface (PermissionCondition + its evaluator) is coherent and implemented, which is a different thing from ObjectLevelPermission, which was a naming with no implementation anywhere.

Recommendation: B, keep both, and close this card on the ObjectLevelPermission retirement alone. On the three axes — business need: neither option has measured pull, but A destroys a working implementation while B only leaves it unused, and the asymmetry matters because the cost of being wrong is not symmetric. Long-term soundness: the thing #4288 and this card are actually about is a declared surface the runtime does not honour — an author writing permissions: [...] on a role got silence. evaluateCondition is the opposite shape: call it and it works, correctly, on all eleven operators. Hard-to-get-wrong: retiring ObjectLevelPermission removes the trap (there is no longer a type inviting role-attached grants); retiring evaluateCondition removes no trap, because nothing can reach it accidentally — it is not in the barrel.

If you rule A, it is a small follow-on PR against this same branch or a fresh card; I have not filed a separate issue for it, since it sits inside this card's completion scope and splitting it would scatter the decision away from the ruling.

Also delivered on the same PR: #4368 in full (Fixes) — both console duplicates deleted, both measured to have drifted behind their live app-shell counterparts, and the @object-ui/plugin-designer dependency kept because the measurement disproves the dangle (app-shell's DefaultAppContent, which the console renders, lazy-loads it for four live routes, so the console suite's vi.mock is load-bearing).

---

Generated by Claude Code

---

Generated by Claude Code

[yinlianghui]

PM RULING #2 — correction and closure (session session_017Qqyix2QcnpUC9XeYVDzx3; veto window open as always).

My original ruling ordered both types retired on this card's transitive premise. The premise was false at the branch point — PermissionCondition types the live, tested evaluateCondition (evaluator.ts:14/:116, 26 assertions, prototype-pollution guard) — and the dev correctly stopped that member rather than executing the error (PR #4410's report, and the follow-on comment above).

Corrected ruling: recommendation B is adopted. PermissionCondition and evaluateCondition both stay. The asymmetry argued on the card is decisive: ObjectLevelPermission was a naming with no implementation — the trap shape that invites building against a contract the runtime doesn't honor — and it is retired (PR #4410, armed). evaluateCondition is the opposite: a correct implementation with its own pins, not reachable from the package barrel, posing no imitation trap; deleting it destroys value while reducing no risk. If role-attached grants ever gain business pull, the type and its evaluator return to service as a coherent, already-tested unit — which is the "keep as vocabulary" branch of this card done with the reader attached, the only honest way to keep vocabulary.

Closing this card as completed: the title defect (the trap-shaped type) is retired via PR #4410; the kept surface is a recorded decision, not an oversight.

---

Generated by Claude Code