docs: publish Tend Compose continuity evidence

Export the reviewed allowlisted snapshot from private source commit 07c1655921f21ee5e4fc4d85639d199e8867b17d. This records the Docker Compose activation, schema-compatible rollback, and stateful migration resource findings from Observatory Preview 19 dogfooding.

AI-Assisted: OpenAI Codex
Signed-off-by: Cole Speelman <crspeelman@gmail.com>

README.md

@@ -0,0 +1,102 @@
+# Gamertan Tend
+
+Tend is an opinionated release and deployment tool for small Go services on
+Linux, systemd, and Caddy. It packages a clean pushed commit, records exact
+build provenance, activates a health-checked candidate, and keeps rollback
+state explicit.
+
+The v0.2 development line supports two quiet deployment shapes:
+
+- Caddy-switched blue/green services.
+- A singleton service with an isolated transient candidate check.
+
+It does not manage databases, migrations, containers, Kubernetes, or arbitrary
+shell hooks. Application-specific data activation remains application-specific.
+
+## Commands
+
+```text
+tend check    --config tend.json
+tend package  --config tend.json --version v0.2.0-preview.2 --out dist
+tend inspect  --config tend.json --artifact FILE --sha256 HEX --approve-sha256 HEX
+tend push     --target tend-deploy@host --known-hosts FILE --service NAME --artifact FILE --sha256 HEX --approve-sha256 HEX
+tend receive  --policy /etc/tend/receive-policy.json
+tend check-server --policy /etc/tend/receive-policy.json
+tend deploy   --config /etc/tend/services/example-site.json --artifact FILE --sha256 HEX --approve-sha256 HEX
+tend status   --config /etc/tend/services/example-site.json
+tend reconcile --config /etc/tend/services/example-site.json --json
+tend rollback --config /etc/tend/services/example-site.json
+tend prune    --config /etc/tend/services/example-site.json --keep 3 [--apply]
+```
+
+`inspect` performs the complete archive, checksum, approval, manifest, SBOM,
+and binary-identity validation without staging or activating a release.
+`reconcile` is also read-only: it compares Tend's journal with conventional
+release symlinks, systemd units, the installed release identity, and the Caddy
+handler. It reports drift and retained-candidate residue without silently
+"repairing" a service.
+
+`push` transfers one approved artifact through a pinned OpenSSH connection. A
+forced, no-shell receiver maps the service name to one root-owned configuration;
+it accepts no remote path, environment value, URL, or shell fragment. Production
+hosts receive binaries and evidence, never source or Go dependencies.
+
+Schema 2 keeps all services under `/etc/tend/services/`, references a distinct
+root-owned `0600` environment file for each service, and serializes activation
+through `/run/lock/tend-deploy.lock`. Builds and transfers remain parallel;
+only the short Caddy/service activation phase is host-wide. Tend is still a
+single command, not a daemon.
+
+Each service also keeps a bounded JSONL deployment-event stream and explicit
+desired, candidate, active, previous, and last-attempt release identities. The
+stream contains only fixed provenance and lifecycle fields; Observatory may
+ingest it later, but an event-write failure never blocks deployment or rollback.
+After Caddy reload, Tend repeatedly probes the configured canonical HTTPS
+origins for the activation window. Blue/green deployments simultaneously keep
+checking the previous slot, restoring the prior handler and inactive-slot state
+if routed traffic or continuity fails.
+
+Singleton activation and rollback candidates use an operation-scoped systemd
+unit and persist a bounded lease containing the operation, release, unit,
+address, and start time in a separate adjacent file. Conventional deployment
+state remains schema 1 so a retained older binary can still read active and
+previous release identities; operators must reconcile before downgrading while
+a lease exists. `tend
+reconcile --json` compares that lease with unit activity, release pointers, and
+the exact Caddy handler file without changing any of them. It deliberately does
+not stop or clear a retained candidate: that process may still be the only
+healthy route after an interrupted recovery.
+
+Dry-run and digest approval are intentional friction. See the
+[schema-2 migration guide](docs/SCHEMA_V2_MIGRATION.md) and the
+[two-service walkthrough](docs/WALKTHROUGH.md).
+
+Run `./scripts/verify.sh` on Linux. That required release lane exercises tests,
+the race detector, vet, deterministic builds, schema-2 examples, and the
+dependency-free module graph. Tend supports Linux hosts with systemd and Caddy;
+WSL may be used as a Linux development environment, but native Windows is not a
+supported execution, deployment, or release-gate platform.
+
+The v0.1 public preview and immutable `v0.2.0-preview.1` each completed
+maintenance releases and explicit rollback/reactivation for both Gamertan and
+the Sandwich Hime website using one reviewed candidate. See the dated
+[dogfood evidence](docs/DOGFOOD_EVIDENCE.md) for exact scope and limitations.
+
+The additive `v0.2.0-preview.2` candidate keeps that transport and activation
+contract while adding bounded deployment-event JSONL, routed-origin continuity,
+rollback annotations, and the operational findings recorded through real
+dogfooding. Preview 1 remains unchanged. Preview 2 will not be tagged until one
+identical binary has deployed, rolled back, and reactivated Gamertan, the
+Sandwich Hime website, and Gamertan Observatory.
+Operational friction discovered while applying the same contract to new
+services is tracked separately in the
+[dogfood friction ledger](docs/DOGFOOD_FRICTION.md). The ledger preserves the
+fail-closed behavior and records candidate product improvements instead of
+normalizing application-specific deployment workarounds.
+The canonical public repository begins with a sanitized root snapshot rather
+than the private development history.
+
+## Licensing
+
+Tend and its release machinery are AGPL-3.0-only. Reusable example
+configuration and service templates under `examples/` are 0BSD.