Tooling
CLI, formatter, linter, tests, REPL, and the Language Server.
Tooling
Tooling in the current repo is bigger than a single souc binary. A comprehensive picture needs to include the checked artifact, the script-based gates, the website quality checks, and the self-host verification surfaces that surround the compiler.
Current contract
- The checked-in
soucartifact is still the most concrete public CLI surface. - The CLI surface should be discovered from
--helpandinfo, not inferred from stale docs. - Scripted gates are part of the tooling story because they are how the repo proves whole-system claims about the compiler, stdlib, self-host path, and website.
CLI surfaces to inspect first
export SOUC_BIN="$(pwd)/artifacts/omega/souc-bin/souc-linux-x86_64-jit"
"$SOUC_BIN" --help
"$SOUC_BIN" info
"$SOUC_BIN" fmt --help
"$SOUC_BIN" lint --help
"$SOUC_BIN" repl --help
Repo map
scripts/holds the main gate and workflow commands.scripts/selfhost/covers self-host verification and zero-fallback gates.website/package.jsondefines the docs and publish-quality checks for the site itself.self-hosted/tools/and related self-host verification docs explain the rustless and bootstrap-oriented tooling story around the compiler.
High-value repo checks
bash scripts/fast_gate.sh
bash scripts/selfhost/selfhost_zero_fallback_gate.sh
npm --prefix website run check:quality
How to document tooling accurately
- Describe the checked artifact, then describe the surrounding verification scripts.
- Document feature-gated tooling such as LSP, GPU, or LLVM as artifact-dependent.
- If a workflow depends on a self-host or bootstrap stage, say so directly instead of presenting it as a default end-user path.