# (moved) Phase 1 exposure runbook

This file used to contain the Phase 1 exposure record for one specific
deployment — the primary host and tunnel host by name, the DNS registrar step,
the Pangolin/newt resource wiring, the shared-token handling, per-machine flip
dates, and a palace lineage naming three work machines.

**That content now lives in a private repository**, for the same reason
[`synlig-primary-runbook.md`](synlig-primary-runbook.md) does: a host inventory
is operator data for one deployment, not part of the toolkit. This repository is
public and keeps only host-agnostic *mechanism*.

What lives where:

| Content | Home |
|---|---|
| Why a palace needs a special backup, and how to restore one | [`backup-and-recovery.md`](backup-and-recovery.md) (here) |
| The coordination log: semantics, delivery, trust model, landmines | [`rfc-003-coordination-log.md`](rfc-003-coordination-log.md) (here) |
| What the stores are for, and how a fleet shares one palace | [`fleet-memory.md`](fleet-memory.md) (here) |
| Unit/timer/plist templates | [`contrib/`](../contrib/) (here) |
| Which host is primary and which fronts the tunnel, at which addresses, as which user | private fleet repository |
| Registrar/DNS records, tunnel resource config, token custody | private fleet repository |
| Per-machine flip dates, seeding history, palace lineage | private fleet repository |

## The mechanism this file also carried — not yet extracted

Unlike the primary-host runbook, this file was **mixed**: several sections were
reusable mechanism that would be true of anyone's palace, and those are not
published anywhere else yet. Named here so the debt is visible rather than lost:

- **The bind trap, in full.** Why binding a palace to a public interface is not
  the same as exposing it, and the `Host`/`Origin` pin that makes an MCP
  endpoint refuse requests that arrive with the wrong hostname — the single
  most surprising failure in the whole exposure path.
- **Why not per-device users at the proxy.** The reasoning behind one shared
  fleet token instead of per-device proxy credentials, and the consequence
  documented in [`rfc-003-coordination-log.md`](rfc-003-coordination-log.md) §6:
  the deployment authenticates the *fleet*, not the *agent*.
- **The one place per-device identity does exist**, and why that is the feeder
  path rather than the HTTP path.
- **Flipping a client: three variables, or none.** The all-or-nothing shape of
  pointing a machine at a remote palace, and how a half-flipped client fails.

Until that extraction happens, the mechanism is readable only in the private
record. If you are standing up your own palace over HTTP, the two pieces you
must not skip are the `Host`/`Origin` pin and the fact that a client is flipped
by environment variables that travel as a set.