Delivery & Adoption
Move from a library to an operable service deliberately.
The cascade consists of create-package, create-server, secure-server, and deploy-server. Later rungs satisfy earlier prerequisites; the sequence is designed to be idempotent. Adoption syncs canonical scripts into a repository, checks drift, and retains the adopting owner's authority. The tracker rail carries concrete failures of racecar's defaults back for review.
Adopter Delivery
A manifest governs what is copied
The delivery manifest inventories files racecar syncs into adopting repositories. It includes standalone scripts and shared lexicon schema read by their checkers. Templates create missing starting artifacts rather than overwriting user-owned changes. The manifest is checked against the canonical catalogue, so the description of delivery cannot quietly diverge from the delivered set.
Deployment
A reproducible path from code to service
The delivery path is staged: build a package, create a service, secure it, and deploy it. Host tooling validates and expands seed configuration, inspects proposed changes without touching a host, and requires explicit execution for deployment. Long-running work can be chunked and resumed. Planning, checking, and irreversible operations remain distinct rather than hiding inside one opaque command.
Feedback & Escalation
Concrete adopter failures can amend the canon
When a default fails in an adopting repository, a structured tracker rail records evidence and escalates the problem. The operator approves the issue draft before sending it; unknown fields or headings are refused. A hash-chained egress receipt is recorded before external transmission, providing forensic observability without keeping a second copy of the payload. This is not an exfiltration control.