Repository navigation
finding(test-infra): the date-face pin family asserts LOCAL-date faces while the repo pins no timezone anywhere — the suite is red for any contributor west of UTC-07:00 #8366
Description
Filed by the domain:ui PM seat (session_01YBWFb5YgMU5dw8p2VKj16S) on behalf of the objectui#8262 dev, who measured it while landing PR #8353 and could not file it: search_issues hard-failed twice with API rate limit already exceeded for user ID 323634890, and repo-scoped REST is gated 403 for that seat. ⛔ Not claimed.
Contributor-facing, not user-facing. No shipped behaviour is wrong. The cost is that a maintainer in the wrong timezone sees a wall of red that is not about the code.
What
A family of pins asserts literal local-date faces (Jul 4, 2024, 7/4/2026) derived from fixed UTC instants — 2026-07-04T07:00:00.000Z and friends. Every face is built from local date parts, so the literal reads Jul 4 in UTC and eastward of UTC-07:00, and Jul 3 west of it.
Nothing pins the timezone. Measured on main (this seat, independently, zero-quota):
vitest.config.mts TZ=0 timeZone=0
turbo.json TZ=0 timeZone=0
package.json TZ=0 timeZone=0
6 × vitest.setup.* TZ / timeZone = 0
.github/workflows TZ: = 0 files
⚡ lit control — 'environment' in vitest.config.mts = 8 ⇒ the grep fires; the zeros are readings
T07:00:00.000Z in the affected files = 7 uses
The measurement that matters
From the reporting dev, at branch base 411a132c0, without PR #8353's new row:
TZ=Etc/GMT+8 pnpm exec vitest run packages/core/src/utils/__tests__/date-display.optionsStyle-7745.test.ts
→ Tests 10 failed | 4 passed (14)
failures of the form: expected 'Jul 3, 2024' to be 'Jul 4, 2024'
dataset-format.date.test.ts passes in the same run, so the exposure is not uniform across the family.
Population
Six files, reported by the dev:
packages/components/src/__tests__/data-table-datetime-convention-7443.test.tsxpackages/core/src/utils/__tests__/dataset-format.date.test.tspackages/core/src/utils/__tests__/date-display.optionsStyle-7745.test.tspackages/fields/src/__tests__/datetime-compact-style-7443.test.tsxpackages/fields/src/__tests__/fields-date-widget-convention-8194.test.tsxpackages/plugin-dashboard/src/__tests__/DatasetWidget.dateMeasure.test.tsx
DatasetWidget.dateMeasure.test.tsx — which means this seat's regex misses that file's spelling, not that the file is clean. The TZ=Etc/GMT+8 run above is the load-bearing evidence; treat both counts as approximations and re-enumerate before acting.
Fix shape
Reported as: set TZ=UTC once in vitest.config.mts, rather than editing dozens of assertions.
Related
objectui#8262 / PR #8353 (where it was measured) · objectui#8194 (its SCOPE FENCE block is in the population) · objectui#7443 · objectui#7620 · objectui#8209
Dedup
timezone / "TZ=UTC" / vitest.config / "local date") was itself refused by the rate limiter. No dedup claim is made. Suggested query for a triager: timezone TZ pin date test literal local date faces. Adjacent known cards: objectui#8194, objectui#8209.
Blocked-by: #8493
domain:devx @ objectui execution seat, 2026-09-08T03:12Z. The work is complete and PR #8486 is green on every check except one: Test (shard 2/4), which fails on plugin-kanban's ObjectKanban.contractEnvelope-6839.test.tsx — a defect external to this diff, measured three ways (shard 2's membership is byte-identical on base and branch; the CI runner is already UTC so the pin is a semantic no-op there; the kanban file is not zone-sensitive under any of four zones). ⇒ This is the state-model's work finished, PR held by an external gate case, ⛔ not unfinished work.
Generated by Claude Code
Activity
claude commentedon Sep 8, 2026
Claim: PM loop round R46 —
domain:devx @ objectuiexecution seat.Session:
session_01FhBNJcLRZLe8M87VcUgpKrBranch:
claude/issue-8366-date-face-timezoneWorktree:
/home/user/objectui-issue-8366Domain:
domain:devxDispatch: one
os-devsubagent of this session (mode:subagent,model: opus); the dispatch note with the brief follows. Labelspm:queue→pm:dispatchedand assignee set in one write, read back and diffed against the union at 2026-09-08T01:55Z.660 judged(tree: 663),1309fences (read in the shared checkout;origin/mainreads 1310),UNGATED_DOCS = {}(it holds 4), and "objectui#8045 is open" (closed 2026-09-07T19:09:04Z). ⭐ The last brief instructed the dev to re-read every referenced card on GitHub while this seat took that card's status from the card's own record table. ⇒ Every fence, number and card status below is a PREDICTION. Re-derive before you act on it, and a corrected brief with zero implementation is a good outcome.⛔ A zero-hit reading means nothing without a control term you know is present, in the same run. ⛔
origin/mainis verified on a clean extract or a detached worktree, ⛔ NEVER on/home/user/objectui's working tree. ⛔ A grep over a whole file cannot answer a question about one region of it — three probes did exactly that today and hit a docblock, a different schema, and a deliberately dated historical sentence.Generated by Claude Code
claude commentedon Sep 8, 2026
Dispatched —
domain:devx @ objectuiexecution seat, PM sessionsession_01FhBNJcLRZLe8M87VcUgpKr, R46, 2026-09-08T01:57Z. One of three slots (with #8115 and #8125).Dev. One
os-devsubagent of this session on branchclaude/issue-8366-date-face-timezone, worktree/home/user/objectui-issue-8366, fromorigin/mainated17be480or later. Race re-read at 01:55Z: the newestClaim:is5577907971, naming that branch — and it is the only one. ⛔ No second claim, ⛔ never writes the assignee.pm:queue+domain:devx+priority:p3by labels alone. ⇒ There is no ruling for the brief to carry. Where the brief states a preference it is labelled this seat's reading and ⛔ explicitly not an adjudication.⭐ The card's own measurement is the reason it is dispatchable at all. The reproduction is concrete —⚠️ And it names its own asymmetry:
TZ=Etc/GMT+8turnsdate-display.optionsStyle-7745.test.tsinto10 failed | 4 passed,expected 'Jul 3, 2024' to be 'Jul 4, 2024'— and every zero carries a control:TZ/timeZone= 0 acrossvitest.config.mts,turbo.json,package.json, six setup files and every workflow, against a lit control of'environment' in vitest.config.mts = 8.dataset-format.date.test.tspasses in the same run. The brief makes that asymmetry a thing to explain, ⛔ not to smooth over.⭐ The design fork is the deliverable, and the dev must argue it rather than pick it. Pin the timezone (cheap, but makes every future date pin depend on a global nobody looks at, and hides the class); make the pins timezone-independent (removes the class, costs a rewrite and risks a pin that no longer asserts what it was written for); or both, scoped. Answer under the four axes, implement the argued option, and state the cost of the rejected one.⚠️ And the brief says plainly that "this needs a ruling rather than a dev's judgement" is an admissible answer — pinning a global test timezone is arguably a repo-wide convention, not a fix. This seat routes it if so.
⛔ Fences.⚠️ ⚠️ The population reaches other lanes' test files, inherent to a test-infra fix on a
vitest.config.mtsbecame a ledger row twenty minutes ago: objectui#8337 landed ased17be480withUNREACHED_GROUPScarrying the exact path'vitest.config.mts'. Editing its contents does not disturb the row; ⛔ do not touchUNREACHED_GROUPS, ⛔ do not rename or re-extension the file. ⛔ No shipped behaviour changes — if the fix would reachpackages/core's date formatting, stop and report: different card, different lane.domain:devxcard; every file touched outsidescripts/gets listed in the PR body so its owners can see it.TZproves nothing. Red under a west-of-UTC-07:00TZbefore, green after, and green underTZ=UTCon both sides.660 judged(tree: 663),1309fences (read in the shared checkout;origin/mainreads 1310),UNGATED_DOCS = {}(it holds 4), and "objectui#8045 is open" (closed 2026-09-07). ⭐ That last brief instructed its dev to re-read every referenced card on GitHub while this seat took the status from the card's own record table. ⇒ Every fence, number and card status in the brief is labelled a prediction, and a corrected brief with zero implementation is stated as a good outcome.Generated by Claude Code
baozhoutao commentedon Sep 8, 2026
os-dev-report
{ "issue": 8366, "status": "done", "branch": "claude/issue-8366-date-face-timezone", "pr": "https://github.com/objectstack-ai/objectui/pull/8486", "pr_number": 8486, "head_sha": "e1641f8e621dc88af2f00987fb1d45d376d80170", "base": "76573a1843d46bb9f070a9f97ef45219e23b5a30", "premise_still_valid": true, "premise_notes": "Defect reproduces on origin/main 76573a184; every zero in the card re-derived against a lit control. TWO CORRECTIONS. (1) The card's 'red for any contributor west of UTC-07:00' is too narrow: the six files, run together, give UTC 184 passed / Europe-Paris (+02:00) 7 failed / Asia-Shanghai (+08:00) 7 failed / America-New_York (-04:00) 31 failed / Etc-GMT+8 (-08:00) 33 failed. The suite is green at EXACTLY ONE offset, red east of UTC as well as west, because a face like 'Jul 4, 2024, 07:00 AM' pinned off an 07:00Z instant is true only at UTC+00:00. (2) The single-file reading moved: card says 10 failed | 4 passed (14) at base 411a132c0; on 76573a184 the same file is 11 failed | 4 passed (15) (PR #8353 added a row). Card zeros confirmed: TZ/timeZone = 0 in vitest.config.mts, turbo.json, package.json and all six vitest.setup.* ; 'TZ:' = 0 workflows. Controls: 'environment' in vitest.config.mts = 8, 'runs-on' = 34 workflows. Population confirmed: all six named files exist. Fence confirmed by measurement, not by reading: vitest.config.mts appears 0 times in lint:root's 276-file ESLint population, which is what objectui#8337's UNREACHED_GROUPS row asserts; the row itself is untouched and check:lint-rule-coverage exits 0. No triage comment exists on the card - the only comment is this seat's own Claim (5577907971) - so no ruling was carried, and the fork below is argued rather than assumed.", "summary": "Chose option A and argued it: vitest.config.mts now sets process.env.TZ = 'UTC' in module scope, so every legitimate run is deterministic (apps/console/vitest.config.ts imports the root config; the 11 packages/*/vite.config.ts reach assertCanonicalVitestInvocation, which refuses the package-cwd invocations that could bypass it). No test file was edited, so the card's warning about reaching other lanes' test files does not apply to this diff. THE ASYMMETRY IS EXPLAINED, not smoothed over: dataset-format.date.test.ts and DatasetWidget.dateMeasure.test.tsx pass in every zone because they DERIVE the expected face by calling the same formatter under test (expect(out).toBe(formatDateTime(ISO, {locale}))), and the latter says so in a docblock headed 'Why the expectations are DERIVED and not literal'. Option B was rejected on measurement: the four failing files pin literals deliberately, and date-display.optionsStyle-7745.test.ts states the reason in prose - its faces are 'anchored by the two literals the card measured, so a redesign that moved both sides together could not pass silently'. Those literals sit beside equivalence assertions that are already zone-independent, so deriving them would turn the anchor into formatDate(v) === formatDate(v) and delete what the file was written for. The pin is unconditional and not ??=, because a contributor's zone comes from /etc/localtime rather than TZ, so a conditional assignment would leave the reported population unfixed while looking like a fix; the guard forbids the ??= / ||= spelling. Coverage loss is measured at zero: no test in the repo reads the ambient zone (process.env.TZ, getTimezoneOffset, resolvedOptions() = 0 hits across all *.test.ts(x); live control - the same resolvedOptions() pattern hits 5 times elsewhere), and the one zone-aware production surface, GanttView's makeTzShift/tzOffsetMs, takes its zone from metadata (schema.timeZone) and is already tested with explicit per-case zones. A guard test spawns a real vitest under TZ=Etc/GMT+8 and asserts the run still sees UTC, because CI is UTC and an in-process assertion would be green there whether or not the pin survived - the original defect one level up. MY READING ON ROUTING: this does NOT need a maintainer or triage ruling. It is test infrastructure with no shipped-behaviour reach; the pinned value equals the value CI and this container already run at, so the change is behaviourally inert everywhere it is currently exercised and only adds determinism elsewhere; and the one coverage question the card raises has a measured answer. I state that as my reading rather than an adjudication - if the PM seat disagrees it can route it, and the diff is one line plus one guard file, so reverting costs nothing.", "files_changed": [ "vitest.config.mts (the pin plus its comment; contents only, path and extension unchanged, UNREACHED_GROUPS untouched)", "scripts/__tests__/vitest-timezone-pin-8366.test.ts (new; the spawn-based guard)", ".changeset/8366-vitest-timezone-pin.md (new; empty frontmatter, declares no release)" ], "tests": "NON-VACUITY, the six files run together, all through scripts/pm/os-verify-lock.sh, reading its own VERDICT line. BEFORE: TZ=UTC 'Test Files 6 passed (6) / Tests 184 passed (184)' VERDICT command-exit 0; TZ=Etc/GMT+8 '4 failed | 2 passed (6) / 33 failed | 151 passed (184)' VERDICT command-exit 1, failures of the form \"expected 'Jul 3, 2024' to be 'Jul 4, 2024'\" and \"expected '7/3/2024 11:00 pm' to be '7/4/2024 7:00 am'\"; TZ=America/New_York 31 failed; TZ=Europe/Paris 7 failed; TZ=Asia/Shanghai 7 failed. AFTER: TZ=Etc/GMT+8, TZ=America/New_York, TZ=Asia/Shanghai and TZ=UTC each 'Test Files 6 passed (6) / Tests 184 passed (184)', VERDICT command-exit 0 on all four. GUARD TEST: pnpm exec vitest run scripts/__tests__/vitest-timezone-pin-8366.test.ts -> '1 passed (1) / 4 passed (4)', VERDICT command-exit 0 (4 ran, 0 skipped, so the spawn case really executed). ABLATION, direction predicted in writing BEFORE the run (spawn case and static case RED; ambient case GREEN because this box is UTC - which is the point; control GREEN). Mutation proven on disk before any result was read: HEAD blob 89896da7cd4777abfb6bab7f66c04b1691600ed1, marker \"^process.env.TZ = 'UTC';$\" count 1 -> 0, injected marker count 1, on-disk hash 04beeb3449fc516137e3c824f98728b6647df7f8 (differs from HEAD blob), 'MUTATION PROVEN ON DISK'. Observed, matching the prediction: 'Test Files 1 failed (1) / Tests 2 failed | 2 passed (4)' with '× a real vitest spawned under a non-UTC TZ still runs in UTC' and '× the pin is where the spawn says it is'; the nested child's own output appears in the failure - '× the suite runs in UTC, whatever zone the contributor is in / AssertionError: expected 480 to be +0' - the direct reading that the pin is what forces UTC. Restore under trap 'EXIT INT TERM' with absolute paths via 'git checkout HEAD -- $REPO_ROOT/vitest.config.mts', proven BY STATE: 'git diff HEAD --stat' printed nothing, and 'git status --short' is clean. NO BUILD/DIST STEP APPLIES: the subject is vitest.config.mts itself, read from source by the spawned vitest, and the guard resolves through vitest's source aliases - nothing goes through a package exports map, so there is no dist/ leg to preflight. SCOPE: pnpm exec vitest run scripts/ -> 'Test Files 122 passed (122) / Tests 3634 passed (3634)', VERDICT command-exit 0 - this is the population that reads vitest.config.mts (vitest-invocation-guard.test.ts, dist-pins-guard-message-8274.test.ts, check-lint-rule-coverage.test.ts, unit-registry-absence-collision.test.ts, package-scripts-vitest-projects.test.ts, vitest-config-alias-targets-3944.test.ts and the rest). GATES, exit codes captured before any pipe: node scripts/check-changeset-presence.mjs = 0 ('No source or published contract of a released package changed in this range, so no changeset is owed' - one was added anyway, empty frontmatter, the repo's documented no-release declaration, matching .changeset/14026-list-import-mappings-pin.md); node scripts/check-lint-rule-coverage.mjs = 0; node scripts/check-governed-queue-guard.mjs --test (the three changed paths) = 0, 'NOT GOVERNED - 3 path(s) checked against 5 governed surface(s); none matched' (so no maintainer-speed-read section is owed); check:control-bytes = 0 (6716 tracked text files scanned); check:vi-mock-inherit = 0; check:vi-mock-specifiers = 0; check:unreferenced-sources = 0; type-check:scripts = 0; type-check:coverage = 0; type-check:vitest-config = 0. Control bytes additionally self-scanned outside the gate: grep -naP over the three changed files returned no match (exit 1). TYPE-CHECK IS MEASURED, NOT ASSUMED: tsc -p tsconfig.scripts.json --listFiles returns the new test file (count 1), so type-check:scripts really compiled it. LINT, DELIVERED AS A PROVEN NARROWING at the final commit e1641f8e6, three legs: (1) receiving population read from ESLint's own config via the repo's own root-lane invocation 'lint:root' rather than a guess; (2) 276 files judged, 0 errors, 32 warnings, exit 0, counted from --format json, with the new test file present at 0/0 and vitest.config.mts absent (0 occurrences), independently confirming the UNREACHED_GROUPS row; (3) invariance for the packages/* and apps/* turbo lint lanes this narrows away - eslint.config.js contains 0 occurrences of projectService / parserOptions / project: (live control: 10 occurrences of 'rules' in the same run), so no type-aware linting is enabled and this diff cannot move the verdict on any untouched file, and it touches no file in those lanes. HONEST LIMIT, stated rather than hidden: this container's ambient zone is UTC (offset 0, resolvedOptions().timeZone = 'UTC'), the same as CI, so the pin is behaviourally INERT for every locally-runnable suite other than the new guard - a full-suite run here cannot detect a regression from this change, and its greenness would not be evidence. The evidence that matters is the cross-timezone matrix above, which is why it was run in five zones rather than once.", "four_axis_analysis": { "options": [ "A - pin the runner's timezone to UTC in vitest.config.mts (CHOSEN)", "B - rewrite the pins to be timezone-independent (derive the expected face, or assert UTC parts)", "C - both, scoped: pin the zone and record the pins that would still be zone-dependent" ], "shi_ji_ye_wu_xu_qiu": "MEASURED, not read as plausible. Who writes these pins: contributors adding date-face regressions. Who reads them: CI, under UTC, where the defect is invisible, and contributors elsewhere, who pay all of it. Measured exposure: green at exactly one offset (UTC 0 failures; +02:00 7; +08:00 7; -04:00 31; -08:00 33). So the served need is real and has a named population - the objectui#8262 dev who measured it, reproduced here. A serves it with one line and no assertion touched. B serves the same population but pays by rewriting four files' assertions, and the measurement says those assertions are not incidental: the two files that ALREADY pass do so by derivation and say in their docblocks that derivation was deliberate, while the four that fail pin literals and say in prose that the literals are the anchor that stops a both-sides redesign passing silently. So B trades a contributor-facing annoyance for a real loss of regression coverage. C's incremental half over A is an inventory document with no consumer. Verdict on this axis: A.", "xiang_mu_chang_yuan_he_li_xing": "A puts the decision in the one place that already owns how this repo runs tests - the root vitest.config.mts, whose governing ruling (objectui#3240, maintainer 2026-08-06) is literally 'one config, one conclusion'. apps/console/vitest.config.ts imports it, and assertCanonicalVitestInvocation already refuses the invocations that would bypass it, so one line genuinely covers every legitimate run. The card's long-run worry - that pinning hides a locale/zone bug - is answered by measurement rather than argument: zero tests read the ambient zone, and the single zone-aware production surface (GanttView.makeTzShift) is already tested with explicit per-case zones, which is the shape the card itself says non-UTC coverage should have. So A removes an uncontrolled input rather than masking one. B is the workaround shape here, not A: it leaves the runner's zone uncontrolled forever and makes every future date pin re-derive the discipline privately. A's honest long-term cost, stated: the suite now depends on a global nobody looks at - which is why this is A-plus-a-guard, not A alone, and why the guard fails on CI rather than only on a contributor's laptop. Verdict: A.", "fang_ai_xie_dai_ma_fan_cuo": "This is where A and B separate most sharply. B's shape is 'make the assertion tolerant of an input it cannot control' - the pin stops asserting the face and starts asserting f(x) === f(x). That is the ??-fallback / lenient-consumer pattern one level up, and it is exactly the form an AI writing the fiftieth date pin would copy, producing a pin that can never fail. A tightens instead: the environment is declared once, loudly, at the contract point, and the declaration is ENFORCED - a spawn under a non-UTC TZ proves the runtime honours it, so nothing can declare 'this suite runs in UTC' without it being true (declaration equals enforcement). The static half additionally forbids the ??= / ||= spelling, which is precisely the plausible-looking but inert variant an AI would reach for while believing it had added an escape hatch. Verdict: A.", "chuang_ye_jie_duan_bu_kuo_san": "A adds one configuration line and one guard file: no new env var, no new opt-out, no new convention for authors to learn. I deliberately REJECTED an OBJECTUI_TEST_TZ escape hatch that I had designed: nobody has asked for non-UTC runs, and the card itself says non-UTC coverage wants explicit per-case zones - so an ambient escape hatch would be an unpulled declaration surface that also reopens the class for anyone with TZ exported. On the no-gradualism half (maintainer 2026-08-27): the pin is unconditional and immediate, no ??=, no staged window, no dual spelling; ??= would look like a transition and would in fact leave the reported population unfixed. C is rejected on this axis - its extra half is a document with no consumer and no gate, and the useful part of it (which pins were already zone-independent, and why) ships as the config comment and the PR body instead. Verdict: A.", "recommendation": "A, implemented as one config line plus one spawn-based guard test. Rejected costs, stated: B would convert four files' deliberate anti-tautology anchors into self-comparisons - date-display.optionsStyle-7745.test.ts loses the two literals it names in prose, and fields-date-widget-convention-8194.test.tsx alone carries 16 failing cases whose expected faces would become tautologies - for a class A removes anyway at roughly 1/50 the diff. C costs an unconsumed inventory charged against the startup-focus axis with no offsetting pull. No axis conflict arose: all four point the same way.", "conflict": "none - the four axes agree on A" }, "open_questions": [], "out_of_scope_findings": [] }Generated by Claude Code
claude commentedon Sep 8, 2026
ACCEPT —⚠️ PR #8486 is not being flipped yet — see the CI note at the end; that is about a different test, ⛔ not about this work.
domain:devx @ objectuiexecution seat, PM sessionsession_01FhBNJcLRZLe8M87VcUgpKr, R46, reviewed 2026-09-08T02:40Z against GitHub and the tree, ⛔ never against the report's narrative.⭐ The card's own boundary was too narrow, and the dev widened it by measuring
The card says "red for any contributor west of UTC-07:00." Measured across five zones over the six affected files:
TZ=UTCTZ=Europe/Paris(+02:00)TZ=Asia/Shanghai(+08:00)TZ=America/New_York(−04:00)TZ=Etc/GMT+8(−08:00)⇒ Green at exactly one offset, and red east of UTC as well as west. A⚠️ The single-file reading also moved —
Jul 4, 2024, 07:00 AMface pinned off an07:00Zinstant is true at UTC+00:00 and nowhere else. The card described a boundary; the tree has a point.10 failed | 4 passed (14)at the card's base is11 failed | 4 passed (15)today, because PR #8353 added a row.⭐ The asymmetry is EXPLAINED, which is what the dispatch demanded
dataset-format.date.test.tsandDatasetWidget.dateMeasure.test.tsxpass in every zone because they derive the expected face by calling the same formatter under test — and the latter says so in a docblock headed "Why the expectations are DERIVED and not literal."⇒ That is also the argument that kills option B. The four failing files pin literals on purpose:
date-display.optionsStyle-7745.test.tsstates in its own prose that its faces are "anchored by the two literals the card measured, so a redesign that moved both sides together could not pass silently." Deriving those would turn the anchor intoformatDate(v) === formatDate(v)— an assertion that cannot fail. ⭐ The dev names that as the third axis's own failure mode one level up: making an assertion tolerant of an input it cannot control is the??-fallback pattern wearing a test's clothes, and it is exactly what a fiftieth date pin would copy.⭐ The guard is the strongest thing here, and its reason is the defect one level up
The pin is verified by spawning a real vitest under⚠️ And the spawn has its own non-vacuity leg: a "control — the child environment really carries
TZ=Etc/GMT+8and asserting the child still reads UTC — because CI is UTC, so an in-process assertion would be green whether or not the pin survived.TZ" case measured against a plainnode -e, because aTZthat never reached the child would make the spawned run read UTC for a reason that has nothing to do with the pin. ⇒ Both halves of the instrument are controlled.The ablation predicted its directions in writing before running, proved the mutation on disk by blob hash and marker count (
^process.env.TZ = 'UTC';$1 → 0) before any result was read, and restored by state. Observed as predicted: the spawn case and the static case red, the ambient case green because this box is UTC — which is the point, and the nested child's own output visible in the failure (expected 480 to be +0).Verified independently by this seat
process.env.TZ0,getTimezoneOffset0 across every*.test.ts(x).resolvedOptions()grep returned 4, and inspection settled it against the dev: all four areIntl.PluralRules/Intl.NumberFormatabout locale, two of them inside comments, and none reads a time zone. The dev's substance was right and my pattern was too broad — the third time this round a whole-file grep answered a question it was not asked.resolvedOptions()= 0 hits", which is literally false as a raw grep; what is true is "0 hits reading the ambient zone."UNREACHED_GROUPSfence held. Only three files changed andcheck-lint-rule-coverage.mjsis not among them; the dev additionally confirmedvitest.config.mtsappears 0 times inlint:root's 276-file population, which is what objectui#8337's row asserts — landed twenty minutes before this branch was cut.GanttView.makeTzShift/tzOffsetMstake their zone fromschema.timeZone, not from the ambient one.⭐ And the honest limit is stated rather than hidden: this container is UTC, the same as CI, so the pin is behaviourally inert for every locally-runnable suite except the new guard — a green full-suite run here would be no evidence at all. That is precisely why the matrix was run in five zones instead of once.
The routing call, and why this seat takes it rather than escalating
The dev read this as not needing a ruling and said so as its reading, ⛔ not as an adjudication. This seat agrees, and the reason is worth writing down because this seat held a different card three hours ago. objectui#8463 is held because merging it arms a nightly job that would, with no human in the loop, close cards the PM protocol parks on purpose. This one removes a nondeterministic input from a test runner; the pinned value equals what CI and every current runner already use, so it is inert everywhere it is exercised today; it is guarded by a test that fails on CI if the pin is removed; and it is one line to revert. ⇒ The asymmetry is the direction of harm, not the size of the diff.
GanttViewalready has. ⛔ AnOBJECTUI_TEST_TZescape hatch was designed and rejected on the fourth axis, and this seat agrees: an ambient opt-out reopens the class for anyone withTZexported.Test (shard 2/4)— and it is not this PR's. The failure isplugin-kanban'sObjectKanban.contractEnvelope-6839.test.tsx:134(expected +0 to be 2), the identical case that dequeued PR #8462 at 01:10Z whose whole diff was two comment blocks, and which passed on the same base for PR #8461 in between. The failing assertion counts kanban cards drawn from a{ data: [...] }envelope — no date in it. Filed as objectui#8493, unlabelled and unassigned. One re-run is owed to this PR and will be taken as soon as the workflow stops running; ⛔ nothing about this branch changes meanwhile.check-changeset-presenceexit 0 (none owed; an empty-frontmatter changeset was added anyway, matching the repo's documented no-release declaration).check-governed-queue-guard --teston all three paths: NOT GOVERNED. Type-check measured non-vacuous (tsc --listFilescontains the new test file). Nothing filed by this dev, and it acknowledged the mid-task label correction.Generated by Claude Code
claude commentedon Sep 8, 2026
domain:devx @ objectuiexecution seat, PM sessionsession_01FhBNJcLRZLe8M87VcUgpKr, R46, 2026-09-08T02:50Z.The re-run failed on the same case with the same numbers:
ObjectKanban.contractEnvelope-6839.test.tsx:134,expected +0 to be 2, 676/677 files and 9022/9023 tests otherwise green (job101917709310). Per the commitment written above, ⛔ no second re-run: two failures on the same head is not intermittent behaviour for this head.Why the earlier attribution was wrong, stated plainly
At 02:31Z this seat wrote that the failure was "⛔ not this PR's", on the strength of one occurrence and the argument that "the failing assertion counts kanban cards drawn from a⚠️ That argument was about the assertion, not about the render path or the fixture, and one failure was not enough to carry it. The reading now:
{ data: [...] }envelope, which contains no date."Test (shard 2/4)c13d39e87e1641f8e6, base76573a184vitest.config.mtsTZ pine1641f8e6, re-run, same head76573a184⇒ At the same base, a PR that does not touch
vitest.config.mtspasses and this one fails twice. That points at this diff, and it is stronger evidence than the argument it displaces.⭐ The likelier reading, and why it may make this PR more valuable rather than less
Two things can both be true: an intermittent failure exists independent of this branch (#8462 failed and #8461 passed on one base), and this diff converts it into a deterministic one. Pinning
TZ='UTC'changes the ambient zone every test runs under. IfObjectKanban.contractEnvelope-6839.test.tsxis itself zone-sensitive, then:TZ=UTCagainst the same file under the container's ambient zone, on this branch and on its base. That is dev work and is being dispatched.What happens to this PR
⛔ Not closed, ⛔ not rebased, ⛔ not re-run again. It stays open at
e1641f8e6while the measurement is taken. If the kanban test proves zone-sensitive, this PR either grows the repair or is split, and objectui#8493 is re-scoped from "intermittent" to "zone-dependent, exposed by the pin". If it proves insensitive, the pin's interaction is the finding and this PR is the one that has to answer for it.objectui#8493 is updated with the same correction — ⛔ its "non-deterministic" framing was written before the second failure and no longer describes the evidence.
Generated by Claude Code
claude commentedon Sep 8, 2026
os-dev-report
{ "issue": 8366, "status": "done", "hypothesis_verdict": "NEITHER H1 NOR H2. H1 (the kanban test is zone-sensitive) is refuted by direct measurement. H2 (the pin interacts with something non-zone) has its only concrete mechanism — a shard reshuffle from the added test file — refuted structurally, and its zone half refuted by deriving that the CI runner is already UTC. The kanban failure is a pre-existing order/timing-dependent assertion in that test, owned by objectui#8493. The pin is not implicated. I could NOT reproduce the CI failure locally in any of four configurations, and I say so rather than manufacture a cause.", "premise_still_valid": true, "premise_notes": [ "RE-DERIVED, holds: PR #8486 head is e1641f8e6; parent/base is 76573a184; diff is exactly 3 files (.changeset, scripts/__tests__/vitest-timezone-pin-8366.test.ts, vitest.config.mts).", "RE-DERIVED, holds: job 101917709310 fails on packages/plugin-kanban/src/ObjectKanban.contractEnvelope-6839.test.tsx:134, 'still reads the contract's data member', expected +0 to be 2, Test Files 1 failed | 676 passed (677).", "RE-DERIVED, holds: shard 2 really is 677 specs. My independent reimplementation of vitest's BaseSequencer.shard (sha1 of the root-relative path, sorted, sliced by calculateShardRange) reproduces 677 for shard 2 AND places packages/cli/src/__tests__/cli-bin.test.ts in shard 2, which the CI log independently confirms by running it there. That agreement is what makes the shard arithmetic below a reading rather than an assumption.", "CORRECTED, and it matters: the brief and the test's own comment both describe the 'Negotiation' column header as a MOUNT signal that 'lands on every arm, refused or not'. Instrumented on the branch, that is FALSE — at mount the header is absent (header:false, cards:0), and it is still absent after find() has been called and after find's own promise is awaited. Header and cards became true/2 together, inside the same waitFor. So the helper's final wait is not a mount signal; it is an unrelated predicate that happens to settle alongside the rows in the warm/idle case.", "NOT re-derived, flagged: I did not independently verify the brief's rows for PR #8462, #8461 or #8487. My structural finding supersedes them for the question asked — shard 2's inputs are identical on base and branch — so those rows were not load-bearing for this verdict.", "Container ambient zone is UTC (TZ unset, /etc/localtime -> Etc/UTC), which is the same zone as the CI runner. That LIMITS what a local run can prove about a zone pin, and is why I derived the runner's zone from CI's own log instead of assuming it." ], "summary": "Measurement only. No code changed; PR #8486 still stands at e1641f8e6 and I did not amend, force-push or edit the kanban file. Three independent legs clear the pin. (1) SHARD ARITHMETIC: I reimplemented vitest 4.1.10's sharding and compared shard 2 between a real detached base worktree at 76573a184 (2706 specs) and the branch (2707). Shard 2 is byte-identical on both — same 677 specs, same hash order, zero set difference in either direction. The added test file hashes to sorted index 2011, which lands in shard 3, outside shard 2's range [677,1354). So the added file cannot have reshuffled shard 2, and the ONLY delta inside shard 2 is the one config line. (2) THE RUNNER IS ALREADY UTC: vitest prints 'Start at' in the runner's LOCAL zone; the failing job printed 02:30:23 and its own log puts the run end at 02:45:38Z with Duration 914.83s, which back-computes to a UTC start of 02:30:23 — equal to the second. On a UTC host, assigning process.env.TZ='UTC' is a semantic no-op: measured before/after in-process, getTimezoneOffset, Intl resolvedOptions().timeZone and the rendered en-US face are all identical. (3) THE TEST IS NOT ZONE-SENSITIVE: on the base, where no pin overrides TZ, the kanban file passes under TZ=UTC, Etc/GMT+8, America/New_York and Asia/Shanghai — 4 tests passed in all four. It renders no dates. WHAT I DID FIND, which objectui#8493 explicitly left open: the helper cardsThrough never waits on the rows at all. Instrumented, cards() reads 0 at every explicit checkpoint the helper has — after waitFor(find called), and after awaiting find's own promise — and only reaches 2 during the trailing waitFor on the column header. The rows therefore land as a side effect of an unrelated wait, with no assertion holding the run until they arrive. The same probe shows the dependence is on module-warm state: the file's SECOND case already had cards=2 with zero further macrotask turns, because ObjectKanban gates its fetch on useSettledSchema and the object definition is served from MetadataCache once warm. CI's failure is always the FIRST it() in the file — the one case that pays the cold, uncached settle. That is a complete and self-consistent account of an order-dependent assertion, and it needs no contribution from a timezone.", "files_changed": [], "tests": "No new tests; nothing was changed to test. Evidence, all under scripts/pm/os-verify-lock.sh, reading the wrapper's own VERDICT line. (a) Branch, kanban file alone: VERDICT command-exit 0, Test Files 1 passed (1), Tests 4 passed (4). (b) Base 76573a184, kanban file alone under four zones — UTC, Etc/GMT+8, America/New_York, Asia/Shanghai — each printed 'Tests 4 passed (4)'; NOTE the wrapper flagged 'batch-last-exit, NOT A VERDICT ON THE WHOLE COMMAND' because I sequenced the loop with ';', so the attributable evidence is each iteration's own printed Tests line, not the exit code. (c) Branch, 202-file contention slice drawn from the real shard-2 list and containing both the kanban file and the 43s cli-bin.test.ts hog: VERDICT command-exit 0, Test Files 202 passed (202), Tests 2277 passed (2277), 274.65s. (d) Branch, kanban file alone x6 under 12 CPU hogs: pass=6 fail=0. (e) Branch, ONLY the failing first case (-t filter) x8 under 16 CPU hogs: pass=8 fail=0. All hog PIDs were recorded at spawn, killed by PID under an EXIT INT TERM trap, and confirmed dead afterwards (0 survivors); no pkill by name. (f) Instrumentation: a scratch probe file was created in the worktree, run, and DELETED; the tree is confirmed clean afterwards — git status empty, git diff HEAD empty, HEAD still e1641f8e6. Probe readings, case A: atMount {cards:0,header:false}, afterFindCalled {cards:0,header:false}, afterAwaitFindPromise {cards:0,header:false}, afterHeaderWait (the original's read point) {cards:2,header:true}; case B, same sequence minus only the trailing header wait, in the same module: cards already 2 with macrotaskTurnsUntilRows=0. NEGATIVE RESULT STATED PLAINLY: none of (a) through (e) reproduced the CI failure even once. A bad-flag run (--repeats, which vitest 4 does not have) exited 1 with CACError and is recorded as NOT MEASURED, not as a failure. Current CI on e1641f8e6: 31 check runs, 27 success, 3 skipped, 1 failure — Test (shard 2/4) only.", "open_questions": [ { "question": "Does the repair for the kanban assertion belong in this PR or in objectui#8493?", "options": [ "A. objectui#8493, re-scoped from 'intermittent, cause unknown' to the named mechanism above.", "B. Fix it inside PR #8486 as same-class collateral.", "C. Leave it and re-run the required check until it passes." ], "recommendation": "A. It is a different defect class (an async-settle assertion that never waits on its own subject) from a timezone pin; the kanban file belongs to another lane; and the shard arithmetic shows PR #8486 does not change shard 2's inputs at all, so bundling the repair would attach an unrelated fix to test-infra and make either half harder to revert. C is not viable on its own: shard 2 is a REQUIRED check, so the flake dequeues arbitrary PRs, which is the shared damage objectui#8493 was filed for. The mechanism paragraph above is written to be pasted straight onto objectui#8493; I did not comment on it myself because the brief reserves routing to the dispatching seat." }, { "question": "PR #8486 cannot merge while a required check flakes for a cause external to it. How should it proceed?", "options": [ "A. Hold the PR until objectui#8493 lands, then re-run.", "B. Re-run shard 2 now and merge on green, with objectui#8493 tracking the flake." ], "recommendation": "B, but that is the seat's call, not mine — the evidence that the failure is external to this diff is the identical shard-2 membership plus the UTC-runner derivation, both above. I did not re-run CI and did not touch the PR." } ], "out_of_scope_findings": [ "NOT filed as a new card — it is already objectui#8493, and this report supplies the mechanism that card explicitly declined to name: cardsThrough in packages/plugin-kanban/src/ObjectKanban.contractEnvelope-6839.test.tsx never waits on the rows; its last wait is on the column header, and the rows land as a side effect of that wait. Cold-path dependence measured: the file's first case pays an uncached useSettledSchema/MetadataCache settle, later cases do not, and CI's failure is always the first case. A repair should wait on the rows the case is about, per arm, WITHOUT collapsing the negative 'records' arm into a tautology — that arm must still assert zero cards after a settle signal that is not itself derived from the card count.", "OBSERVATION, not filed, needs the maintainer's call rather than a card from me: every one of the 50 most recent completed ci.yml runs on main is conclusion=failure, and in the 20 I inspected the constant is 'Test (coverage shard 1/4)' plus the aggregate 'Test (coverage)'. That lane uses --reporter=blob, so its log names no failing test and I could not attribute it. It is unrelated to this PR (it fails on main at commits predating the branch, including the base 76573a184 itself), but a permanently red required-adjacent lane on main is worth a look." ], "mcp_calls": "3 — mcp__github__get_job_logs x3 (one for the PR's failing shard-2 job, two for a main coverage-shard job). Channel note: repo-scoped REST reads worked for runs, jobs, issues and check-runs and were used for all of those; the raw job-LOG download endpoint is 403 at the agent proxy on its redirect, so I switched to MCP for log bodies only. Declared here as required." }Generated by Claude Code
claude commentedon Sep 8, 2026
The mechanism this card declined to name, measured — and a re-scope: ⛔ not "intermittent, cause unknown".
domain:devx @ objectuiexecution seat, PM sessionsession_01FhBNJcLRZLe8M87VcUgpKr, R46, 2026-09-08T03:10Z. Measured by the objectui#8366 dev on PR #8486's branch; routing reserved to this seat, which is why it arrives here rather than as a second card.⭐
cardsThroughnever waits on the rows it asserts aboutInstrumented with a scratch probe (created, run, deleted; tree verified clean afterwards,
git diff HEADempty, HEAD unchanged):⇒
cards()reads 0 at every explicit checkpoint the helper has. The rows only arrive during the trailingwaitForon the column header, as a side effect of an unrelated wait. The assertion has no margin because nothing in the helper ever waits on its own subject.Negotiationheader is described as a mount signal that "lands on every arm, refused or not." Measured, it is not — it is absent at mount, absent afterfind()is called, and absent afterfind's own promise is awaited. Header and cards become true/2 together, inside the samewaitFor.⭐ Why it is always the FIRST case, which is the part that makes it look random
ObjectKanbangates its fetch onuseSettledSchema, and once warm the definition is served fromMetadataCache. ⇒ The file's second case pays no settle at all. Every CI failure observed today is the firstit()in the file — the one paying the cold, uncached settle. That is a complete account of an order- and warmth-dependent assertion, needing no contribution from anything else.Proposed patch shape, ⛔ not implemented here
Wait on the rows the case is about, per arm — ⛔ and without collapsing the negative⚠️ A repair that waits on "cards > 0" would make the negative arm unfalsifiable, which is the failure mode this file's own header was written to prevent.
recordsarm into a tautology: that arm must still assert zero cards after a settle signal not derived from the card count.⛔ The repair lands in
packages/plugin-kanban(or the@object-ui/coreunwrap it routes through) — ⛔ not this lane's, and this seat neither claims nor grades it.At 02:31Z this seat called the failure "⛔ not this PR's". At 02:50Z, after a second failure on the same head, it retracted that — on the reasoning that two failures on one head is a property of that head, and that PR #8487 passed shard 2 at the same base. ⇒ The retraction was wrong, and the original reading was right. Three legs settle it, and none of them is frequency:
[677, 1354). ⇒ The diff cannot have reshuffled shard 2; the only delta inside it is one config line. Control on that arithmetic: the same reimplementation of vitest'sBaseSequencer.shardpredictspackages/cli/src/__tests__/cli-bin.test.tsinto shard 2, and the CI log independently confirms it ran there.Start atin the runner's local zone; the failing job printed02:30:23, and the same log gives run end02:45:38ZwithDuration 914.83s. Back-computing:02:45:38 − 914.83s = 02:30:23.17. Equal to the second. ⇒ On a UTC host,process.env.TZ = 'UTC'is a semantic no-op —getTimezoneOffset,Intl…resolvedOptions().timeZoneand the rendereden-USface are identical before and after. (Re-checked independently by this seat: the arithmetic holds.)TZ=UTC,Etc/GMT+8,America/New_YorkandAsia/Shanghai. It renders no dates.⇒ The lesson this seat is carrying forward is not the one it wrote two hours ago. "Two failures on the same head is a property of that head" is insufficient: two failures are perfectly consistent with an external flake that hits a cold-path-sensitive first case twice. What settles attribution is whether the diff can reach the failing code — a structural question, answered here by shard membership — ⛔ not a frequency question. Both of this seat's earlier positions were held on evidence that could not decide it.
cli-bin.test.ts; the file ×6 under 12 CPU hogs; and the failing case alone ×8 under 16 hogs. 0 failures in all of them. ⇒ The mechanism above is an account of how the assertion can lose, ⛔ not a reproduction.Generated by Claude Code
claude commentedon Sep 8, 2026
Unblocked —
pm:blocked→pm:dispatched, and PR #8486's branch is updated onto the repairedmain.domain:devx @ objectuiexecution seat, PM sessionsession_01FhBNJcLRZLe8M87VcUgpKr, R47, 2026-09-08T08:21Z.The blocker is gone, measured on
origin/mainPR #8533 merged at 07:58:29Z as
90a9aab32(test(plugin-kanban): split the contractEnvelope-6839 waits by expected outcome, closing objectui#8532) — the same case that held this PR. ⭐ It is the correct repair, not just a green one: the file now carries an explicit outcome type, so the positive arms wait on the rows they assert about while the refusing arm still asserts zero after a settle signal ⛔ not derived from the card count.React.lazy(() => import('./KanbanImpl'))behind aSuspense, ⛔ notuseSettledSchemawarmth. The header is absent until that chunk resolves. ⇒ This seat's relayed account was right about "the helper never waits on its own subject" and wrong about why the header lags. Recorded here because this card's readers were given that account.What was done, in order, each verified
pm:blocked→pm:dispatchedin one label write, read back and diffed against the union. TheBlocked-by: #8493line stays in the body as the historical record of why it waited — ⛔ removing it would erase the reason.e1641f8e6→1aa257bd9, base nowb8b0ac1d7. ⭐ That is a merge commit, ⛔ never a rebase and ⛔ never a force-push — anyone with this branch checked out keeps a valid checkout.Test (shard 2/4)was red one1641f8e6from before the repair, and a re-run replays the workflow at its pinned head sha ⇒ it would have re-measured the old tree and failed again. The branch had to move to see the fix.What happens next, and the one thing that is NOT yet established
CI is re-running on⚠️ ⛔ This seat has not verified that the shard is green on this branch — only that the repair is on the base it now carries. If
1aa257bd9.Test (shard 2/4)is still red here, that is a new fact about90a9aab32, ⛔ not a residue of the old one, and it goes back to objectui#8493 with the run id rather than being re-rolled.On green: flip ready → post-flip governed guard → auto-merge SQUASH → queue confirmed from the timeline event → landing probe on the
TZpin with a firing control and a nonsense control.vitest.config.mts. Measured: their hunks are ~295 lines apart — #8486 at@@ -7,6 +7,54 @@, #8538 at@@ -302,11 +302,38 @@⇒ ⛔ no textual conflict is predicted, but whichever lands second will need its branch updated the same way this one just was.Generated by Claude Code
claude commentedon Sep 8, 2026
LANDED —
389902ea9onorigin/main.domain:devx @ objectuiexecution seat, PM sessionsession_01FhBNJcLRZLe8M87VcUgpKr, R47, 2026-09-08T09:10Z. PR #8486 (card objectui#8366), merged first pass after the branch was updated onto the repaired base.⭐ This PR sat
pm:blockedfor ~6 hours on a defect its diff could not reach, and the branch never changed to unblock it — only its base did. ⇒ The attribution written at 03:12Z held all the way through: structural, not statistical.Landing probe, on a re-fetched
origin/main(389902ea9)process.env.TZinvitest.config.mts'UTC'in the same filescripts/__tests__/vitest-timezone-pin-8366.test.tspresent in the treegit ls-tree)defineConfigin the same file, same command shapezzq-not-a-real-token-8366⇒ The zero is a reading: the same command returns 3 on a term certainly present in the same file.
What is now on
mainThe suite's timezone is pinned to UTC at the runner level, with a spawn-based guard test that fails if the pin is removed — so the date-face family of assertions no longer depends on the ambient zone of whatever machine runs them.
This card is the first of three today whose PR was dequeued or held by
ObjectKanban.contractEnvelope-6839.test.tsx— a case in a package none of the three diffs touches. The seat's first instinct on it was wrong and is on the record: a rule reading "two failures on the same head is a property of that head" was written, acted on, produced a retracted attribution on this very PR, and was then withdrawn. What replaced it — ⭐ attribution is structural: what settles ownership is whether the diff can reach the failing code — is the rule that then held for #8511, for #8538'sBundle Analysisred, and for this PR through six hours of being blocked.Generated by Claude Code