The build boots the fact schema 1051 times, and a reset costs a fraction of a boot

Which boots must stay boots. Some tests have the boot as their subject: PersistentStoreTest, WarmStartRefreshTest, FactCaptureAgreementTest, and anything asserting on the DDL-hash directory segment or the store_stamp integrity check. Those keep booting, and naming them is the first task because the saving is computed net of them. R769 supplies the criterion to name them by, and the warning not to pin the list. The rule that did the work there is whether the boot or the schema’s shape is the test’s subject rather than its setup, which is what settles a class without arguing about it. The list itself drifted twice inside that item’s own review, once when a new class landed on trunk mid-review and once in the recount it forced, so derive the set from the criterion at pickup rather than trusting a count written here.

The scope of a shared store, which is per thread and not per JVM. These modules run four test classes at once. One store shared across four threads would need every fixture write serialized, which trades the boot cost for a lock. A store per test thread is the shape that keeps the tests independent: a boot per test thread rather than 420. Both halves are now answered by R769 and one of them corrects this bullet. A ThreadLocal does survive the worker pool, so the mechanism works; but "4 boots per module JVM" is the wrong expectation and asserting it would have failed. At fixed.parallelism=4 that module booted eight stores on eight distinct threads, because fixed sizes a ForkJoinPool and the pool adds compensation threads when a task blocks, so the number of threads that ever run a test class is not the configured parallelism. Budget for a boot per booting thread, some multiple of the configured width, and pin the invariant as an equality between boots and distinct booting threads rather than against a literal.

~~How a reset is proved complete, because the failure mode is silent.~~ Settled by R769, and reuse its answer rather than re-deriving it, because the first two shapes tried there both failed review. The guard is always on rather than opt-in: the probe is a single UNION ALL census in one round trip, which costs a few milliseconds against the 133 s of boots it protects, and a nightly-only guard lets a bad case land for a working day, which is an invariant that has stopped failing when it breaks. It asserts the whole base-table set and not the clear’s own list: after a TRUNCATE over exactly those tables "those tables are empty" is entailed, so a guard scoped to the clear’s exclusion pattern cannot see that pattern being wrong, and the leak worth catching is a row surviving in a table the clear does not reach. And it is positive, asserting each table’s boot row count rather than emptiness, so the tables a boot legitimately fills are covered too. The INFORMATION_SCHEMA requirement in this bullet held up, with a consequence worth carrying: because the partition is derived once when the thread boots, a case on the funnel must not execute DDL, or the clear names a relation the schema has since turned into something else. Budget for finding the DDL-executing cases in each remaining module before routing that module’s funnel.

~~Whether MaterializeDependencies.populate belongs in a reset.~~ Settled: it does not, so a reset is 0.85 ms rather than 9.3 ms and the ratio against a boot is about 160x rather than 15x. populate derives its edges from Materializations.registrations and from the stored view definitions it reads out of INFORMATION_SCHEMA, and reads no fact relation, so no row a test writes can invalidate meta_materialize_dependency and clearing rows cannot either. Established by reading populate and by observing the relation byte-identical across a clear. Note the other derivation is a different thing and already per-case: Materializations.refreshAll does depend on fact rows, and every seeded case already calls it. Every saving figure in this item was computed on the conservative reading and is therefore a floor rather than a projection.

~~Whether StoreRefresh is the seam or a new one is.~~ Answered for graphitron-model: a new one, and the parallel mechanism is deliberate. StoreRefresh is package-private in graphitron, which depends on graphitron-model and its test-jar, so a call from that module’s fixture would invert the module dependency, and its clear is a different question anyway: prepare takes a FactSink, a ClasspathSources and a class census and deletes what one capture run owns, scoped by graph_name and by crawled source. StoreRefresh answers "what does this run own" and ThreadConfinedStore answers "make this store look freshly booted". Note the reachability half of that answer is module-scoped and does not carry: StoreRefresh lives in graphitron, so for that module it is reachable and the question is live again there, on the contract rather than on the dependency direction.

Whether the fixture helpers can carry this without every test changing. SeededStore.withSeededStore in graphitron-model is one funnel for 420 boots; if graphitron’s 382 test classes reach the store through a comparable helper, the change is small, and if they each call `open() directly it is not. That count decides whether this is one item or a staged one. Answered for graphitron-model and shipped: R769 took that module, where 159 call sites across 30 classes funnel through the one helper and five classes boot directly because the boot is their subject. 420 boots became 31, no test class changed, and this item keeps the other three modules, 631 boots and 262.8 s.

New, and it is the thing to settle first: graphitron’s harnesses are populated by a pipeline, so R769’s mechanism does not carry over unchanged. That module is this item’s biggest row, 348 boots and 146.5 s, and its store fixtures are not a funnel of the `withSeededStore shape. StoreFixtureGuardTest enumerates them: CapturedStore fills a store by driving FactCapture over SDL fixtures, BuiltStore by running a whole buildOutput(), and thirteen further test classes reach FactStores directly. The premise R769 rested on was that a body seeds its own rows cheaply, so handing it an emptied store is as good as handing it a booted one. These two harnesses instead hold content that, in their own javadoc’s words, cannot be arranged but only produced, and clearing to booted-empty throws away the expensive part rather than the cheap one. So the arithmetic to measure here is not the one in this item’s reset table: it is whether a captured or built store can be re-populated more cheaply than re-booted, and if it cannot, the lever for those classes is a store shared across the cases that want the same population rather than a clear between them. FactStores.perClass(), which landed separately, is that shape for a class whose cases share one fixture, and its boots are already counted. Settle this before scoping graphitron, because a plan that assumes one funnel per module is a plan for graphitron-lsp and graphitron-mcp and not for the module holding most of the cost.