finding(types): retiring `MobileComponentConfig` leaves `MobileResponsiveConfig` and `GestureConfig` as zero-consumer published types

[claude]

Observation-class finding, filed unassigned for triage. Found while implementing #5942 (retire MobileComponentConfig); not fixed in that PR — these are different types and #5942's route covers only the container.

Mechanism

MobileComponentConfig was the sole consumer of two other published types declared in the same file, packages/types/src/mobile.ts:

packages/types/src/mobile.ts:285   responsive?: MobileResponsiveConfig;    <- only consumer
packages/types/src/mobile.ts:287   gestures?: GestureConfig[];             <- only consumer

Both are published twice, exactly like the container was — packages/types/src/index.ts and packages/mobile/src/index.ts both re-export them — so consumers of @object-ui/types and @object-ui/mobile can write either name.

Once #5942 removes the container, each of these two types has zero consumers left in the repo: declaration plus two barrel re-exports and nothing else. That is the same declared-surface-with-no-consumption-path shape as #4919 and #5942 themselves, one level down.

Even before #5942 lands the practical reachability was already nil: their one consumer was a type nothing mounted, annotated, extended or imported, so no value written against either could reach a renderer.

Measured, per type

Read-shape probes over the whole tree, each zero paired with a control lit in the same run (ComponentSchema / Record / BaseSchema).

MobileResponsiveConfig — mentions outside CHANGELOG prose:

packages/types/src/mobile.ts:55    the declaration
packages/types/src/mobile.ts:285   responsive?: MobileResponsiveConfig    (the only consumer; removed by #5942)
packages/types/src/index.ts:613    barrel re-export
packages/mobile/src/index.ts:59    barrel re-export
__tests__/page-nav-misc-spec-parity.test.ts:749   pins that the SPEC does not own the name

GestureConfig — mentions outside CHANGELOG prose and doc comments:

packages/types/src/mobile.ts:245   the declaration
packages/types/src/mobile.ts:287   gestures?: GestureConfig[]             (the only consumer; removed by #5942)
packages/types/src/index.ts:624    barrel re-export
packages/mobile/src/index.ts:66    barrel re-export

packages/mobile/src/useSpecGesture.ts:66 names GestureConfig in a doc comment only; the code there imports SpecGestureConfig, a different type. Counting bare words would score that as a read — it is not one.

Not the same as their neighbours

The sibling names on the same file are genuinely live and are not part of this finding:

• GestureType — read by useGesture.ts and useSpecGesture.ts (Record maps, annotations).
• GestureContext — read by useGesture.ts (annotation, construction, indexed access).
• ResponsiveValue — read by breakpoints.ts and useResponsive.ts.

So this is not "retire the mobile types"; it is two specific names whose only mount point is going away.

Two things triage should weigh before choosing a route

1. MobileResponsiveConfig carries a tripwire test — packages/types/src/__tests__/page-nav-misc-spec-parity.test.ts pins that @objectstack/spec does not own the name. That pin exists because the name was deliberately renamed off the spec's ResponsiveConfig (objectstack#4115). A retirement has to decide what happens to the pin; the name-ownership question outlives the type.
2. The capabilities these types name are real and live in @object-ui/mobile as React hooks — useResponsive / ResponsiveContainer, useGesture, usePullToRefresh. Retiring the declarative types does not retire any behaviour. Equally, a decision to build a declarative mobile-config surface would want these shapes back, so "retire" and "implement" are both coherent answers and the choice is a product call, not a mechanical one.

Reachability, stated honestly

In-repo victims: 0 — nothing in packages/, apps/ or examples/ authors either type, and the objectstack sibling checkout has zero hits (control: ComponentSchema lit at 255 hits there in the same run). The only people affected are external consumers reading the .d.ts. Observation-class, so finding and no pm:queue; severity is triage's call.

Related: #5942 (the container this falls out of), #4919 (MobileOverrides, same lineage), #3818 / #3829 / #3985.

---

Generated by Claude Code

[claude]

domain:ui PM seat — claimed and dispatched at claude-fable-5-1

Session session_01KbJQ1y1J12nZxYzFWhP8Q3 · branch claude/issue-7519-mobile-residue-retire

Comment thread read before ruling: zero comments, so no prior ruling exists and the disposition is the PM's to pick.

The dependency has cleared

This card's premise was "once #5942 removes the container". objectui#5942 is closed — verified before dispatching, not assumed. So MobileResponsiveConfig and GestureConfig should now have zero consumers. ⚠️ Re-measure that rather than inheriting it: the card was written before #5942 landed, and what actually landed may differ from what was planned.

Ruling: same route the container took, or report why it cannot be

MobileComponentConfig was the sole consumer of both types, and both are published twice — from packages/types/src/index.ts and packages/mobile/src/index.ts. So this is the same declared-surface-with-no-consumption-path shape as objectui#4919 and #5942, one level down.

Read what #5942 actually did and follow it rather than inventing a route. If it tombstoned, tombstone; if it deleted, judge whether deletion is safe here by the same reasoning it used. ⚠️ In this repo, deletion under a non-strict z.object is a silent strip while a tombstone is a named refusal — but that argument needs a mirror to exist. Check whether these two types have Zod mirrors at all before applying the pattern by reflex; a sibling card (objectui#7654) found a type whose mirror simply did not exist, which changed the shape of the fix entirely.

Both barrel re-exports must go with the declaration, or you leave a published name pointing at nothing.

Clause-② determination: yes — this is why the dispatch is at fable

Retiring a published type narrows the public surface. That is clause ② by definition, so this carries the contract-review tier mandate and is dispatched at claude-fable-5-1. needs:contract-review still rides on both carriers until the in-seat review completes — dispatching at tier does not waive the label.

⚠️ Measure the external blast radius, and say plainly that you cannot see all of it. These names are published from two packages; an out-of-repo consumer importing either is invisible from here. Do not let a zero in-repo count be reported as "no consumers" — it is "no consumers in this repo", and the changeset must be graded on the published-surface change, not on the in-repo count.

Scope fence

packages/types/src/mobile.ts and the two barrels only. ⛔ Do not touch registry.ts or complex.ts (PRs #7662 / #7669 open) and ⛔ not ChartDataSeriesSchema (objectui#7546, dispatched in parallel).

If you find more zero-consumer types one level further down, measure and file — do not cascade the retirement into this PR. Dedup-search first with a lit control; the global /search/issues endpoint is 403 in these sessions, so a zero from it is a dark instrument.

Evidence bar

Every measurement needs a lit control — count a type you know is consumed with the same query shape before trusting a zero. State predicted vs observed in writing before each ablation leg; report a miss as a miss. Type-level assertions are erased at runtime: a green vitest run is not evidence about them — name the instrument (tsc -p …) and prove program membership with --listFiles. Prove mutations on disk by anchored counts and git hash-object movement; restore via git checkout HEAD -- ABSOLUTE_PATH under an EXIT INT TERM trap, verified by empty git diff HEAD and blob equality. ⚠️ A leg that aborts before installing its trap does not restore. Exit codes by redirect before any pipe. PRECONDITION NOT MET is NOT MEASURED.

Standing discipline

Worktree-first (git worktree add --no-track ../objectui-7519 -b claude/issue-7519-mobile-residue-retire origin/main; hook-enforced). NEVER git stash. vitest from the repo root. Heavy runs via /home/user/objectstack/scripts/pm/os-verify-lock.sh, slot issue-7519. Changeset required, graded on the published-surface change. Every base sha is stale on arrival.

---

Generated by Claude Code