bob ready

bob ready — converge a project to warp-drive-ready

Making a project warp-drive-ready on a machine used to be five separately remembered steps — cdi, cdprov refresh, label bootstrap, port band, dev.json / checks.json sanity — each idempotent alone, none asserting the others ran. Forgetting one was silent until a run broke. bob ready is one façade over those tools plus a verdict (#1922). It adds no convergence logic of its own; it composes what exists, in order, and says whether the project is ready — naming the exact fix for anything that is not.

bob ready [project-dir] [--dry-run] [--json] [--name <project-name>]
bob-ready …                    # same engine, PATH wrapper
make ready ARGS=<project-dir>  # same engine, from the BOB_SOURCE checkout

Exit 0 READY · 1 NOT READY · 2 usage error. Engine: scripts/ready/ready.js.

Steps, in order

Step	Runs	ok / no-op means	Blocker names
host	host-drift.js (bob doctor, #1921)	this machine’s BOB_HOME matches source	scripts/deploy.sh
init	cdi -y <dir>	.claude/ scaffolded, universal items linked, project registered	cdi -y <dir>
provision	cdprov refresh <dir>, or cdprov --init --auto <dir> when no provisions/<name>.json exists — the manifest write rides cdprov’s own #1478 fast-path / staged-PR route, never a silent write	manifest projection converged (no [unlinked] items)	the failing cdprov command
labels	bootstrap-labels.sh check, then ensure only if labels are missing	the canonical label set is on the repo’s forge	gh auth login / a GitHub remote
ports	port-fleet-migrate.js --dry-run --json as a collision gate, then port-project-sync.js sync	a band exists in provisions/ports.json and dev.json carries its _bob_ports projection	make port-migrate on a collision
manifests	dev.json against schemas/dev.schema.json; checks.json shape (name / command / kind)	manifests parse and validate (absent dev.json is fine — a CLI repo has no dev server)	the manifest to fix

Every step runs even after a blocker, so one pass reports every blocker.

Contract

• No prompts, ever. Every tool is invoked in its non-interactive form with stdin closed. Anything that would need a human is a blocker with the command to run, not a question.
• Idempotent. A second run on a ready project changes nothing and reports each step ok / no-op. Change detection is a fingerprint of the project’s .claude/ tree (and, for ports, dev.json + the ledger) taken around each mutating step — changed is observed, not assumed.
• --dry-run reports what each step would do (would lines) and runs nothing that writes; only read-only probes (host-drift.js, cdprov --status, bootstrap-labels.sh check, the collision gate) execute.
• macOS and Linux alike. node + bash only; no iTerm2 or brew assumptions; paths resolve via $BOB_SOURCE / $BOB_HOME / $HOME.
• --json emits a versioned project-ready/1 document: verdict, ok, steps[] (name, status, detail, fix), blockers[].
• The verdict persists. A non-dry run writes <project>/.claude/.project-ready.json (verdict, at, machine, blockers). The fleet snapshot reads it as project_ready per project and rolls it up per machine; audit.js view renders a “Project ready” table naming NOT READY projects with their blocking steps; cdb prints a ready: READY / ready: NOT READY (step…) line per graded project. Nothing re-runs the steps to show a verdict.

Sample output

bob ready — shop (/Users/you/projects/shop)
  ok           host       BOB_HOME converged with source (4 sections)
  no-op        init       .claude/ already initialised
  changed      provision  cdprov refresh re-linked declared items
  ok           labels     standard label set present
  BLOCKED      ports      port ledger has a collision (shop)
               Fix: make port-migrate (in BOB_SOURCE) — resolves the collision loudly
  ok           manifests  dev.json valid; checks.json: 3 check(s) declared

NOT READY — 1 blocker(s): ports (fixes above)

Where it is called from

• A human, after cloning a project on any machine (cdi alone is no longer the whole story — see New machine setup).
• Fleet repos sync as its post-clone BoB hook, and thefarm’s bob workload for farm checkouts (paulirv/fleet#15, #1920 R5).
• The warp-drive preflight gate (#1923) consumes the same verdict: bob preflight (scripts/warp-drive/host-preflight.js) runs bob doctor and bob ready --dry-run as one warp-preflight/1 document — non-mutating by default, --converge applies bob ready first and then re-checks — and on failure files (or bumps, by a fingerprint over the failing set) one todo naming each fix. It never proceeds past a failed check; exit 0 pass · 1 fail · 3 engine error (fails closed).

Testing

make test-ready drives the façade against stubbed step tools ($BOB_READY_TOOLS names a directory of same-named executables), so the contract above — order, classification, idempotence, dry-run, verdict, exit codes, persistence, the cdb line — is what is under test; each underlying tool keeps its own suite.