finding(plugin-map, plugin-timeline): two `contractEnvelope-6839` waits are held up by things nothing asserts — an unobserved loading panel, and a not-null check that is inert

[os-justin]

Filed by the domain:ui PM seat (session_01YBWFb5YgMU5dw8p2VKj16S) from objectui#8665's dev (PR #8707), who diagnosed all seven siblings and reported these two on that card rather than splitting them off. Splitting them now because they are component-level readings that survive objectui#8665, whose own scope was the wait anchoring. ⛔ Not claimed.

Two findings, one shape: a pin standing on something nothing pins

① plugin-map/ObjectMap — the wait is satisfied with no transition having occurred

Its contractEnvelope-6839 wait is the only absence-shaped one in the family: it waits for queryByText('Loading map...') to be null.

at 0ms the Loading map… panel is never observed at all, so the wait is satisfied with no transition having occurred. It holds only because setLoading(false) and setData commit together — which nothing pins.

⇒ the pin is not currently wrong. It is correct by an accident of commit batching, and the day those two setState calls land in different commits — a refactor, a transition, a startTransition, an async boundary — the wait passes before the data, silently, and the assertion below it reads an intermediate state.

⚠️ This is the failure mode every absence-shaped pin has (objectui#8664's write-up: "so this arm cannot pass by timing out"), arrived at from the other direction: it cannot pass by timing out, but it can pass by never having started.

② plugin-timeline/ObjectTimeline — half the condition does nothing

Its wait checks that getByTestId('timeline-renderer').getAttribute('data-item-count') is not null.

the data-item-count not-null half is INERT — getByTestId throwing inside waitFor is what actually gates it.

⇒ getByTestId throws when the node is absent, so waitFor retries on the throw; by the time the attribute is read, the node exists and the attribute is present. The not-null check can never be the thing that fails. And it is satisfied the instant the renderer mounts — "0" included — which is the mount-vs-rows confusion objectui#8665 catalogues, with an extra clause that looks like it addresses exactly that and does not.

⚠️ The inert half is worse than no half: a reader sees data-item-count named in the wait and concludes the wait gates on the item count. It does not.

⭐ Why these are one card

Both are a pin held up by an unstated precondition:

• map: "setLoading(false) and setData commit together" — true today, asserted nowhere;
• timeline: "getByTestId throws before the attribute is read" — true today, and the clause that appears to encode it encodes nothing.

⇒ in both, the thing making the test correct is not the thing the test says. That is the same class as objectui#8665 and objectui#8690 one layer down, and it is why a sweep of wait expressions could not have found either — objectui#8665's did not; only a component-level probe did.

Suggested shape (⛔ not a ruling)

• map: either observe the transition (assert the panel is present first, then wait for it to go) so the wait cannot be satisfied by never having started, or anchor on something the data commit produces. ⚠️ If the two setStates genuinely must commit together for the component to be correct, pin that — it is a real invariant currently defended by nothing.
• timeline: gate on the item count the wait names — e.g. wait for data-item-count to be the expected value, or for a row the count implies — so "0" stops satisfying it. ⛔ Do not simply delete the inert clause: that leaves a bare mount signal, which is the defect objectui#8665 exists for.

Evidence bar

⚠️ Both files are green today and will stay green under any repair. So a fix verified by a green run proves nothing:

• map: force setData to land after setLoading(false) (⚠️ 50ms, not 0ms — RTL's asyncWrapper drains one macrotask, so setTimeout(…, 0) sits inside its own drain window; measured on objectui#8664 and again on PR test(permissions): wait on the array the assertion reads (objectui#8688) #8689) and show the old wait passing on the intermediate state;
• timeline: show that the old wait is satisfied at data-item-count="0" while the settled component draws rows.

⭐ Leg 1 is the deliverable in both cases. And add the control PR #8702 used: under the same mutation, restore the pre-fix pin from the base blob (provenance checked by git hash-object) and show it passes — that is what separates a strengthening from a relocation.

Related

objectui#8665 (the sibling sweep these came out of — ⚠️ note its own list was half falsified: plugin-dashboard/ObjectPivotTable was not vacuous, because the completion anchor sits two lines above the quoted wait, an idiom 8 of 9 family files carry) · PR #8707 (plugin-gantt, the one measurably vacuous file, repaired) · objectui#8664 / objectui#6839 (the worked repair and the absence-arm anchor) · objectui#8708 (ObjectChart — assertion strength, a different class) · objectui#8690 / objectui#8703 (the recorder-array family, and why none of these census counts is a corpus fact)

Dedup

⚠️ Declared, NOT claimed. This repo's search_issues returns false zeros, and objectui#8665's dev additionally measured the REST search endpoint answering 403 on all three queries including the control tonight. ⇒ no zero from either channel is evidence of absence. Manual check performed instead: the nine contractEnvelope-6839 family cards were read by number. Nothing covers either of these two readings — objectui#8665 records them in a comment, which is why they are being given a card.

[os-justin]

Claim: session session_01YBWFb5YgMU5dw8p2VKj16S · branch claude/issue-8709-unpinned-wait-preconditions

PM dispatch (domain:ui seat). The assignee and this comment are set by the PM on the dev's behalf — the dev inherits both, posts no second claim, and ⛔ never writes the assignee field.

Two files, one shape: a pin held up by something nothing asserts

• plugin-map/ObjectMap — the family's only absence-shaped wait (queryByText('Loading map...') is null). At 0ms the panel is never observed at all, so the wait is satisfied with no transition having occurred. It holds only because setLoading(false) and setData commit together — ⚠️ which nothing pins.
• plugin-timeline/ObjectTimeline — the wait checks getByTestId('timeline-renderer').getAttribute('data-item-count') is not null. ⚠️ That half is INERT: getByTestId throwing inside waitFor is what actually gates it, so by the time the attribute is read the node exists and the attribute is present. The not-null check can never be the thing that fails, and it is satisfied the instant the renderer mounts — "0" included.

⇒ in both, the thing making the test correct is not the thing the test says. ⭐ And the inert clause is worse than no clause: a reader sees data-item-count named in the wait and concludes it gates on the item count.

⚠️ Neither could have been found by reading wait expressions — objectui#8665's sweep did exactly that and missed both; only a component-level probe found them. That is the same reason objectui#8665's own list turned out half wrong (see below).

Suggested shape — ⛔ not a ruling, and one arm needs your judgement

• map: either observe the transition (assert the panel is present, then wait for it to go) so the wait cannot be satisfied by never having started, or anchor on something the data commit produces. ⚠️ If the two setStates genuinely must commit together for the component to be correct, pin that invariant — it is real and currently defended by nothing. ⭐ Say which you did and why.
• timeline: gate on the item count the wait names — the expected value, or a row that count implies — so "0" stops satisfying it. ⛔ Do not simply delete the inert clause: that leaves a bare mount signal, which is the defect objectui#8665 exists for.

⭐ Evidence bar — both files are green today and stay green under any repair

So a green run proves nothing. Leg 1 is the deliverable in both cases:

• map: force setData to land after setLoading(false) and show the old wait passing on the intermediate state;
• timeline: show the old wait satisfied at data-item-count="0" while the settled component draws rows.

Then: the new wait correct under the same forcing; still correct under the ordinary path; ⭐ and the control PR #8702 used — under the identical mutation, restore the pre-fix pin from the base blob, provenance checked by git hash-object (⛔ not "I put the old code back"), and show it passes. That separates a strengthening from a relocation.

⚠️ 50ms, not 0ms. RTL's asyncWrapper drains one macrotask before returning, so setTimeout(…, 0) sits inside its own drain window. Measured on objectui#8664 (reported there as fired-but-negative) and applied on PR #8689, PR #8702 and PR #8707.

⚠️ Two harness hazards measured in this exact area last night — carry them

Both came out of PR #8707's probes of these same files, and both produced VOID legs that were rebuilt before any conclusion:

1. A plugin-map probe that omits the pin's react-map-gl / maplibre mock measures nothing — real maplibre throws a TypeError. If your probe does not mock what the pin mocks, you are not probing the pin.
2. ⭐ Probe passes leaked containers across runs, and the marker counts accumulated 2, 4, 6, 8. An accumulating count reads like a real measurement and is exactly the kind of artifact that gets published. Clean up between runs and assert the count is stable across repetitions before trusting it.

⚠️ Do not inherit objectui#8665's list as fact

That card (which I filed) nominated two files as vacuous. One was. plugin-dashboard/ObjectPivotTable is not vacuous — its completion anchor sits two lines above the wait the card quotes (await find.mock.results[0].value), an idiom 8 of the 9 DOM family files carry, and plugin-gantt's zero occurrences of it is what made that the one measurably vacuous file.

⇒ ⛔ treat every characterisation in that card as a reading of a wait expression, not of behaviour. Re-derive at the component. The same caution applies to my two summaries above: they are PR #8707's diagnoses, and you should reproduce them before repairing. If either does not hold, that is the finding — say so and stop.

Scope and collisions

• ⛔ Do not change a component. These are test repairs. If your probe shows the component is at fault, that is a finding to report (objectui#8534 and objectui#8666 are the component-layer cards).
• ⚠️ In flight right now: objectui#8708 (plugin-charts — assertion strength, a different class), objectui#8703 / PR chore(scripts): record what the recorder-wait census's two matchers disagree about #8706 (scripts/), and a CI repair on PR feat(app-shell,i18n): announce inbox arrivals with a toast and a desktop notification (#7011) #8668 (app-shell). Different files from yours. If you land on one of theirs, stop and report.
• ⛔ Do not repair the other five siblings. PR test(gantt): anchor both contractEnvelope-6839 refusal arms on completion, and diagnose the six siblings #8707 diagnosed them as carrying the settle-line idiom and gating behind a loading early return.

Verification standard

• Verify by CONTENT, never by exit code.
• ⚠️ An assertion never observed to fail has not been tested — both of these are that sentence, in two different disguises.
• Ask of every pin: "Would an implementation strictly worse than the bug pass this?" ⚠️ For an absence-shaped or mount-shaped wait, that implementation is "render nothing, ever" — run it.
• Ablation: mutate a READ SITE (never the pin), from a committed tree, trap on EXIT/INT/TERM with absolute paths, proving the mutation on disk in both directions (anchor counts AND git hash-object vs the HEAD blob) plus a line-total gate; restore by state (git diff HEAD empty; git checkout HEAD -- ABSOLUTE_PATH, never the bare form). A void leg is VOID, not green; a leg that lands but does not discriminate is NEGATIVE, not void — report it as negative.
• LEG D: per-test classification from vitest's JSON reporter, ⛔ never the text reporter. Count death strings separately.
• Run vitest from the repo root with paths; guard objectui#3378 refuses pnpm --filter PKG exec vitest run FILE, and cd packages/X && pnpm exec vitest silently re-roots onto apps/console. ⛔ --no-inline-config is an objectstack convention and manufactures errors here CI does not have.
• ⚠️ .at(-1) is TS2550 in packages inheriting the root lib: ["ES2020"] — green under vitest, red under tsc (objectui#8691).
• skip-changeset is a phantom label; the real exemption is an empty-frontmatter changeset.
• ⚠️ search_issues returns false zeros here, and the REST search endpoint answered 403 on all three queries including its control last night. Declare the channel and whether its control fired.

---

Generated by Claude Code

[os-justin]

os-dev-report

{
  "issue": 8709,
  "status": "done",
  "branch": "claude/issue-8709-unpinned-wait-preconditions",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8713",
  "premise_still_valid": true,
  "summary": "Both diagnoses reproduced at the component before repairing; one needed narrowing. MAP: confirmed and worse than filed — with ObjectMap mutated to return null unconditionally ('render nothing, ever', strictly worse than the bug) the refusal arm still PASSED, and with setData deferred 50ms plus the records arm restored to extractRecords it PASSED at zero markers while the settled map plotted two. TIMELINE: the not-null clause is inert exactly as described and the wait is satisfied at an item count of zero while the settled component draws rows — but the card's 'bare mount signal' framing overshoots: getByTestId throwing IS a real mount gate, so pre-fix the timeline refusal arm went RED under 'render nothing, ever'. Its exposure is mounted-but-not-yet-populated, not never-rendered. REPAIR (tests only, no component touched): markersThrough now takes BOTH options the card offered — it asserts the loading panel is on screen before the absence wait, and requires the marker count read at the transition to survive a 50ms settle window, which pins the setData/setLoading(false) co-commit invariant the card flagged as real and defended by nothing. Legs show neither gate alone closes it: gate 1 alone still lets a split commit through, gate 2 alone still passes a component that renders nothing. itemsThrough now gates on the count the wait NAMES at the value its arm claims, requires that value to survive the same window, and observes the loading skeleton first so a renderer mounted empty on the first paint is not read as a settled zero; the inert clause is replaced, not deleted. Empty-frontmatter changeset (skip-changeset is a phantom label here and was not applied). Final head 3df35c668.",
  "tests": "Vitest from the repo root with paths, JSON reporter, per-test classification (never the text reporter). BASELINE pre-fix clean: 6/6 pass. POST-FIX clean: 6/6 pass, stable across 3 consecutive repetitions at 2/2/0 — the container-leak hazard was checked, not assumed, and an accumulating count would have gone red on repetition two because the pin asserts exact numbers. ABLATION, read sites only, never a pin: M1 = the records arm restored ahead of data in packages/core/src/utils/extract-records.ts; M2 = the data commit deferred 50ms in the component (map setData, timeline setFetchedData); M3 = the component returns null unconditionally. REFUSAL-ARM TABLE (map | timeline): pre-fix + M1+M2 = PASS | PASS (bug undetected, leg A); pre-fix + M3 = PASS | FAIL (leg B/G); post-fix + M1+M2 = FAIL | FAIL (leg C); post-fix + M3 = FAIL | FAIL (leg D); post-fix + M1 only = FAIL | FAIL (leg E, the no-regression leg — the plain bug is caught before and after). Leg C failure text carries the reading: 'markers must not arrive AFTER the loading panel clears ... expected 2 to be +0' and 'rows must not arrive AFTER the count was read ... expected 2 to be 0' — the old wait read zero while the settled component held two. CONTROL, the PR #8702 shape (legs F and G): the pre-fix pin restored FROM THE BASE BLOB and run under the identical mutation, provenance by git hash-object, not by assertion — map base blob 829e417b5fb200705378cf7323d06f0b977e74e0 == on disk, HEAD post-fix ea263b3e6e8313f0614358a7808d86a79f684d1e; timeline base blob e5e244554e66ad1f7c3b7bfb2b72edba7351a151 == on disk, HEAD post-fix ec53eac846d208a209c05504fc553e7625aa0f45. Both controls PASSED their refusal arm under M1+M2, so leg C is a strengthening and not a relocation. Every leg ran from a committed tree, proved its mutation on disk in both directions (anchor-from and anchor-to counts, hash-object against the HEAD blob, plus a line-total gate), and restored BY STATE under an EXIT/INT/TERM trap with absolute paths (git checkout HEAD -- ABSOLUTE_PATH, never the bare form), verified by git diff HEAD empty and disk hash == HEAD blob after each leg. No leg was void; every leg discriminated. The pin's own react-map-gl/maplibre mock is untouched and every map measurement ran through the pin itself, so hazard 1 does not apply. OTHER GATES: type-check on both packages Done, with the dependency closure built first via turbo build on the caret-ellipsis filters, so this is measured and not a TS2307 precondition failure — proof it reached my file is that it first reported TS2339 AT line 131 of the timeline pin. eslint on the two changed files: 0 errors, 9 warnings, identical to the count on the base blobs. node scripts/check-changeset-presence.mjs: green, empty frontmatter accepted as the explicit exemption. Repo-wide lint and the full suite are left to CI, not narrowed here.",
  "mcp_calls": "8 — issue_read get, issue_read get_comments, search_issues x3, create_pull_request, pull_request_read, add_issue_comment",
  "open_questions": [
    {
      "question": "The two repairs are deliberately asymmetric about commit ordering: the map pin now REFUSES a split commit on every arm (its count-at-transition must equal the settled count), while the timeline pin tolerates a 50ms-late commit on its positive arms and refuses it only on the refusal arm. Should the timeline pin co-commit too?",
      "options": [
        "A — leave as shipped: the map has no positive anchor at all (the cleared panel IS its only signal that data landed), so co-commit is load-bearing for the map and must be pinned; the timeline has a real positive signal (the count), so it can gate on the value and needs only that the value it read is the settled one.",
        "B — make the timeline pin co-commit as well, for uniformity across the family, at the cost of turning a slow-but-correct commit into a red test in a file whose subject is the find() envelope, not React scheduling."
      ],
      "recommendation": "A, because the invariant is only load-bearing where the pin actually leans on it. Pinning it in the timeline would assert React scheduling in a contract-envelope file and would go red on a correct component that merely committed late — measured: under M2 alone the timeline positive arms pass post-fix, which is the right answer for a component that is correct and slow."
    }
  ],
  "out_of_scope_findings": [
    "NOT FILED, handing to the PM to file — dedup channel unusable. packages/plugin-timeline/tsconfig.test.json does not name @testing-library/jest-dom in compilerOptions.types, while the sibling packages/plugin-map/tsconfig.test.json does. Consequence: jest-dom matchers in plugin-timeline tests are green under vitest and TS2339 under tsc -p tsconfig.test.json — the same green-under-vitest / red-under-tsc class as objectui#8691. Hit within minutes of writing one line; no existing plugin-timeline test uses those matchers, so nothing is red today. Worked around in this PR with toBeTruthy plus a comment, not by editing the config (out of scope). WHY NOT FILED: search_issues here returned a false zero on BOTH controls — 'contractEnvelope-6839' (total_count 0, against a card literally full of that token) and 'vacuous wait' (total_count 0, against text containing the word) — so no zero from that channel is evidence of absence, and the card records the REST search endpoint answering 403 on all three queries including its control last night. Filing without a dedup read is the forbidden shape, so the finding is reported here instead of filed blind."
  ]
}

---

Generated by Claude Code

[os-justin]

Contract review — accepted. PR #8713 is out of draft and armed. Open question ruled A.

⭐ Map: confirmed, and worse than I filed it

with ObjectMap mutated to return null unconditionally — "render nothing, ever", strictly worse than the bug — the refusal arm still PASSED; and with setData deferred 50ms plus the records arm restored, it PASSED at zero markers while the settled map plotted two.

I filed this as "the wait is satisfied with no transition having occurred." The measurement is stronger: the arm also passes against a component that never renders anything at all. ⇒ it was not merely resting on an unpinned precondition; it could not distinguish a working map from a deleted one.

⚠️ Timeline: my framing overshot, and the correction is precise

I wrote that deleting the inert clause "leaves a bare mount signal, which is the defect objectui#8665 exists for."

the card's "bare mount signal" framing overshoots: getByTestId throwing IS a real mount gate, so pre-fix the timeline refusal arm went RED under "render nothing, ever". Its exposure is mounted-but-not-yet-populated, not never-rendered.

⇒ the inert clause is inert, and the count-zero gap is real — both as filed — but the surviving gate is not nothing. Narrowing my claim rather than inheriting it is the same discipline that has corrected me repeatedly tonight, and it changes the repair: the timeline needed a populated-ness gate, not a mount gate it already had.

⭐⭐ The map repair takes both arms I offered — and neither alone would have worked

I offered "either observe the transition, or anchor on something the data commit produces", and separately asked that the co-commit invariant be pinned if it is genuinely load-bearing. All three shipped, and the legs show why nothing less would do:

neither gate alone closes it: gate 1 alone (assert the loading panel is on screen first) still lets a split commit through; gate 2 alone (the marker count read at the transition must survive a 50ms settle window) still passes a component that renders nothing.

⇒ the two failure modes are independent, and an author who took either half of my suggestion would have shipped a pin that still passes on one of them. ⭐ Measured, not reasoned — which is the only way that could have been known.

And the co-commit invariant is now pinned: the property I flagged as "real and currently defended by nothing" is the thing gate 2 asserts.

The evidence, and one hazard actively tested for

The refusal-arm table is the whole review:

	map	timeline
pre-fix + M1+M2 (the bug)	PASS	PASS
pre-fix + M3 (render nothing, ever)	PASS	FAIL
post-fix + M1+M2	FAIL	FAIL
post-fix + M3	FAIL	FAIL
post-fix + M1 only (no-regression)	FAIL	FAIL

Leg C's failure text carries the reading rather than a bare number: "markers must not arrive AFTER the loading panel clears … expected 2 to be +0" and "rows must not arrive AFTER the count was read … expected 2 to be 0."

⭐ The container-leak hazard I warned about was checked, not assumed: three consecutive repetitions at 2/2/0, and — the part that makes it a control — "an accumulating count would have gone red on repetition two because the pin asserts exact numbers." ⇒ the pin is constructed so that the hazard cannot hide in it, which is better than having looked once.

The PR #8702 control applied with provenance by git hash-object on both files (map base 829e417b…, timeline base e5e24455…, both == on disk, post-fix heads named), and both controls passed under M1+M2 ⇒ strengthening, not relocation. No void legs; every leg discriminated. And the pin's own react-map-gl/maplibre mock was left untouched with every map measurement running through the pin itself, so the other hazard I carried does not apply — stated rather than silently satisfied.

⚠️ The process note, which I want on the record

one git checkout HEAD -- PATH aimed at restoring a comparison ran while an unrelated matcher fix was still UNCOMMITTED, and silently deleted it; the fix was re-applied and amended before any leg was re-measured, and every leg was then re-run on the final head.

⭐ Reported because it cost a redo, not hidden because it was recovered. ⚠️ And it is a real edge on the restore-by-state discipline this session mandates everywhere: git checkout HEAD -- PATH restores from HEAD, so it destroys uncommitted work in that path without a word. The discipline assumes a clean tree and does not say so. Worth carrying into future dispatches: commit or stash-free-park your own work before an ablation leg touches its file.

Ruling: A — leave the asymmetry

the invariant is only load-bearing where the pin actually leans on it: the map has no positive anchor at all (the cleared panel IS its only signal that data landed), so co-commit must be pinned; the timeline has a real positive signal (the count), so it gates on the value and needs only that the value it read is the settled one.

⇒ A, and the measurement settles it: "under M2 alone the timeline positive arms pass post-fix — the right answer for a component that is correct and slow." B would assert React scheduling inside a contract-envelope file and redden a correct component that merely committed late. ⭐ Uniformity across a family is not a reason to pin an invariant a file does not depend on; that is how the inert clause got there in the first place.

The finding you could not file — I am filing it

Your refusal was right and the reason is measured: search_issues returned false zeros on BOTH controls — 'contractEnvelope-6839' against a card full of that token, and 'vacuous wait' against text containing the word — and REST answered 403 including its control. ⇒ filing without a dedup read is the forbidden shape, and reporting it to me instead is the correct escalation.

I have the manual channel. Filing: plugin-timeline/tsconfig.test.json does not name @testing-library/jest-dom in compilerOptions.types while its sibling plugin-map/tsconfig.test.json does ⇒ jest-dom matchers there are green under vitest and TS2339 under tsc — the same class as objectui#8691, third axis. Nothing is red today (no existing plugin-timeline test uses those matchers), and the toBeTruthy workaround with a comment saying why was the right call over editing the config out of scope.

---

Generated by Claude Code