158 — Publishing Is Not a Distributed Transaction
Governance chapter: 158. An approved static publication is an authored release, not a distributed application transaction. EstatePublisher compiles and verifies. A bounded authenticated transport delivers. Caddy serves. Application-state replication, MIDI2 session establishment and FCIS Host Agent enrollment are not prerequisites for static publication.
The correction
The Fountain Coach publication estate has reached a revealing contradiction. A writer asks to publish an essay. Its source is committed, its illustration exists, its static page is tested, and the requested public route has a known hostname. Yet publication can remain blocked because a remote Store mirror or an FCIS host session has not been enrolled. A system designed to shorten the distance from meaning to public work has turned that distance into an infrastructure ceremony.
A missing application runtime cannot legitimately become the sole reason that an otherwise valid static page remains unpublished. This chapter separates the authority to publish from the machinery used to deliver an already accepted release. It does not remove authentication, source integrity, access control, rollback or evidence. It makes them proportional to the operation being performed.
The decision is specific. For an immutable static estate release, FountainStore replication, an FCIS Host Agent, MIDI2 transport and a continuously running application coordinator MUST NOT be mandatory dependencies. Their capabilities remain available for work that actually needs them. Ordinary static publication uses a finite, secure deployment profile.
One writer, one publication intention
The writer's operation remains semantic: publish this chapter, replace this edition, restore the previous release, or withdraw a route. The writer does not choose SSH flags, Caddy directives, filesystem permissions or background agents. EstatePublisher translates that intention into a concrete publication scope: an approved source revision, declared hostname and routes, expected assets, content digests, and an exact target root.
A publication approval establishes the author's will to make those specific artifacts public. It is neither an arbitrary command-execution grant nor a permit to alter unrelated domains. When the content or target changes, the operation must be re-evaluated. The visible authoring surface reports what was published and where, or it reports the exact failure. Repository commit, draft preview, and production release are different states.
Static publication profile
The minimum production contract consists of six steps:
- Compile. Resolve the author-approved content and its dependencies; apply the semantic difference to the declared estate routes without rebuilding or transferring unrelated domains.
- Validate. Check source references, publication scope, private-source exclusions, routes, media, manifests and deterministic asset digests.
- Package. Produce an immutable release with a release identifier, source revision, file inventory, route set and previous-release reference.
- Deliver. Use an authenticated transport admitted for the named host and bounded destination. SSH/SFTP, including a restricted remote deployment command where needed, is a supported production transport.
- Activate. Stage files outside the active document root, verify the archive and permissions, and activate an immutable release atomically. Preserve the predecessor for rollback; validate Caddy before any necessary configuration reload.
- Verify. Read back the exact public HTTPS routes and representative asset digests from outside the server, check sibling routes, and record a receipt. Report success only from that public witness.
The remote edge stays deliberately boring. It serves accepted static bytes and does not interpret manuscripts, run Reframe, hold a FountainStore mirror or possess editorial authority.
Separation of authorities
The author owns the publication intention and content decision. EstatePublisher owns semantic planning, validation, release packaging, target specification and verification. The deployment identity owns only bounded file delivery and release activation on the named server. Caddy owns HTTPS serving from the selected immutable root. The public read-back witnesses what a reader can actually access.
FountainStore MAY retain source records, authoring evidence, release history or a copy of the publication receipt when available. It MUST NOT be the mandatory bridge between two machines for this static profile. A valid release can be independently identified by its manifest, source revision, digest and public witness, even when a local Store is offline. A receipt may be appended to Store later without rewriting the publication history or changing the truth of the already verified public release.
The semantic domain, internet name, publication artifact and deployment machine are distinct identities. Ownership of a domain is not ownership of a server. Control of a server is not permission to publish any content. A machine transport is not an authoring authority.
SSH is a transport, not a governance failure
SSH is a mature authenticated and encrypted connection. It is not disallowed merely because it provides a shell-capable protocol. Its admitted use here is bounded: a dedicated deployment identity, pinned host identity, destination allowlist, minimum filesystem rights, no interactive escalation and only the fixed operations needed for upload, validation, atomic activation and rollback. A forced-command deployment endpoint, restricted SFTP subsystem, or equivalent fixed activation helper MAY implement the host side.
A private key, valid SSH handshake or writable directory alone does not prove publication authorization. The selected release manifest and target must be checked before any effect. SSH MUST NOT become a general-purpose root shell or a substitute for independent read-back. The deployment operation rejects unknown hosts, path traversal, mismatched release material, mutable source-directory publication, and attempts to modify sibling virtual hosts.
Provider credentials and SSH keys stay in their authorized secret custody; never in published pages, Git history or manifests. DNS and TLS provisioning remain separate operations with their own bounded authorization. Ordinary content updates on an existing HTTPS host do not require repeating an unrelated DNS, TLS, Store or agent-enrollment ceremony.
What is superseded
This chapter amends the static estate production profile of Chapter 146, Local FountainStore, Remote Caddy: The Production Static Estate. The requirement that every static release execute through an FCIS-KIT-owned remote effect and local FountainStore admission, and the rejection of authenticated SSH as an alternative, are superseded for immutable static releases. The requirement that a remote FountainStore not serve static requests, the immutable release contract, atomic activation, rollback, provenance and HTTPS verification remain binding.
Chapter 152, The Host Is the Instrument, already identifies the host's capabilities independently of any single transport. This chapter applies that transport-neutral principle to publishing. Chapter 156, The Writer Never Operates EstatePublisher, continues to protect the writer-facing semantic operation. Chapter 157, The Writer Owns the Public Domain, continues to protect the writer's public identity from hosting providers. Chapter 143's insistence on simplicity remains a design criterion, not a waiver of security.
This is a deliberately narrow governance correction. It does not change the admission of secret-bearing application runtimes, mutable FountainStore services, account provisioning, DNS ownership, signing, identity issuance, or other operations whose effects actually require separate authorization and distributed state.
Failure is evidence
A Git push is not deployment. A valid HTML document is not a public route. HTTP 200 on the home page is not proof of the newly published chapter. A host-agent failure is not a static-content failure. The release executor MUST retain these distinctions.
If SSH authentication is not available, publication stops at a named infrastructure prerequisite: the deployment identity cannot authenticate to the named host. If target directories or Caddy ownership are unavailable, it stops at that exact boundary. The tool MUST NOT quietly replace the transport with an invented side channel, bypass host controls, disable TLS verification or declare success on the basis of a repository commit.
Conversely, if the admitted SSH delivery and fixed activation are available, the release MUST NOT be blocked merely because an unrelated FCIS session, FountainStore mirror, or MIDI2 server is absent.
The acceptance case: Chapter 158 and the Solstice essay
The correction is accepted by a concrete two-publication sequence. First, compile and publish this chapter to the existing Governance host, including its illustration, reading index and chapter navigation, with its previous release available for rollback. Second, use the same static publication profile to publish Semantic Compilation — The Archive Is Not the Edition to fountain.coach/essays/, including the landscape artwork, gallery entry and Solstice navigation identity.
For each publication the receipt SHALL identify the exact release, changed routes and assets, HTTPS evidence for the new content, and successful independent checks of neighboring routes. A green local build, a pushed commit or an agent's account of intentions is insufficient. The sequence must demonstrate that one publication no longer waits for a distributed runtime unrelated to the artifact being served.
A missing deployment credential is a conventional operational problem to repair by authorized account recovery, not evidence that a new messaging framework must be invented.
Governing sentence
Publication is an authored release, not a distributed application transaction. The publisher compiles and verifies; an authenticated transport delivers; Caddy serves. No unrelated runtime may prevent an authorized writer from publishing an otherwise valid static work.