valis - Build TODO

The store is built strictly bottom-up: block, then tree, then the generation-fenced head (the spine), then the manifest, the fabric adapter, reassembly, the fence↔revocation unification, caching, and the end-to-end migration proof. The fossil/venti replacement point named in the first arc's item 6 is the store-store adapter of item 14.

1. [X] Content-addressed block store. A write-once, hash-addressed, integrity-verified block primitive: the foundation everything else hangs off.

   Done when

   writing octets returns a content address whose hash recomputes from the stored bytes; a corrupted block is detected on read, never served; identical content dedups to a no-op; and a block reported written survives a kill -9 plus drop_caches.

   Landed

   a file-per-block store over portable Lisp stream IO with the proven fs-store fdatasync→rename→dir-fsync durability discipline, SHA-256 behind a swappable store-block-digest seam, and an in-memory index plus bloom filter so a miss avoids a seek.

2. [X] Tree codec. A single hash names a whole subtree; snapshots share unmodified blocks by content identity.

   Done when

   one root hash resolves a directory tree to its leaf blocks and the same logical tree always encodes to the same root hash; changing one leaf writes only new blocks on the path to the root; and a snapshot is an O(1) retained root that copies no bytes.

   Landed

   deterministic, dedup-friendly directory and file node encoding through the block seam, importing nothing from valis's capability/namespace packages.

3. [X] Generation-fenced mutable head: the spine. A monotonic, generation- fenced root pointer advanced by compare-and-swap, where a superseded write is rejected at the commit and a recovered head always names a fully-durable tree.

   Done when

   a write carrying a superseded generation is rejected at the commit even after an injected stop-the-world pause lands it arbitrarily late (the Kleppmann fencing-race proof); the generation is strictly monotonic, 64-bit, store-allocated; every block is durable before the head names it; and a recovered head needs no repair pass.

   Landed

   CAS-advance of the root pointer via an atomic rename as the single linearization point, validated by a kill -9 + drop_caches + injected-pause fault-injection harness.

4. [X] Namespace manifest. The mount table made literal, living inside the mutable tree, reachable from the head, so it migrates atomically.

   Done when

   the serialized manifest contains no key bytes and no derivation seed (a structural bar with a regression test); it pins a specific generation and everything it references is durable before it is published; a first boot with no manifest reproduces today's axes exactly; and a manifest with a bad hash or a missing root is rejected fail-closed.

   Landed

   a versioned manifest inside the durable tree referencing only key locations and trust-domain identifiers, defaulting to the live six-axis set so a fresh boot is byte-identical to the first arc.

5. [X] store-store adapter and fabric wiring. The durable store dropped into the running fabric behind seven's backend node layer: no new 9P wire surface.

   Done when

   /pub serves byte-identical results over the durable store as over fs-store (no first-arc regression); start-fabric selects the durable backend with a one-line swap; a /pub write goes through the head CAS as a single-writer mutation; and the subsystem cold-builds with the new backend selected.

   Landed

   the publication store seam implemented over head and tree, selected at fabric start-up, with mtime/version synthesized from the head generation rather than a POSIX mtime.

6. [X] Assembler manifest path and reassembly. A fresh instance reconstructs the namespace from the manifest plus the owner's keys: reassembly-not-transfer.

   Done when

   a fresh instance reads head → manifest → roots and reassembles the same namespace; reachability of every referenced root is verified before the namespace is declared assembled, fail-closed on any missing root; a clean install with no manifest reassembles today's axes; and the destination cannot come up without an out-of-band key acquisition step.

   Landed

   the assembler's canonical-frame builder gained a manifest-driven path; keys arrive out of band through the existing factotum/custody path and never travel in the manifest.

7. [X] Fence ↔ revocation unification. Evacuation fencing and capability revocation collapsed into one append-only monotonic authority log.

   Done when

   standing up a new instance bumps the generation as its first durable act and the store rejects the superseded instance's subsequent writes; that superseded generation is expressed as a revoked write capability on the existing append-only revocation log, checked on the same write path as a revoked hash; live write-capable grants under a fenced generation are swept from active sessions; and single-writer authority is enforced at the store, not by a clock-based lease.

   Landed

   a write capability carries a generation stamp inside its owner-signed bytes and is rejected at verify time on the same membership check as a revoked token, with the head CAS as the commit-point backstop and a write-right eviction sweep for live grants, so fencing and revocation cannot drift apart.

8. [X] Caching coherence and qid.version. Coincident instances get read-your-writes against the single-writer head without funneling all reads through it.

   Done when

   a write through one instance is visible to a coincident instance within the staleness bound, without the reader funneling through the writer; an immutable-block cache hit is always valid (the score is the validator) and only the head needs revalidation, keyed to the current generation; qid.version tracks the generation so a conditional GET / ETag returns 304 and kernel v9fs caching stays correct under mutation across instances; and the cache honours an explicit byte budget with every pin released on every exit path: no pin leak, no finalizer-based release.

   Depends on

   the generation-fenced head (item 12) and the store-store adapter (item 14).

   Landed

   qid.version tracks the head generation so a conditional GET / ETag returns 304 and kernel v9fs caching stays correct under cross-instance mutation; an immutable-block cache hit validates by its score and only the head revalidates, keyed to the current generation; the cache honours an explicit byte budget with every pin released on every exit path. The seven sibling carries the matching qid.version backend stamp.

9. [X] Migration/evacuation end-to-end. The thesis proven end to end, with the auditor-facing architecture document shipped.

   Done when

   a fresh instance reassembles from manifest plus out-of-band keys and serves the namespace while the evacuated instance's writes are fenced and its live grants swept; an old instance paused across the generation bump cannot land its commit (the fencing race re-verified end to end, across a GC pause); a confused-deputy audit confirms no store, backup, or observability path ever reaches decrypted content (the store handles opaque blocks only: encryption-ready, not encrypting); and docs/ARCHITECTURE.org is updated to capture the fencing/CAS/migration flow.

   Depends on

   reassembly (15), the fence↔revocation unification (16), and caching coherence (17).

   Landed

   a fresh instance reassembles from manifest plus out-of-band keys and serves the namespace while the evacuated instance's writes are fenced and its live grants swept; an instance paused across the generation bump cannot land its commit (the fencing race re-verified across a GC pause); a confused-deputy audit confirmed no store, backup, or observability path ever reaches decrypted content (opaque blocks only: encryption-ready, not encrypting); and docs/ARCHITECTURE.org carries the fencing/CAS/migration flow. The seven sibling carries the matching drain-on-evacuation teardown. The second arc is complete.

The store is the spine of the durable substrate and stays architect-held, built in-tree with the dependency ordering reviewed before each piece begins. The boundaries open in the same places as before:

• The one seven dependency (a bulk-transfer msize ceiling for the read/walk/write path) lands in seven as a sibling repository; this arc may depend on its arrival but plans no seven-internal work.
• libp2p/IPFS content-addressed block transport remains a later, separable sibling unit: the future repository boundary is the block transport, not the store itself, which is why the store cluster is kept import-clean from day one.

valis owns the plugin plumbing: the module class, the registry, the admission gate, and the manifest stay architect-held. The boundary opens at the adapters:

• c3po (the protocol adapters): a separate sibling repository. With the seam landed and its exported surface signalled, c3po has carried its HTTP, Gopher, and Finger adapters onto valis's real edge seam (the conversion is complete); they ride reassembly as ordinary vouched modules through the admission gate. SMTP is parked for the messaging substrate (architect-led).
• libp2p/IPFS as the live module-distribution transport remains the named gate for a later milestone: content addressing stays local and seam-shaped here, so the admission gate is transport-agnostic when that distribution path arrives.

The factotum is identity-critical and its seam stays architect-held, but the work is inherently cross-repo:

• mercer (the factotum): the sibling repository that becomes the home of the transport authenticator and, later, the broader key-custody surface. It owns the independent-vector validation and the cryptographic review.
• seven (the 9P keystone): owns the 9P auth seam the authenticator sits over; coordinates the interface mercer's handshake rides.

The spine is the substrate; the wire is the sibling's. The split holds across the subsystem:

• c3po (the protocols): owns the SMTP and IMAP wire engines that ride the mail spine through the adapter seam, and (for the deliverability arc beyond) the SPF / DKIM / DMARC evaluators. valis owns the substrate, queue, router, and the adapter seam they plug into.
• mercer (the factotum): for the deliverability arc, owns the DKIM key custody and the sign / verify crypto; the contract with c3po stays opaque ("sign these octets") so the private key never crosses into the parser.

The seam is built foundation-first: the PostgreSQL operator-state seam, then the zone schema and the :names door over it, then the DNS adapter seam and in-memory zone view, then the secondary-first cutover substrate. The runciter sibling scaffold and the versioned seam contract overlap the foundation because the cross-repo coordination with c3po-dns has lead time.

1. [X] Scaffold runciter and the DNS adapter seam contract. Stand up the runciter DNS-substrate sibling and define the versioned seam contract the :53 wire engine binds to, stubbed locally, so the cross-repo interface is versioned before the substrate that fills it is built.

   Landed

   the runciter sibling exists and carries the DNS substrate; valis names a versioned, fail-closed adapter seam and no concrete wire engine, with the c3po-dns binding deferred to its own roadmap and stubbed here.

2. [X] The PostgreSQL operator-state seam: the foundation. The mutable, pooled, fenced dao-class seam every later axis reads through, where a body never enters the database and two valis sharing one database cannot both write.

   Done when

   the seam is wired into the fabric boot/teardown path; the store generation is projected into PostgreSQL fence-first on evacuation, so a superseded instance cannot write; and a body is structurally barred from the database (pointer-hash only).

   Landed

   the fenced dao-class pool stands up and tears down with the fabric; the generation projects fence-first on evacuation, proven across the real fabric evacuation path so coincident instances on one database cannot both write.

3. [X] Zone schema, the :names axis, and the BIND text parser. Zones live in PostgreSQL and are mutated only through the capability-gated :names axis; legacy BIND zone files parse correctly into :names rows.

   Done when

   a zone is authored and mutated only through :names, never by reaching the table directly; and a legacy BIND zone parses into canonical rows.

   Landed

   the zone schema lives behind the operator-state seam, the :names axis is the sole capability-gated door to it, and the BIND text parser canonicalises legacy zones into rows.

4. [X] The DNS adapter seam, the in-memory zone view, and the stub-adapter proof. Prove the seam end to end with the wire stubbed: a decoded query resolves through the in-memory zone view, independent of the database hot path, admission fail-closed.

   Done when

   a decoded query resolves through the zone view to a record set and result code; a kill-PG-mid-load leaves the last good view serving; and a DNS wire module is admitted only as a capability decision, fail-closed.

   Landed

   the in-memory serving view answers off the database hot path and degrades to serve-last-good across a PG outage; the versioned adapter seam resolves a decoded query end to end against a stub wire engine; admission is a capability decision.

5. [X] The cutover substrate: secondary-first zone sink/source. Ingest a legacy zone as a secondary, track its SOA-timer and cutover policy, and support the outbound-feed and serial-bump data side, so a domain can be moved onto valis before valis answers as its primary.

   Done when

   a zone is ingested as a secondary and tracked through the cutover lifecycle (held → answer-as-secondary → primary, operator-gated); a held or expired secondary never enters the serving view; serve-time expiry is enforced fail-closed against the persisted absolute deadline; and cutover legality is decided by runciter through the seam, never re-implemented.

   Landed

   the per-zone /ctl flips (answer-as-secondary → promote-to-primary) with runciter-decided legality through the serving seam and a fenced persist; the answerability gate is centralised at the refresh-zone install chokepoint; serve- time expiry is enforced against the persisted absolute deadline (restart-safe bigint epoch timers); and the outbound zone-change feed is fault-isolated. The runciter pin is tightened to 0.3.0 with the typed rdata-parse-error adopted fail-closed on the import and per-zone read boundaries. Merged to main via PR #32 (352c2ff).

6. [X] Resolver policy and the mail-drain seam. runciter's MX resolution policy, wired into the v1.4 mail drain to close the deferred MX-over-DNS slice, so an outbound message resolves its recipient's exchanger through the sovereign DNS substrate rather than a stubbed lookup (the resolver wire itself stubbed).

   Done when

   the mail drain resolves a recipient MX through runciter's resolver policy behind the seam; the resolver wire is stubbed but the policy and the seam are exercised end to end; and the deferred MX-over-DNS slice in the mail spine is closed.

   Landed

   the mail drain routes relay entries through an injected resolver and maps runciter's four MX outcomes onto the delivered/deferred/bounced queue vocabulary, proven end to end over stub-wire DNS with no live wire. The seam is versioned around runciter's resolve-mail-exchangers; the wire client fills it later. Merged to main via PR #37. The real-wire cutover (inject the live resolver at the production boot seam and retire the smarthost) is item 41 below, still open.

7. [X] Operator-state migration and the per-axis sovereignty model. Carry the mail-transport state and the social graph onto the PostgreSQL seam, then document and audit the per-axis sovereignty boundaries.

   Done when

   mail-transport state and the social graph live on the operator-state seam alongside the DNS zones; and the per-axis sovereignty model is documented and audited. One principle, three boundaries: a content boundary for mail bodies, write-authority for DNS zones, capability-scoped access for the social graph.

   Landed

   mail-transport state and the social graph sit on the operator-state seam alongside the DNS zones; the per-axis sovereignty model is documented and audited: the content boundary for mail bodies, write-authority for DNS zones, and capability-scoped access for the social graph each hold as a distinct axis.

8. [X] valis becomes the pure ndb DATA owner: the nameserver serving layer moves to runciter. Conform the DNS code to the architecture of record: valis holds the authoritative zone data and dispatches connections; the logical nameserver (runciter) holds the serving index and composes every answer.

   Done when

   valis holds no DNS answer logic and no serving cache: it exposes the zone data through the zone-data-source read protocol (plus the held-inclusive origin set and the per-zone cutover status the nameserver gates answerability on), and the bind registers runciter's serving handler at the agreed contract version, fail-closed; a held or expired secondary still never answers, now enforced from the cutover-status data plus runciter's gate rather than a valis serving view.

   Landed

   the in-memory serving layer (the loaded-zone index and the RFC 2308 answer composition) is shed from valis and relocated to runciter, parity-checked branch-for-branch before the shed; bind-dns-view registers (make-dns-service-handler <pg-zone-source>) via late resolution at contract-version 1; the transitional serving-seam fallbacks are deleted (the seam is thin late-bound delegation, fail-closed); serve-last-good is handed to runciter with an explicit audit confirmation rather than dropped; docs/CONSTELLATION.org and docs/ARCHITECTURE.org record the split. Pending merge to main; the runciter pin tightens to its serving-module tag when that repo is merged and tagged.

9. [X] TSIG-gated zone-transfer allowlist and serial monotonicity. valis owns the transfer-peer allowlist as capability-mediated operator-state and enforces RFC 1982 serial monotonicity on the transfer path; no zone reaches the wire except to an allowlisted, authenticated peer.

   Done when

   a zone leaves valis only to an allowlisted peer, the allowlist is mutated only through the capability-gated operator-state door, and a non-monotonic serial is rejected before it can be emitted.

   Landed

   the allowlist verdict is injected into runciter's authorize-before-emit gate through the seam (bind-transfer-authorizer mirrors bind-dns-view), serial monotonicity is carried on the transfer path, and the gate is proven end to end across the repo boundary. Merged to main via PR #42 and PR #43 (04f41a4).

10. [X] Authoritative answers on :53 through fail-closed admission. valis answers authoritative DNS on :53: a steered connection is dispatched to the admitted DNS module fail-closed, and with runciter's serving orchestration and c3po's wire codec landed, the answer is externally probeable: non-recursive and amplification-bounded.

    Done when

    a steered :53 UDP/TCP descriptor is admitted fail-closed and pumped through the wire codec onto runciter's serving exchange; the serve loop starts from boot once the DNS view binds and disarms on module revocation; and an out-of-band probe from a stranger vantage confirms authoritative, non-recursive answers with EDNS0@1232 and TC/TCP fallback bounding amplification.

    Landed

    two steered :53 fds sit behind one admitted handler; queries pump through c3po's codec onto runciter's serve-exchange; the loop boots with the DNS view and retires fail-closed on revocation (a revoked fd stays live yet serves nothing); and an out-of-band probe from a stranger vantage confirms authoritative, non-recursive answers with amplification bounded. Merged to main via PR #44 (7b6579d).

11. [X] Real-wire mail-drain resolver cutover: retire the smarthost. Inject runciter's live MX resolver into the production outbound drain and remove the static smarthost fallback, so an outbound message resolves its recipient's exchanger over the real DoT wire, fail-closed against a hung or hostile upstream. The stub-wire seam (item 36) is the substrate; this closes it onto the live wire.

    Done when

    the production drain boots with the live resolver as the MX source and the smarthost fallback is gone from the delivery path; a resolvable recipient delivers to its preference-sorted MX; a transient failure (SERVFAIL, timeout, TLS or auth failure, budget exhaustion) defers and never loses the message; a null-MX or NXDOMAIN bounces; the resolve is deadline-bounded so a hung upstream defers rather than stalling the drain thread; a wrong-cert DoT upstream defers, never delivering over an unauthenticated or downgraded channel; and the resolver stays client-only, with no inbound listener or accept loop.

    Landed

    the production drain builds runciter's live DoT resolver at boot (late-bound, so valis stays cold-loadable without it) and resolves each relay recipient's MX over the real wire; the static smarthost is gone; an unresolved, unconfigured, or empty-trust upstream DEFERS rather than delivering; the open-relay guard is unchanged. All mail suites green, cold-hermetic. Merged to main via PR #45 (4ba6004), over runciter's make-mail-resolver (PR #19).

The substrate and the seams stay architect-held; the wire and the resolver engine are the siblings'. The split holds as in the prior arcs:

• runciter (the DNS substrate): owns the zone model over PostgreSQL, the :names semantics, BIND text parsing, and the resolver policy; coordinated cross-repo, with merge and tag operator-gated.
• c3po-dns (the wire): owns the RFC 1035 binary engine on :53 (serving, AXFR/NOTIFY, the resolver wire client), on its own roadmap and gated on valis signalling the DNS adapter seam; stubbed locally through this arc.

The primitive lands first (the descriptor crossing and the shared fd-passing seam), then the resident boot that consumes it, then the two hardening pieces: a race-free push at the wire and the privileged launcher for the live-kernel bring-up.

1. [X] The descriptor peer and the shared fd-passing seam. An SCM_RIGHTS descriptor-passing primitive with fail-closed admission: a single caller-owned descriptor crosses the process boundary and every crossing goes through one shared seam.

   Landed

   the SCM_RIGHTS primitive gates each crossing through fail-closed admission (a multi-descriptor control message is refused, a sent descriptor stays caller-owned, syscall returns are checked), proven cold across a real process boundary by a fresh-SBCL-child spawn harness; the edge passes every descriptor through the one shared seam. Merged to main via PR #48 and PR #49.

2. [X] The resident boot on the pushed descriptor. valis boots its edge on the steered LISTEN descriptor pushed from the privileged host agent, fail-closed: the resident listening path replaces the loopback stand-in.

   Depends on

   the descriptor peer and the shared seam (item 42).

   Landed

   valis mints its designated-port LISTEN descriptor in production and a resident boot brings the steered edge sources up on the descriptor pushed over a 9P control client; a --resident dispatch boots fail-closed with the shipped adapter set, and the bounded control-push read closes a failed dial. The push sends the descriptor only after the control-port write drains, and the crossing is proven over a real process boundary. Merged to main via PR #51.

3. [X] A race-free descriptor push. The production descriptor push crosses race-free at the wire, so no buffered read on the receiver can over-read the carrier byte and silently discard the passed descriptor.

   Done when

   the sender pushes the descriptor immediately after the control frame with no out-of-band readiness marker and the descriptor still crosses race-free; the carrier byte is only ever consumed by a control-armed receive, never a plain buffered read; and ordinary control frames stay byte-identical.

   Depends on

   the resident boot (item 43). Today's production push is fail-fast: it makes the race loud with a read deadline, not gone.

   Note

   the reader that guarantees this is owned by the seven sibling (its AF_LOCAL control-endpoint reader); valis's sender adopts it by swapping its push seam onto seven's primitive with no construction change, retiring the in-test readiness barrier and the hand-rolled raw-frame push while keeping the read deadline as defence-in-depth. fulcrum's receiver adopts the matching guard. Merged to main via PR #55.

4. [X] The privileged resident launcher. The host agent brings the resident unit up under a real network namespace and hands over the descriptor across a well-known control socket, so the steered path comes up from a single privileged bring-up rather than a manual stitch-together.

   Done when

   the fulcrum host agent launches valis into the network namespace it steers and hands over the LISTEN descriptor across a well-known control socket, and the resident unit is reachable on its steered port without a manual bring-up.

   Depends on

   the resident boot (item 43); independent of the race-free push (item 44).

   Landed

   the fulcrum launcher brings the unit up in the network namespace it steers, under dropped privilege, and constructs the control socket valis dials. Every resident boot that names that control socket pushes its steered socket and takes up the session, even with nothing to declare, so the live host comes up from one supervised bring-up. Merged to fulcrum main via PR #4; the session on every boot via valis PR #370.

5. [X] Live-kernel capstone. The whole resident path (steer, push, resident boot, answer) proven end to end on a real kernel from an out-of-band operator run.

   Done when

   an out-of-band operator run steers a designated port on a real kernel, pushes the descriptor to a resident valis, and a stranger-vantage client is answered on the steered port through the resident edge, with valis holding no privileged kernel state.

   Depends on

   the race-free push (item 44) and the privileged launcher (item 45).

   Landed

   the live host's bring-up is that run. Its resident holds no privileged kernel state. Every TCP connection to its served ports, :80 and :443 included, arrives through the steer, and a client off the host is answered on the port it dialled. A fresh image shows the same in the proving ground (item 53). Deployed to the live host with valis PR #370.

The resident path is the valis process's own and stays architect-held; the privilege stays across the repository boundary, as in every prior arc:

• seven (the 9P keystone): owns the race-free control-endpoint reader the descriptor push rides; valis and fulcrum adopt it as consumers with no re-plumb.
• fulcrum (the privileged host agent): owns the network-namespace launcher and the well-known control socket that bring the resident unit up on a real kernel, and adopts the receiver-side guard for the race-free push.

1. [X] Public authoritative DNS on :53. The resident serves authoritative DNS to the public internet on UDP and TCP, no geoblock, CAA answered correctly, reachability proven off-host, the dns-01 precondition.

   Landed

   fulcrum binds :53 UDP/TCP in the netns and exec-inherits the descriptors to an unprivileged valis, whose resident boot adopts them and drives the sibling serve loop over them with a pg-zone-source: no privileged/loopback bind. CAA and TYPE257 answer NOERROR/NODATA; the serving path is proven end to end off-host in a real-kernel integration gate, and a multi-region reachability harness proves worldwide answerability and gates the public go-live. Merged to main via PR #58.

2. [X] The host-deployment contract and the deployment proving ground. A durable, declarative harness that stands Debian guests up from source and drives valis's own deploy == condense-from-genesis path under assertion, plus the written contract.

   Landed

   docs/deployment/host-deployment-contract.org states the prerequisites, bring-up order, provisioning, teardown, and fail-closed invariants. proving-ground/ pins a Nix verification fabric, boots a two-location VLAN-tagged Debian topology via Terraform-libvirt, provisions with cloud-init, and drives three scenarios (deploy, evacuate, restore) over one mechanism through an in-image Lisp/SSH assertion layer (valis-proving-ground, its own ASDF system). The scenarios assert the shipped condense/fence path; the harness is unit-green against fixtures, with a live libvirtd run the one out-of-band step. Merged to main via PR #59.

3. [ ] The active-module (resident/lifecycle) seam. A start/stop/supervise module kind with capability-scoped egress, boot-supervised, proven with a trivial no-op module: the non-reactive second module archetype the ACME manager will consume.

   Built

   the archetype exists and the renewal manager registers through it; module admission runs from the durable manifest.

   Not yet true on the live node

   no active module has ever been admitted there.

   Corrected since

   this used to read as a certificate fault, the node reporting no certificate in custody while holding a complete chain and key on disk, because the status line read an enumerator that was never bound to the credential store. It no longer does. The cert gate loads the credential for the configured edge domain straight from the ACME store path, and the readiness status is handed that same resolved fact rather than re-deriving one. The independent cert-expiry watch still goes through a custody enumerator seam, which is a different surface and was not the one reporting wrongly.

4. [X] The ACME/dns-01 manager and public HTTPS on :443. Obtain and renew a real TLS certificate over ACME dns-01 (mercer custody), terminate server-TLS, and serve the anonymous /pub view over public HTTPS on :443, with the fabric absent from the public wire and a restore-tested backup before exposure.

   Already on main

   the server-TLS termination seam with renewed-cert hot-reload; the :443 edge itself, terminating to the anonymous /pub view with the fabric structurally absent from the public wire; the challenge machinery, proven against a real CA, with five Let's Encrypt vantages observed querying the challenge name on the wire; and the order lifecycle through to a downloaded chain.

   Done since

   a production order was placed and the public :443 serves it. The live node answers for deepsky.systems under a Let's Encrypt chain that verifies off-host. The edge stays dark by design without a certificate, and that gate behaves correctly.

   Landed

   every zone the live node is authoritative for is answered on :443 under its own certificate, rhipidon.eu and rhipidon.ca included. Item 52 records how.

   ⚠ Known before the next attempt

   opening :443 requires the port to be declared to the host agent and admitted by its firewall, which then admitted :53 only. Declaring the port on the valis side without the matching firewall admission took the nameserver down for two minutes on 2026-08-13; a missing edge port now degrades to a dark :443 instead of killing the resident.

5. [X] The owner control plane over a running node. Owner authority over a running node became withdrawable, and content became placeable on a node that is already up rather than only on one being created.

   Landed

   Live sessions are registered with an identity an operator can read off a listing and type back, and the identity axis carries a door that reports the live sessions and fences the one it is told to. A session is also fenced by idleness, checked by the operation that wakes it, with the bound unset by default so no deployment is locked out by an upgrade it did not ask for; and by an authority transfer, so an instance that has surrendered write authority stops serving an owner after an evacuation. An owner-keyed publication verb places a page on the running node, and the client verbs list and fence a session from outside the image. Merged to main via PR #116 and PR #117.

   Off-host reach

   PROVEN on a deployed node, from the owner's machine. The node's DID was read on its host and pinned before the port opened, and the client first refused an attach with no pin, with nothing dialled. The host agent's owner-port verb and a restart moved the port closed, open, closed, and open again, each reading taken from off the host beside a port the node admits and one it drops. The pinned attach with an enrolled device key listed the keyring, the client refused a pin naming another DID, and a key the node never enrolled got an empty view. The director carries every connection to the owner port to the owner terminus: a silent connection is cut at 10 seconds, a fifth connection from an origin already holding 4 is refused at accept, and only the terminus's claim on the port arms the handshake bound and the connection cap. Recorded in the runbook's off-host route.

   Managed from the owner's machine

   With the node pinned and an enrolled device key, the owner reaches these surfaces with valis --node NAME: zone records, certificate obtain, publication, configuration, the served set, and restart. Each was driven against a test node and each change read back after it took effect: a zone record answered and then gone over UDP and TCP, a page published and revised, a setting and the served set changed and put back with no restart, a certificate issued over dns-01 by a test authority, and a restart answered from a new boot identity. A key the node never enrolled was refused by every one of those verbs with exit 2, and nothing changed. The runbook leads each of those sections with this route and keeps the host as the break-glass. The same run then held on a deployed node that serves the public, with no shell on its host: the zone record, the page, a live setting taking effect at the owner port, the served set read open and closed from off the host, a certificate from the production authority served on the :443 edge with no restart, and a restart to a new boot identity with the key still enrolled, each read back. A key the node never enrolled was refused by every verb.

   Still open after the off-host proof

   The owner-port verb takes effect only at a restart of the unit. ubik is proven on a test node: it attaches with its own key, its panels manage the node, and it attaches again after a restart or a lost connection. ubik has also managed a deployed node that serves the public, and attached again there after a restart it sent. Not yet shown on that node are a ubik session coming back on its own after something else restarts the node, a lost connection without a restart, and a certificate ordered through ubik. ubik's publication panel, its scrolling, and its configuration panel have the rough edges the runbook lists. ubik shows each key's live sessions but does not fence one, which waits for richer session control on the node, and it enrols no key: a device key is enrolled on the node's host, by design. Enough origins together can fill the owner port's all-origin cap of 16 and keep the owner out while they keep reconnecting. An enrolled key does not yet reach the owner frame over the :443 edge. No verb retracts a publication. The served set's per-port door, /edge/served/ctl, has no command-line verb; ubik's served-ports panel composes its request. A transfer key for a zone's secondary is minted only on the node's host. Mail is not managed from the owner's machine. The first certificate order is not refused on a node whose acme.production is false, although a renewal there is.

   The remaining half

   A fence does not revoke a handle already open below the session root, so a client holding one keeps it until the revocation reaches it. The remedy is a generic per-session handle revoke in the 9P library, which needs to know nothing about owners or fences. That mechanism has since landed upstream; valis is not yet wired to it, so the limit stands here for now.

The public exposure and privilege stay across the repository boundary, as in every arc:

• fulcrum (the privileged host agent): owns the :53=/:443= exposure, the netns and firewall, and the launcher that brings the resident unit up.
• mercer (the credential authority): owns the ACME lifecycle, the dns-01 digest, cert custody, and the server-TLS termination seam.
• runciter (the DNS service module): serves the transient challenge TXT for dns-01.

• valis is the primary authoritative server for the registered domains. The lame delegation is closed, a sibling host runs as an AXFR secondary, and zone data lives in PostgreSQL as operator state. Zone editing is typed and structured; the master-file text format is a boundary format for the secondary, never the edit format.
• A node can be brought up from nothing and made to serve DNS. The acceptance gate provisions a guest, installs the delivery artifact, and drives the resident up on it. Two checks in that gate could not have reported a failure and were corrected: the gate's exit status now carries its verdict, and the write-fence assertion authenticates as the account that holds the row.
• Connections may outlive a request, in the codebase. The edge no longer assumes a client-speaks-first, reply-only protocol, which is the precondition for every continuous protocol after it. Not yet exercised on the live node.
• A running node can be updated and published to without being rebuilt, and the operator reaches it over an authenticated path rather than by editing files on the host.
• A certificate renewal completes end to end in the deployed shape. Proven on a two-NIC guest in the deployed shape, against an authority that resolved the dns-01 challenge rather than being told to accept it. The defect that had stalled every local proof for months was ours: an outbound connection was not asked for as a duplex stream, so the request sat unsent. A public authority's handshake happens not to arrive in the order that exposes it, which is why certificates kept coming back from the field while every local proof hung.
• The edge holds one credential per served name, so a request for one name is no longer answered with another name's certificate.
• A deploy refuses before it moves anything the node cannot run, from one declaration that the boot path and the deploy path both consult. The refusal comes before the binary moves, so a node that cannot run the new build keeps serving the old one.
• The two-NIC production topology passes its acceptance gate. The dedicated interface moves wholesale into the serving namespace, and :53 answers authoritatively on its routable address there. Verified on a guest destroyed and rebuilt rather than on the one that had been running. The fault that stalled this for weeks turned out not to be ours: a guest given no CPU model gets a default that lacks POPCNT, and SBCL's own bignum logcount faulted on its non-POPCNT path. ⚠ The gate is not yet the whole property, and I am recording the gate: :53 is asserted from outside the node and not yet from inside it, and the topology is written down nowhere under docs/ as the contract a host-install recipe would encode.
• A node keeps its own configuration. Every setting is declared with its type and held in a private store under the node's data root, seeded from valis.env once per key. The owner reads and changes it with valis config, through the running node or directly on a stopped one, and each change says when it takes effect. A module declares and reads its own settings, and a backup carries the whole configuration.
• The owner restarts a node from the owner's seat. valis restart asks the host agent supervising the node to restart it, and waits for the node to answer from a new boot.
• A destination a third party chose is held to what the owner allows. A dial whose address a stranger picked, such as a nameserver a delegation names or an exchanger a domain publishes, is refused in a private or other special-purpose range unless net.dial-allow allows that range for that client; a module is a client under its system name. Mail whose exchangers all lie in refused ranges bounces instead of waiting in the queue, and a bounce of the owner's outbound mail is logged as mail.relay-bounced with its reason. valis zone delegation stops the run on an --allow-range the dial rules refuse, before it asks any nameserver.
• Two sockets on one address and port no longer collide silently. A UDP pair both carrying SO_REUSEADDR are both accepted and the second takes every datagram, which is a total DNS outage that reports nothing. The DNS datagram socket is bound without that option and first, so the kernel refuses the second bind instead.
• What a node serves follows its owner's configuration, live. The served set is the node key edge.served-ports, changed through /edge/served/ctl or /config and kept across a restart. The node writes it to the host agent's admit door at boot and on every change, so the firewall admits exactly that set, and DNS answers on UDP exactly while 53 is in it, on a socket the host agent binds on request when the launch handed none down. Every reply says whether the firewall and DNS followed the change, and none of it needs a restart. The host agent no longer opens :53 or :80 on its own, and its :designated-ports key is only a first-boot seed.

I settled the order of these on 2026-09-06, after looking at how far the tree still is from where it is going: item 53 first, then item 55, then item 52. Item 54 depends on none of them and can run alongside. The recipe that installs a two-NIC host comes last of all. Items 53, 55 and 52 have since landed. Items 57 to 61 came out of making the served set owner configuration, and are not yet ordered. Item 62 is the one kind of name a node cannot yet prove it controls. Item 63 is the one part of an owner's change to the served set that still waits for a restart. Item 64 is a renewal signal a node does not yet read: the window its CA suggests.

Item 53 led because it was the only one with no evidence either way. The recipe comes last because it becomes the durable contract, and it has to capture a node whose served set is owner configuration and whose ports arrive through the steer, not one whose ports are handed down one at a time, which is the version that costs the most to undo.

1. [X] Every served name answered under its own certificate, on the live host. The machinery is built and listed under What is delivered above: one credential per served name, the order lifecycle, the challenge machinery, and a renewal proven end to end in the deployed shape.

   Landed

   all four zones the live node is authoritative for are answered under their own certificates, rhipidon.eu and rhipidon.ca included. A name below one of them is answered by the certificate whose wildcard covers it, or by one that lists it, so www under each verifies as well. A name nothing covers still meets the base certificate.

   Known going in

   never SAN-pack the four names into one certificate. One certificate per registrable domain, because Certificate Transparency records the pairing permanently. Reaching the edge at all is item 53.

2. [X] Cold verification that steered traffic is delivered. Real traffic reaching the resident accept path from a fresh image, with the four-tuple preserved and the original destination port recovered in userland. ⚠ I want this one first because nothing else would have caught what the entry below records, and it stayed invisible for weeks while every part of it read as correct.

   Known going in

   on the live host no port arrives through the steer at all. The :53 pair and the :443 edge are both inherited descriptors, and the http and gopher adapters bind loopback, so every public port is a privileged bind the host agent hands down. I went looking for the boot-path defect this item used to record and it is gone: the resident composes both arrival paths, and it declines to mint a socket only when the port it was told to serve is the one already arriving inherited. The live node is told :53 and inherits :53, so nothing is minted and the steering map stays empty. Name a port that is not inherited and the steer carries it with no code change, which is what makes this item a verification rather than a repair.

   Worth knowing

   the steer has carried public traffic before. gopher and http were served through it until the DNS work shadowed them, and the catchall object ships and sits dormant on the node. A failure here is a regression, never a first proof.

   Landed

   a fresh image of the current tree, in the proving ground, declares two privileged ports, which it cannot bind because it runs unprivileged, and pushes one descriptor carrying both. Traffic dialed at each arrives through the steer with its four-tuple intact and is answered in that port's own protocol, while nothing inside the serving namespace is bound to either number. The live node steers as well now: every resident boot that names a control socket pushes its steered socket, so the steer carries every TCP connection there, the :443 edge and DNS over TCP included.

3. [ ] A TLS-terminated connection the event loop can drive. Termination hands back a blocking stream bound to one thread, while the loop drives raw descriptors and a TLS connection's raw descriptor carries ciphertext. Until this is answered, a continuous protocol over TLS costs a thread per idle session, which is the cost the continuous-protocol work exists to remove. Gates owner mail access.
4. [X] A node declares the port set it serves, not one port. I want the set, because a person's node runs the protocols that person chose and one port cannot carry them.

   Landed

   a node serves a set of ports, and the set is its owner's configuration rather than a launch flag: the node key edge.served-ports, kept across a restart and changed live through /edge/served/ctl or /config. The empty set is a choice the node keeps. The first boot records the launch's --ports when it names any and the default core, 53 and 80 today, when it names none, and a launch with no --ports boots. Carrying the set needed no new descriptor traffic: one steered descriptor carries every TCP port, because the steer fans every TCP connection at it and the dialed port is recovered per connection, and the declaration is one whole-set write. What the contract with the host agent gained is two doors in the control session: admit, which the node writes its configured set to so the firewall follows it, and bind, which binds a UDP :53 socket for a running node on request. Every resident boot that names a control socket, which is every boot the host agent launches, pushes that descriptor and holds it for the life of the session, even with nothing to declare.

   Note

   the design is in docs/ARCHITECTURE.org, under what a node serves and who decides.

5. [X] A fresh node serves its documentation on :80. :80 is in the default core, so a node serves its own documentation there in the clear until its owner says otherwise, and a new owner can read the manual for the machine off the machine itself before a certificate exists and before anything else on the node is working. Like every member of the core it is the owner's to remove.

   Landed

   a release binary carries the manual: make dist builds and stages it from the commit it releases, the binary bakes it in, and a fresh node seeds every page as its own publication with the staged landing page as its front door, so every link on that page reaches a page the node holds. :80 is a served port like any other: the steer delivers its connections to the http adapter, whose port it is, the host agent binds nothing for it and admits it at the firewall, because the node writes its served set to the agent's admit door. A node created from a release tarball on a fresh guest, holding no certificate and with nothing published to it, answered a client speaking plain HTTP/1.1 to :80 from off the guest with its front door. Every page reached by following links from there answered too, 52 in all. The node held no listening socket on :80; the connection arrived through the steer.

   Note

   the built site is not committed, so the release host needs emacs and python3. A binary built with make build alone carries no manual, and a node it creates serves the landing page alone. The node answers the same front door whatever name the client asks for, which is intended: a new owner reaches it by address, before any name resolves. The design it serves is in docs/ARCHITECTURE.org, under what :80 is for.

6. [ ] An adapter attached from an owner session shares the steered socket. An adapter attached at boot shares the one steered socket. One attached from an owner's session binds its port on loopback instead, so the node holds a listener it does not need. Steered connections for that port are still answered through the protocol registry.

   Done when

   an adapter attached from an owner session serves its port over the held steered socket, as one attached at boot does.

7. [ ] Steered connections count against their own port's budget. Every connection arriving on the steered socket counts against that socket's budget and session ceiling, not against those of the port it was dialed on, so an adapter with a budget of its own is bounded by the socket's instead. The shipped adapters all use the default today.

   Done when

   a steered connection is charged to the budget of the port it was dialed on.

8. [ ] The edge declares only the owner's set to the host agent. The edge re-declares its whole held set to the host agent, the loopback stand-ins its own adapters bind included, so the agent's record of declared ports is wider than what the owner configured. Admission already leaves those ports out; the declaration does not.

   Done when

   what the node declares to the host agent and what it admits name the same set.

9. [ ] valis takes up a new control session when its session ends. valis dials its control session once, at boot, and has no path to reconnect. The host agent restarts the node it launched when it restarts itself, so after that the node boots fresh and admits its set again. A control session that ends while the node keeps running, for instance when the agent's serve thread fails, leaves the node with no session: no owner change reaches the firewall, and no DNS socket can be asked for, until the node next boots.

   Done when

   a node whose control session ends takes up a new one and admits its configured set without a restart of its own.

10. [ ] Creating a listening socket changes what every listening socket accepts. In the iolib fork, the class of the connection a listening socket accepts is allocated on the class rather than on each socket (active-class is class-allocated on passive-socket), so creating one listening socket changes the accepted-connection class for every listening socket in the image.

    Done when

    creating a listening socket leaves the accepted-connection class of every other listening socket in the image unchanged.

11. [ ] A brought domain whose DNS lives elsewhere gets a certificate and serves. I want a valis to prove control of every name it serves. A name in a zone the node is authoritative for is proved by dns-01. A domain an owner brings while its DNS stays with a third party is proved by tls-alpn-01, answered on the node's live :443 edge: acme-tls/1 is negotiated inside the TLS stack that already serves :443, and the domain is admitted by an explicit per-domain enrollment the owner makes through the control plane.

    Done when

    an owner enrolls such a domain, the node proves it by tls-alpn-01 on its live :443 edge, and serves it.

    Where it stands

    only dns-01 is built. A brought domain whose DNS lives elsewhere cannot obtain a certificate, and its site does not serve. The same gap covers a node whose served set leaves out :53, since a node answers dns-01 only from its own :53. The earlier standalone tls-alpn-01 responder was retired because it listened beside the steer, where a deployed node's connections never arrive; nothing had ever called it.

    What is left

    the per-domain enrollment through the control plane; answering acme-tls/1 inside the :443 edge's TLS stack with the challenge certificate for an enrolled name while its order is open; and an order path that proves an enrolled name by tls-alpn-01 instead of refusing it as not served.

    Note

    the design is in docs/ARCHITECTURE.org, under the credential a name is answered under.

12. [ ] An adapter follows its port into the served set without a restart. I want an owner's change to the served set to reach a running node completely, so a port that joins the set is answered by the adapter whose port it is as soon as the change is made, through the steer, and a port that leaves it stops being answered there.

    Done when

    on a running node, adding an adapter's own port to the served set makes that adapter answer it through the steer with no restart, and removing the port takes it back off.

    Where it stands

    what the node admits at the firewall and declares to the host agent follows a change at once. Which port an adapter listens on does not: an adapter whose port was outside the set when the node booted comes up on the loopback port it falls back to when it cannot bind its own, and nothing moves it when its port later joins the set, so the port is admitted and steered but the adapter is not there to answer it until the next boot. The proving-ground's steered gate restarts the node after adding 70 for exactly this reason. A port that leaves the set is closed at the firewall at once, and its adapter stays registered for it, with nothing arriving, until the next boot.

    What is left

    re-deciding an adapter's bind when the served set changes, and the restart in the steered gate comes out with it.

13. [ ] A node renews inside the window its CA suggests, not only on its own schedule. I want a node to renew a certificate inside the renewal window its CA suggests when that window opens early, so a certificate due for revocation is replaced ahead of the revocation and not at a fixed point that may fall after it.

    Done when

    a node reads the CA's suggested renewal window for each certificate it holds, through ACME Renewal Information (RFC 9773), and renews inside that window when the window opens before the node's own fixed point; with a CA that offers no window, the node keeps the schedule it has now.

    Where it stands

    a node renews each certificate at a fixed point, when a third of its lifetime remains, and never reads a window from the CA. mercer can read a window when it is handed a certificate's renewalInfo URL, and nothing in the node builds that URL or passes one in. Let's Encrypt publishes windows, and on 2026-10-17 every window it suggested for the live host's certificates opened before the node's fixed point and closed after it, so the node's own schedule fell inside each one. When Let's Encrypt moves a window earlier, as it can ahead of a revocation, the node still renews only at its fixed point, which can fall after the window closes.

    What is left

    building each certificate's renewalInfo URL and reading its window after issuance, when the renewal schedule is built, and again at the interval the CA's reply names; renewing at a time inside the window; and recording with each renewal the window it was made against.

⚠ Each of the items above is a whole-path property, and every failure found in this arc was a feature that bound its own listener instead of arriving through the single steered socket. The steering model is that every TCP port arrives on one socket, the owner's configured served set decides what the host agent admits at its firewall, and the registry decides which module answers it. A feature that binds, inherits, or accepts on its own is departing from that, and UDP :53 is the one place where departing is correct.

✅ Custody scales. Custody on the live host is keyed per domain on disk, so a second order has somewhere of its own to land rather than a slot to take over.

✅ Selection scales too. The edge holds one credential per served name and chooses, per connection on the handshake path, the certificate for the name the client asked for. A name the node holds nothing for meets the base credential; refusing it with an unrecognized-name alert, which boomer can do, is not wired.

✅ The edge reads what the node serves. The served name set is the base name plus every name in certificate custody for a zone this node answers the DNS for. Custody on its own admits nothing, so material placed in the store by any other route cannot make a name served.

A design that works for two names can fail at scale in ways that do not look like defects:

• The issuing CA rate limits per registrable domain, so standing up many names is a pacing problem rather than a loop. ⛔ Never widen a certificate to cover more names instead: a SAN-packed certificate publishes the whole name list to certificate transparency permanently, correlating every domain on it.
• Renewal becomes scheduling. A watcher that renews one credential is a different thing from one that keeps thousands current without a stampede.
• Cost must remain measurable per domain, not in aggregate, or there is no way to say how many domains one node can carry and still pay for itself.
• The set is assembled whole, at boot and again when a setting it depends on changes. That is fine for a handful of names and puts the timing of assembly in question for thousands.

⇒ None of these four is designed yet, and edge.domain still answers three questions a set has no single answer for.

Refined by fade, 2026-08-16, and it is what keeps the ruling above from over-applying. The rule is not "shell is wrong." Standing up host OS services is a perfectly normal and correct use of shell code. What requires Lisp is anything a node must manipulate from valis.

Preparing the ground a node runs on	shell is right	scripts/pg-dev.sh stands up a dev PostgreSQL; valis consumes a DSN and never touches the container
Acting through a node at runtime, under its authority	Lisp	namespace create, enter and teardown; placing publications into /pub

The test to apply: does valis itself have to do this, while running, as part of being a node? If a person or a build host prepares something before valis starts, shell is fine. If the node reaches its own state or an owner's through it, that path belongs in the image. A namespace is not host provisioning, which is why ip(8) falls on the Lisp side: the resident creates it, enters it, and must know whether it is live.

Called out by fade, 2026-08-16, the same day as the ruling above. The first driver that placed the manual into /pub was written as a Python build script that shells out to the publish verb once per page. It works and it is what put the documentation site up, so it is not being torn out to reach that aim.

The reason it is the wrong shape is not the reason ip(8) is. That one is about a node controlling its own environment. This one is about whose authority the act runs under: a stranger operating their own valis must be able to publish their own words within their own instance's authority, and that makes tree publishing an owner-facing capability of the node, not scaffolding on a build host. Filing it as site tooling mistook our first use of a general capability for the capability itself, in the same way :443 is an existence proof for the http server rather than the point of it.

What follows from that, for whoever picks this up:

• The act belongs in the image, reachable by an owner who has no build host, no python3, and no checkout. A capability a stranger cannot reach is not a capability they have.
• It should open one owner session and publish through it, rather than one session per page.
• It must call valid-slug-p rather than restate it. The Python driver copied that charset into a regular expression, which puts a fail-closed traversal gate in two languages with nothing keeping them honest.
• The link rewriting is a separate matter and can stay a build step: turning ARCHITECTURE.html into /architecture is post-processing an Org export, and it sits beside split-api.py, which already post-processes the same export.

⇒ The split to carry forward: rewriting names is a build concern, placing publications is a node concern. Bundling them is what hid the second inside the first.

The precedent was already in the tree. tools/api-doc.lisp, contributed by Glenn Thompson on 2026-06-08, walks valis's own packages through sb-introspect and writes docs/API.org. The documentation pipeline has carried the right division since then:

code to docs	tools/api-doc.lisp	Lisp, because it introspects the loaded image
org to HTML	site.el, split-api.py	text transformation, and non-Lisp is fine

Placing publications is the first kind of work, not the second: it acts on a running node under an owner's authority. Nothing needed inventing here; the shape was already demonstrated, and consulting tools/ would have settled it.

🄯 Brian O'Reilly <fade@deepsky.com>, 2026