@gfdelarue/testkit 0.5.0 → 0.6.1

package/docs/test-types.md

@@ -11,12 +11,15 @@ so does any Node-side test that reads its environment from `process.env` or
 [Plain Vitest test files](../README.md#plain-vitest-test-files) for which files
 Testkit runs.
 
-Typed files carry one of three product-level test types in their filename
-suffix:
+A plain Vitest test records data-flow evidence, such as metrics, sequences,
+records, and budgets, with `dataFlow(context)` from
+`@gfdelarue/testkit/node-vitest/data`. Recording evidence gives the test no
+type and no setup. See
+[Record data-flow evidence](../README.md#record-data-flow-evidence).
+
+Typed files carry one product-level test type in their filename suffix:
 
 - `ui`: browser-level UI checks for user-visible pages and interactions.
-- `contract`: Node-backed service/runtime contract checks that need Node APIs but are not data-flow evidence suites.
-- `data`: data-flow and data-contract checks for throughput, payload shape, conversation/request traces, and cost/latency budgets.
 
 Consumers choose the type that describes the product behavior and declare the
 execution engine in each file's `defineFile(...)` metadata. Testkit validates
@@ -24,12 +27,10 @@ that pair against its engine catalog and resolves the exact runner profile.
 
 The current catalog is deliberately explicit:
 
-| Test type          | Engine        | Runner profile         |
-| ------------------ | ------------- | ---------------------- |
-| none, a plain file | `node-vitest` | `node-vitest`          |
-| `data`             | `node-vitest` | `node-vitest-data`     |
-| `contract`         | `node-vitest` | `node-vitest-contract` |
-| `ui`               | `playwright`  | `playwright-ui`        |
+| Test type          | Engine        | Runner profile  |
+| ------------------ | ------------- | --------------- |
+| none, a plain file | `node-vitest` | `node-vitest`   |
+| `ui`               | `playwright`  | `playwright-ui` |
 
 Every typed file must import `defineFile` from the root package and export one
 direct metadata declaration:
@@ -37,7 +38,7 @@ direct metadata declaration:
 ```ts
 import { defineFile } from "@gfdelarue/testkit";
 
-export const testkit = defineFile({ engine: "node-vitest" });
+export const testkit = defineFile({ engine: "playwright" });
 ```
 
 The engine is not inferred from the suffix, imports, or repo configuration. A
@@ -46,9 +47,9 @@ error. The profile is derived from the validated pair and is carried unchanged
 through scheduling, results, and immutable run evidence.
 
 Run selection by `--file`, `--group`, `--type`, or `--suite` narrows the files
-whose engine metadata is read and validated. A `--type` that names test types
-and typed suite selectors select typed files only; `--type all` includes plain
-files. Testkit uses discovered paths, canonical type
+whose engine metadata is read and validated. `--type ui` and typed suite
+selectors select typed files only, `--type plain` selects plain files only, and
+`--type all` selects both. Testkit uses discovered paths, canonical type
 suffixes, and suite names to select candidates; each selected typed file must
 still declare a valid engine. Invalid metadata in an unselected file
 does not block that focused run. Root configuration, service dependencies, and
@@ -56,11 +57,7 @@ group skip, requirement, and isolation selectors remain validated against
 the complete discovered project. `discover`, `doctor`, and `typecheck` validate
 metadata across the whole project.
 
-Canonical filename suffixes:
-
-- `*.ui.testkit.ts`
-- `*.contract.testkit.ts`
-- `*.data.testkit.ts`
+The canonical filename suffix is `*.ui.testkit.ts`.
 
 UI tests may import Playwright's public browser primitives directly from the
 managed native package:
@@ -72,56 +69,9 @@ import { expect, test } from "@playwright/test";
 export const testkit = defineFile({ engine: "playwright" });
 ```
 
-Data suites import data-flow primitives from Testkit:
-
-```ts
-import { defineFile } from "@gfdelarue/testkit";
-import { dataScenario } from "@gfdelarue/testkit/node-vitest/data";
-import { expect } from "vitest";
-
-export const testkit = defineFile({ engine: "node-vitest" });
-```
-
-Contract suites import Node-backed contract primitives from Testkit:
-
-```ts
-import { defineFile } from "@gfdelarue/testkit";
-import { contractScenario } from "@gfdelarue/testkit/node-vitest/contract";
-import { expect } from "vitest";
-
-export const testkit = defineFile({ engine: "node-vitest" });
-```
-
-Use `contract` when the behavior under test is a service/runtime boundary that
-needs Node APIs, fixtures, file IO, or richer protocol checks, but does not need
-Testkit data-flow evidence. Contract files are native Vitest suites:
-`contractScenario(...)` provides the managed Testkit contract context, while
-direct public runner APIs remain available for native behavior such as
-`test.skip(...)` and `test.todo(...)`. Contract suites run as Node processes
-managed by Testkit and should talk to configured service URLs.
-
-Use `data` when the behavior under test is the shape, cost, volume, latency, or
-movement of data through a real product flow. A data suite is not a generic
-Vitest migration target: write `dataScenario(...)` cases that record Testkit
-structured data-flow evidence with the provided data context, such as metrics,
-budgets, traces, fixtures, HTTP payload measurements, cache behavior, LLM usage,
-actors, systems, records, transitions, external calls, and reconciliation
-evidence.
-Data scenarios use Vitest directly for assertions, hooks, and mocking.
-`dataScenario(...)` owns case registration and evidence: lint reports native
-registration imports, and the runtime rejects cases registered any other way.
-Weak bookkeeping such as a single `count(...)`, `event(...)`, or `finding(...)`
-is useful as supporting detail, but it is not enough by itself to make a suite a
-data-flow suite.
-
-Data suites run as Node processes managed by Testkit's `node-vitest` engine and
-should use configured service URLs for data-flow evidence. If a check requires
-service-local loopback, `serviceContextUrl`, DOM rendering, browser automation,
-or raw app-server process access, use a plain Vitest test, `contract`, or `ui` instead.
-
-Use a plain Vitest test file for unit tests and other Node-side checks that need
-no Testkit context, `contract` for typed service or protocol contracts, and `ui`
-when the browser is part of the assertion. Plain Vitest files can exercise HTTP,
+Use a plain Vitest test file for unit tests, other Node-side checks, and
+service or protocol contracts, and `ui` when the browser is part of the
+assertion. Plain Vitest files can exercise HTTP,
 persistence, and service-spanning flows without a type label.
 
 The retired `@gfdelarue/testkit/runtime`, `@gfdelarue/testkit/data`,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gfdelarue/testkit",
-  "version": "0.5.0",
+  "version": "0.6.1",
   "description": "Test orchestration platform for product acceptance and QA workflows",
   "license": "SEE LICENSE IN LICENSE",
   "type": "module",
@@ -50,10 +50,6 @@
       "types": "./dist/types/node-vitest-data.d.ts",
       "default": "./dist/engines/node-vitest/runtime/data/index.js"
     },
-    "./node-vitest/contract": {
-      "types": "./dist/types/node-vitest-contract.d.ts",
-      "default": "./dist/engines/node-vitest/runtime/contract/index.js"
-    },
     "./workspace": {
       "types": "./dist/types/workspace.d.ts",
       "default": "./dist/app/inspect/index.js"
@@ -88,6 +84,7 @@
     "dist/",
     "docs/bug-records.md",
     "docs/engines.md",
+    "docs/release-notes.md",
     "docs/test-types.md",
     "testkit-config-schema.md"
   ],
@@ -139,7 +136,19 @@
     "yauzl": "3.4.0"
   },
   "overrides": {
-    "postcss": "8.5.24"
+    "@verdaccio/config": {
+      "js-yaml": "5.4.1"
+    },
+    "@verdaccio/hooks": {
+      "handlebars": "4.7.10"
+    },
+    "express": {
+      "qs": "6.16.0"
+    },
+    "postcss": "8.5.24",
+    "verdaccio": {
+      "compression": "1.8.2"
+    }
   },
   "engines": {
     "node": ">=22.15.0 <23.0.0 || >=24.14.1 <25.0.0",

package/testkit-config-schema.md

@@ -75,7 +75,7 @@ file-local metadata of a typed file may also declare skip and lock intent:
 import { defineFile } from "@gfdelarue/testkit";
 
 export const testkit = defineFile({
-  engine: "node-vitest",
+  engine: "playwright",
   skip: "Billing is currently unavailable locally",
   locks: ["payments-sandbox-webhook"],
 });
@@ -94,12 +94,10 @@ literal values `"node-vitest"` or `"playwright"`.
 The filename suffix determines the test type, and each engine and test type
 pair runs under exactly one runner profile:
 
-| Test type          | Engine        | Profile                |
-| ------------------ | ------------- | ---------------------- |
-| none, a plain file | `node-vitest` | `node-vitest`          |
-| `data`             | `node-vitest` | `node-vitest-data`     |
-| `contract`         | `node-vitest` | `node-vitest-contract` |
-| `ui`               | `playwright`  | `playwright-ui`        |
+| Test type          | Engine        | Profile         |
+| ------------------ | ------------- | --------------- |
+| none, a plain file | `node-vitest` | `node-vitest`   |
+| `ui`               | `playwright`  | `playwright-ui` |
 
 For a typed file, missing metadata, dynamic values, and unsupported
 engine/test-type pairs are discovery errors. There is no default-engine or legacy-runner compatibility
@@ -121,36 +119,45 @@ runtime-policy modules under `src/` just to cooperate with managed runs.
 
 ## Top-Level Fields
 
+The top-level keys are `areas`, `artifacts`, `bugs`, `discovery`, `execution`,
+`fingerprints`, `groups`, `lint`, `redact`, `services`, `toolchains`, and `ui`.
+Testkit refuses a config with any other top-level key. The error names the key
+and the closest known key when one is close.
+
 ### `execution`
 
 Default execution settings for the repo.
 
-- `taskConcurrency`: maximum concurrent test tasks across the run (default `1`)
+- `taskConcurrency`: maximum concurrent test tasks across the run (default `1`).
+  A typed file, a batch of typed files, or one Vitest invocation of plain files
+  is one task. Plain files in one invocation run with Vitest's file
+  parallelism, which the Vitest config's `fileParallelism` and `maxWorkers`
+  control.
 - `fileTimeoutSeconds`
 
-`execution.workers` and `presets.nodeNext({ workers })` remain deprecated aliases
-through 0.2.x and will be removed in 0.3.0. Use `taskConcurrency` in new config.
+`execution.workers` and `presets.nodeNext({ workers })` are deprecated aliases.
+Use `taskConcurrency` in new config.
 If both names are present, their values must match.
 
-`--task-concurrency` overrides the configured value. The CLI alias `--workers`
-also remains available through 0.2.x; contradictory CLI aliases are rejected
-before applying CLI precedence. Contradictory config aliases are rejected even
+`--task-concurrency` overrides the configured value. The deprecated CLI alias
+`--workers` also works; contradictory CLI aliases are rejected before applying
+CLI precedence. Contradictory config aliases are rejected even
 when the CLI supplies an override.
 
 Run documents keep the configured `run.workers` field. Observed
 `workerCount`, Playwright's own `workers`, `runtime.instances` and
 `runtime.maxConcurrentTasks` keep their existing meanings.
 
-`fileTimeoutSeconds` is the single per-file wall clock budget for the repo. Runtime
-helpers like `waitFor()` consume this budget automatically.
+`fileTimeoutSeconds` is the single per-file wall clock budget for the repo.
 
 ### `lint`
 
 Optional `testkit lint` settings. Omit it to run the default rules.
 
 - `rules`: map of rule name to `true`, `false`, or an options object.
-  `engineImports`, `configImports`, `dataSuiteContract`, and `uiSpecShape` default to enabled; `unitTestBoundaries` and
-  `testkitBoundary` default to disabled.
+  `engineImports`, `configImports`, and `uiSpecShape` default to enabled; `unitTestBoundaries` and
+  `testkitBoundary` default to disabled. `dataSuiteContract` was removed in
+  0.6.0, and `testkit lint` rejects a config that sets it.
 - Rule options: `enabled` (default `true`), `include`, `exclude`. `testkitBoundary`
   also accepts `allowed` and `trackedOnly`.
 - `ui`: `maxLines` (default `220`) and `maxTests` (default `8`) for UI suites.
@@ -158,16 +165,11 @@ Optional `testkit lint` settings. Omit it to run the default rules.
 Enabled-rule findings and syntax errors fail the command. There are no severity
 levels. The rules report:
 
-- `engineImports`: a value import the suite's engine can't load, such as Playwright
-  in a contract suite. Type-only imports
+- `engineImports`: a value import the suite's engine can't load, such as Vitest
+  in a UI suite. Type-only imports
   are allowed.
 - `configImports`: `testkit.config.ts` importing a repo-local `__testkit__`
   helper module.
-- `dataSuiteContract`: a data suite that doesn't register its cases through
-  `dataScenario` from `@gfdelarue/testkit/node-vitest/data`, registers them
-  through Vitest's `test`, `it`, `describe`, `suite`, or `bench`, or records
-  only bookkeeping such as `count(...)`, `event(...)`, and `finding(...)`
-  without product data-flow evidence such as `http(...)` or `record(...)`.
 - `uiSpecShape`: a UI suite longer than `ui.maxLines` lines or with more than
   `ui.maxTests` tests.
 - `unitTestBoundaries`: test doubles, module replacement, `process.env` reads,
@@ -193,7 +195,11 @@ areas: {
 
 - The key is the area id: lowercase letters, digits, and single hyphens, at
   most 40 characters.
-- `name`: one line of 1 to 60 characters. It becomes the label's description.
+- `name`: one line of 1 to 60 characters. It becomes the label's description,
+  and the issue carries it. Testkit doesn't rewrite it, so it must hold no
+  text that Testkit redacts as a secret. `testkit bug file` stops when the
+  fault's area has such a name. [Issue body](docs/bug-records.md#issue-body)
+  lists what Testkit redacts.
 - `paths`: at least one glob. Globs are relative to the repository root and
   written with `/`. A leading `!` or `/` and a `..` segment are rejected.
 
@@ -277,7 +283,7 @@ runs. The backend falls back to `TESTKIT_BACKEND_BASE_URL` and then
 ### `services`
 
 Map of service name to service config. A service describes what Testkit can
-start. With `groups` set, a service owns no test files.
+start. It owns no test files; [`groups`](#groups) assigns them.
 
 ### `groups`
 
@@ -324,21 +330,21 @@ Files that no group's roots claim belong to the implicit group `root`, which
 uses no service. `root` is reserved. With no `testkit.config.ts`, every file
 belongs to `root`, and `groups: {}` gives every file to `root`.
 
-With `groups` set, Testkit ignores a service's `discovery` and rejects a
-service's `skip`, `requirements`, or `runtimeIsolation` with a message naming
-the group field to use.
+Testkit assigns no files by a service's `discovery`. With `groups` set, it
+rejects a service's `discovery`, `skip`, `requirements`, or `runtimeIsolation`
+with a message naming the group field to use. The `discovery` that
+`database.fixture()` adds by default is the exception.
 
-#### Legacy ownership
+#### Configs without `groups`
 
-A config with `services` and no `groups` key uses legacy ownership. Each
-service is a group of the same name that uses that service. It owns the typed
-`*.testkit.ts` files under its `local.cwd` and `discovery.roots`, and its
-`skip`, `requirements`, and `runtimeIsolation` apply to them. A typed file
-outside every service root belongs to `root`. Legacy ownership never claims a
-plain Vitest test file; those belong to `root` unless declared groups claim
-them. When legacy ownership gives a
-file to a service, Testkit prints a notice on stderr. Legacy ownership will be
-removed; declare `groups` instead.
+Before 0.6.0, a config with `services` and no `groups` key gave each service
+the typed `*.testkit.ts` files under its `local.cwd` and `discovery.roots`. Such
+a config now fails to load when a service's directories hold a typed file. The
+error lists a `groups` entry for each of those services, with its `roots`,
+`uses`, and any `exclude`, so the files keep their services. `status`,
+`destroy`, `cleanup`, and `db schema` still run on such a config. A group also
+owns the plain Vitest files under its roots, which a service never did. When no
+service's directories hold a typed file, every file belongs to `root`.
 
 ### `toolchains`
 
@@ -378,48 +384,12 @@ download mode fails on a musl host before downloading anything.
 - `package.json#packageManager`
 - `package.json#engines.npm`
 
-### `profiles.http`
-
-Named HTTP profiles for Node/Vitest data suites, selected through
-`flow.http({ profile })`.
-
-Node/Vitest data profiles may carry `auth`, `headers`, and
-`rawHeaders` functions. `auth.setup` or `auth.setupAsync`
-returns a session bundle of named actors; `headers` maps the bundle and the
-requested actor to request headers.
-
-```ts
-interface SessionBundle {
-  actors: Record<string, { session: { jwt: string } }>;
-  primaryActor: string;
-}
-
-profiles: {
-  http: {
-    default: {
-      auth: {
-        async setupAsync({ env, http }): Promise<SessionBundle> {
-          const login = await http.post(`${env.BASE}/api/v1/auth/login`, body);
-          const jwt = login.cookies?.session?.[0]?.value;
-          if (!jwt) throw new Error("Login response did not set the session cookie");
-          return { actors: { primary: { session: { jwt } } }, primaryActor: "primary" };
-        },
-        headers(setupData): Record<string, string> {
-          const bundle = setupData as SessionBundle | null;
-          return bundle
-            ? { Authorization: `Bearer ${bundle.actors[bundle.primaryActor].session.jwt}` }
-            : {};
-        },
-      },
-    },
-  },
-}
-```
+### `profiles`
 
-Repository profile setup data is typed as `unknown`. The example gives its
-test-owned setup result a name and uses that type in the corresponding header
-builder. Suite-specific functions can also be passed through
-`flow.http({ profile: "default", auth: { setupAsync, headers } })`.
+Testkit 0.6.0 removed HTTP profiles. A config that sets `profiles` fails to
+load. A test logs in with `fetch` or its own client against the URL from
+`@gfdelarue/testkit/environment`, as
+[Record data-flow evidence](README.md#record-data-flow-evidence) shows.
 
 ## Service Fields
 
@@ -594,10 +564,9 @@ to the matching `{db*:api}` token. `env.values` entries override expanded names.
 ### `envFile` / `envFiles`
 
 Optional extra env files loaded into the declared service/task environment for
-migrations, seeds, services, and every execution engine. Node/Vitest data and contract contexts expose task values through
-immutable `context.env`; and managed Playwright contexts expose them through
-`readPlaywrightContext().env`. Direct managed-Node `process.env.KEY` reads are a
-non-enumerable compatibility overlay, not the consumer-input contract.
+migrations, seeds, services, and every execution engine. Node/Vitest tests read
+task values from `process.env`, and managed Playwright contexts expose them
+through `readPlaywrightContext().env`.
 
 Testkit reads a service's env files only when a selected group uses the service
 or a used service depends on it. Loading the config reads none of them, so a
@@ -626,10 +595,10 @@ Environment names are validated case-insensitively. All engines reserve
 `XDG_CONFIG_HOME`, and `XDG_DATA_HOME`. Engine-specific reservations and limits
 are:
 
-| Engine        | Additional reservations                                                                                                                                    | Consumer environment limit                 |
-| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ |
-| `node-vitest` | exact keys `BASE_URL`, `FORCE_COLOR`, `NODE_OPTIONS`, `NO_COLOR`, `UPDATE_SNAPSHOT`, `VITEST_POOL_ID`, `VITEST_WORKER_ID`, and the `TESTKIT_` keys it sets | 512 entries; 4 MiB of UTF-8 key/value data |
-| `playwright`  | prefixes `TESTKIT_`, `PLAYWRIGHT_`, `PWTEST_`, `PW_TEST_`; exact keys `BASE_URL`, `FORCE_COLOR`, `NODE_OPTIONS`, `NO_COLOR`                                | 512 entries; 2 MiB of UTF-8 key/value data |
+| Engine        | Additional reservations                                                                                                                                                  | Consumer environment limit                 |
+| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------ |
+| `node-vitest` | exact keys `BASE_URL`, `FORCE_COLOR`, `NODE_OPTIONS`, `NO_COLOR`, `UPDATE_SNAPSHOT`, `VITEST_POOL_ID`, `VITEST_WORKER_ID`, and the `TESTKIT_` keys it sets               | 512 entries; 4 MiB of UTF-8 key/value data |
+| `playwright`  | prefixes `TESTKIT_`, `PLAYWRIGHT_`, `PWTEST_`, `PW_TEST_`; exact keys `BASE_URL`, `DBUS_SESSION_BUS_ADDRESS`, `FC_FONTATIONS`, `FORCE_COLOR`, `NODE_OPTIONS`, `NO_COLOR` | 512 entries; 2 MiB of UTF-8 key/value data |
 
 Empty names, names containing `=` or NUL, values containing NUL, and
 case-variant duplicates are rejected. The limits apply after env files and
@@ -743,13 +712,37 @@ service provisioned in the same runtime instance, as `DATABASE_URL` and in
 
 ### `runtime`
 
-Shared runtime topology and preparation behavior.
+Service-local runtime instances and their preparation.
+
+```ts
+runtime: {
+  instances: 1,
+  maxConcurrentTasks: 4,
+  prepare: {
+    inputs: ["frontend/src", "frontend/public", "frontend/package.json"],
+    steps: [{ kind: "command", run: "npm run build", cwd: "frontend" }],
+  },
+}
+```
 
 - `instances`
+  - number of reusable local runtime instances for that service graph
 - `maxConcurrentTasks`
+  - maximum number of concurrent file tasks admitted to each runtime instance
+  - omit it to leave concurrency bounded only by the outer `taskConcurrency` setting
 - `toolchain`
+- `prepare`
+  - optional runtime-generation preparation hook
+  - runs once per runtime instance before local services start
+  - fingerprints declared `inputs` plus referenced step files/module inputs
+  - use this for build-once/start-many shared runtimes such as `next build` +
+    `next start`
 - `prepare.inputs`
+  - extra repo-relative inputs that should invalidate prepared artifacts when
+    they change
 - `prepare.steps`
+  - ordered lifecycle steps using the same step DSL as `database.template`
+  - each step supports `cwd` and `inputs`
 
 `runtime.toolchain` may be either:
 
@@ -766,19 +759,20 @@ Changing the resolved Node or npm version invalidates prepared artifacts, so
 
 ### `skip`
 
-Skip rules for a group's files, set as `groups.<name>.skip`. Under legacy
-ownership a service's `skip` applies to the files it owns. Skipped files remain
+Skip rules for a group's files, set as `groups.<name>.skip`. Skipped files remain
 visible in run artifacts with `status: "skipped"` and the configured reason.
 
 Prefer file-local `export const testkit = defineFile({ ... })` metadata
-for per-file skips and locks. Repo-level `skip` is mainly for broad suite-level
-policy.
+for per-file skips and locks in a typed file. Repo-level `skip` is mainly for
+broad suite-level policy. A plain Vitest file has no file-local metadata, so its
+skips, locks, and isolation go in `skip.files`, `requirements.files`, and
+`runtimeIsolation.files`.
 
 ```ts
 skip: {
   files: [
     {
-      path: "__testkit__/billing/billing.contract.testkit.ts",
+      path: "src/billing/billing.test.ts",
       reason: "Billing is currently unavailable",
     },
   ],
@@ -796,59 +790,26 @@ skip: {
 - `files[].reason`
   - required non-empty explanation recorded in artifacts
 - `suites[].selector`
-  - existing suite selector syntax, including typed selectors like `contract:health`
-    and `ui:billing`
+  - existing suite selector syntax, including typed selectors like `ui:billing`
 - `suites[].reason`
   - required non-empty explanation recorded in artifacts
 
-Use `--ignore-skip-rules` on the CLI to run matched files anyway.
-
-### `runtime`
-
-Service-local runtime instance settings.
-
-```ts
-runtime: {
-  instances: 1,
-  maxConcurrentTasks: 4,
-  prepare: {
-    inputs: ["frontend/src", "frontend/public", "frontend/package.json"],
-    steps: [{ kind: "command", run: "npm run build", cwd: "frontend" }],
-  },
-}
-```
-
-- `instances`
-  - number of reusable local runtime instances for that service graph
-- `maxConcurrentTasks`
-  - maximum number of concurrent file tasks admitted to each runtime instance
-  - omit it to leave concurrency bounded only by the outer `taskConcurrency` setting
-- `prepare`
-  - optional runtime-generation preparation hook
-  - runs once per runtime instance before local services start
-  - fingerprints declared `inputs` plus referenced step files/module inputs
-  - use this for build-once/start-many shared runtimes such as `next build` +
-    `next start`
-- `prepare.inputs`
-  - extra repo-relative inputs that should invalidate prepared artifacts when
-    they change
-- `prepare.steps`
-  - ordered lifecycle steps using the same step DSL as `database.template`
-  - each step supports `cwd` and `inputs`
+A run that skips a selected file fails, even when every other file passes, and
+`--allow-empty` doesn't change that. Use `--ignore-skip-rules` on the CLI to run
+skipped files anyway.
 
 ### `requirements`
 
-Task lock rules for a group's files, set as `groups.<name>.requirements`. Under
-legacy ownership a service's `requirements` apply to the files it owns.
+Task lock rules for a group's files, set as `groups.<name>.requirements`.
 
 ```ts
 requirements: {
   suites: [
-    { selector: "contract:payments", locks: ["payments-sandbox-webhook"] },
+    { selector: "ui:checkout", locks: ["payments-sandbox-webhook"] },
   ],
   files: [
     {
-      path: "src/api/routes/__testkit__/payout-webhook.contract.testkit.ts",
+      path: "src/api/routes/payout-webhook.test.ts",
       locks: ["payments-sandbox-webhook"],
     },
   ],
@@ -861,7 +822,7 @@ wait for each other. Use a lock for a resource that can't be duplicated, never
 for tests that share rows.
 
 - `suites[].selector`
-  - typed selector like `contract:health` or `ui:billing`
+  - typed selector like `ui:billing`
 - `suites[].locks`
   - named locks required by matching files
 - `files[].path`
@@ -872,15 +833,14 @@ for tests that share rows.
 ### `runtimeIsolation`
 
 What a group's files share with each other in a run, set as
-`groups.<name>.runtimeIsolation`. Under legacy ownership a service's
-`runtimeIsolation` applies to the files it owns. A file can set its own with
+`groups.<name>.runtimeIsolation`. A file can set its own with
 `defineFile({ runtimeIsolation: "resetBefore" })`.
 
 ```ts
 runtimeIsolation: {
   default: "shared",
-  suites: [{ selector: "contract:migrations", policy: "resetBefore" }],
-  files: [{ path: "__testkit__/orders/purge.contract.testkit.ts", policy: "resetBefore" }],
+  suites: [{ selector: "ui:admin", policy: "resetBefore" }],
+  files: [{ path: "src/orders/purge.test.ts", policy: "resetBefore" }],
 }
 ```
 
@@ -957,44 +917,15 @@ Typed suites are discovered from the filesystem:
 - a file belongs to the group with the deepest matching root in
   `groups.<name>.roots`
 - files that no group claims belong to the implicit group `root`
-- under legacy ownership, service groups take their roots from `local.cwd` and
-  `discovery.roots`
-
-Supported suffixes:
 
-- `*.contract.testkit.ts`
-- `*.data.testkit.ts`
-- `*.ui.testkit.ts`
+The supported suffix is `*.ui.testkit.ts`.
 
 Every discovered typed file must also export `defineFile({ engine: "..." })`
 from the root package. The suffix supplies `testType`; the required engine declaration
 supplies `engineId`; and Testkit derives `profileId` from the catalog. None of
 those identities are silently rewritten later in the run.
 
-`*.contract.testkit.ts` is a Node-backed service/runtime contract suite type. It
-declares `engine: "node-vitest"`, uses
-`@gfdelarue/testkit/node-vitest/contract`, runs through
-`node-vitest-contract`, and is the right place for checks that need Node APIs
-but are not data-flow evidence suites. Contract files are native Vitest suites:
-`contractScenario(...)` provides managed Testkit context when needed, while
-direct public Vitest runner APIs remain valid.
-
-`*.data.testkit.ts` is a Testkit-owned data-flow/data-contract suite type. It
-declares `engine: "node-vitest"`, uses
-`@gfdelarue/testkit/node-vitest/data`, records evidence through
-`dataScenario(...)`, and runs through `node-vitest-data`. Data suites may use
-non-registering public Vitest APIs such as `expect`, but `dataScenario(...)`
-owns case registration. Ordinary Node/Vitest assertions, DOM/browser checks,
-and service-local loopback checks belong in the appropriate non-data suite
-type.
-
-Examples:
-
-- `src/api/routes/__testkit__/auth/me.contract.testkit.ts`
-- `src/api/routes/__testkit__/runtime.contract.testkit.ts`
-- `src/api/routes/__testkit__/agent-flow.data.testkit.ts`
-- `src/db/__testkit__/sessions/count-type.contract.testkit.ts`
-- `frontend/__testkit__/navigation/navigation.ui.testkit.ts`
+Example: `frontend/__testkit__/navigation/navigation.ui.testkit.ts`.
 
 `testkit discover` exposes that inventory directly without running suites:
 

package/dist/app/lint/rules/data.js

@@ -1 +0,0 @@
-import{AST_NODE_TYPES as r}from"@typescript-eslint/types";import{binding as p,memberName as w,stringValue as E}from"../policy.js";const T=new Set(["addFinding","actor","budget","bytes","count","duration","event","externalCall","expectMetric","expectSequence","fixture","finding","http","metric","money","ratio","reconcile","record","recordCache","recordHttpRequest","recordLlmUsage","recordRpc","sequence","sequenceBudget","system","transition"]),N=new Set(["actor","bytes","duration","externalCall","http","money","ratio","reconcile","record","recordCache","recordHttpRequest","recordLlmUsage","recordRpc","sequence","system","transition"]),f=new Set(["bench","describe","it","suite","test","BenchmarkRunner","TestRunner","EvaluatedModules"]);export function createDataPolicy({context:o,file:C,report:n}){if(!C.endsWith(".data.testkit.ts"))return{};const d=new Set,h=new Set,v=new Map,g=new Map;let y=!1,b=!1;const u=(e,t,a="vitest-runner-import")=>{n(e,a,t,`Data suites cannot use ${t} for Vitest case registration; declare cases with dataScenario(...)`)},x=e=>{for(const t of o.sourceCode.getAncestors(e).reverse())if(t.type===r.ArrowFunctionExpression||t.type===r.FunctionExpression){const a=g.get(t);if(a)return a}},m=e=>e.startsWith("vitest/")&&e!=="vitest/package.json"||e==="@gfdelarue/testkit/node-vitest/contract",k=e=>{E(e)?.includes("{serviceContextUrl:")&&n(e,"service-namespace-url","serviceContextUrl","Data suites must not use serviceContextUrl placeholders because they run outside the deployed service namespace")};return{ImportDeclaration(e){const t=e.source.value;if(t==="@playwright/test"&&n(e,"browser-runtime-import",t,"Browser/runtime driving belongs in ui suites, not data suites"),(t.startsWith("@testing-library/")||t==="jsdom"||t==="happy-dom")&&n(e,"dom-runtime-import","dom-runtime","DOM/rendering tests belong in ui suites, not data suites"),e.importKind==="type")return;const a=e.specifiers.filter(s=>s.type!==r.ImportSpecifier||s.importKind!=="type");if(!(e.specifiers.length&&!a.length)){m(t)&&u(e,t),t==="@gfdelarue/testkit/node-vitest/data"&&(y=!0);for(const s of a){const i=o.sourceCode.getDeclaredVariables(e).find(l=>l.name===s.local.name);if(t==="vitest"&&s.type===r.ImportNamespaceSpecifier&&i&&h.add(i),s.type!==r.ImportSpecifier)continue;const c=s.imported.type===r.Identifier?s.imported.name:s.imported.value;t==="vitest"&&f.has(c)&&u(s,c),t==="@gfdelarue/testkit/node-vitest/data"&&c==="dataScenario"&&i&&d.add(i)}}},ExportNamedDeclaration(e){if(!e.source||e.exportKind==="type")return;const t=e.specifiers.filter(a=>a.exportKind!=="type");if(!(e.specifiers.length&&!t.length)&&(m(e.source.value)&&u(e,e.source.value),e.source.value==="vitest"))for(const a of t){const s=a.local.type===r.Identifier?a.local.name:a.local.value;f.has(s)&&u(a,s)}},ExportAllDeclaration(e){e.exportKind!=="type"&&m(e.source.value)&&u(e,e.source.value)},MemberExpression(e){if(e.object.type!==r.Identifier)return;const t=p(o,e.object),a=w(e);t&&h.has(t)&&a&&f.has(a)&&u(e,a,"vitest-runner-call")},CallExpression(e){const t=e.callee.type===r.Identifier?p(o,e.callee):null;if(t&&d.has(t)){b=!0;const i=e.arguments.at(-1);if(!i||i.type!==r.ArrowFunctionExpression&&i.type!==r.FunctionExpression){n(e,"missing-scenario-callback","dataScenario","dataScenario(...) must provide a callback that receives the Testkit data context");return}const c=i.params[0]?.type===r.AssignmentPattern?i.params[0].left:i.params.at(0),l=c?.type===r.Identifier?o.sourceCode.getDeclaredVariables(i).find(D=>D.name===c.name):null;if(!l){n(e,"missing-data-context","dataScenario","dataScenario callbacks must accept the Testkit data context and record data evidence");return}const S={callback:i,context:l,contextName:l.name,methods:new Set,assertion:!1};v.set(e,S),g.set(i,S);return}const a=o.sourceCode.getText(e.callee);e.callee.type===r.MemberExpression&&a.includes(".serviceContextUrl")&&n(e,"service-namespace-url","serviceContextUrl","Data suites run in the managed Node.js runner, not inside a service namespace; use baseUrl/public endpoints or move service-namespace checks to contract");const s=x(e);if(s&&(/^(expect|assert)(?:\(|\.)/u.test(a)&&(s.assertion=!0),e.callee.type===r.MemberExpression&&e.callee.object.type===r.Identifier&&p(o,e.callee.object)===s.context)){const i=w(e.callee);i&&T.has(i)&&s.methods.add(i)}},"CallExpression:exit"(e){const t=v.get(e);if(!t)return;const{callback:a,contextName:s,methods:i,assertion:c}=t;i.size?[...i].some(l=>N.has(l))||(n(a,"weak-data-evidence",s,"Data scenarios must record product data-flow evidence such as http, bytes, sequence, record, transition, system, externalCall, recordCache, recordLlmUsage, or reconcile; ordinary Node/Vitest-style checks belong in *.contract.testkit.ts with @gfdelarue/testkit/node-vitest/contract"),c&&n(a,"vitest-shaped-data-suite",s,"This dataScenario looks like an ordinary assertion test with weak data bookkeeping; move Node-backed contract checks to *.contract.testkit.ts or model the product data flow with structured evidence")):n(a,"missing-data-evidence",s,"Data scenarios must record Testkit-owned data-flow evidence with the data context, such as http, bytes, sequence, record, transition, system, externalCall, recordCache, recordLlmUsage, or reconcile")},ThrowStatement(e){const t=x(e);t&&(t.assertion=!0)},Literal:k,TemplateLiteral:k,"Program:exit"(e){y?d.size?b||n(e,"missing-data-scenario","dataScenario","Data suites must declare at least one dataScenario(...)"):n(e,"missing-data-scenario-import","dataScenario","Data suites must import dataScenario from @gfdelarue/testkit/node-vitest/data"):n(e,"missing-data-import","@gfdelarue/testkit/node-vitest/data","Data suites must import dataScenario from @gfdelarue/testkit/node-vitest/data")}}}

package/dist/config/authoring/runtime.js

@@ -1 +0,0 @@
-let o=null;export function registerRepoConfig(n){o=n??null}export function getRepoConfig(){return o}export function clearRepoConfig(){o=null}export function resolveHttpProfile(n){if(!n)return null;const t=getRepoConfig();if(!t)return null;const r=t.profiles?.http?.[n];if(!r)throw new Error(`Unknown testkit HTTP profile "${n}"`);return r}

package/dist/config/loader/task-policy.js

@@ -1 +0,0 @@
-import{matchesSuiteSelectors as a}from"../../domain/suite-selection.js";import{normalizePath as l}from"./paths.js";import{resolveRuntimeIsolationPolicy as i}from"./runtime-isolation.js";export function resolveTaskPolicy(o,t,r){return{locks:m(o,t,r),runtimeIsolation:i({testkit:o},t,r)}}function m(o,t,r){const n=l(r),s=new Set;for(const e of o.requirements.suites)if(a(t.testType,t.name,[e.selector]))for(const c of e.locks)s.add(c);for(const e of o.requirements.fileLocksByPath.get(n)??[])s.add(e);for(const e of o.fileMetadataByPath.get(n)?.locks??[])s.add(e);return[...s].sort()}