Part 5 of 5

From Command to Reliable Daily Loop

The last spine page turns the chosen lock into a daily reliability workflow where refusal is a feature, not friction.

Broken intuition

bb up looks short because earlier commands already chose and locked the daily driver. The short command is reliable only because it resolves the current machine first, requires the locked profile, fetches the pinned artifact, performs manifest verification, refuses drift, starts the local server on the expected port, and writes matching Pi metadata. README.org:13 src/coding_agent/detect.clj:47-56 src/coding_agent/main.clj:54-72 src/coding_agent/profile.clj:38-68 src/coding_agent/fetch.clj:109-119 src/coding_agent/fetch.clj:161-174 src/coding_agent/serve.clj:9 src/coding_agent/serve.clj:27-48 src/coding_agent/agent_config.clj:26-77

Experiment

Step through the daily reliability workflow and watch what each stage protects.

Refusal is a feature: it turns hidden drift into an explicit stop.

The profile as a machine-specific contract matters here because the wrong Mac must not quietly reuse the wrong runtime, lock, or context window. src/coding_agent/detect.clj:47-56 src/coding_agent/main.clj:54-72 src/coding_agent/profile.clj:38-68

Revealed constraint

The loop stays dependable only if every restart reconstructs the same candidate-shaped runtime. That means the profile must refuse to proceed when no locked daily driver exists, fetching must stay pinned to the exact repo and revision, manifest verification must catch drift before serving, and the server layer must refuse to start on a busy port. Those refusals are useful because they stop a fake success before the frontend points at the wrong process or wrong snapshot. src/coding_agent/profile.clj:38-68 src/coding_agent/fetch.clj:109-119 src/coding_agent/fetch.clj:161-174 src/coding_agent/serve.clj:136-166

Named concept

The right name here is a daily reliability workflow: a profile as a machine-specific contract, one locked winner adapted back into a candidate-shaped runtime, one pinned artifact source, one manifest verification step, one local server bound to 127.0.0.1, and one Pi provider entry whose URL, model id, modality, and context metadata match the serving process. src/coding_agent/lock.clj:55-88 src/coding_agent/detect.clj:47-56 src/coding_agent/main.clj:54-72 src/coding_agent/profile.clj:38-68 src/coding_agent/fetch.clj:109-119 src/coding_agent/serve.clj:9 src/coding_agent/serve.clj:27-48 src/coding_agent/serve.clj:136-166 src/coding_agent/agent_config.clj:26-77

Repo implementation

The README reduces the loop to direnv allow, bb up, then pi -p "Reply with exactly: OK". Under that surface, bb up depends on the locked profile requirement, the fetch path for pinned artifacts and companions, manifest verification for MLX snapshots, the serve layer's selected-port refusal and local startup, and the Pi writer that merges the matching provider into ~/.pi/agent/models.json. README.org:1-31 src/coding_agent/detect.clj:47-56 src/coding_agent/main.clj:54-72 src/coding_agent/profile.clj:38-68 src/coding_agent/fetch.clj:109-119 src/coding_agent/fetch.clj:161-174 src/coding_agent/serve.clj:9 src/coding_agent/serve.clj:27-48 src/coding_agent/agent_config.clj:26-77

Recognition

Pick the statement that matches the repo's reliability model.

Select a statement to see whether it matches the daily reliability workflow.

Sources

README.org:1-31 src/coding_agent/lock.clj:55-88 src/coding_agent/detect.clj:47-56 src/coding_agent/main.clj:54-72 src/coding_agent/profile.clj:38-68 src/coding_agent/fetch.clj:109-119 src/coding_agent/fetch.clj:161-174 src/coding_agent/serve.clj:9 src/coding_agent/serve.clj:27-48 src/coding_agent/agent_config.clj:26-77

Why end on the daily loop?
The journey has to close on repeatable practice, otherwise the earlier technical detail never becomes usable habit.