Platform control-plane end-to-end runner

@wildo-ai/platform-e2e-runner provides the control-plane half of the end-to-end substrate: the back-office API surface, the three principals a request can arrive as, the shared verdict for a service-token read, and the assertions built on them. Three scenarios in the shared registry use it, and the package also carries its own browser and API lanes plus a deliberately opt-in destructive recovery journey.

The problem it solves

The platform services are what manage applications: they hold each application’s configuration, issue its credentials and register its scheduled work. An application’s own tests cannot cover them, because from an application’s point of view the control plane is simply somewhere its configuration comes from. Nothing else would look at them at all.

They also fail in a shape that ordinary assertions miss. A control plane that manages secrets can answer a configuration read successfully while logging a fatal error resolving a managed-secret branch, so a successful status is not evidence that the read was correct. And a key generation can drift, where the stored verification key and the materialised signing key stop matching, which presents as an authentication refusal that reads like a configuration mistake and is really a broken initialisation.

What it does

A separate end-to-end lane for the control plane, built around the fact that the control plane is not an application: no provisioning, no tenant, no adapter, and one observation scope.

Its surface drives the back-office API and returns the status and body for ANY status — so a refusal is data the caller classifies rather than a thrown error.

Three principals are supported, matching the three doors the control plane actually opens: an application’s own platform credential, which is exactly what a real backend sends; an administrative credential; and a service token. A call can override the default, so one scenario can prove that a door which should be shut is shut.

The service-token verdict lives in ONE place. Every control plane classifies the same way — served, key generations incoherent, or an unexpected fault — and only the human-readable message differs per door, so each door supplies its wording and the classification is written once.

The gated entry point reuses the registry, the replay command and the fatal-gate wrapper from the application lane, and changes only the gate’s SCOPE. The development command tees the platform tree and the application tree into one log with per-line labels, so the platform gate reads only the platform lines: an application’s fatal error never reds a platform run and a platform fatal never reds an application run.

One of its contract lanes checks the customer-infrastructure double against wire drift — which is how an independent double stays independent without silently diverging.

Limits

The three platform scenarios are on a separate axis from the application matrix and appear in no application’s declared list, so the application command never runs them.

The recovery journey is destructive by design: it wipes every local backing service’s data. Gated behind an explicit flag and meant for a disposable runner, never for a developer’s working stack.

The package has no local container-first workflow and no in-cluster lane; both are stated as non-goals rather than as gaps to be filled later.

The contract lane is a placeholder that skips TRUTHFULLY when no executable contract suite exists — a deliberate choice over a lane that reports green having run nothing.