EstatePublisher is Codex’s governed IP-network topology mutator

The human states the outcome. Codex selects a live EstatePublisher command. EstatePublisher executes, records, and proves the result.

The governing decision

Operating rule: EstatePublisher is a tool Codex uses when a human asks for a governed deployment outcome. Codex chooses from EstatePublisher’s live command catalog; it does not invent deployment steps.

A human is not asked to discover or author infrastructure records. Codex is a reasoning client, not an authority. EstatePublisher is the single native operational authority. The joining device is authoritative for its own signed identity and live capabilities. The FountainStore enrollment authority accepts or refuses the signed device enrollment request. FountainStore is the durable record and typed read-back authority.

The joining sequence

The principal interaction is temporal:

1. The device announces: “I am here.”
2. EstatePublisher discovers that presence.
3. The device exposes its MIDI 2 capability and signed identity.
4. EstatePublisher binds one deterministic candidate.
5. The enrollment authority accepts or refuses that identified device.
6. EstatePublisher sends only admitted typed operations.
7. FountainStore records the result and read-back proof.

Discovery answers which device is present. MIDI 2 and MIDI-CI answer what it can speak. Binding answers which identity is the intended target. Enrollment answers whether that target may join. Operation answers what it may do. Proof answers what happened. No later answer is assumed from an earlier one.

Participants and authority

Implementation contract

This chapter gives an implementing agent a bounded order of work. It does not require guessed runtime facts or turn an absent fact into a policy choice.

1. Read EstatePublisher --inspect --strict and EstatePublisher --commands. If the selected operation is absent, stop with command-surface-insufficient.
2. Resolve the operation's Swift kit contract and named host adapter. A missing contract or adapter is capability-seam-missing, not permission to create a script or second authority.
3. Select the compiled scenario by exact capability, operation, scope, and terminal predicates. A different identity, stale platform assumption, or missing predicate is scenario-mismatch and must be repaired before mutation.
4. Read the explicit FountainStore intent and records. Reuse a record only when identity, target, authorization, source revision, and evidence binding match. Store state is read-back, not live discovery.
5. Run the native collector when live facts are required. Keep its enumeration in memory until EstatePublisher writes the redacted observation. Bind only deterministic candidates; zero candidates is a typed result and ambiguity is a terminal refusal.
6. Compose one typed request and invoke the existing authorization, SecretStore, release, host, and publication adapters in governed order. Each phase returns its receipt before the next mutation.
7. Verify terminal predicates through correlated FountainStore read-back and named external witnesses. Report each as observed, inferred, or unestablished.

Agent execution record

An implementing agent uses the existing scenario estate-local-wlan-turnkey-access, capability fountaincoach.estate-domain-publication.1.0, and operation estate.publication.sync. The native entries are --install-local-developer-cloud --request <file> --output <file> and --scan-local-developer-cloud --request <file> --output <file>. The agent verifies these with EstatePublisher --inspect --strict and EstatePublisher --commands, then validates the scenario YAML and checked JSON projection. Disagreement stops the run with command-surface-insufficient or scenario-mismatch before mutation.

The typed request must carry one operation, scenario, correlation, and idempotency identity; the configurable domain pattern/prefix and complete manifest digest; the same-run discovered candidate and complete interface inventory; enrollment and authorization references; host-key, SecretStore, signed-release, and source-revision references; and the typed gateway policy and recovery identity. These come from the catalog/scenario, request and manifest, in-memory scan and Store receipt, enrollment authority, native adapters, and host-adapter contract. Guessed addresses, device or operating-system names, SSIDs, interfaces, routers, clients, per-device DNS edits, credentials, host keys, and hardcoded domains are forbidden. The collector creates live inventory in memory; EstatePublisher validates and binds it; only then is the redacted observation persisted.

Phase gates for implementation

The workflow is one EstatePublisher authority with ordered gates. A failed gate is terminal for that attempt; later phases are not called and the previous known-good state remains available for rollback.

A plan, process exit, packet, screenshot, or HTTP response is not a phase gate. Every gate is tied to the correlation identity, target binding, source revision, Store path, and scenario identity.

Acceptance matrix

Implementation is complete only when the scenario reports scenario-validation: PASS and scenario-preparation: COMPLETE, and one correlated run proves configuration, discovery/binding, admission/custody, gateway, publication, clients, restart persistence, and rollback. Required failures are typed as configuration-mismatch, discovery-incomplete, binding-ambiguous, admission-failed, credential-invalid, host-reconcile-failed, publication-unproven, client-readback-failed, persistence-unproven, or rollback-unproven. Missing correlated evidence means BLOCKED, never a partial installation claim. Invalid credentials produce one refusal and a resumable recovery path, never a password loop.

IP-network topology mutation

Local developer cloud names the requested deployment profile, not a localhost-only implementation and not a fixed LAN topology. The governed object is an admitted IP network topology. EstatePublisher may connect or disconnect an admitted node, extend or shrink an admitted segment, reconcile uplink, management, access, and standby paths, and publish the resulting estate routes only through the declared host adapter. It discovers actual interfaces and addresses and applies declared policy; Chapter 140 never names a router, subnet, interface, SSID, device, client, or address.

Every topology mutation has a before-state, intended after-state, exact target binding, idempotency identity, and rollback state. EstatePublisher must prove resulting routes, preserved management and internet access, and recovery to the prior known-good topology. The same contract applies to a private WLAN, another IP segment, or a future provider-neutral IP transport declared by a host adapter.

What this chapter supplies

It supplies authority, order, refusal states, and evidence vocabulary. It does not supply an IP address, device identity, interface role, WLAN credential, host key, certificate, source revision, domain value, or approval. Those are target-specific facts or authorizations resolved through the named native contracts. Their absence produces a typed refusal; prose defaults may not fill the value.

The implementation agent closes this boundary by wiring those reads and collectors to the declared typed contracts. After closure, one EstatePublisher workflow owns the complete sequence: it discovers the reachable device and host interfaces, binds one deterministic target, composes the authorized request, activates the persistent gateway, publishes the complete estate, and records every phase in FountainStore.

Closure state

The implementation is closed when the compiled scenario and live command surface describe the same operation and one correlated run proves:

• a device-neutral, deterministically bound participant with signed identity, a reachable authenticated MIDI 2 peer endpoint, and declared capabilities;
• every admitted uplink, management, access, and standby interface classified by EstatePublisher;
• SecretStore custody, owner authorization, strict host-key verification, signed release, and source revision bound to the target without exposed secrets;
• persistent WLAN, DHCP, DNS, NAT, and estate routing with internet and management access preserved;
• the complete estate manifest served through the selected configurable domain pattern, without router or per-device DNS edits;
• browser access to the estate and selected subdomains, with typed route and certificate read-back;
• restart persistence and rollback to the previous known-good release; and
• correlated FountainStore receipts with EstatePublisher as the only native publication/deployment authority.

The closure state is the implementation target, not a claim that a particular live target has already reached it. Once these predicates pass, the agent reports the correlated result and does not reopen this chapter as a questionnaire or invent a second workflow.

Four mechanisms, four questions

Declared discovery transport answers “which devices are present?” Bonjour / mDNS is one supported option, not a requirement. For governed joining, the device must provide a reachable authenticated MIDI 2 peer endpoint; it may be native or supplied by a separately admitted companion/bridge. MIDI-CI answers “what can this MIDI peer speak?” Enrollment answers “may this identified device join?” The MIDI 2 command plane carries an admitted typed operation and its lifecycle. None of these layers silently substitutes for another, and EstatePublisher does not silently install the MIDI 2 endpoint.

discovery transport → MIDI 2 peer → signed identity → enrollment decision → managed connection → capability read-back → installation → publication proof

Concrete enrollment authority

In the current FountainStore implementation, the enrollment step is provided by the /enroll/{deviceKeyID} endpoint, implemented by FountainStoreTrustedDeviceEnrollmentService, verified through MaintenanceEnrollmentAuthority, and persisted in maintenance.trusted-devices. These names identify the current adapter; they do not make enrollment precede discovery.

What is created

1. EstatePublisher creates an in-memory discovery enumeration, then stores a redacted observation.
2. It creates an owner-signed enrollment request using private material held in SecretStore.
3. After the existing enrollment authority responds, it writes and reads back the admitted connection and complete host inventory.
4. It reuses the signed release-promotion path, activates the declared gateway, and publishes through estate.publication.sync.
5. It records one correlated terminal receipt, including restart and rollback results.

Failure is typed and recoverable

The lifecycle is not-seen → discovered-unadmitted → enrollment-pending → enrolled → ready → installed, with terminal refused, expired, identity-mismatch, failed, rolled-back, or revoked states. Invalid credentials produce one typed failure, preserve the last working release, and permit retry after SecretStore recovery. They never cause a password loop.

Acceptance boundary

This chapter is the governance contract. A live installation claim requires correlated evidence from the joining machine, EstatePublisher, FountainStore, host services, DNS, browser clients, restart, and rollback. The contract does not claim that a live WLAN newcomer is currently enrolled or installed.

Current status: the governance and native EstatePublisher workflow are projected here; live WLAN bootstrap and end-to-end installation evidence remain unestablished until a real target and valid authorization are present.