You own the test suite for a large multi-team codebase using Kotest. How do you decide which settings belong in the project-wide AbstractProjectConfig versus in individual specs?

## The two axes Every candidate setting can be placed with two questions. **Axis 1 — is a per-spec answer meaningful?** Some settings have one correct answer for the whole organisation. Nobody wants a green build from zero tests; nobody wants two tests sharing a name and one silently vanishing. Others have genuinely different right answers per spec: timeouts, tags, isolation for a spec with expensive shared state. When the per-spec answer carries information, forcing uniformity destroys that information. **Axis 2 — what does getting it wrong look like?** A global that adds strictness fails loudly and locally: someone sees an error naming the exact problem. A global that changes execution semantics fails quietly and distantly: a spec that was implicitly relying on shared fixture state starts failing (or worse, starts passing for the wrong reason) after someone changed a default in a file the spec's author has never opened. Strictness globals are cheap; semantics globals are expensive. That asymmetry drives most of the policy. ## The default recommendation **Globalise** - `failOnEmptyTestSuite` — a filter that matches nothing must fail, not go green. - duplicate test name policy — duplicates hide tests and corrupt reporting. - `assertionMode` — a suite-wide quality bar, enforced. - a generous default `timeout` and a `projectTimeout` — safety nets so a hung test costs a minute, not a CI slot. - cross-cutting `extensions()` — metrics, leak detection, run-wide infrastructure. **Keep local** - real timeouts for genuinely slow specs (via `defaultTestConfig`) — the exception is documentation. - tags that describe what a spec is. - isolation mode, unless your whole codebase truly shares one convention and you are prepared to defend it. - anything only one team needs. ## Why isolation mode is the special case It is the setting people most want to globalise and the one that punishes globalising hardest. It changes how many times a spec class is instantiated, which changes what state is shared between tests, which changes whether a spec that quietly depended on ordering still works. It also multiplies the cost of every per-instance callback: a `beforeSpec` that starts a container becomes a container per test. When you change it globally you are simultaneously changing correctness assumptions and runtime cost across every spec in the repository, and the failures surface far from the change. If you must change it, do it spec by spec, or per module with the ability to roll back a module at a time. ## Discoverability is a first-class cost Project config is invisible from the spec it governs. A developer debugging a flaky test reads the spec, the fixture, maybe the SUT — not a config class in another package. Mitigations that work: keep the config short enough to read in one screen; comment each override with *why* rather than what; log run-wide extensions once at startup so their presence appears in the output; and prefer strictness settings, whose effects announce themselves, over semantics settings, whose effects do not. ## Change management Changing a global in a large suite is a migration, not an edit: 1. Measure first — how many specs are affected, and how? 2. Introduce in the least destructive mode (warn before error). 3. Triage the resulting list, fixing or explicitly exempting. 4. Enforce, so new violations cannot land. 5. Announce, because other teams' builds are the blast radius. For semantics changes, add a step: land it behind per-module configs so a failing module can revert independently. ## Multi-module reality Each module's run resolves its own config from its own test classpath. The scalable arrangement is a small test-support artefact holding the extensions and shared setting values, plus a thin `AbstractProjectConfig` subclass per module that registers them. This keeps one source of truth for behaviour while letting a single module deviate deliberately — which is also the unit at which you can safely roll out a risky change. ## What separates a strong answer A weak answer lists settings. A strong one gives the decision rule (uniformity + failure visibility), names the setting that is the exception (isolation mode) with the reason, treats discoverability as a real cost rather than a nicety, and describes changing a global as a staged migration with a rollback unit.