finding(mobile): SpecResponsiveConfig is a renamed hand-copy of the spec's ResponsiveConfig — same key set, no compile-time tie

[yinlianghui]

Observation-class finding, surfaced by the structural census run for #4592. Nothing is changed for it there — #4592 owns scripts/** only, and packages/mobile is another seat's surface.

What was found

packages/mobile/src/useResponsiveConfig.ts:26 declares:

/**
 * Spec-aligned ResponsiveConfig (mirrors @objectstack/spec ResponsiveConfigSchema).
 * ...
 */
export interface SpecResponsiveConfig {
  breakpoint?: BreakpointName;
  hiddenOn?: BreakpointName[];
  columns?: Partial< Record< BreakpointName, number > >;
  order?: Partial< Record< BreakpointName, number > >;
}

This is the #4588 shape exactly: a hand-written interface mirroring a spec object, renamed away from the spec's symbol (ResponsiveConfig → SpecResponsiveConfig), carrying a canonical-sounding claim, with no import, no z.infer, and no other compile-time tie to the spec.

Of the 38 structural census hits in #4592, this was one of only three that ALSO carried an unbacked prose claim, and the only one of those three whose duplication is not deliberate and reasoned at the declaration (the other two — MarketplacePackageTranslation, bundle size; ElementDataSourceConfig, a documented filter divergence — are in the gate's CLAIM_ALLOW with those reasons).

It agrees with the spec TODAY — that is the whole point

Measured against @objectstack/spec 17.0.0-rc.6: the spec's ResponsiveConfig declares exactly breakpoint?, hiddenOn?, columns?, order?, all optional, over the same six breakpoint names (BreakpointName in @object-ui/types includes 2xl). Key-for-key and optionality-for-optionality identical — 1.00 overlap.

So this is not a live defect and nothing is broken. It is the state the derivation guard's header calls "one spec release away from drifting": the agreement is maintained by nobody, checked by nothing, and the comment already tells the next session it is canonical. ViewNavigationConfig (#4588) presumably read exactly like this on the day it was written, and had drifted on mode by the time anyone looked.

Options, if it is picked up

• Derive it — export type SpecResponsiveConfig = ResponsiveConfig (or z.infer< typeof ResponsiveConfigSchema >), which is what finding(types): @object-ui/types publishes two spellings of the spec's navigation config, and the hand-written ViewNavigationConfig still requires mode #4588's fix did for ViewNavigationConfig and what makes the claim structural. Costs an @objectstack/spec dependency edge from @object-ui/mobile, which may be the reason it was hand-written; that is worth checking before assuming it is an oversight.
• Keep the copy and say why, moving it to the gate's CLAIM_ALLOW with the reason (the route MarketplacePackageTranslation takes for bundle size).
• Add a parity test pinning the key set both directions, the way select-option-spec-parity.test.ts does — the cheapest option that makes drift loud without adding a dependency edge.

Not established here: which of the three is right, and whether the dependency-edge concern is real.

It is named in the shrink-only CLAIM_DEBT ledger added by #4592, so the gate reports it until it is resolved one of those ways.

Refs #4592, #4588, #4550.

---

Generated by Claude Code

[yinlianghui]

CLAIM — session session_017Qqyix2QcnpUC9XeYVDzx3, branch claude/issue-4598-mobile-responsive-config.

PM ruling (delegated, veto window open) — measure first, then the cheapest honest binding:

1. Measure: (a) does @object-ui/mobile already depend on @objectstack/spec (direct dep, not hoisted node_modules reachability — check:phantom-deps is the arbiter)? (b) does a package mobile ALREADY depends on (types, core) publish a spec-bound ResponsiveConfig it could import (core's ResolvedResponsiveConfig is a sibling census hit, NOT necessarily spec-bound — verify, don't assume)?
2. Fix hierarchy: existing dependency edge with a spec-bound export ⇒ derive/import through it; direct spec dep already present ⇒ derive from the spec; NEITHER ⇒ do NOT add a new package dependency for one 4-key type — instead make the comment honest (state it is a deliberate local copy and why, naming the diverging risk) and move the symbol from CLAIM_DEBT to CLAIM_ALLOW with that reason. Adding @objectstack/spec to mobile's dependencies is an open question, not a unilateral move.
3. Whichever branch: the CLAIM_DEBT entry "@object-ui/mobile": ["SpecResponsiveConfig"] must be deleted (derived ⇒ claim is backed; ALLOW ⇒ moved) — ratchet Implement component reordering via drag-and-drop in designer canvas #5 of the hardened gate enforces this, which is also your red-first: with the source fix applied and the ledger line still present, check:spec-symbols REDS on the stale entry; deleting it greens. If deriving, add an invariant Equal< … > pin against the spec's published type.

Mutual exclusion: scripts/** edit is ONE surgical ledger-line deletion (+ possible CLAIM_ALLOW entry) — #4592's seat has delivered and landed, so the file is free, but touch nothing else in it. ⛔ packages/types base.ts + react + layout + app-shell = #4581-remainder's in-flight seat. ⛔ #4597's surfaces (i18n spec-formatters, types/views.ts, their ledger lines) — do not touch, it dispatches separately to avoid ledger-block conflicts.

---

Generated by Claude Code

---

Generated by Claude Code

[yinlianghui]

PM step-7 复核: ACCEPT. PR #4604 took branch 1 of the hierarchy on measurement — @object-ui/types already publishes the schema's own type under this exact name (index.ts:1223), so the binding cost no new dependency edge, no ALLOW entry, and no open question. Three things are exactly right: (1) the parity pin targets @objectstack/spec/ui DIRECTLY, because pinning against types' re-export would compare the import to itself — the middle link (types re-growing a hand copy) is the one place this fix can still rot and the one place no gate sees, and the test header says so; (2) the honest mechanism note that the hardened gate goes quiet by seeing NOTHING (a bare export type {…} is not a declaration it collects), so the parity test is the load-bearing pin, not the gate's silence; (3) the reverse verification's unpredicted extra signal (the hook's own body went red on order when the copy was re-grown without it) reported as found. Ledger 27→26 claims / 7→6 packages with the ratchet red verbatim. Entry .d.ts byte-identical, shape proven invariant-equal by probe ⇒ patch. CI 20/20 zero failures.

(Also noting the dev's rule-2 observation on my own claim comment's doubled footer — correct call to surface rather than touch; it's the platform's comment-path rewrite, cosmetic only.)

Flipping ready and arming auto-merge now. #4597 dispatches on this landing (shared CLAIM_DEBT block).

---

Generated by Claude Code

---

Generated by Claude Code