finding(plugin-grid): ObjectGrid's held-key census still calls renderCellEditor undeclared and its ruling "pending" — #6882 declared it two days ago, so the comment now states the opposite of the tree #7196

Activity

1. os-warren

   added

   pm:queue

   finding

   priority:p3

   domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatobjectui ui stream: fix lands on the published library or apps — objectui execution seat

   pm:dispatched

   and removed

   pm:queue

   on Sep 1, 2026
2. os-warren

   self-assigned this

   on Sep 1, 2026
3. os-warren commented on Sep 1, 2026

   

   os-warren

   on Sep 1, 2026 – with Claude

   CollaboratorAuthor

   More actions

   Claim — domain:ui execution seat, R19

   • Session: session_012wwHa4aaFybxXrfmfHioDM
   • Branch: claude/issue-7196-stale-held-key-census
   • Domain: ui · Worktree: dedicated, off origin/main (2d83cedc5 or later)
   • Clause ②: ⛔ not engaged. Nothing declared moves — this corrects a comment and a local type's documentation of an intersection that already matches. No behaviour change, no export change.
   • Serial constraints cleared: ObjectGrid.tsx was edited by three PRs today (test(plugin-grid): render what the inline lookup picker actually receives #7167, fix(plugin-grid): retire the three inert fieldMeta copies the cell never reads #7186 and fix(plugin-grid): feed the inline cell editor the row as dependent values, so a dependsOn lookup column is no longer permanently uneditable #7193, all landed or armed) and no lane currently holds it. ⚠️ The dispatch order tells this lane to re-derive on current main and expect line numbers to have moved.

   Dispatched immediately because it is small, unambiguous, and free of the tier — a rare combination in this queue today (1 of 7 candidates read across R18/R19 were dispatchable as filed; see #6853).

   ⚠️ The scope note from the body is carried into the order as a ruling, because it is the part most likely to be skipped: a hold list that is stale in one entry has no claim to be current in the others, so the whole census gets re-derived, not read. But ⛔ this card does not assert the other entries are wrong — only that nobody has checked.

   ---

   Generated by Claude Code
4. os-warren commented on Sep 1, 2026

   

   os-warren

   on Sep 1, 2026 – with Claude

   CollaboratorAuthor

   More actions

   os-dev-report

   {
     "issue": 7196,
     "status": "done",
     "branch": "claude/issue-7196-stale-held-key-census",
     "pr": "https://github.com/objectstack-ai/objectui/pull/7202",
     "premise_still_valid": true,
     "summary": "Re-derived SIXTEEN census claims across the two held-key censuses in ObjectGrid.tsx; SEVEN were defective — four stale (drifted after being written) and three wrong on the day they were written. The card named one; the re-derivation found the other six. Stale: (1) renderCellEditor undeclared + ruling 'pending' — the card's entry, declared by #6882 on 2026-08-30 on all three named surfaces, and the (schema as any) cast is gone with it; (2) cellClassName carried the SAME 'pending ruling' and was declared by the SAME ruling — the card did not claim this one; (3) 'leaves exactly TWO undeclared keys' — re-derived with the TypeScript checker against the still-exact 46 flat-literal and 8 group-literal keys, it now leaves ZERO; (4) the data-table.tsx consumer read set listed fourteen col.KEY reads including 'name', retired by #6963 on 2026-08-31, so it is thirteen. Wrong when written (each dated against the commit that wrote the prose, beccf1c6b / 2026-08-26): (5) the schema-level cellClassName was described as folded 'into every body cell's className' — it reaches exactly three UTILITY cells and never a data cell, which folds the per-column twin; the stated failure mode is wrong the same way, and the three sites were already utility-only at that commit; (6) 'the 7-literal union TableColumn declares' — eight since #6370 on 2026-08-25, a day earlier, whose own subject line says '8-literal'; (7) the downstream read list omitted className, cellClassName, sortable and cell, all read by passes that predate the list. NINE claims re-derived clean and are recorded as such, including every column-level verdict (headerIcon, pinned, wrap, options, essential, name) and the FieldType count of 49 — 'the others are correct' is a real result and it is now measured rather than assumed. A2.2 CONFIRMED and not inherited: each hold's shape is Equal (not merely extends) to the upstream declared member and the two are mutually assignable in both directions, so nothing mis-renders and no type is unsound; the only trace is the seam's renderCellEditor resolving to the identical signature intersected with itself, which is inert. A2.4 answered: RetiredListColumnKey IS mechanically derived and re-derives correctly, but the censuses are hand-maintained and guarded asymmetrically — the column-level hold's entry condition is pinned (columnHoldsExpiry-6424.test.ts asserts TableColumn does not declare pinned) while the schema-level one has only an ACCEPTANCE pin, which is green whether the keys are held here or declared upstream and so could never have gone red at the moment of loss. That asymmetry is why this census rotted and its twin did not. Documentation only: no runtime code, no exported type, no declared member moved; packages/types untouched, Clause 2 never approached. The holds type is KEPT with its docblock rewritten to say why it survives as a deliberate redundancy plus the three measurements a removal card would start from — deleting a member of an exported type is a different kind of change, the order #6615 to #6424 took for headerIcon.",
     "tests": "All on d20267a93 (branch head); `git diff HEAD` empty at that point, so the measured tree is byte-identical to the committed one. Dependency closure built FIRST: `pnpm --filter '@object-ui/plugin-grid^...' build` exit 0. `pnpm --filter @object-ui/plugin-grid type-check` exit 0, echoing `tsc --noEmit && tsc -p tsconfig.test.json` (note the hyphenated script name this repo uses). NOT-MEASURED trap closed: the package tsconfig excludes __tests__, so `tsc -p tsconfig.test.json --listFiles` was run — both edited files are program inputs, 1 hit each against a 0-hit control. `pnpm exec vitest run --maxWorkers=2 packages/plugin-grid/` (from the repo ROOT — the package-dir invocation is refused by a repo guard, which is a PREREQUISITE failure and not a red test) => 105 files, 952 tests, ALL PASSED. Census suite verbose: 7/7 including the renamed 'accepts both schema-level keys'. `pnpm --filter @object-ui/plugin-grid lint` => eslint exit 0, 0 errors, 749 pre-existing warnings. Gates, each quoting its own verdict line with the exit code captured BEFORE any pipe: check-control-bytes OK (5964 tracked text files), check-changeset-presence OK (empty frontmatter accepted as the explicit exemption), check-changeset-no-major OK, check-shell-escape-residue OK. Re-run on the final HEAD after committing. RE-DERIVATION INSTRUMENTS, each with a live control: the key-membership diff used the TypeScript checker (bogus key absent / `columns` present on the same instrument); the read-set census used an AST walk over whole files (col.pinned = 0 in data-table.tsx against col.accessorKey = 28 in the same command and path scope); the A2.2 Equal probe carried a must-fail control that was the ONLY diagnostic emitted. Probed for the PRESENCE of replacements, never the absence of removed tokens. DECLARED NARROWING: repo-wide `pnpm lint` not run; the affected package's own `eslint .` was, a strict superset of the diff, with all three pieces of evidence — population from eslint's own config resolution, file count 2 from `--format json`, and config invariance (no projectService, no parserOptions.project in eslint.config.js against a live control, so verdicts are per-file and a comment-only two-file diff cannot move an untouched file). NO ABLATION was run and none is owed: the diff adds and removes no assertion; the one assertion touched keeps its exact shape and only its name and docblock change.",
     "mcp_calls": "11 — REST was probed FIRST and returned 403 on a repo-scoped read (gh absent, the documented shape), so the dedupe went through ONE targeted MCP search_issues instead of REST + local grep. Channel switch declared. Both dedupe queries returned non-empty results, so each is self-validating and no separate control query was needed.",
     "open_questions": [],
     "out_of_scope_findings": [
       "filed as #7201: the schema-level held-key census has NO gate — its only pin (dataTableSchemaSlot-6459.test.ts) asserts that the seam ACCEPTS the two keys, which stays green whether they are held locally or declared upstream, so it is green on both sides of the event that expires a hold. The column-level twin IS guarded (columnHoldsExpiry-6424.test.ts pins that TableColumn does not declare pinned). Filed unassigned with both candidate shapes described and neither argued, per the order's report-only instruction; deliberately NOT built here.",
       "NOT filed, already open — #6919 ('ObjectGridDataTableSchemaHolds' docblock forbids the exact declaration the 2026-08-30 ruling authorised, and the seam hold itself is now redundant), unassigned, blocked-by #6918 which has since landed. Caught by the dedupe search, so no duplicate was created. FOR PM: this PR substantially satisfies both halves of its scope in the 'keep and state why' branch — the standing prohibition is gone and the deliberate redundancy is recorded with measurements. Its remaining open half is the hold's ACTUAL removal, which this card's order forbade (no export change). Whether #6919 stays open for that or is re-scoped is triage's call; this PR does not touch its state and carries no keyword acting on it, only 'Refs: #6919'.",
       "NOT filed, observation only — the 'wrong when written' pair (the every-body-cell description and the 7-literal count) both entered at beccf1c6b/#6461 and are of one shape: a number or a scope copied into prose rather than measured at the seam it describes. Both were checkable in under a minute by the instruments used here. If PM wants a class-level card rather than two instances, this is the material; not filed unprompted because it overlaps #7201's argument for mechanising the census."
     ]
   }

   ---

   Generated by Claude Code
5. os-warren

   closed this as completedin #7202on Sep 1, 2026
6. os-warren commented on Sep 1, 2026

   

   os-warren

   on Sep 1, 2026 – with Claude

   CollaboratorAuthor

   More actions

   ✅ LANDED — PR #7202 squash-merged to main (f08cbd996)

   Verified by content with a live control:

   probe	result
   SUBJECT — the corrected census prose now cites #6882	9 lines
   CONTROL — ObjectGridDataTableSchemaHolds still present	3

   ⭐ That control is the point, not a formality: the type was kept deliberately, with its docblock rewritten to explain why it survives as a redundancy. A probe that only checked "the stale sentence is gone" would pass equally if the whole type had been deleted — which was explicitly not the deliverable.

   ⭐ The ruling earned itself six times over

   I ruled "re-derive the WHOLE census, not just the named entry — a hold list stale in one entry has no claim to be current in the others."

   16 claims re-derived. SEVEN defective. The card named ONE.

   And they split two ways, which I did not anticipate:

   • 4 stale — true when written, drifted since. Including cellClassName carrying the SAME "pending ruling" prose, settled by the SAME [Decision] Declare renderCellEditor and schema-level cellClassName on DataTableSchema? — the two live undeclared keys the #6459 census measured #6882 ruling — a second instance of the card's own defect, sitting beside it, unmentioned.
   • 3 wrong when written — false on the day, dated to beccf1c6b. One claimed "the 7-literal union" when it had been eight since fix(types): make the 8-literal union the one canonical TableColumn.type #6370 landed a day earlier, in a PR whose own subject line says "8-literal".

   ⚠️ The second kind is the more alarming, and it was nowhere in the card. "Stale" implies a document once accurate — ordinary decay. These had no moment at which a reader could have trusted them, and no drift to detect.

   ⭐ And the root cause was diagnosed, not just the symptoms

   the censuses are guarded asymmetrically — the column-level hold's entry condition is pinned (columnHoldsExpiry-6424.test.ts asserts TableColumn does not declare pinned), while the schema-level one has only an ACCEPTANCE pin, which is green whether the keys are held here or declared upstream, and so could never have gone red at the moment of loss.

   ⇒ That is why this census rotted and its twin did not. The general lesson outlives the card: a pin that stays green on both sides of the event it exists to catch is not a guard. It looks like coverage, runs on every CI, and is structurally incapable of failing. Filed as #7201.

   The nine clean claims are a real result

   Every column-level verdict (headerIcon, pinned, wrap, options, essential, name) and the FieldType count of 49 re-derived correctly. ⭐ "The others are correct" is now measured rather than assumed — the epistemic state a future reader actually needs, and precisely what a fix confined to the named entry would have left undone.

   A2.2 was confirmed properly: each hold's shape is Equal (not merely extends) to the upstream member, and the two are mutually assignable in both directions. Checking both ways is what makes "identical" a measurement rather than a one-directional subtype check that would pass on a narrower hold.

   ⚠️ No ablation, and none owed — "the diff adds and removes no assertion; the one assertion touched keeps its exact shape and only its name and docblock change." Stating why an ablation would measure nothing beats running a ceremonial one.

   Downstream

   #6919 was found during dedupe, correctly not touched, and is now ruled: it stays open, re-scoped to the hold's actual removal, and pm:blocked on the CONTRACT_REVIEW_TIER quota (deleting a member from an exported type narrows published surface). This PR discharged its first half — the prohibition is lifted and the redundancy is recorded with measurements. ⛔ Closing it would have lost the only tracker for a removal deliberately not made. That card was also carrying no labels at all, which is why it had been invisible to every sweep.

   Clearing pm:dispatched.

   ---

   Generated by Claude Code
7. os-warren

   removed

   pm:dispatched

   on Sep 1, 2026