[measured out] async-settled surfaces read with a SYNCHRONOUS query — 21 sites triaged across 4 packages, ZERO defects; #6959 was the only one

[os-sam]

⛔ THE TABLE BELOW IS SUPERSEDED — DO NOT DISPATCH FROM IT

The census was re-derived on 2026-08-31 and this body's original numbers did not survive. The per-site lists, the 55 subtracted sites, and the instrument itself are published in a comment on this card — cut every slice from those, not from the table further down.

rung	body originally said	actual at 7a5da1414
tier 1	1,105	1,606
tier 3	176	475 (tier-2 witness rung retired)
tier 3 + settle	—	149
published population	173	94

⚠️ The per-package split of the published 94 — use ONLY this for slicing

package	in the 94		package	in the 94
app-shell	41		plugin-dashboard	3
components	14		plugin-form	3
plugin-detail	9		plugin-grid	3
plugin-list	7		plugin-charts	2
apps/console	7		plugin-chatbot	2
fields	3		plugin-kanban	0

Sums to 94, and 94 + 55 absence-only = 149 = tier 3 + settle.

⛔ Do not confuse these with the tier-3+settle counts, which are larger because the 55 absence-only sites have not yet come out of them: plugin-detail is 14 there but 9 here, plugin-list 12 there but 7 here, and plugin-kanban is 3 there but 0 here because all three of its candidates are absence-only. An earlier version of this banner quoted the tier-3+settle figures next to the published total — my error. A slice cut at 14 or 12 over-scopes by 5; a plugin-kanban slice finds nothing to triage.

Why the original numbers are void, and it is not a rounding matter: this body lists GanttView.autoscheduledlg.test.tsx:63 as a tier-3 hit, and tier 3 is cumulative on tier 2's "surface async-witnessed elsewhere in its own package". That site reads gantt-autoschedule-confirm, which occurs exactly twice in the whole repository — the production element at GanttView.tsx:5030 and the candidate read itself — and is never named by a findBy, a waitFor, or any async query anywhere. It cannot reach tier 2, therefore cannot be tier 3, yet this body published it as tier 3. The original numbers are not reproducible from their own definitions even in principle. The tier-2 witness rung is retired as a result.

The .each blind spot that prompted the re-run is real but small — about 1.6%. It was not what killed the numbers.

Measured at 7a5da1414 (main as of #6954). ⚠️ That is not current main, which is fd8dacecc, two merges ahead; the drift is exactly one added test file and four edited ones, which moves no conclusion. Effective corpus 2,260 after excluding 28 Playwright specs where the ladder does not apply (page.getByRole returns an auto-waiting Locator, not a synchronous DOM read).

The 55 absence-only sites are subtracted from the published count and retained in this card as a named sub-population — they cannot fail this card's way (an early read makes an absence assertion pass) but can pass vacuously. Their first step is a probe, not a fix: make the element appear late and see whether the test still passes. Their site list is published alongside the 94.

Everything below is kept for the record. The calibration and the trap sections remain valid and are still the most useful part of this card.

---

Filed by the domain:ui execution seat (PM session session_013hfmP9hoMd3dJwTh85J4yB), carrying forward the census #6959's implementer produced and deliberately did not file itself — several of the named packages had live PRs at measurement time, so it reported rather than widened. ⛔ Grading beyond the p2 carried from #6959 is triage's.

The class

#6959 was one instance: ObjectGantt.referenceArms-6837.test.tsx:257 read a surface that appears after an async settle using a synchronous getByTestId. In the merge queue — a heavier runner than PR CI — it lost that race twice in fifteen minutes and ejected two PRs that do not touch plugin-gantt at all, one of which passed and failed on byte-identical content.

⚠️ Read #6959's correction before working this card. That card's original text — mine — blamed a React.lazy boundary. There is none. ObjectGantt imports statically and the package contains zero React.lazy; the fallback is a plain if (loading) early return. The real race is a gate that settles a mock call being ISSUED one promise-resolution before setLoading(false) runs in a finally. ⇒ The class is wider than "lazy": it is any test whose awaited settle does not touch the DOM, followed by a synchronous DOM read.

The measurement ⛔ SUPERSEDED — see the banner

Pathspec bound, stated: git ls-files -- '*.test.tsx' '*.test.ts' '*.spec.tsx' '*.spec.ts' = 2,282 files.

tier	definition	hits
1	async block, first sync DOM read, no gate naming that surface	1,105
2	+ surface async-witnessed elsewhere in its own package	413
3	+ no DOM-touching gate at all before the read, resolving awaited file-local helpers one level	176

Tier 3 is the real shape — the awaited settle never touches the DOM.

⭐ The hot control fired, and the instrument was fixed rather than the corpus declared clean. Tier 1 initially did not report :257 itself, because it required a literal render( in the block while :257 mounts through a helper. A zero that would have read as "clean" was caught as "broken search."

What is already done, and what remains

packages/plugin-gantt's 3 tier-3 hits were hand-triaged: exactly one real defect (:257, fixed in PR #6966). The other two are false positives — ObjectGantt.quickfilter.test.tsx:141 is gated at :135 through the file-local gv() helper, and GanttView.autoscheduledlg.test.tsx:63 has a synchronous mount with nothing to race.

Remaining: 173 tier-3 candidates outside plugin-gantt. ⛔ SUPERSEDED — the current population is 94, and the per-package table below is void.

package	hits		package	hits
app-shell	58		plugin-detail	4
fields	28		plugin-calendar	3
apps/console	25		plugin-dashboard	3
components	16		react	3
plugin-form	11		e2e/live	3
plugin-grid	9		examples/schema-catalog	2
plugin-charts	5		plugin-list	2
			plugin-chatbot	1

⭐ Calibration — apply this before dispatching, it is the most useful thing here

From the implementer, who hand-triaged its own package's hits:

my plugin-gantt triage found 2 of 3 tier-3 hits were false positives, so assume roughly a 2-in-3 false-positive rate; the dominant false-positive causes are a real DOM gate hidden behind a one-token file-local helper, and a mount that is synchronous to begin with.

⇒ A candidate count is not a defect count. Expect the triage cost to dominate the fix cost. ⛔ Do not dispatch this as a mechanical sweep — a blind getBy → findBy rewrite would churn files that were never wrong, and would erase gates that are load-bearing (see below).

⛔ The trap that makes this not-mechanical

#6959's fix kept mount()'s find-call gate rather than trading it for the DOM gate — because the two gates measure different facts, and the refusal probe above it needed the schema-dependent commit that the chart's presence alone does not carry.

⇒ A rewrite that replaces an existing gate with a DOM gate can silently weaken a test while leaving it green. Whoever takes a slice must, per site, establish what the existing gate proves before adding or replacing one.

Suggested shape

Slice by package, largest first, one PR per package or per small group — ⛔ not one sweeping PR. Cut slices from the published-94 split in the banner, never from the void table above.

Per site, the deliverable is a judgement, not a rewrite: is the awaited settle DOM-touching? If not, is there another gate, possibly behind a helper? Only then change the read.

Related

• finding(test-infra): ObjectGantt.referenceArms-6837.test.tsx:257 reads the lazy Gantt through a SYNCHRONOUS query and ejects unrelated PRs from the merge queue — two ejections in 15 minutes, neither PR touching plugin-gantt #6959 — the instance, its correction, and the census method
• PR test(plugin-gantt): read the chart through an async query, not a race #6966 — the fix, including the delayed-resolution probe that reproduces the failure deterministically (and the honest negative at 25 ms that established the local window is sub-50 ms)

[os-sam]

Claim: PM loop — domain:ui execution seat, FIRST SLICE ONLY
Session: session_013hfmP9hoMd3dJwTh85J4yB
Branch: claude/issue-6967-fields-async-settled-reads
Worktree: objectui-issue-6967

⛔ Dispatched: packages/fields ONLY — 28 of the 173 candidates

⛔ The other 145 are NOT dispatched. Slicing by package is this card's stated shape, and I am taking the largest slice with no live PR on it. app-shell (58) and apps/console (25) are bigger but I have unlanded work adjacent to them right now (PR #6961 in app-shell/src/providers), and components (16) has PR #6963 live. Those slices wait.

⛔ This is a TRIAGE task, not a rewrite

The card's calibration is binding, and it is the whole reason this is not mechanical:

assume roughly a 2-in-3 false-positive rate; the dominant false-positive causes are a real DOM gate hidden behind a one-token file-local helper, and a mount that is synchronous to begin with.

⇒ Of 28 candidates, expect on the order of 9-10 real defects. ⛔ A blind getBy → findBy rewrite across all 28 would churn ~18 files that were never wrong.

Per site, the deliverable is a judgement before any edit:

1. Does the awaited settle actually touch the DOM? (If yes → false positive, the read is already gated.)
2. If not, is there another gate — possibly behind a file-local helper? Resolve helpers at least one level. This is the dominant false-positive cause and a grep will not see it.
3. Is the mount synchronous to begin with? (Then there is nothing to race.)

Only when all three say "no gate" is it a real defect.

⛔ The trap that can make a green test weaker

#6959's fix kept mount()'s find-call gate rather than trading it for the DOM gate — because the two gates prove different facts, and the assertion above it needed the schema-dependent commit that the element's presence alone does not carry.

⇒ Replacing an existing gate with a DOM gate can silently weaken a test while leaving it green. Per site, establish what the existing gate proves before adding or replacing one. ⛔ Add the async read; do not remove a gate unless you can say what it proved and why that is now redundant.

⛔ Not the remedy

• ⛔ Never skip, disable, or quarantine a test.
• ⛔ Never raise a global timeout. The bug is a synchronous read of an asynchronous surface.
• ⛔ Do not change production code. If a test can only be fixed by changing the component, stop and report — that is a different card.

Report, whatever you fix

• The per-site triage table: candidate → real / false-positive → the reason.
• ⭐ Your own false-positive rate for packages/fields, against the card's 2-in-3 calibration. If it diverges sharply, say so — the calibration came from a 3-hit sample in one package and a second data point is worth more than the fix.
• Any site you could not classify. "I could not tell" is an acceptable answer and better than a guess.

File surface: test files under packages/fields only. ⛔ OUT: every other package, packages/fields production source, packages/components/**, packages/app-shell/**, packages/data-objectstack/**, packages/plugin-detail/**.

Container & model: M, mode:subagent.

Clause-②: no — test-only, no published surface moves. ⚠️ If you find a site that cannot be fixed without touching production code, that changes the routing: stop and report.

Land: Refs #6967, ⛔ never Fixes — 145 candidates in other packages remain and this card must survive its own PR. Changeset: judge whether a test-only change owes one under check-changeset-presence.mjs's own verdict, and say which way you decided.

⛔ Worktree-first. ⛔ Never git stash. ⛔ vitest root-relative only — a package-dir launch silently runs apps/console's 22 files and reports a green that tested nothing. ⛔ Open as draft.

---

Generated by Claude Code

[claude]

os-dev-report

{
 "issue": 6967,
 "status": "done",
 "branch": "claude/issue-6967-fields-async-settled-reads",
 "pr": null,
 "premise_still_valid": false,
 "summary": "TRIAGE COMPLETE FOR packages/fields, AND THE ANSWER IS ZERO. I triaged every candidate the slice produces and found NO real defects — 0 of them, against the card's calibrated expectation of 9-10. No test file needed changing, so there is NO PR and the branch carries ZERO commits (pushed empty as the write-routing probe; base 8f1d995ef). WHICH HALF OF THE PREMISE DIED: the class itself is real and I reproduced it inside packages/fields (see the POWER-RED probe leg in `tests`) — what does not carry is the 2-in-3 CALIBRATION. In this package the candidates are not one-third real, they are zero-third real. The three causes, in order of population: (1) SYNCHRONOUS MOUNT, 34 of 42 per-read sites — overwhelmingly `screen.getByRole('button', { name: /Select/i })` read immediately after a synchronous `render()`, where LookupField's trigger Button (LookupField.tsx:1090-1131, testid at :1099) is rendered UNCONDITIONALLY; `loading` never hides it, it only swaps the label text and adds a spinner. complex-widgets.test.tsx alone contributes 19 such sites. (2) A REAL DOM GATE BEHIND A ONE-TOKEN FILE-LOCAL HELPER, the card's stated dominant cause, 23 further sites that the card's tier-3 wording would still list: `formRow()` = waitFor(document.querySelector('[data-field=f]')) in slider-signature-host-channels-e2e.test.tsx (18 sites), `readonlyProse()` = waitFor(item(type).querySelector('div.prose')) (3), and `personRowNames()` / `optionLabels()` = waitFor over queryAllByTestId('person-row') / queryAllByRole('option') in LookupField.recentsFilters.test.tsx. (3) THE READ SURFACE DOES NOT DEPEND ON THE PENDING SETTLE — this is a THIRD false-positive cause the card does not name, and it covers the sites that look MOST like #6959. Both LookupField.dependsOn.test.tsx:197 and RecipientPickerField.test.tsx:82 gate on a MOCK CALL (waitFor(expect(ds.find).toHaveBeenCalled())) and then read the DOM synchronously — the exact #6959 gate shape — yet both are false positives, because the surface they read is PROP-DERIVED, not fetch-derived: the picker's Filters button hangs off `effectiveFilterColumns` (RecordPickerDialog.tsx:556) which resolves from the `filterColumns`/`lookupFilters` props (`fieldsMeta` is a prop too), and RecipientPickerField renders its Combobox from props with `records === null` only swapping placeholder text. I did not settle those two by reading alone — I measured them (probe legs A and B). ImageField.maxSize.test.tsx:106 is the same cause INVERTED and worth stating separately: its gate waitFor(onChange called) is strictly DOWNSTREAM of the read surface, because `setErrors(rejections)` runs synchronously at ImageField.tsx:171 before the handler's first `await`, while `onChange` only fires after `await Promise.all(upload)` at :185/:187. #6959 was upstream-gated; this is downstream-gated, and downstream can never race. NOTHING WAS EDITED: no test changed, no gate removed or replaced, no test skipped or quarantined, no timeout raised, no production code touched. The working tree is clean (git status --porcelain empty).",
 "tests": "NO code change, so nothing to re-verify on a new head; every reading below is on base 8f1d995ef with a clean tree. ALL RUNS THROUGH THE SHARED VERIFY LOCK (objectui has no scripts/pm/, so I used the container lock at /home/user/objectstack/scripts/pm/os-verify-lock.sh) with OS_VERIFY_LOCK_SLOT=issue-6967-fields set BEFORE the first attempt; exit codes captured by redirecting to a file FIRST, never after a pipe. (1) BASELINE, root-relative vitest as required (the package-dir form is guard-blocked here anyway): `pnpm exec vitest run --maxWorkers=2` over the six candidate files -> 'Test Files 6 passed (6) / Tests 80 passed (80)', lock's own line 'VERDICT command-exit 0'. (2) THE MEASUREMENT THAT MATTERS — a DELAYED-RESOLUTION PROBE carrying its own POWER CONTROL, mutating only the TIMING FACT (find() resolves 500ms late), never any assertion. A throwaway packages/fields/src/__probe6967__.test.tsx held four legs. POWER-RED (mock gate, then a synchronous read of a genuinely FETCH-DERIVED row) FAILED exactly as required, with the #6959 signature verbatim: 'TestingLibraryElementError: Unable to find an element with the text: Nora Field'. That failure is what makes the greens below falsifiable — without it a green leg would only prove the probe cannot fail. POWER-GREEN (same surface, DOM-gated with findByText) passed, resolving through the delay. LEG A (LookupField.dependsOn:197 shape) PASSED under the 500ms-late fetch; LEG B (RecipientPickerField:82 shape) PASSED. Final tally 'Tests 1 failed | 3 passed (4)', captured EXIT=1 — the 1 failure IS the power control and is the intended result. The probe file was then deleted and `git status --porcelain` is empty, so nothing from it survives. (3) CENSUS INSTRUMENT, with hot controls, because a zero that reads as 'clean' is exactly what this card family warns about. I could not obtain the original census script, so I RECONSTRUCTED it and validated the reconstruction against the one place ground truth exists: packages/plugin-gantt, where PR #6966 has NOT yet landed on main (:257 still reads synchronously), so the known answer is live. My instrument reports :257 itself — the hot control the card demands — AND its sibling reads :258-:261, which is precisely the block #6959's fix repaired. It independently clears both false positives the card names (quickfilter:141 via gv(), autoscheduledlg via the synchronous mount). SECOND HOT CONTROL, specific to THIS package rather than borrowed from gantt: I copied LookupField.recentsFilters.test.tsx to a scratchpad file and swapped its DOM gate for a mock gate; mutation proven ON DISK by grep counts (personRowNames gate 2 -> 1, injected ds.find gate 0 -> 1, anchor asserted to match exactly once), and the instrument went 1 -> 2, newly reporting the synthetic site. The repo itself was never mutated for this. (4) INSTRUMENT BUGS I FOUND AND FIXED RATHER THAN REPORTING THEIR OUTPUT — each one had made the corpus look dirtier or cleaner than it is: reads inside a waitFor callback are RETRIED, not one-shot, so they are the gate and must never count as a racing read; a read inside `await act(async () => ...)` is that call's ARGUMENT, so the act gates nothing for it and the correct anchor is the enclosing statement, not the read; and a helper that RETURNS waitFor(...) instead of awaiting it is still a real DOM gate — that one bug alone had 21 genuinely-gated sites reading as candidates. (5) A BLIND SPOT I CAUGHT BEFORE REPORTING THE ZERO, flagged in open_questions because it may affect the other 145: my first block matcher silently parsed ZERO `it.each` / `test.each` blocks, of which packages/fields has 109 occurrences. After fixing it the parser sees 168 async blocks in the package, 12 of them `.each` — and the verdict was unchanged at 8 settle-then-read candidates, so the zero survives with the blind spot closed. (6) CHANGESET, judged from the script's OWN verdict line as asked: `node scripts/check-changeset-presence.mjs` -> captured EXIT=0, 'No source of a released package changed in this range, so no changeset is owed.' I decided NONE is owed, and the reason is the trivial one — my diff is empty. Recording the non-trivial half for whoever takes a slice that DOES edit tests: the script has NO carve-out for test files under src/ (its header says so at lines 158-161), so a test-only change here DOES owe a changeset, satisfied by the empty-frontmatter form.",
 "mcp_calls": "0 — no MCP GitHub calls this run. Card/comment reads went through REST (the repo-scoped probe returned 200 on this seat), this report was posted through the additive REST endpoint POST /issues/6967/comments, and all code reading was local git.",
 "open_questions": [
 {
 "question": "Does the ORIGINAL census parse `it.each` / `test.each` blocks? Mine silently parsed zero of them until I fixed it, and packages/fields alone has 109 such occurrences. If the original shares the blind spot, the 173 tier-3 figure is an UNDERCOUNT and the per-package concentrations are skewed toward whichever packages happen to favour plain `it(`.",
 "options": [
 "A — Re-run the original census with `.each` parsing and re-publish the per-package table before dispatching the remaining 145.",
 "B — Leave the count as filed and let each slice's dev close the gap locally, as I did here.",
 "C — Treat it as immaterial on the grounds that `.each` blocks are usually synchronous."
 ],
 "recommendation": "A. It is cheap, it is a one-line class of fix, and the failure mode is the same one this card family already got burned by — a search that reports a clean zero because it never looked. C is the tempting answer and is unsafe: in this package 12 of the parsed async blocks WERE `.each`, so they are not reliably synchronous; they merely happened to be false positives here. B leaves every future slice re-deriving the same fix and silently disagreeing about the denominator, which is exactly what makes the false-positive rates non-comparable across slices."
 },
 {
 "question": "The card's tier-3 wording resolves 'awaited file-local helpers one level', but three mechanical artifacts inflate the candidate list well beyond what that clears: reads inside a waitFor callback, reads inside an `await act(...)` callback, and helpers that RETURN waitFor(...) rather than await it. Should the remaining 145 be re-filtered before dispatch?",
 "options": [
 "A — Re-filter centrally and dispatch the reduced list, stating the new count.",
 "B — Dispatch the raw tier-3 list and let each dev clear the artifacts by hand, as I did."
 ],
 "recommendation": "A for the third artifact specifically (helpers that return a gate), because it is purely mechanical and it alone accounted for 21 of my sites; B is defensible for the other two, since judging whether a surface depends on the pending settle is irreducibly manual. Stating the artifact list in the dispatch would let each dev clear them consistently instead of re-discovering them."
 }
 ],
 "out_of_scope_findings": [
 "NOT FILED, deliberately, and I want the reason on the record rather than a speculative card: several triaged sites assert ABSENCE after a non-DOM settle (ImageField.maxSize.test.tsx:83 and :93 with queryByText(...).toBeNull(), UserFieldPicker.test.tsx:61, readonly-richtext-display-5498.test.tsx:218-220). These are structurally incapable of the #6967 failure — this class fails by an element being MISSING, which toBeNull() cannot detect — but they are capable of passing VACUOUSLY, which is the adjacent #6640 'green that tested nothing' shape. I did NOT file a card because I have no evidence any specific one is actually vacuous: each sits beside a positive control in the same block (ImageField:83 asserts upload was called exactly once; UserFieldPicker:61 is followed by a real waitFor on people-picker-search). Filing on 'this shape could in principle be weak', with no measurement showing one IS weak, is the speculative-capability trap, so I am reporting it as an observation for triage rather than manufacturing a card."
 ]
}```

---

## Per-site triage table — `packages/fields`, 42 per-read sites, **0 real / 42 false-positive**

**A. A non-DOM settle really did precede the read** (the #6967 shape proper) — 8 sites

| site | verdict | reason |
|---|---|---|
| `complex-widgets.test.tsx:205` | false positive | Gate is `waitFor(find called)`. But the popover's search `Input` (LookupField.tsx:1225) renders **unconditionally** inside `PopoverContent`; `loading` only adds an adjacent `lookup-loading` spinner. The popover's open-state was already flushed by the preceding `act`. |
| `ImageField.maxSize.test.tsx:83` | false positive | `queryByText(...).toBeNull()` — an **absence** assertion. This class fails by an element being *missing*; `toBeNull()` cannot fail that way. |
| `ImageField.maxSize.test.tsx:93` | false positive | Same absence-assertion shape. |
| `ImageField.maxSize.test.tsx:106` | false positive | Gate `waitFor(onChange called)` is strictly **downstream** of the read surface: `setErrors(rejections)` runs synchronously at ImageField.tsx:171 *before* the handler's first `await`, while `onChange` fires only after `await Promise.all(upload)` at :185/:187. #6959 was upstream-gated; downstream can never race. |
| `LookupField.dependsOn.test.tsx:197` | false positive | **Measured** (probe LEG A, passed under a 500ms-late fetch). Exact #6959 gate shape, but the Filters button hangs off `effectiveFilterColumns` (RecordPickerDialog.tsx:556) ← `baseFilterColumns` ← the `filterColumns`/`lookupFilters` **props**; `fieldsMeta` is a prop too. Nothing about it depends on the fetch. |
| `LookupField.recentsFilters.test.tsx:249` | false positive | Read follows a synchronous `rerender`; LookupField's trigger Button is unconditional. The pending settle (an `act` that clicked a row) does not produce this surface. |
| `RecipientPickerField.test.tsx:82` | false positive | **Measured** (probe LEG B, passed under a 500ms-late fetch). `Combobox` renders from props (RecipientPickerField.tsx:167); `records === null` only swaps placeholder/empty text. The genuinely fetched options *are* correctly gated by `await screen.findByText('Ada Auditor')` on the next line. |
| `RecordPickerDialog.filterOptions.test.tsx:573` | false positive | `panel` was obtained through a real DOM gate (`openFilterPanel()`); the checkbox is rendered from the `filterColumns` prop. The pending settle concerns the outgoing query, not this element. |

**B. Synchronous mount — nothing to race** — 34 sites

| site(s) | verdict | reason |
|---|---|---|
| `complex-widgets.test.tsx` :105 :127 :142 :172 :186 :232 :270 :295 :312 :336 :365 :383 :396 :422 :455 :478 :546 :591 :630 (**19**) | false positive | `getByRole('button', { name: /Select/i })` immediately after a synchronous `render()`. LookupField's trigger Button (LookupField.tsx:1090-1131, testid :1099) is unconditional — `loading` only swaps its label. |
| `LookupField.dependsOn.test.tsx:105` :143 | false positive | Same trigger button. |
| `LookupField.recentsFilters.test.tsx:202` :228 | false positive | Same trigger button. |
| `readonly-richtext-display-5498.test.tsx:218` :219 :220 | false positive | Synchronous `renderForm`; the `async` on the callback is vestigial (no `await` anywhere). Absence assertions besides. |
| `UserFieldPicker.test.tsx:61` :64 | false positive | `browse-all-records` absence + `lookup-trigger`, both first-paint. |
| `GridField.test.tsx:522` | false positive | `input[type=file]` on a row rendered from the `value` prop. |
| `ImageField.maxSize.test.tsx:113` :126 | false positive | `image-field-crop-0` (ImageField.tsx:233) renders from the `value` prop. The genuinely lazy crop dialog **is** gated with `findByTestId`. |
| `composite-group-label-readonly-e2e.test.tsx:466` :470 | false positive | Synchronous `renderForm`; submit button from `showSubmit: true`. (Found only after fixing the `.each` blind spot.) |
| `richtext-host-plumbing-e2e.test.tsx:218` | false positive | Synchronous `renderForm`; the async assertion below it is properly `waitFor`-gated. (Also `.each`.) |

**C. Cleared mechanically — a real DOM gate behind a one-token helper.** The card's *dominant* stated cause. These 23 would still be listed by tier-3's wording, because the gate is `return`ed rather than `await`ed inside the helper:

| site(s) | verdict | reason |
|---|---|---|
| `slider-signature-host-channels-e2e.test.tsx` (**18**) | false positive | `formRow()` = `waitFor(document.querySelector('[data-field=f]'))`. |
| `readonly-richtext-display-5498.test.tsx:169` :170 :171 | false positive | `readonlyProse()` = `waitFor(item(type).querySelector('div.prose'))`. |
| `LookupField.recentsFilters.test.tsx:299` :322 | false positive | `personRowNames()` = `waitFor` over `queryAllByTestId('person-row')`; at :322 the gate names the very surface read (`Alpha Widget`). |

### False-positive rate vs the card's calibration

| | card's calibration | measured here |
|---|---|---|
| false-positive rate | ~67% (2-in-3) | **100%** (42/42) |
| real defects expected in `fields` | 9-10 of 28 | **0** |

⭐ **This diverges sharply, and the divergence is the deliverable.** The calibration came from a 3-hit sample in one package; `packages/fields` is a second data point and it does not support extrapolating ~50-60 real defects across the remaining 145. The *class* is real — I reproduced it inside this package (POWER-RED) — but this package's candidate population is entirely explained by a synchronous trigger button, helper-hidden gates, and read surfaces that do not depend on the pending settle.

### Sites I could not classify

**None** — but two verdicts rest on reading production source plus structure rather than on an empirical probe: `RecordPickerDialog.filterOptions.test.tsx:573` and `LookupField.recentsFilters.test.tsx:249`. Both are clear, and neither has the #6959 upstream-gate shape; I am flagging them so the confidence basis is visible rather than uniform.

_Generated by [Claude Code](https://claude.ai/code)_


---
_Generated by [Claude Code](https://claude.ai/code)_

[os-sam]

PM: the packages/fields slice returned ZERO. Correcting this card, and ⛔ freezing further slices until the census is re-derived.

domain:ui execution seat, PM session session_013hfmP9hoMd3dJwTh85J4yB.

⚠️ My 2-in-3 calibration does not carry — I wrote it from an n=3 sample

packages/fields: 0 real defects of 8 candidates, against the 9-10 this card told the dev to expect.

⭐ The class is real and the dev proved it rather than just reporting a zero. A delayed-resolution probe carried its own POWER-RED leg — a mock-gated, genuinely fetch-derived read — which failed with the #6959 signature verbatim under the same 500 ms latency. That failure is what makes the greens falsifiable; without it "zero" and "broken instrument" are the same reading.

⇒ Correct the card's calibration: it came from a 3-hit hand triage in one package, and one further package measured 0/8. The rate is not estimable from two samples. Report per-slice rates; do not carry a number forward.

⭐ A THIRD false-positive cause this card does not name — and it covers the sites that look MOST like #6959

The read surface does not depend on the pending settle. LookupField.dependsOn.test.tsx:197 and RecipientPickerField.test.tsx:82 are both "await a mock call, then read the DOM synchronously" — structurally identical to :257 — yet both are false positives because the surface is prop-derived, not fetch-derived (effectiveFilterColumns resolves from props at RecordPickerDialog.tsx:556; RecipientPickerField renders its Combobox from props, with records === null only swapping placeholder text). The dev measured both rather than reading them.

⭐ And its inversion, which is the sharpest distinction produced so far: ImageField.maxSize.test.tsx:106 gates on waitFor(onChange called) — which is strictly DOWNSTREAM of the read surface, because setErrors(rejections) runs synchronously at ImageField.tsx:171 before the handler's first await, while onChange fires only after await Promise.all(upload) at :185/:187.

#6959 was upstream-gated. Downstream can never race.

Both go into the triage guidance for every remaining slice.

Population breakdown from the slice, worth carrying

Of 42 per-read sites: 34 synchronous mounts (overwhelmingly getByRole('button', {name: /Select/i}) after a synchronous render(), where LookupField's trigger Button is rendered unconditionally — loading only swaps the label and adds a spinner), and 23 further sites with a real DOM gate behind a one-token file-local helper that tier-3's wording still lists because the gate is RETURNED rather than AWAITED inside the helper (formRow() 18, readonlyProse() 3, personRowNames()/optionLabels() 2).

⛔ Two rulings — both mine, both now binding on this card

Q1 = A. DISPATCH FROZEN until the original census is re-run with .each parsing.

The dev's first block matcher silently parsed zero it.each / test.each blocks, and packages/fields alone has 109 occurrences. After the fix it saw 168 async blocks, 12 of them .each — and the verdict held, so the zero survived with the blind spot closed. ⚠️ If the original census shares that blind spot, the 173 is an undercount and the per-package table is skewed toward whichever packages happen to favour plain it(. That is the exact failure this card family has already been burned by: a search reporting a clean zero because it never looked.

⛔ No further slice is dispatched until the census is re-derived. Dispatched as a measurement-only task below.

Q2 = A, for the third artifact only. Centrally pre-filter "helper RETURNS waitFor(...)" — purely mechanical, and it alone inflated the dev's candidate list by 21 genuinely-gated sites. The other two artifacts (reads inside a waitFor callback, which are retried and therefore ARE the gate; reads inside await act(async () => …), which are that call's argument so the act gates nothing for them) stay manual, but the artifact list must be stated in every future slice dispatch so each dev clears them consistently instead of rediscovering them.

Method notes worth keeping

• The instrument was validated against live ground truth, not asserted: reconstructed and run against packages/plugin-gantt while PR test(plugin-gantt): read the chart through an async query, not a race #6966 had not yet landed on main, so :257 was still synchronous. It reports :257 and its siblings :258-:261 — exactly the block finding(test-infra): ObjectGantt.referenceArms-6837.test.tsx:257 reads the lazy Gantt through a SYNCHRONOUS query and ejects unrelated PRs from the merge queue — two ejections in 15 minutes, neither PR touching plugin-gantt #6959 repaired — while independently clearing both false positives this card names.
• A second hot control specific to the package: a scratchpad copy with its DOM gate swapped for a mock gate, mutation proven on disk by grep counts, and the instrument went 1 → 2, newly reporting the synthetic site. The repo was never mutated.
• A restraint worth naming: the dev found several sites asserting absence after a non-DOM settle and deliberately did not file them — structurally incapable of this card's failure (which manifests as an element being missing, which toBeNull() cannot detect) but capable of passing vacuously, the adjacent finding(test-infra): the ECONNREFUSED 127.0.0.1:3000 class is closed four times over yet still prints in 12 of 16 GREEN full-suite shards — and it reads as a red gate whenever a run is cut short #6640 shape. It declined because "filing on 'this shape could in principle be weak', with no measurement showing one is, is the speculative-capability trap." Each sits beside a positive control in the same block.

---

Generated by Claude Code

[claude]

Re-derived census — the card's 173 does not stand, and ⚠️ .each is not the main reason it doesn't

Measurement-only run, per the Q1=A ruling. ⛔ Nothing was edited. No test, no source, no gate, no skip, no timeout, no production code. git status --porcelain is empty in all three worktrees (objectui-issue-6967-census, objectui-issue-6967-control, and the shared checkout). No branch, no PR — the instrument is a scratchpad script and is deliberately not committed, same as its predecessor.

• Census tree: 7a5da1414 (current main), 2,288 matched files.
• Control tree: 8f1d995ef — main immediately before c0c436db8 (PR test(plugin-gantt): read the chart through an async query, not a race #6966), so :257 is still live there, exactly as the fields-slice dev used it.

---

1. Did the original instrument parse .each? ⛔ Unrecoverable — and I can prove something sharper

How I established it. The original census script does not exist anywhere:

• Its author said so in the finding(test-infra): ObjectGantt.referenceArms-6837.test.tsx:257 reads the lazy Gantt through a SYNCHRONOUS query and ejects unrelated PRs from the merge queue — two ejections in 15 minutes, neither PR touching plugin-gantt #6959 report: "The instrument is reproducible from the tier definitions above; it is a scratchpad script and was deliberately not committed."
• I verified rather than took it: git log --all --diff-filter=A over *census*, *tier3*, *tier-3* across every ref returns only unrelated pre-existing test files, and PR test(plugin-gantt): read the chart through an async query, not a race #6966 changed exactly two files (.changeset/6959-gantt-lazy-read-flake.md and the gantt test).

⇒ Every number below is against a RECONSTRUCTION, not against the original. I cannot inspect what the original did with .each, and I will not assert it.

⭐ But the card's tier ladder provably is not the ladder that produced 1,105 / 413 / 176

This is a harder result than the .each question and it lands first, because it invalidates the published numbers on its own.

The card lists GanttView.autoscheduledlg.test.tsx:63 as one of plugin-gantt's three tier-3 hits. Tier 2 is worded "+ surface async-witnessed elsewhere in its own package", and tier 3 is cumulative on it. That site reads [data-testid="gantt-autoschedule-confirm"], and here is every occurrence of that testid in the entire repository:

packages/plugin-gantt/src/GanttView.tsx:5030: data-testid="gantt-autoschedule-confirm"
packages/plugin-gantt/src/GanttView.autoscheduledlg.test.tsx:63: ... baseElement.querySelector('[data-testid="gantt-autoschedule-confirm"]') ...

Two occurrences. One is the production element; the other is the candidate read itself. It is never named by a findBy, a waitFor, or any async query — not in plugin-gantt, not anywhere. ⇒ Under the card's own tier-2 wording that site cannot reach tier 2, therefore cannot be tier 3. Yet it is published as tier 3.

So the tier definitions on the card are not a faithful description of the instrument that produced its counts. Reproducing 176/173 from the published wording is not merely hard, it is impossible. That is the load-bearing reason the census had to be re-derived rather than patched.

What can be said about .each, measured rather than asserted

Since the original is gone, I measured the size of the blind spot itself on the same corpus, with one flag flipped and nothing else changed — see section 5. It is real but small: 8 tier-3 candidates, 2 after the settle refinement. So even on the worst assumption (the original was fully .each-blind), .each alone makes 173 an undercount of order 1.6%, not the large skew the card feared.

Two corroborating (not conclusive) data points that the original probably was blind: the fields-slice instrument, written independently from the same published tier definitions, had exactly this blind spot; and my own first block matcher did too, until the positive control in section 2 forced it out.

⇒ The .each fear was worth freezing dispatch over — the answer just turned out to be "yes it was a hole, no it was not the big one." The big one is section 3 and section 6.

---

2. ⭐ Hot controls — these come before any number

HC-1 — :257 and its siblings on the pre-merge tree (the required control)

Run against 8f1d995ef, where PR #6966 has not landed and the ground truth is live:

# ROOT /home/user/objectui-issue-6967-control (8f1d995ef) --only=plugin-gantt
TIER1 56 TIER3 6 TIER3_SETTLE 1
 T3+settle -> ObjectGantt.referenceArms-6837.test.tsx:257 siblings=257,258,259,260,261

:257 is reported, and so are :258, :259, :260, :261 — precisely the block PR #6966 repaired. In plugin-gantt the instrument leaves exactly one candidate standing, which is exactly what the hand triage found.

HC-1b — the negative half, on current main

# ROOT /home/user/objectui-issue-6967-census (7a5da1414) --only=plugin-gantt
TIER3_SETTLE 0

Post-#6966 the site is gone. The instrument responds to the fix rather than reporting a constant. Without this leg, HC-1 only proves the instrument reports something.

HC-2 — a .each positive control, with a discriminating negative

⛔ The repo was never mutated. I copied ObjectGantt.referenceArms-6837.test.tsx into the scratchpad and rewrote the :253 block header — body verbatim, so the genuine :257 defect shape is preserved — as an it.each array-table block, then appended a template-table positive and a DOM-gated negative.

Mutation proven on disk, not by an editor's exit code:

anchor occurrences BEFORE: 1 (unique, so the edit cannot be a no-op)
removed-anchor count (must be 0): 0
injected it.each count (must be 4): 4
bytes before/after: 14190 / 15104

Result, one flag apart:

each=on TIER3_SETTLE 3 -> line 257 (each), line 291 (each), line 299 (each)
each=off TIER3_SETTLE 0

• The array-table and template-table positives both fire.
• The it.each block whose read is gated by await view.findByTestId('gantt-view') is not reported — the parser discriminates, it does not simply report every .each block.
• each=off returns zero on the identical file. That is the blind spot reproduced end to end.

Both known false positives are cleared, mechanically

site	card's verdict	my instrument
ObjectGantt.quickfilter.test.tsx:141	false positive, gated at :135 through gv()	cleared at tier 1 — file-local helpers are resolved inside gate expressions, so waitFor(expect(gv(container)).toBeTruthy()) reads as the DOM gate it is
GanttView.autoscheduledlg.test.tsx:63	false positive, synchronous mount	cleared by the settle requirement — nothing is awaited anywhere before the read's anchor statement, so there is no pending settle to race

⭐ Cross-validation against the fields slice, which I did not coordinate with

My instrument is independent of the one that produced the fields triage, and it agrees with it on four separate facts:

1. packages/fields has exactly 109 it.each occurrences — the dev's figure, to the unit.
2. My parser sees 160 async blocks in fields, 12 of them .each; the dev reported 168 async, 12 of them .each. The .each count matches exactly; the async-block totals differ by 4.8%, which is the expected spread between two independently written block matchers.
3. The .each-only candidates my instrument finds in fields are composite-group-label-readonly-e2e.test.tsx:466 (siblings 466, 470, 479) and richtext-host-plumbing-e2e.test.tsx:218. Those are exactly the sites the dev's table annotates "Found only after fixing the .each blind spot" and "Also .each" — including the :466/:470 pair.
4. All five of my fields tier-3+settle candidates fall inside the dev's hand-triaged group A: ImageField.maxSize:83, :93, :106, LookupField.dependsOn:197, RecipientPickerField:82 — the last two being the ones the dev did not settle by reading but measured with probe legs A and B.

---

3. ⚠️ Two instrument bugs found and fixed rather than reporting their output

Both had made the corpus look cleaner than it is, which is this card family's signature failure.

(a) The masker was silently eating live code. My comment/string/template masker mishandled ${...} interpolation and blanked everything downstream of certain template literals. Effect, measured: in packages/fields only 84 of 109 it.each occurrences were visible to the parser. Fixing .each parsing while the masker hid a quarter of the .each blocks would have produced a "we now parse .each" claim with a quarter of the corpus still dark. After the rewrite, repo-wide: 613 of 627 it.each occurrences visible, and I checked every one of the 14 still hidden — all 14 are genuinely inside comments (they are prose mentions such as "it.each([]) reports nothing"), so the masker is now correct rather than merely quieter.

(b) e2e/live was 30 structurally impossible candidates. Those files are Playwright, where page.getByRole(...) returns an auto-waiting Locator, not a synchronous DOM read. The entire tier ladder is inapplicable there. I excluded the 28 spec files importing @playwright/test rather than shipping the number. This matters for the card's table too: it lists e2e/live = 3, so the original was already partly filtering this and the two instruments were not measuring the same population there.

---

4. The corrected census

Definitions, stated, because the card's are not reproducible (section 1):

• T1 — an async test block (it, test, and it.each/test.each in both array-table and template-table forms) containing a synchronous DOM read that is not itself inside a waitFor callback, with no gate before it naming that surface.
• T3 — T1 and no DOM-touching gate at all before the read. Gates are resolved through file-local helpers one level in both directions: a helper called inside a waitFor callback (gv()), and a helper that is awaited (await mount()).
• T3+settle — T3 and an await actually precedes the read's anchor statement. Reads inside await act(async () = are that call's argument, so the anchor is the enclosing statement, not the read.

The witness rung (tier 2's "async-witnessed elsewhere in its own package") is reported but not carried into T3, because section 1 shows it excludes a site the card itself publishes as tier 3.

tier	current main (7a5da1414)
T1	1,606
T2, witness rung applied	751
T3, witness rung applied	231
T3, witness rung dropped	475
T3 + settle	149
T3 + settle, minus absence-only assertions	94

⇒ The replacement for "173 tier-3 candidates across 15 packages" is 475 candidates across 20 buckets under the card's tier-3 shape, narrowing to 149 once a settle is actually required to precede the read. ⛔ The 149 is the number I recommend the card carry; see section 9.

Corrected per-package table

package	card said	T3 (witness rung)	T3	T3+settle	Q2 removed	after dropping absence-only
app-shell	58	74	150	62	0	41
components	16	63	121	19	0	14
plugin-detail	4	11	23	14	0	9
plugin-list	2	10	22	12	0	7
plugin-form	11	8	10	10	20	3
apps/console	25	0	32	8	0	7
fields	28	29	36	5	14	3
plugin-dashboard	3	5	12	5	0	3
plugin-grid	9	8	10	4	0	3
plugin-chatbot	1	7	8	4	0	2
plugin-charts	5	4	20	3	0	2
plugin-kanban	0	3	3	3	0	0
plugin-view	0	0	6	0	0	0
plugin-calendar	3	3	5	0	0	0
plugin-gantt	0	0	5	0	0	0
auth	0	3	3	0	1	0
react	3	2	3	0	0	0
examples/schema-catalog	2	0	2	0	0	0
permissions	0	0	2	0	0	0
plugin-designer	0	1	2	0	0	0
e2e/live	3	—	—	—	—	— (Playwright, out of scope)
TOTAL	173	231	475	149	35	94

⚠️ The concentrations moved, and not by a little. app-shell stays the largest slice under every definition. But apps/console drops from second-tier (25) to 8; fields drops from 28 to 5, which is consistent with that slice's measured zero; plugin-detail and plugin-list rise from 4 and 2 to 14 and 12; plugin-kanban appears at 3 where the card had it absent entirely. ⛔ Any dispatch order derived from the card's table is wrong in both directions.

---

5. The .each delta — the skew, per package

Same tree, same instrument, one flag: each=on versus each=off. Everything else held.

	each-blind	each-aware	delta
T1	1,578	1,606	+28
T3	467	475	+8
T3+settle	147	149	+2

Per package, at T3: components +3, fields +2, app-shell +1, plugin-dashboard +1, examples/schema-catalog +1.

The eight candidates an each-blind parser cannot see:

examples/schema-catalog/test/toast-demo-dispatch-6250.test.tsx:150
packages/app-shell/src/views/__tests__/DeclaredActionsBar.test.tsx:327
packages/components/src/renderers/action/__tests__/action-record-predicate-root.test.tsx:307
packages/components/src/renderers/action/__tests__/action-record-predicate-root.test.tsx:318
packages/components/src/renderers/form/__tests__/form-required-when-server-owned.test.tsx:110
packages/fields/src/__tests__/composite-group-label-readonly-e2e.test.tsx:466
packages/fields/src/__tests__/richtext-host-plumbing-e2e.test.tsx:218
packages/plugin-dashboard/src/__tests__/DashboardRenderer.headerActions.test.tsx:59

Two survive the settle requirement, both in components (action-record-predicate-root.test.tsx:307 and :318).

⭐ Why the blind spot is small even though packages/fields alone has 109 it.each occurrences: repo-wide there are 611 .each blocks, but only 101 are async, and only 32 of those contain a synchronous DOM read at all. .each is overwhelmingly used here for table-driven schema, parser and vocabulary assertions that never mount anything. ⛔ That is a measured explanation, not the ".each blocks are usually synchronous" hand-wave — which was option C in the original question and would still have been the wrong reasoning even though it lands near the right number.

---

6. ⛔ Q2 = A applied — the "helper RETURNS waitFor(...)" pre-filter, before and after

Centrally pre-filtered as ruled. A file-local helper written const formRow = (f) = waitFor(...) returns a real DOM gate even though the await sits at the call site; an instrument that only recognises await waitFor inside the helper body misses it.

	before the Q2 filter	after	removed
T3	510	475	35
T3+settle	184	149	35

Both numbers on record, as required. Where the 35 sit:

 9 packages/fields/src/__tests__/slider-signature-host-channels-e2e.test.tsx (formRow())
 6 packages/plugin-form/src/WizardForm.successBehavior.test.tsx
 4 packages/plugin-form/src/ObjectForm.requiredBoolean.test.tsx
 4 packages/plugin-form/src/ObjectForm.submitBehavior.test.tsx
 3 packages/fields/src/__tests__/readonly-richtext-display-5498.test.tsx (readonlyProse())
 2 packages/plugin-form/src/ObjectForm.locationRefusal.test.tsx
 7 one each: auth, plugin-form x4, fields x2

⭐ The filter is worth more than the fields slice showed. It removes 14 blocks in fields — the dev's 21 per-read sites, counted per block — but 20 in plugin-form, a package nobody had looked at. plugin-form goes from 30 candidates to 10, a two-thirds reduction, entirely from this one artifact. That package would otherwise have been dispatched at three times its real size.

---

7. Pathspec bound — expression confirmed, count corrected, scope corrected

The expression is right as written. git ls-files -- '*.test.tsx' '*.test.ts' '*.spec.tsx' '*.spec.ts'.

The count 2,282 was correct when it was taken and is now stale. Walking the count back through history: it was exactly 2,282 at b28a2c5d0 / b84dc1854 / b03ba3ad5 on 2026-08-31 — and b84dc1854 is one of the merge-queue bases named in #6959, so that is the tree the original census ran against. Since then the corpus has grown:

tree	matched files
b84dc1854 (original measurement)	2,282
8f1d995ef (pre-#6966 control)	2,286
7a5da1414 (current main)	2,288

The drift is new test files, not a wrong pathspec. ⚠️ One correction to the scope, not the expression: 28 of those 2,288 are Playwright specs (@playwright/test) where the ladder does not apply at all (section 3b), so the effective corpus for this class is 2,260 files.

---

8. Can tier 3 be tightened mechanically? — Partly. One of the three causes can, two cannot.

⛔ As instructed, nothing below is silently subtracted from any count above.

(a) The read surface does not depend on the pending settle — ⛔ NOT mechanical. Deciding that LookupField.dependsOn.test.tsx:197 is prop-derived requires following effectiveFilterColumns back through RecordPickerDialog.tsx:556 to the filterColumns/lookupFilters props. That is a data-flow question spanning the test, the component, and its props, and nothing in the test file can answer it. This is also the cause that produces the candidates which look most like :257 — same gate shape, same read shape, opposite verdict. No filter can help here; it is triage work.

(b) Its inversion, a gate strictly DOWNSTREAM of the read — ⛔ NOT mechanical either. ImageField.maxSize.test.tsx:106 needs the ordering fact that setErrors(rejections) runs synchronously at ImageField.tsx:171 before the handler's first await, while onChange fires only after await Promise.all(upload) at :185/:187. Upstream versus downstream is a fact about the component's execution order, invisible to any test-file analysis. ⭐ It is the sharpest distinction this card family has produced and it is entirely a reading task.

(c) Absence assertions — ✅ this one IS mechanical, and I measured it. A read whose own line asserts absence (.toBeNull(), .not.toBeInTheDocument(), .toBeFalsy(), .toHaveLength(0)) is structurally incapable of the #6967 failure, which manifests as an element being missing. 55 of the 149 T3+settle candidates are of this shape, leaving 94.

⚠️ I am reporting that number, not applying it, and the reason is the one the fields dev already put on the record: these sites cannot fail this way but can pass vacuously, which is the adjacent #6640 shape. Subtracting them silently would convert a known-weak population into an invisible one. If the PM wants the 94, it should be an explicit ruling, and the 55 should be handed to #6640 rather than deleted.

⇒ Net answer: tier 3 can be mechanically tightened from 149 to 94, and no further. The remaining 94 require per-site judgement, and the two dominant judgement classes are (a) and (b) above.

---

9. What I recommend the card carry

1. ⛔ Retire 173 and the per-package table under it. Not because of .each — because the published tier ladder cannot have produced them (section 1), so they are not reproducible even in principle.
2. Carry 149 (T3+settle) as the candidate population, with the per-package table in section 4. Carry 475 only as the card-definition-shaped upper bound.
3. State the artifact list in every slice dispatch, as ruled: reads inside a waitFor callback are the gate; reads inside await act(async () = are that call's argument; helpers that return a gate are gates (now centrally filtered); Playwright specs are out of scope.
4. Re-order the slices. app-shell (62) still leads. But apps/console drops 25 to 8, fields 28 to 5, while plugin-detail rises 4 to 14 and plugin-list 2 to 12. plugin-form is 10 only because Q2 removed 20 from it.
5. ⛔ Do not carry a false-positive rate. Two samples, 2-of-3 and 0-of-8, do not estimate one. Report per-slice rates and let the population accumulate.

⛔ No slice was dispatched or fixed. The remaining candidates stay frozen for the PM's call.

Generated by Claude Code

---

Generated by Claude Code

[claude]

os-dev-report

{
 "issue": 6967,
 "status": "done",
 "branch": "none — measurement-only task, no branch and no commits; both worktrees are detached HEADs (objectui-issue-6967-census at 7a5da1414, objectui-issue-6967-control at 8f1d995ef) and git status --porcelain is empty in both plus the shared checkout",
 "pr": null,
 "premise_still_valid": false,
 "summary": "CENSUS RE-DERIVED AND POSTED on card 6967 (comment 5474204975). The card's 173 does not stand — but the `.each` blind spot is NOT why, and that is the half of the premise that died. WHAT KILLS THE CARD'S NUMBERS, and it is stronger than the .each question: the published tier ladder cannot be the ladder that produced 1105/413/176. The card lists GanttView.autoscheduledlg.test.tsx:63 as one of plugin-gantt's three tier-3 hits, and tier 3 is cumulative on tier 2's 'surface async-witnessed elsewhere in its own package'. That site reads gantt-autoschedule-confirm, and that testid occurs EXACTLY TWICE in the whole repository — the production element at GanttView.tsx:5030 and the candidate read itself. It is never named by a findBy, a waitFor, or any async query anywhere. So it cannot reach tier 2, therefore cannot be tier 3, yet it is published as tier 3. The card's numbers are not reproducible from its own definitions even in principle. WHETHER THE ORIGINAL PARSED .each: UNRECOVERABLE, and I verified that rather than taking the author's word — git log --all --diff-filter=A over *census*, *tier3*, *tier-3* across every ref returns only unrelated pre-existing test files, and PR 6966 changed exactly two files. So every number I report is against a RECONSTRUCTION, stated as such. What I could measure instead is the SIZE of the blind spot on the same corpus with one flag flipped: 8 tier-3 candidates, 2 after the settle refinement, i.e. about 1.6 percent. Real, worth the freeze, not the large skew the card feared. The measured reason it is small: repo-wide there are 611 .each blocks but only 101 async and only 32 with any synchronous DOM read — .each is used here overwhelmingly for table-driven schema and vocabulary assertions that never mount. THE REPLACEMENT NUMBERS on current main 7a5da1414: tier1 1606, tier3 475 (card's tier-3 shape, witness rung dropped), tier3+settle 149 (the number I recommend the card carry), 94 if absence-only assertions are also dropped. THE CONCENTRATIONS MOVED IN BOTH DIRECTIONS: apps/console 25 to 8, fields 28 to 5 (consistent with that slice's measured zero), while plugin-detail rises 4 to 14 and plugin-list 2 to 12, and plugin-kanban appears at 3 where the card had it absent. Any dispatch order taken from the card's table is wrong. NOTHING WAS EDITED: no test, no source, no gate, no skip, no timeout, no production code, no slice dispatched or fixed.",
 "tests": "No code change, so there is no head to re-verify against; every reading is on 7a5da1414 (census) or 8f1d995ef (control) with clean trees. The instrument is a scratchpad script, deliberately not committed, and it runs in about 3 seconds over 2288 files, so no shared verify lock was needed and none was taken. (1) HOT CONTROL 1, the one the dispatch requires: run against 8f1d995ef, main immediately BEFORE c0c436db8 (PR 6966), where :257 is still live. Output: 'TIER1 56 TIER3 6 TIER3_SETTLE 1' and 'T3+settle -> ObjectGantt.referenceArms-6837.test.tsx:257 siblings=257,258,259,260,261'. :257 AND :258-:261 are all reported, and plugin-gantt leaves exactly ONE candidate standing, matching the hand triage. (2) HOT CONTROL 1b, the negative half, which the dispatch did not ask for and which is what makes 1 falsifiable: the same instrument on current main returns TIER3_SETTLE 0 for plugin-gantt — the site is gone because 6966 landed. Without this leg, control 1 only proves the instrument reports something. (3) BOTH KNOWN FALSE POSITIVES CLEARED, and mechanically, not by hand: quickfilter:141 is cleared at tier 1 because file-local helpers are resolved inside gate expressions, so waitFor(expect(gv(container)).toBeTruthy()) reads as the DOM gate it is; autoscheduledlg:63 is cleared by the settle requirement because nothing is awaited anywhere before the read's anchor statement. (4) .each POSITIVE CONTROL with a discriminating negative. The repo was NEVER mutated — I copied ObjectGantt.referenceArms-6837.test.tsx into the scratchpad and rewrote the :253 block header, body verbatim so the genuine :257 defect shape is preserved, into an it.each array-table block, then appended a template-table positive and a DOM-gated negative. MUTATION PROVEN ON DISK, not by an editor's exit code: 'anchor occurrences BEFORE: 1' (unique, so the edit cannot be a no-op), 'removed-anchor count (must be 0): 0', 'injected it.each count (must be 4): 4', bytes 14190 to 15104. Result one flag apart: each=on gives TIER3_SETTLE 3 at lines 257, 291, 299 all flagged each=true (array table AND template table both fire); each=off gives 0 on the IDENTICAL file. The it.each block gated by await view.findByTestId is NOT reported, so the parser discriminates rather than reporting every .each block. (5) TWO INSTRUMENT BUGS FOUND AND FIXED RATHER THAN REPORTING THEIR OUTPUT, both of which had made the corpus look CLEANER than it is. (a) My comment/string/template masker mishandled dollar-brace interpolation and blanked live code downstream of certain template literals: in packages/fields only 84 of 109 it.each occurrences were visible to the parser. Fixing .each parsing while a quarter of the .each blocks were dark would have produced a 'we now parse .each' claim with the hole still open. After the rewrite, repo-wide 613 of 627 it.each occurrences are visible, and I inspected every one of the 14 still hidden — all 14 are genuinely inside comments (prose mentions such as 'it.each([]) reports nothing'), so the masker is correct rather than merely quieter. (b) e2e/live contributed 30 structurally impossible candidates: those files are Playwright, where page.getByRole returns an auto-waiting Locator, not a synchronous DOM read. I excluded the 28 spec files importing the playwright test package rather than shipping the number. (6) INDEPENDENT CROSS-VALIDATION against the fields slice, which I did not coordinate with, on four separate facts: packages/fields has exactly 109 it.each occurrences, the dev's figure to the unit; my parser sees 160 async blocks in fields with 12 of them .each against the dev's 168 async with 12 .each, so the .each count matches exactly and the async totals differ by 4.8 percent, the expected spread between two independent block matchers; my .each-only fields candidates are composite-group-label-readonly-e2e.test.tsx:466 (siblings 466, 470, 479) and richtext-host-plumbing-e2e.test.tsx:218, which are EXACTLY the sites the dev's table annotates 'Found only after fixing the .each blind spot' and 'Also .each', including the 466/470 pair; and all five of my fields tier3+settle candidates fall inside the dev's hand-triaged group A (ImageField.maxSize:83, :93, :106, LookupField.dependsOn:197, RecipientPickerField:82), the last two being the ones the dev measured with probe legs A and B rather than settling by reading. (7) Q2 = A APPLIED, both numbers on record as required: tier3 510 before the filter and 475 after; tier3+settle 184 before and 149 after; 35 removed either way. Where they sit: 9 in fields slider-signature-host-channels-e2e (formRow()), 3 in fields readonly-richtext-display-5498 (readonlyProse()), and 20 in plugin-form across 8 files — so the filter is worth MORE than the fields slice showed, taking plugin-form from 30 to 10, a package nobody had looked at. (8) PATHSPEC BOUND: the expression is right as written; the count 2282 was correct at b28a2c5d0 / b84dc1854 / b03ba3ad5 on 2026-08-31 — and b84dc1854 is one of the merge-queue bases named in 6959, so that is the tree the original ran against — and it is 2286 at 8f1d995ef and 2288 at current main, the drift being new test files. One scope correction, not an expression correction: 28 of the 2288 are Playwright specs where the ladder does not apply, so the effective corpus is 2260.",
 "mcp_calls": "0 — no MCP GitHub calls this run. The repo-scoped REST probe returned 200 on this seat, so the card, its comments, card 6959 and its correction comment, and PR 6966's file list all came through REST; the census comment was posted through the additive endpoint POST /issues/6967/comments and read back in full (body byte-identical, the only delta being the platform's own appended second signature footer); all code reading was local git.",
 "open_questions": [
 {
 "question": "55 of the 149 tier3+settle candidates assert ABSENCE on the read's own line (toBeNull, not.toBeInTheDocument, toBeFalsy, toHaveLength(0)). They are structurally incapable of THIS card's failure, which manifests as an element being missing. Should they be subtracted, taking the population from 149 to 94?",
 "options": [
 "A — Subtract them from this card and hand the 55 to 6640 as the adjacent 'green that tested nothing' class, so they are re-homed rather than deleted.",
 "B — Keep all 149 in this card and let each slice's dev clear them per site.",
 "C — Subtract them and file nothing."
 ],
 "recommendation": "A. The subtraction is the one mechanical tightening actually available here (the other two false-positive causes are irreducibly manual, see the next question), so it is worth taking. But it must be a re-homing, not a deletion: the fields dev already put on record that these sites cannot fail THIS way yet can pass vacuously, which is exactly 6640's shape. C converts a known-weak population into an invisible one, which is the failure this card family keeps having. I did NOT apply the subtraction myself — both 149 and 94 are on record and the ruling is the PM's."
 },
 {
 "question": "Should the card retire tier 2's witness rung ('surface async-witnessed elsewhere in its own package') from the tier-3 lineage?",
 "options": [
 "A — Retire it: report tier 3 as tier 1 plus 'no DOM-touching gate at all', with no witness requirement.",
 "B — Keep it and accept that some real hits are excluded.",
 "C — Replace it with a looser witness rule."
 ],
 "recommendation": "A, and the argument is a proof rather than a preference: gantt-autoschedule-confirm occurs exactly twice in the repository and is never async-witnessed anywhere, so under ANY string-based reading of that rung autoscheduledlg:63 cannot be tier 2 — yet the card publishes it as tier 3. The rung as worded demonstrably excludes a site the card itself carries, so it cannot be the rung the original used, and keeping it would silently drop real candidates. C is worse than A because a looser rule that nobody can state precisely is how the card ended up with numbers nobody can reproduce. I have reported both figures (231 with the rung, 475 without) so the choice is visible."
 }
 ],
 "out_of_scope_findings": [
 "NOTHING FILED, deliberately, and the reason is on the record rather than a speculative card. This was a measurement task and it found no repo defect to file: the two candidate findings are (a) the 55 absence-assertion sites, which I am escalating as open question 1 rather than carding, because the fields dev already established the correct restraint — filing on 'this shape could in principle be weak' with no measurement showing one IS weak is the speculative-capability trap, and re-homing them to 6640 is a PM routing decision, not a new card; and (b) e2e/live's Playwright specs appearing in the card's table at 3, which is an instrument scoping error in a card that is being corrected by this very comment, not a defect in the repository. Filing either as a new issue would manufacture cards out of a correction that already exists."
 ]
}

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

Seat ruling on the re-derived census — both open questions answered, dispatch unfrozen

Ruling on the census posted above. Q1 = A. Q2 = A. The card's published population becomes 94, and the table in this card's body is superseded — see the banner now on the body.

Q2 (the tier-2 witness rung) = A, retire it — and I verified the proof myself rather than taking it on report

This is the ruling that matters, because it is a proof of self-contradiction rather than a preference, so I re-measured its load-bearing fact against the bytes at 7a5da1414 before ruling:

$ git grep -n 'gantt-autoschedule-confirm' 7a5da1414
packages/plugin-gantt/src/GanttView.autoscheduledlg.test.tsx:63: fireEvent.click(baseElement.querySelector('[data-testid="gantt-autoschedule-confirm"]') as HTMLElement);
packages/plugin-gantt/src/GanttView.tsx:5030: data-testid="gantt-autoschedule-confirm"

Exactly two occurrences repo-wide: the production element, and the candidate read itself. Filtering the same result for findBy|waitFor|await returns nothing. So that testid is never async-witnessed anywhere in the repository, and under any string-based reading of tier 2's rung — "surface async-witnessed elsewhere in its own package" — autoscheduledlg.test.tsx:63 cannot reach tier 2, and therefore cannot be tier 3. This card publishes it as tier 3.

A rung that excludes a site the card itself carries cannot be the rung that produced the card's numbers. It is retired. Tier 3 is now tier 1 plus "no DOM-touching gate at all", with no witness requirement. Both figures stay on the record so the choice remains auditable: 231 with the rung, 475 without.

Option C is refused for the reason given: a looser witness rule nobody can state precisely is exactly how this card ended up with numbers nobody can reproduce.

Q1 (the 55 absence-assertion sites) = A, subtract and re-home

Subtract them — 149 becomes 94 — and hand the 55 to #6640 rather than dropping them.

The argument is about defect class, not confidence. This card's failure is a synchronous read landing before the DOM settles. Where the assertion is a presence assertion, an early read makes the test fail — a flaky red, which is this card. Where it asserts absence (toBeNull, not.toBeInTheDocument, toBeFalsy, toHaveLength(0)), an early read finds nothing, the assertion passes, and the test reports green having witnessed nothing. That is not a weaker instance of this card's defect; it is #6640's defect. Re-homing keeps that population visible under the card that can actually characterise it, which option C would not.

The numbers this card now carries

Measured at 7a5da1414, effective corpus 2260 after excluding 28 Playwright specs where the ladder does not apply (page.getByRole returns an auto-waiting Locator, not a synchronous DOM read):

rung	count
tier 1	1606
tier 3 (witness rung retired)	475
tier 3 + settle	149
tier 3 + settle − absence-only (published)	94

The concentrations moved in both directions, so every slice boundary in the old table is void: apps/console 25 → 8, packages/fields 28 → 5, while plugin-detail rises 4 → 14, plugin-list 2 → 12, and plugin-kanban appears at 3 where the card recorded it absent.

The .each blind spot that motivated the freeze is real but small — about 1.6% (8 tier-3 candidates, 2 after the settle refinement). The measured reason it is small: of 611 .each blocks repo-wide only 101 are async and only 32 contain any synchronous DOM read, because .each here is overwhelmingly used for table-driven schema and vocabulary assertions that never mount. The freeze was still the right call — not because of .each, but because the slice table it would have dispatched from is wrong.

Drift bound — stated, because the report did not carry it

The census ran at 7a5da1414, which the report calls "current main". It is not: 7a5da1414 is main as of #6954, and main is now fd8dacecc, two merges ahead (#6960, #6961). I measured the consequence rather than waving at it — between those trees exactly one test file is added (packages/data-objectstack/src/metadata-client.publishAdvisories.test.ts) and four existing test files are edited. The numbers above are therefore one file short of current main, which does not move any conclusion.

Pathspec bound on my own drift check, stated so it is not mistaken for the census's: I counted **/*.{test,spec}.{ts,tsx,js,jsx,mts,cts} and got 2296 → 2297 across those two merges. That is a different expression from the census's and yields a different total; it bounds the drift, not the corpus.

Why these numbers are worth acting on where the card's were not

Recording what the re-run did, because it is the difference between a census and a number:

• A hot control with its negative half. Run against 8f1d995ef — main immediately before test(plugin-gantt): read the chart through an async query, not a race #6966 — the instrument reports ObjectGantt.referenceArms-6837.test.tsx:257 and its siblings, the known-live defect. Run against the tree where test(plugin-gantt): read the chart through an async query, not a race #6966 has landed, plugin-gantt returns zero. Without the second leg the first only proves the instrument emits something.
• A .each positive control with a discriminating negative, run on a scratchpad copy so the repo was never mutated, with the mutation proven on disk by anchor counts and byte size rather than an editor's exit code. A .each block gated by await findByTestId is not reported — so the parser discriminates instead of flagging every .each.
• Two instrument bugs found and fixed rather than shipped, both of which had made the corpus look cleaner than it is: a masker that mishandled ${...} interpolation and blanked live code (only 84 of 109 .each occurrences visible in fields; 613 of 627 repo-wide after the fix, with all 14 remaining hand-inspected and genuinely inside comments), and 30 structurally impossible Playwright candidates.
• Independent cross-validation against the fields slice on four facts it did not coordinate on, including reproducing that slice's two .each-only sites exactly.

Dispatch is unfrozen, with one condition

The freeze on the remaining candidates is lifted. Any dispatch order must be cut from the table above, never from this card's body table. Slices will be re-cut against the new concentrations, which means plugin-detail and plugin-list lead and apps/console/fields are largely spent.

No repo defect was filed out of this run, correctly: the two candidates were the 55 sites (routed here as Q1, not carded) and the Playwright scoping error (an instrument fault being corrected by the census itself, not a repository defect).

---

Seat session: https://claude.ai/code/session_013hfmP9hoMd3dJwTh85J4yB

---

Generated by Claude Code