blue — the command line.
Every subcommand does one thing, per ★★ CLOSED-LOOP MASS-SYNTHESIS:
a monolithic blue do-everything is the shape this forbids. Each one is a
projection of the same pipeline, so blue ast and blue run cannot
disagree about what a program means — they read the same stages from
blue_lang_runtime::pipeline.
blue run FILE parse, check, erase, execute
blue fmt FILE [--check] the one formatting; --check exits 1 on drift
blue ast FILE the tatara-lisp form — homoiconicity, visible
blue erase FILE the tatara-lisp form after type erasure
blue check FILE the sliding-scale report: analysis and seams
blue test FILE run the file's `test` blocks
blue deps BLUEFILE resolve the manifest's dependencies
blue posture BLUEFILE the posture the manifest's floors require
blue config [TIER] the bounds blue is running with
blue lsp speak LSP over stdio
blue banner the wordmark — the blueshift ramp
blue shift FILE how far this is shifted, and what is shifting it
blue deps and blue posture read a Bluefile, which is itself a blue
program — see blue_lang_pkg::bluefile. posture was previously absent
because there was no declaration surface to read a floor from; there is one
now.
Neither fetches anything. Resolution is real; there is no registry
client, so deps resolves against the distribution already on
BLUE_PATH (via GitRegistry) and installs nothing. With no distribution
there, it says so rather than printing a hollow resolution.
Every subcommand runs under the bounds in config — resolved once, here,
and threaded down.
blue ast and blue erase are separate on purpose: the difference
between them is the sliding scale, and being able to print both sides of
it is how a reader sees that annotations are consumed rather than carried.