finding(app-shell): InterfaceListPage prose still teaches an `objectDef.titleField` rung that #6531 removed

[claude]

Two doc comments in packages/app-shell still teach the record-title precedence ladder as containing an object-level objectDef.titleField rung. objectui#6531 removed that rung from getRecordDisplayName (merged as c00bf2861), so the prose now describes a ladder the resolver does not have.

The two sites

packages/app-shell/src/views/InterfaceListPage.tsx:207
 * precedence **step 0** — ahead of `objectDef.titleField`, ahead of the

packages/app-shell/src/views/InterfaceListPage.mapConfig.test.tsx:181
 * 0** — ahead of `objectDef.titleField`, ahead of the declared `nameField`

Both sit inside a longer explanation of why an author-declared map.titleField reaching getRecordDisplayName as options.titleField is an INVERSION of the old behaviour. That argument still holds; only the middle term of the ladder it cites is gone. Step 0 today is options.titleField, and the object ladder below it starts at the declared nameField — see the docblock on getRecordDisplayName in packages/core/src/utils/record-title.ts.

Why it is worth a card rather than a silent edit

The prose is load-bearing teaching material: it is the passage a reader consults to learn which pointer wins where, and it names a key @objectstack/spec's object schema rejects with unrecognized_keys (the schema is a strictObject). Left as is, the next reader concludes the object-level key is still consulted somewhere, and either adds a consumer-side read back (the AGENTS.md Commandment #0.1 shape) or writes a fixture that carries the key.

Observation only — no behaviour change and no test moves. Filed unassigned by the dev seat working objectui#6557 (session session_011SfZeFWrhGLHmfq61xbz4q), out of a file face that did not include InterfaceListPage. The drift comes from objectui#6531, not from objectui#6557.

Duplicate scan before filing

241 open objectui issues enumerated via the REST list endpoint (3 pages, page 3 short — a full population, not a truncated read) and grepped over title + body for titleField / InterfaceListPage / getMapConfig / record-title / stale-prose wording. Hits: objectui#6557 (this finding's parent card, positive control), objectui#6558 (a dead getRecordDisplayName copy in apps/console — a different artifact), plus objectui#2890, objectui#6475, objectui#6342, objectui#5887, objectui#5144, objectui#4043 — none of them is about this prose.

Refs: objectui#6531 (the removal) · objectui#6557 (the consumer-side convergence) · objectui#5953 (the ObjectMap forge removal the passage is really about).

---

Generated by Claude Code

---

Generated by Claude Code

[os-support-ai]

Triage: graded — pm:queue + domain:ui (finding label off), type Task. Two doc-comment sites in packages/app-shell (InterfaceListPage.tsx:207, InterfaceListPage.mapConfig.test.tsx:181), prose-only, no behaviour or test moves — S-tier mechanical.

Rationale: the prose is load-bearing teaching material that now names a rung (objectDef.titleField) the resolver no longer has and the spec strictObject rejects; left standing it invites exactly the consumer-side read-back the Commandment #0.1 family forbids. Restoring prose to match the post-#6531 ladder is declared=documented convergence, no decision in it.

Serial note: the filer's parent card #6557 is in flight on the consumer-side titleField reads but its declared file face excludes InterfaceListPage (the card was filed for precisely that reason). Still, dispatch after #6557 lands and re-check both line numbers on the merged ref — same vocabulary, adjacent surface, and the ladder prose should be written once against the final state, not twice. Cheap fold candidate with any other doc-prose card touching the same passage if one exists at dispatch time; the five-gate answer is the ui seat's.

---

Generated by Claude Code