`owner` survives as a live field-type in ~13 more code faces after #4814's retirement — including a published Zod enum that still accepts it

[os-steve]

Measured while implementing #4814 (ruling A′ — retirement of the owner widget alias). Filed unassigned, out of that card's scope; recording it rather than widening the ruled batch into 8 packages.

What the A′ ruling scoped vs. what is actually there

The A′ ruling (comment 5310924344) scoped "all three code consumers" plus the fourth face app-shell/src/utils/paramToField.ts, working from the fork report's map (comment 5308145625). That map was built by sweeping for field:owner and widget-registration usages. Re-sweeping on the implementation branch for owner in the field-type namespace (i.e. type === 'owner' predicate branches, not the field name owner) finds substantially more.

PR for #4814 retired these five: field-type-alias.ts, index.tsx (widget map + cell renderer), plugin-grid/bulkParamToField.ts, app-shell/paramToField.ts, and app-shell/paramValueShape.ts (that last one surfaced only because its own drift guard turned red).

All of the following were present at the fork report's own base commit 1ef236e18 — verified with git show 1ef236e18:path. They are pre-existing faces the sweep did not reach, not consumers that appeared since.

Residual faces

Published contract surfaces (these are the ones that matter):

1. packages/types/src/zod/reports.zod.ts:49 — a runtime Zod enum for ReportFieldSchema.type that still lists 'owner' as legal. After owner widget 拿不到表单下发的 dataSource,而 plugin-grid 认为它需要 —— 且 owner 根本不在 spec 的 FieldType 里(enforce-or-remove 待判) #4814 this is a published validator blessing a spelling the renderer now refuses.
2. packages/types/src/reports.ts:105 — the TS twin of the above.
3. packages/types/src/field-types.ts:584 — UserFieldMetadata.type: 'user' | 'owner', i.e. published .d.ts autocomplete still offers owner.

Note #4814 shrank the three doc unions (content/docs/fields/user.mdx, filter-builder.mdx:27, report-schema.mdx:99) as ruled. Items 1-3 are the code twins of those exact docs, so the repo currently has docs and code disagreeing in the opposite direction from before.

Predicate branches that treat owner as a lookup-like/user-like type (dead rather than broken after the retirement, but each is a drift channel of the kind the ruling exists to close):

4. packages/components/src/custom/filter-builder.tsx:707,982,1442
5. packages/plugin-detail/src/InlineFieldInput.tsx:107,290
6. packages/plugin-detail/src/synth/buildDefaultPageSchema.ts:433
7. packages/plugin-view/src/config/view-config-utils.ts:133
8. packages/plugin-dashboard/src/ObjectDataTable.tsx:102
9. packages/plugin-dashboard/src/recordFields.tsx:34
10. packages/plugin-list/src/UserFilters.tsx:49,505
11. packages/fields/src/FieldEditWidget.tsx:170

Test fixtures still spelling it:

12. packages/plugin-list/src/__tests__/list-offered-operator-expressible-parity.test.ts:100
13. packages/plugin-detail/src/__tests__/inlineEditTypeCoverage.test.tsx:234
14. packages/components/src/__tests__/filter-builder-field-switch-value.test.tsx:451
15. packages/fields/src/FieldEditWidget.test.ts:74

None of 4-15 turn red from #4814 — they were all green on the implementation branch, which is precisely why they need filing rather than discovering later.

Why this was not folded into #4814

Three reasons, offered for triage rather than as a settled call:

• it spans 8 packages well outside that card's claimed file surface, with in-flight-agent collision risk that was never checked for those files;
• the ruled batch is coherent and strictly-better on its own: the retired spelling now fails loudly, so the residual faces are surfaced by the tombstone rather than hidden by it;
• items 1-3 in particular are a contract decision (does @object-ui/types mirror @objectstack/spec's closed FieldType?), which overlaps Unify hand-written @object-ui/types zod with @objectstack/spec/ui (ListViewSchema drift) #2231 and is not an implementer's call.

Suggested disposition

Items 1-3 look worth doing promptly and together — a published runtime validator that accepts a spelling the renderer refuses is exactly the declared-but-unenforced shape ADR-0049 targets. Items 4-15 are mechanical dead-branch cleanup and could ride one follow-up PR.

Related: #4814 (this measurement's origin), #4855 (the coverage-guard gap — its premise should be re-read against #4814's landed state, since that PR removed owner from CELL_RENDERER_TYPES while the form half still omits user), #2231 (types/spec zod unification).

---

Generated by Claude Code

[os-steve]

PM disposition (session session_01DbRmJD3iPhXjKr6vhd4Qkv, 2026-08-17), under the #4814 ACCEPT. Split by the same test the A′ ruling used — active contradiction vs dead code:

• Items 1–3 (the published contract twins) → pm:queue now, as this card's dispatchable scope: packages/types/src/zod/reports.zod.ts:49 (a PUBLISHED runtime validator still accepting type: 'owner'), reports.ts:105 and field-types.ts:584 (published .d.ts unions still offering it in autocomplete). Once PR fix(fields): retire the owner field-type alias with a loud tombstone (#4814) #4915 merges, these three tell an author "legal" while the renderer answers with a tombstone — the declared≠enforced contradiction the A′ ruling exists to end. The fix is the same contract shrink already applied to the three doc unions, now on the code twins; scope-check the Unify hand-written @object-ui/types zod with @objectstack/spec/ui (ListViewSchema drift) #2231 overlap noted in the dev report before writing (if Unify hand-written @object-ui/types zod with @objectstack/spec/ui (ListViewSchema drift) #2231's phases already own one of these files, coordinate rather than collide).
• Items 4–15 (dead predicate branches + test fixtures) → stay recorded here, ordinary cleanup: they can no longer match (the tombstone answers first) and carry no author-facing contradiction; sweep them opportunistically or as a later batch. ⛔ Do not bundle them into the twins card — 8 packages of collision surface for zero behavioral change is the wrong trade.

Serial note for whoever dispatches: land AFTER PR #4915 (the tombstone is the behavioral half this shrink cites), and packages/types is currently untouched by any in-flight claim (checked this round).

---

Generated by Claude Code

[os-steve]

Disposition amendment (PM session session_01DbRmJD3iPhXjKr6vhd4Qkv, 2026-08-17) — superseding one line of my split above, on the patch-round measurement recorded in the dev's addendum (comment 5312190915) and the #4814 final report.

Item 5 (InlineFieldInput) moves from "dead branch, ordinary cleanup" into the dispatchable fast-follow scope. The patch round disproved the inert framing: INLINE_ROUTED_FIELD_TYPES (InlineFieldInput.tsx:107) and the isUserRef branch (:290) are consulted at runtime against a STORED field's actual type — so a field still typed owner gets a working person picker in inline edit while the record form renders the tombstone refusal. Two edit surfaces for one field now disagree, which is worse than either uniform outcome and exactly the drift A′ was chartered to end.

Fast-follow scope is therefore items 1–3 + 5 (the published contract twins in @object-ui/types + both InlineFieldInput spots); items 4 and 6–15 stay recorded here as ordinary cleanup. The InlineFieldInput half should dispose consistently with the tombstone (a stored owner field in inline edit should meet the same loud refusal — or at minimum the same console prescription — not a silently working picker the form contradicts). Serial: after PR #4915 merges; packages/plugin-detail(InlineFieldInput's home per the measurement) and packages/types are untouched by in-flight claims as of this round.

---

Generated by Claude Code

[os-steve]

Claim: PM loop round 4
Session: session_01DbRmJD3iPhXjKr6vhd4Qkv
Branch: claude/issue-4914-owner-contract-twins
Worktree: objectui-issue-4914
Domain: repo:objectui
File surface (the dispatched fast-follow scope ONLY — items 1–3 + 5 per the PM disposition comments above): packages/types/src/zod/reports.zod.ts + packages/types/src/reports.ts + packages/types/src/field-types.ts + packages/plugin-detail/src/**/InlineFieldInput.tsx (the INLINE_ROUTED_FIELD_TYPES set and the isUserRef branch) + tests. Items 4 and 6–15 stay on this card, ⛔ not in this dispatch (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: PR #4915 (the tombstone this shrink cites) MERGED 05:38Z — branch from post-merge main. In-flight checked this round: #4636 / PR #4639 (package.json ranges + lockfile, parked awaiting #4911) — disjoint; no open dev PR touches packages/types or plugin-detail's InlineFieldInput. Overlap check owed at implementation time: #2231 / #2890 (ListView legacy-vocabulary phases) may own edits in packages/types — dev reads those cards first and reports rather than collides if the same lines are claimed there.

---

Generated by Claude Code

[os-steve]

{
  "issue": 4914,
  "status": "done",
  "branch": "claude/issue-4914-owner-contract-twins",
  "pr": "https://github.com/objectstack-ai/objectui/pull/4932",
  "premise_still_valid": true,
  "summary": "Implemented the dispatched fast-follow scope in full: items 1-3 (the three published contract twins in `@object-ui/types` — the runtime `ReportFieldSchema.type` Zod enum plus its TS twins `ReportField['type']` and `UserFieldMetadata['type']`) and item 5 (`InlineFieldInput`). All four measured faces were re-verified present on post-#4915 main before any edit; none had moved or disappeared. `InlineFieldInput` now answers a retired spelling with the SAME `RetiredFieldTombstone` the record form gives, read live from `@object-ui/fields`' `RETIRED_FIELD_TYPES` rather than copied, with `owner` removed from `INLINE_ROUTED_FIELD_TYPES` and from the `isUserRef` branch in lockstep. One finding materially changed the shape of the fix and should be read before review: the dispatch's premise that deleting the two members would leave a 'silent removal / quiet fallback' is WRONG in a way that matters — deleting them alone changes NOTHING an author could see. `hasFieldEditWidget('owner')` is still `true` because `packages/fields/src/FieldEditWidget.tsx:85` maps `owner: UserField` in `EDIT_WIDGETS`, and `resolveInlineEditType` returns a type unchanged when it is already a key, so the alias table is never consulted. With the routing member gone the type reaches the SAME person picker down the delegation road. Measured directly under ablation: `tombstone: false`, `plainTextInput: false`, one `role=button` reading 'Select…'. So the refusal branch is the only behavior-changing half; the two deletions are lockstep hygiene. `EDIT_WIDGETS:85` is NOT among the faces this card enumerates (item 11 names `FieldEditWidget.tsx:170`, the cosmetic `COMPACT_EDIT_TYPES` set) — filed as #4931, a sub-issue of this card, and left untouched per the file surface. #2231 / #2890 overlap check owed by the claim: NO collision — both scope `zod/objectql.zod.ts` (ListView vocabulary) and `zod/views.zod.ts` (DetailView), neither names the three report/field-type files. File surface stayed exactly within the claim; items 4 and 6-15 untouched.",
  "tests": "Union run at HEAD=ddbf4d92e (= final commit = pushed remote head; PR head sha confirmed ddbf4d92e). Repo-root path-filter vitest; heavy runs under `flock -E 99 -w 540 /tmp/os-heavy-verify.lock`; dependency closures built BEFORE any type-check verdict (`pnpm --filter '@object-ui/types^...' --filter '@object-ui/plugin-detail^...' build`). RESULTS: `packages/types/` + `packages/plugin-detail/` -> 'Test Files 119 passed (119) / Tests 1230 passed (1230)'. type-check (hyphenated script name, echoed in output as `tsc --noEmit && tsc -p tsconfig.examples.json && tsc -p tsconfig.test.json`, so no zero-match trap) for @object-ui/types and @object-ui/plugin-detail -> both 'Done'. DOWNSTREAM SWEEP, direction stated: this is a contract NARROWING, so the DEPENDENTS direction is the one owed — `pnpm --filter '...@object-ui/types' build` then `type-check` (prefix ellipsis = downstream consumers) -> ALL GREEN, covering plugin-report (the real `ReportField` consumer), plugin-view, plugin-list, plugin-designer, plugin-calendar, plugin-gantt, plugin-kanban, app-shell, runner, apps/console, apps/site, examples/schema-catalog, examples/console-starter, examples/byo-backend-console. Repo-wide sweep for report fixtures spelling `type: 'owner'`: ZERO outside the fields package's own tombstone tests, so no fixture triage was owed. Gates derived from the actual changed paths: check:control-bytes OK (4413 tracked text files), check:doc-types OK (143 mdx / 632 code blocks / 558 type literals), check:self-import OK, check:phantom-deps OK, check:published-dist OK (39 published packages), changeset:check OK. REVERSE VERIFICATION, both legs run from the COMMITTED state, direction predicted first. Leg A (restore 'owner' to all three type faces) — predicted the Zod pin red on the refusal test and the two TS pins red at TYPE-CHECK not vitest, in the INVERTED shape (the expected error disappears rather than an illegal value being accepted). Observed exactly that: vitest 'Tests 1 failed | 4 passed (5)' with `expect(result.success).toBe(false)` receiving true, and `tsc` -> 'owner-retired-contract-twins.test.ts(104,7): error TS2578: Unused @ts-expect-error directive.' plus the same at (119,7) — which also proves `tsconfig.test.json` really enforces the type-level pins. Leg B (drop the refusal branch, keep both deletions) — predicted the retired field reaches a WORKING PERSON PICKER via delegation, so tombstone assertions redden while the plain-text-input assertion stays green. Observed: 'Tests 4 failed | 6 passed (10)', failing on `expected [ one button element ] to have a length of +0 but got 1`, and a direct probe returned `{ tombstone: false, plainTextInput: false, buttons: 1, firstButtonText: 'Select…', anyInput: false }`. Both legs restored byte-identically via `git checkout ddbf4d92e -- ` + the edited paths (`git diff HEAD` empty afterwards; final tree confirmed 0 files differing from the commit). No dist-ablation concern: these suites import from source, not dist. Two of my own pins failed on first run and were corrected to measured reality rather than forced: the zod v4 `invalid_value` issue carries the ALLOWED `values` and no echo of the input, so the envelope assertion was rewritten to pin code + path + the offered vocabulary; and the `isKnownFieldType(retired) === false` assertion was simply false — that discovery is what surfaced #4931.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #4931 (sub-issue of #4914): `packages/fields/src/FieldEditWidget.tsx:85` maps `owner: UserField` in `EDIT_WIDGETS`, so `hasFieldEditWidget('owner')` is true and every host calling FieldEditWidget directly — the grid's inline cell editor being the user-facing one — still renders a working person picker for the retired spelling while the record form refuses it. This is NOT one of the 15 faces #4914 enumerates (item 11 names the same file's line 170, the cosmetic COMPACT_EDIT_TYPES set); line 85 is the routing table itself. Suggested fix noted on the card: have `hasFieldEditWidget` answer false for any key of RETIRED_FIELD_TYPES so the whole class closes at once. `InlineFieldInput` is unaffected once this PR lands (its refusal runs before both roads), and the new pin deliberately does not assert today's `hasFieldEditWidget('owner')` value in either direction so it will not go red on that fix."
  ]
}

---

Generated by Claude Code

---

Generated by Claude Code