A day-one setup script that verifies itself: bootstrap, doctor, smoke test

Goal

A newcomer or an agent runs one command after cloning and ends with a working environment or a precise list of what is missing and how to fix it; run again, the command reports nothing to do.

Prerequisites

A list of what the project needs: runtimes and their versions, package managers, system libraries, services (database, cache), credentials and where they come from, and for each item a check that proves it is present. GitHub's "Scripts To Rule Them All" pattern supplies the split this methodology follows: script/bootstrap is used solely for fulfilling dependencies of the project, script/setup puts the project into its initial state after a clone, script/update runs after a pull, and script/test runs the suite. Homebrew's doctor command, described in its manpage as checking your system for potential problems and exiting with a non-zero status if any are found, is the model for the verification half.

Steps

1. Write the doctor script first: a read-only check that prints one line per requirement with PASS, FAIL or WARN, the value found, the value expected and the fix command. It changes nothing and exits non-zero on any FAIL.
2. Write bootstrap as a sequence of idempotent steps, each guarded by the matching doctor check: install only what is missing, take versions from the repository's version manifest, skip what is already correct.
3. End bootstrap by running doctor and then a smoke test: the fastest test target, --help of the built binary, or a request to the local health endpoint. The script's exit status is the smoke test's.
4. Make every step non-interactive; prompts block agents and CI. Read credentials from environment variables or a documented file, and report their absence as a FAIL with a link, not a prompt.
5. Print what was done and how long it took, and write the same to a log file that a failed run can attach to a bug report.
6. Run bootstrap from a clean machine or container in CI on a schedule; a setup script that only newcomers run rots between newcomers.
7. Treat every newcomer's failure as a bug in doctor: if no check caught it, add the check before fixing the environment.

Expected result

Setup failures become specific ("PostgreSQL 16 expected, 14 found; run the listed upgrade command") instead of a stack trace from the first command that needed the missing piece.

Limits and test basis

Platform coverage is the cost: each supported operating system needs its checks and fixes maintained. The script cannot verify what it cannot observe (a VPN, a permission granted elsewhere), only that a probe failed. This is a proposed protocol; no adoption or timing results are claimed.