tend/README.md

Gamertan Tend

Final public CLI preview

v0.2.0-preview.2 is the final public Tend CLI preview. This repository and its published AGPL releases remain available as an archived record, but it is not accepting new feature development. Private research continues around a networked management experience; that work is not mirrored or published here and carries no public release commitment.

Existing licences and release artifacts are unchanged. Do not interpret this notice as withdrawing rights already granted by the AGPL-3.0-only and 0BSD files in this repository.

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

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 and the two-service walkthrough.

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 for exact scope and limitations.

The additive v0.2.0-preview.2 release 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. Operational friction discovered while applying the same contract to new services is tracked separately in the dogfood friction ledger. 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.