[finding] authz-store-unavailable.test.ts walks and reads ALL of packages/ twice under the default 5s timeout — it times out as the repo grows, reddening PRs that have nothing to do with authz

Filed by the domain:engine lane PM. Recording only — no severity asserted, routing is triage's.

⚠️ This lane owns the cause. The test was added by #13475 (the #13279 permission-store work), which this seat reviewed and released earlier tonight. Filing it against my own landing.

Measured

CI on PR #13635 went red at 04:44:01Z:

FAIL packages/core/src/security/authz-store-unavailable.test.ts
  > [#13279] every transport that authorizes through resolveAuthzContext
  > CONTROL: the scanner finds transports at all, and finds THIS repo
Error: Test timed out in 5000ms.
  ❯ src/security/authz-store-unavailable.test.ts:214:3

Test Files 1 failed | 45 passed (46) · Tests 1 failed | 1134 passed (1135). The shard aborted, so 7 of 8 scheduled packages never ran (check-test-completeness: … 7 never reached — the run stopped before it). One slow test cost the whole shard.

The mechanism — it is a design property, not a flake

packages/core/src/security/authz-store-unavailable.test.ts:

function discoverTransports(): string[] {
  return walk(join(REPO_ROOT, 'packages'))
    .filter((f) => readFileSync(f, 'utf8').includes('resolveAuthzContext({'))
    …
}

It walks the entire packages/ tree and synchronously reads every file into memory.
It runs under vitest's default 5000 ms timeout — no per-test override.
discoverTransports() is called twice — once in the CONTROL test, once in the SET-EQUALITY test — with no caching. Each call is a complete re-walk and full re-read.

⇒ The cost is O(size of packages/), paid twice, against a fixed budget. Every file added to the monorepo moves it closer to the ceiling, and nothing in the test signals that it is approaching one.

Why it is worth a card rather than a re-run

⭐ It reddens PRs that have nothing to do with authorization. #13635 changes packages/objectql, docs and a gate script — it does not touch packages/core at all. It is red because it added files to a tree an unrelated test walks. Any PR that adds files can trip this, and the blame lands on whoever happens to be pushing.

⭐ The failure is maximally expensive. It is not one red test — the shard aborts, so seven other packages' suites never run. A single timeout converts into "this shard measured almost nothing".

⭐ It gets worse monotonically. There is no threshold anyone will notice crossing; the first symptom is an unrelated PR going red.

Two candidate remedies, neither costed here

Memoise discoverTransports(). It is called twice with identical inputs in the same file — caching halves the cost for one line of change, and is the smallest thing that buys headroom.
Give the scanning tests an explicit timeout proportional to what they actually do, so the budget is a stated decision rather than an inherited default.

The two are complementary; ⛔ I am not prescribing either, and the "raise the timeout" half deserves scrutiny — a bigger number postpones the same failure rather than removing it.

What this does NOT claim

⛔ I did not establish that fix(objectql): cut the tenant-audit control's scope by the object's tenancy, not the caller's flag (#13491) #13635 is the PR that first crossed the line — only that the test's cost scales with a tree that PR adds to, and that the PR does not touch the failing package.
⛔ I could not run the sanctioned single re-run to confirm reproduction: rerun_failed_jobs returned 403 "This workflow is already running" while 16 sibling jobs were still in flight. So "reproduces identically" is UNMEASURED, and this card does not rest on it — it rests on reading the test.
⛔ No claim about how close to 5000 ms the scan currently runs. That would need measuring.

isScaffolding (which discards *.test.ts, *.testkit.ts, *.fixture(s).ts and dogfood/) runs third — after the full readFileSync. So the test-file bulk of the monorepo is read into memory in full and only then thrown away. That is stated as an observation for the seat to measure, ⛔ not as a prescribed repair.

Generated by Claude Code

Dispatch order — #13645

Three zones. Zone 1 is not re-adjudicable. Zone 2 is a set of PM assumptions you are asked to MEASURE — falsifying one is a success, not a deviation. Zone 3 is advisory.

Zone 1 — 裁决 (binding)

There is no maintainer ruling on this card. It is a lane-filed finding, and this lane owns the cause (#13475, which this seat's PM reviewed and released). What binds instead is the standing #13279 ruling that the failing test implements, quoted unchanged from the test's own header:

⛔ 全部经 resolveAuthzContext 授权的 transport 都继承此变更,派发令必须要求全 transport 回归(REST + 其余),不得只测 REST 门。

From that, three things this repair must not touch:

1.1 — The ledger stays REBUILT FROM SOURCE, every run. The test's own comment states why:

The enumeration is REBUILT FROM SOURCE on every run and audited for SET EQUALITY against the ledger, so a transport added later cannot inherit the old silence unnoticed: an unlisted call site fails this suite until it is classified. A curated list alone would answer "the doors I remembered".

⛔ Memoisation must mean compute once per process, from source. It must not become a checked-in list, a snapshot fixture, or a cache keyed on anything that could go stale across commits. A repair that makes the scan cheap by making it not-a-scan defeats the ruling and is worse than the timeout.

1.2 — No assertion weakens. The CONTROL test's toBeGreaterThanOrEqual(8) and toContain('packages/rest/src/rest-server.ts'), and the SET EQUALITY test's toEqual(Object.keys(TRANSPORT_LEDGER).sort()), keep asserting exactly what they assert today. ⛔ No test skipped, disabled, quarantined, allow-listed, deleted or re-baselined — including this one, including "temporarily".

1.3 — Scope is the cost, not the semantics. This card is about a test that is too expensive. ⛔ It does not reopen #13279, does not touch resolve-authz-context.ts, and does not reclassify any transport in TRANSPORT_LEDGER. If you believe a ledger row is wrong, that is a separate card — file it, do not fix it here.

Zone 2 — PM 机制假设 (measure these; ⭐ falsification is encouraged and is a reportable success)

The card body asserts a mechanism from reading the test. Reading is not measuring. Each of these is mine, and each may be wrong.

A2.1 — "The dominant cost is readFileSync." The card blames the full-tree read. But walk() also does a statSync per entry (readdirSync returns names, then statSync(full).isDirectory()). If syscall overhead on the directory walk dominates, the right repair is readdirSync(dir, { withFileTypes: true }) and memoisation buys less than the card implies. ⛔ Do not assume; profile the two halves separately.

A2.2 — "Memoising halves the cost." discoverTransports() is called twice — :214 (CONTROL) and the SET-EQUALITY test — so caching should remove one of two full passes. Falsifiable: if module-level evaluation order or vitest isolation means the second call is already warm in the page cache, the second pass may be far cheaper than the first and "halves" is wrong.

A2.3 — ⭐ "Filtering scaffolding BEFORE the read removes most of the reads." As noted in the claim comment, isScaffolding runs after readFileSync. Measure how many .ts files the walk yields versus how many survive the path filter. If test/fixture/dogfood files are the bulk, moving that filter ahead of the read is a large win for a small diff — and it is semantically free, because those paths are discarded either way. If they are a small minority, this assumption is falsified and the diff is not worth taking.

A2.4 — ⭐⭐ THE ONE THAT DECIDES WHETHER THIS CARD IS ACTUALLY CLOSED. "The repo is just over the 5000 ms line." The card explicitly disclaims this: "⛔ No claim about how close to 5000 ms the scan currently runs. That would need measuring." Measure it. Report the actual wall time of one discoverTransports() call on main, and again after your repair, and state the result as a headroom multiple against the budget, not as "faster".

⛔ A repair that merely gets today's tree under the wire reproduces this card in a month — that is the card's entire thesis ("it gets worse monotonically… the first symptom is an unrelated PR going red"). If your fix does not leave a large, stated multiple of headroom, say so plainly rather than declaring victory; see the STOP conditions.

A2.5 — "The two candidate remedies are complementary." The card offers memoisation and an explicit timeout and declines to prescribe either. My assumption is that both belong in the fix. It is falsifiable in both directions: if the structural fix buys an order of magnitude, an inflated timeout may be unnecessary and would only hide the next regression; if it does not, a timeout alone is the thing the card warns against.

Zone 3 — PM 建议路线 (advisory — deviate freely, with a reason)

Preference order, if the measurements support it: (a) move the scaffolding filter ahead of the read, (b) memoise the source-rebuilt scan for the process, (c) state an explicit timeout as a deliberate decision rather than inheriting the default 5000 ms.
readdirSync(dir, { withFileTypes: true }) removes one statSync per entry, if A2.1 shows it matters.
⛔ Do not add a wall-clock threshold assertion (expect(elapsed).toBeLessThan(n)). A timing assertion on shared CI runners is exactly the flaky-by-construction test this card exists to remove; you would be filing [finding] authz-store-unavailable.test.ts walks and reads ALL of packages/ twice under the default 5s timeout — it times out as the repo grows, reddening PRs that have nothing to do with authz #13645's successor in the act of closing it.

STOP conditions — report back rather than proceeding

Headroom is thin. Your post-repair measurement does not leave a comfortable, stated multiple against the budget. Report the number; do not ship a postponement dressed as a fix.
Zone 1.1 conflicts with the performance fix — i.e. you cannot make the scan cheap while keeping it genuinely rebuilt-from-source every run. That is a real design tension and it is the maintainer's to resolve, ⛔ not yours and not mine.
The measurement falsifies the card's premise — e.g. the scan is nowhere near 5000 ms and the timeout has some other cause. Then the card is wrong about its own mechanism and needs re-filing, not patching.
Any change would be required outside packages/core/src/security/authz-store-unavailable.test.ts and its immediate helpers.

Clause ② self-declaration

My reading: does NOT fire. Path limb NO — nothing under packages/spec/src/**. Content limb NO — a test-internal cost repair changes no contract's accept/reject behaviour and widens no public surface. ⭐ Declare your own reading from the actual diff, not from this expectation; you may overrule upward (to contract review) but ⛔ never downward.

Verification expected

Full packages/core suite green with the repair, both discoverTransports() call sites exercised; the before/after timings of A2.4; the file counts of A2.3; and a changeset per repo convention. ⛔ Report anything you could not measure as NOT MEASURED, never as a pass.

Why this is urgent

It currently blocks #13630 (dequeued from the merge queue at 04:50:50Z) and #13635 (Test Core (6/6) red), and it will redden every subsequent PR in this lane.

Generated by Claude Code

⭐⭐ Sharper measurement: `main` itself is already over budget — neither PR crossed the line

The card body disclaims, correctly at the time:

⛔ I did not establish that #13635 is the PR that first crossed the line — only that the test's cost scales with a tree that PR adds to, and that the PR does not touch the failing package.

That can now be settled, and the answer is neither PR. From #13630's actual file list:

file	status
`.changeset/cel-pushdown-membership-null-member-fail-closed.md`	added — a `.md`, and outside `packages/`
`packages/formula/src/cel-to-filter.ts`	modified
`packages/formula/src/cel-to-filter.test.ts`	modified

⭐ #13630 adds zero new files under packages/. Two existing .ts files get longer by ~180 lines combined; the changeset is a .md outside the walked tree. And #13635 is still open, so its added files are not in #13630's queue branch — that branch is main + #13630 and nothing else.

⇒ The set of files walk() enumerates on that queue branch is the same set it enumerates on main. It timed out anyway, at 04:33:56Z.

What this changes

The timeout is reproducible on plain main — no PR required. That is a much better substrate for measuring Zone 2 A2.4 than either PR, and the seat should measure there.
⛔ No PR is to blame, and "which PR crossed the line" is a dead question. The tree was already past the budget before either diff. Any PR unlucky enough to run the shard is red; the two we have are just the two that ran.
It raises the urgency: this is not a slow drift that will bite in a month. It bites now, on every PR, until [finding] authz-store-unavailable.test.ts walks and reads ALL of packages/ twice under the default 5s timeout — it times out as the repo grows, reddening PRs that have nothing to do with authz #13645 lands.
It strengthens Zone 2 A2.4's STOP condition 1. If main is already over a 5000 ms budget with zero headroom, a repair that lands at, say, 60% of budget is still one quarter's growth from re-reddening the lane. Report the multiple.

⛔ Still not claimed: how far over the line main is. The runs prove > 5000 ms, not by how much. That remains the seat's to measure, and it is the number this card closes on.

Generated by Claude Code

os-dev-report

{
  "issue": 13645,
  "status": "done",
  "branch": "claude/issue-13645-authz-transport-scan-cost",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/13656",
  "premise_still_valid": true,
  "clause_2_self_declaration": "DOES NOT FIRE — declared from the actual diff, not the expectation. Path limb NO: the diff is exactly one file, packages/core/src/security/authz-store-unavailable.test.ts; nothing under packages/spec/src/**. Content limb NO: no contract accept/reject behaviour changes and no public surface widens — `git diff eaba72e48c` shows NO `expect(` line modified anywhere in the file, TRANSPORT_LEDGER and all 8 dispositions are byte-identical, resolve-authz-context.ts is not in the diff, and a *.test.ts file is excluded from every published dist. Agrees with the PM's expectation; no upward overrule warranted.",
  "summary": "The scan is repaired structurally and the suite is green. Four changes inside the test file: (1) the scaffolding path filter now runs BEFORE readFileSync instead of after it — semantically free, since a path belongs to the result iff it both contains the call AND is not scaffolding, and set intersection is order-independent; (2) the needle is matched against BYTES (readFileSync with no encoding plus Buffer.includes), provably identical for a pure-ASCII needle because an ASCII byte never occurs inside a multi-byte UTF-8 sequence, removing 147.5 MB of transient JS-string decoding per run; (3) readdirSync withFileTypes replaces 5,926 statSync calls, with a symlink limb preserving the old follow-the-link semantics exactly so a transport behind a symlinked directory still cannot escape the ledger; (4) the enumeration is computed once per PROCESS — still rebuilt FROM SOURCE every run, never a checked-in list, fixture or commit-spanning cache. Per run: 10,152 file opens becomes 2,097 (4.84x fewer), 147.5 MB read becomes 32.5 MB, UTF-8 decoding eliminated entirely. The two scanning tests also carry a stated 30,000 ms budget replacing vitest's inherited 5000 ms default — a BUDGET, not a timing assertion (deliberately not expect(elapsed).toBeLessThan(n), per Zone 3). Zone 1 fully intact: no assertion weakened, nothing skipped or re-baselined, ledger untouched, #13279 semantics untouched.",
  "zone_2_result": {
    "A2.1": "HELD for the card, FALSIFIED for the PM's counter-hypothesis. Profiled the two halves separately: walk() (readdirSync plus 5,926 statSync) 18.6 ms median = 9.9% of the scan; readFileSync over 5,076 files 170.0 ms = 90.1%. Syscall overhead on the directory walk does NOT dominate — swapping in readdirSync withFileTypes ALONE moved the scan only from 222.9 ms to 212.0 ms (4.9%). Unhypothesised finding: roughly half the read half was the UTF-8 DECODE, not the I/O — dropping to Buffer reads took the already-filtered scan from 120.5 ms to 57.8 ms (2.08x).",
    "A2.2": "FALSIFIED, narrowly, in exactly the direction the assumption named as falsifiable. Second call 208.8 ms vs first call 272.8 ms = 0.765x — the second pass IS partly warm in the page cache, so memoisation removes 43.4% of the two-call total, not 50%. 'Halves' is optimistic but close; memoisation is still worth taking.",
    "A2.3": "HELD, strongly, and it is the largest single win for the smallest diff. The walk yields 5,076 .ts files; only 2,097 survive isScaffolding. So 2,979 files (58.7% of files, 56.4% of bytes) were read into memory in full and only then thrown away for their path. Moving the filter ahead of the read took the scan from 222.9 ms to 120.5 ms (1.85x), and it is semantically free — verified by asserting the reordered pipeline returns a byte-identical result list.",
    "A2.4": "FALSIFIED as a local measurement, and this is the report's most important number. On plain `main` (my worktree is main with zero diff, per the addendum) ONE discoverTransports() call costs 632 ms with a COLD page cache (drop_caches before each run, median of 3) and 295 ms warm inside vitest — that is 12.6% and 5.9% of the 5000 ms budget, i.e. 7.9x and 16.9x headroom. `main` is NOT just over the line on this box; it is comfortably under it. After the repair: 255 ms cold and 101 ms warm = 19.6x and 49.5x headroom. BUT the CI-to-local factor is NOT MEASURED and cannot be measured from here: vitest aborts at the timeout, so CI's only datum is 'greater than 5000 ms', which bounds the factor BELOW at 7.9x against local-cold and not above at all. Cost is linear in file count (0.124 ms per file before, 0.122 ms after), so the repair divides whatever that factor produces by 2.42x on the worst single callback — a real improvement, but not by itself a comfortable margin against an unbounded number. That gap, not the local headroom, is why the stated budget is also there.",
    "A2.5": "HELD, but for a reason the assumption did not name. Not because the structural fix is weak — it is 4.84x fewer file opens per run — but because vitest's timeout applies PER CALLBACK, where the reduction is 2.42x, and the CI factor is unbounded above. A stated budget converts an unbounded environment risk into a bounded, stated one; it is not load-bearing for passing (the test runs at 2.0% of the OLD default budget). Also measured and REJECTED rather than shipped: async concurrent reads at concurrency 48 were 285 ms cold vs 255 ms serial — concurrency does not help on this filesystem, so the complexity was not taken."
  },
  "tests": "All verified at final commit 9ae177c47c (named in the PR body and cited from that run). (1) Full suite: `pnpm --filter @objectstack/core exec vitest run --maxWorkers=2` under scripts/pm/os-verify-lock.sh gives `Test Files 46 passed (46)` and `Tests 1135 passed (1135)`; lock VERDICT line reads `command-exit 0`. Same totals CI reported when it was `1 failed | 45 passed (46)` and `1 failed | 1134 passed (1135)`, so the whole suite is accounted for. (2) Both discoverTransports() call sites exercised, from --reporter=verbose: CONTROL 295 ms becomes 101 ms (pays the scan), SET EQUALITY 218 ms becomes 0 ms (reads the memoised result). (3) ABLATION proving the Zone 1.1 guarantee survives memoisation — no rebuild applies here and none was needed: the subject is a filesystem scan of SOURCE at REPO_ROOT, no dist/ is on the path. Mutation leg: wrote packages/core/src/security/scan-probe-tmp.ts containing the call `resolveAuthzContext({`; mutation confirmed ON DISK before running, by file existence plus `grep -c -F` of the injected needle = 1, plus `git status --porcelain` showing the untracked probe — not by an editor exit code. Result: SET EQUALITY went RED and NAMED the probe (grep of the log = 1 hit); CONTROL stayed green at 92 ms. Restore leg: probe removed under a `trap ... EXIT INT TERM` with an absolute path seeded from `git rev-parse --show-toplevel`; restoration proven BY STATE — file absent, `git diff HEAD --stat` empty, `git status --porcelain` empty — then re-run green 37/37 with 0 log hits for the probe. (4) Gate families derived from the ACTUAL diff via `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` (the script reads its own change set from the merge base; no hand-built path list was fed to it), all re-run and green AT 9ae177c47c: check:cross-package-test-inputs, check:test-source-alias, check:engine-double-contract, check:where-matcher, check:query-options-erasure, check:nul-bytes, check:type-check-coverage, check:doc-authoring, check-comment-mask-adoption, check-ci-filter-parity, check-keyed-text-bounds, check-plugin-teardown-shape, check-undeclared-dep-imports. Exit codes captured by redirect-then-capture, never through a pipe. (5) `eslint --no-inline-config` on the changed file: 0 errors, 0 warnings, 1 file linted (read from --format json, not from a tail). NOT MEASURED / not run: repo-wide `pnpm lint` (CI owns it) and the CI runner's own wall time (censored at the timeout, see A2.4). NOT AVAILABLE: `packages/core` declares no `typecheck` script (its scripts are build, test, test:watch only), so a `--filter @objectstack/core typecheck` would have matched zero scripts and exited 0 while saying nothing; its type coverage is ledgered and check:type-check-coverage passes.",
  "mcp_calls": "0 — the whole run used repo-scoped REST (probed first: 200 on the repo and on issue 13645), so no MCP GitHub call was spent. `gh` is not installed in this container.",
  "open_questions": [
    {
      "question": "The one judgement call worth your scrutiny: I shipped the stated 30,000 ms budget ALONGSIDE the structural fix, rather than the structural fix alone. Your Zone 3 warned the timeout half deserves scrutiny and STOP condition 1 asked me to report rather than ship a postponement. My reading is that this is not a postponement — but it is the one place where you may disagree.",
      "options": [
        "A. Keep both, as shipped. The structural fix stands on its own (4.84x fewer opens, 2.42x on the worst callback, UTF-8 decode eliminated); the budget is not load-bearing for passing (the test runs at 2.0% of the OLD 5000 ms default) and exists only because the CI factor is bounded below at 7.9x and NOT above.",
        "B. Drop the explicit budget and ship the structural fix alone. Cleaner, and it keeps the failure loud if the tree regrows — but it leaves the test guarded by a 5000 ms number nobody chose, on an environment whose slowness relative to this box is unmeasured and was already enough to blow it once.",
        "C. Keep the budget but tighten it, say 15,000 ms, which still needs a CI factor above 58.8x to trip versus 117.6x at 30,000."
      ],
      "recommendation": "A, because the two failure modes are wildly asymmetric and that asymmetry is the whole reason this card exists. A budget that is too generous costs nothing on a passing test; a budget that is too tight ABORTS THE SHARD and takes eleven unrelated packages down with it, which is precisely the damage recorded here. The budget is also documented in-file as a budget and not a speed assertion, with an explicit instruction that if it is ever reached the answer is to re-engineer the scan and never to raise the number. If you prefer B I can drop it in one line — the structural fix is independent of it and the suite passes either way."
    }
  ],
  "out_of_scope_findings": []
}

Generated by Claude Code

⚠️ Correcting my own claim: "`main` is already over the line" was wrong as stated

I wrote that on this card (comment 5473927956) and repeated it on #13630 and #13635. The seat measured it and it does not hold as a statement about the tree. On plain main, worktree with zero diff:

	one `discoverTransports()` call	share of the 5000 ms budget	headroom
cold page cache (drop_caches, median of 3)	632 ms	12.6%	7.9x
warm, inside vitest	295 ms	5.9%	16.9x

On a developer box, main is comfortably under the budget. My inference was wrong in a specific and worth-naming way.

What survives, and what does not

Survives — a tree whose walked file set equals main's does blow the budget on CI. That is still measured two independent ways (#13630's queue run at 04:33:56Z, #13635 at 04:44:01Z, disjoint diffs, neither touching packages/core).

Falsified — my framing that this is a property of the tree, and therefore that "the tree crossed a threshold". It is not. It is a property of CI being at least 7.9x slower than that box, a factor which is bounded below and NOT bounded above — vitest aborts at the timeout, so CI's only datum is "> 5000 ms" and the true figure is censored. NOT MEASURED, and no measurement taken on a developer box can close that gap.

⇒ The villain is not growth crossing a line. It is an inherited 5000 ms default with no margin for the environment it actually runs in — vitest's budget for a test that does no I/O, silently applied to a filesystem scan.

⛔ Which decisions this does NOT change

Stated explicitly so nobody re-opens them on the strength of this correction:

fix(formula): fail closed on a null MEMBER of a resolved membership array in the CEL pushdown (#13496) #13630 and fix(objectql): cut the tenant-audit control's scope by the object's tenancy, not the caller's flag (#13491) #13635 are still exonerated. A tree equal to main fails on CI; neither diff caused it. Unchanged.
Still no re-run. The failure is deterministic on CI — same tree, two PRs, identical failure. Unchanged.
fix(formula): fail closed on a null MEMBER of a resolved membership array in the CEL pushdown (#13496) #13630 still must not be re-queued until perf(core): cheapen the authz transport scan so a slow test stops aborting the Test Core shard #13656 lands. Unchanged.
This card was still worth filing and fixing. Unchanged — arguably more so, since the cause is structural rather than a threshold that would have receded.

The operative conclusions in my comments on #13630 (5473907899) and #13635 (5473929447) are unaffected, so I am not re-commenting there to refine a why that moves no decision.

The seat's open question — ruling A: keep the structural fix AND the stated budget

⭐ And this measurement reverses the residual I was going to record against it. I had intended to note that a 30,000 ms budget lets the scan grow ~118x before anyone notices. That concern assumed the budget was absorbing tree growth. It is not — it is absorbing an unmeasured environment factor that is already known to exceed 7.9x. That is a different thing, and covering it is correct rather than indulgent.

Reasons, in order of weight:

The failure modes are wildly asymmetric, and that asymmetry is why this card exists. A too-generous budget costs nothing on a passing test. A too-tight one aborts the shard — measured here as eleven other packages losing their entire run on a PR that never touched authorization.
5000 ms was never chosen. It is vitest's default for a test that does no I/O. Replacing an inherited number with a stated one is the card's own remedy ✨ Set up Copilot instructions #2, and the in-file comment states it as a budget with an explicit ⛔ against ever raising it.
Option C (15,000 ms) prices an unknown. It trips at a CI factor above 58.8x versus 117.6x at 30,000 — but the factor is unbounded above, so choosing the tighter bound buys nothing measurable and re-exposes failure mode 1.
The budget is not load-bearing for passing. The repaired test runs at 2.0% of the OLD 5000 ms default. The structural fix stands alone: 4.84x fewer file opens, 4.54x fewer bytes, UTF-8 decode eliminated, 2.42x on the worst single callback.

⇒ Ship as-is. No change to #13656.

On the seat's Zone 2 work

Four of five assumptions came back with the measurement that decided them, and three falsified something — including my own counter-hypothesis on A2.1 (I suspected statSync might dominate; measured 9.9% vs 90.1%, and the unhypothesised half was the UTF-8 decode, not the I/O). A2.2 was falsified narrowly and honestly: memoisation removes 43.4%, not 50%, because the second pass is already partly page-cache warm.

⭐ Also worth recording: concurrent reads at concurrency 48 were measured (285 ms cold vs 255 ms serial) and REJECTED rather than shipped. Declining complexity on a measurement is the same discipline as taking it.

Generated by Claude Code

Navigation Menu

Repository navigation

[finding] `authz-store-unavailable.test.ts` walks and reads ALL of `packages/` twice under the default 5s timeout — it times out as the repo grows, reddening PRs that have nothing to do with authz #13645

Measured

The mechanism — it is a design property, not a flake

Why it is worth a card rather than a re-run

Two candidate remedies, neither costed here

What this does NOT claim

Related

The one thing this card's own body got wrong, corrected before dispatch

One correction to the mechanism as filed, from re-reading source at `eaba72e48c`

Dispatch order — #13645

Zone 1 — 裁决 (binding)

Zone 2 — PM 机制假设 (measure these; ⭐ falsification is encouraged and is a reportable success)

Zone 3 — PM 建议路线 (advisory — deviate freely, with a reason)

STOP conditions — report back rather than proceeding

Clause ② self-declaration

Verification expected

Why this is urgent

⭐⭐ Sharper measurement: `main` itself is already over budget — neither PR crossed the line

What this changes

⚠️ Correcting my own claim: "`main` is already over the line" was wrong as stated

What survives, and what does not

⛔ Which decisions this does NOT change

The seat's open question — ruling A: keep the structural fix AND the stated budget

On the seat's Zone 2 work

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

PR	when	what it changes	touches `packages/core`?
#13630	`04:33:56Z`, `merge_group` run 33357337261	`packages/formula` (2 files) + 1 changeset	no
#13635	`04:44:01Z`, run 33357913478	`packages/objectql`, docs, a gate script	no

[finding] authz-store-unavailable.test.ts walks and reads ALL of packages/ twice under the default 5s timeout — it times out as the repo grows, reddening PRs that have nothing to do with authz #13645

Description

Measured

The mechanism — it is a design property, not a flake

Why it is worth a card rather than a re-run

Two candidate remedies, neither costed here

What this does NOT claim

Related

Activity

zhuangjianguo commented on Aug 31, 2026

The one thing this card's own body got wrong, corrected before dispatch

One correction to the mechanism as filed, from re-reading source at eaba72e48c

zhuangjianguo commented on Aug 31, 2026

Dispatch order — #13645

Zone 1 — 裁决 (binding)

Zone 2 — PM 机制假设 (measure these; ⭐ falsification is encouraged and is a reportable success)

Zone 3 — PM 建议路线 (advisory — deviate freely, with a reason)

STOP conditions — report back rather than proceeding

Clause ② self-declaration

Verification expected

Why this is urgent

zhuangjianguo commented on Aug 31, 2026

⭐⭐ Sharper measurement: main itself is already over budget — neither PR crossed the line

What this changes

claude commented on Aug 31, 2026

zhuangjianguo commented on Aug 31, 2026

⚠️ Correcting my own claim: "main is already over the line" was wrong as stated

What survives, and what does not

⛔ Which decisions this does NOT change

The seat's open question — ruling A: keep the structural fix AND the stated budget

On the seat's Zone 2 work

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[finding] `authz-store-unavailable.test.ts` walks and reads ALL of `packages/` twice under the default 5s timeout — it times out as the repo grows, reddening PRs that have nothing to do with authz #13645

One correction to the mechanism as filed, from re-reading source at `eaba72e48c`

⭐⭐ Sharper measurement: `main` itself is already over budget — neither PR crossed the line

⚠️ Correcting my own claim: "`main` is already over the line" was wrong as stated