The e2e test harness bundles its own test-time analogues of celilo modules — a
“-sim” variant of the website, a stand-in registry, and about a dozen more. Every
one is a parallel-evolution trap: change the real module and you have to remember
to update its simulator twin, and the drift between them stays invisible until a
test fails. But modules already publish themselves to celilo.computer. The
registry is right there — so cele2e should download modules at test time
rather than ship its own copies baked in.
The harness owns the internet, nothing else
@celilo/e2e will keep exactly what’s genuinely generic: the simulated internet.
That’s the DNS hierarchy, the public/private boundary, the firewalls, ACME via
Pebble, the apt cache, and the management container that runs celilo. Anything
that is “the e2e variant of a specific module” goes away — that behavior belongs
to the module itself.
Fetch, don’t bundle
Modules will be fetched from celilo.computer at test setup time instead of bundled
into the harness’s package. Monorepo development stays easy through an explicit
--local <path> flag rather than implicit environment guessing, so behavior is
identical whether you’re in the monorepo or a fresh install. A module’s authority
to deploy on your network is the same authority it has to join your simulator —
no separate “blessed” tier.
Seed data through backup-restore
A module that needs test-time data — DNS zones, a pre-populated database — will
ship a seed backup in the same file format and restored through the same hook
as a production backup. The harness reads the module’s existing
requires.system.zone to decide which network it joins, and allocates its IP
itself. No new fixture concepts; the module reuses what it already has.