Frontend Workflow
The public FOL entrypoint is the fol tool.
fol is implemented by the fol-frontend crate. It sits above:
fol-packagefol-resolverfol-typecheckfol-lowerfol-backend
Its job is orchestration, not semantic analysis.
What The Frontend Owns
The frontend owns:
- CLI parsing with
clap - grouped command structure
- package and workspace discovery
- project scaffolding
- package preparation and fetch/update workflows
- build, run, test, and emit orchestration
- editor command dispatch under
fol tool - shell completions
- user-facing summaries and workflow errors
Bundled std reminder:
- hosted binary scaffolds should default to
fol_model = "memo" - scaffolded projects should rely on bundled
std - scaffolding should not teach manual std dependency setup
Compiler truth remains in the compiler crates.
Public Command Groups
The root command groups are:
fol workfol packfol codefol tool
Root aliases are single-letter only:
fol wfol pfol cfol t
Run:
fol --help
fol <group> --help
fol <group> <command> --help
for the relevant usage surface.
Root Discovery
For workflow commands, the frontend discovers roots upward from the current directory or from an explicit path.
It recognizes:
- package roots via
build.fol - workspace roots via
fol.work.yaml
A package root is one buildable package.
A workspace root is a parent root that owns multiple member packages and frontend-managed roots like build/cache/package-store locations.
Direct Package Use
The normal workflow shape is group-first:
fol work init --bin
fol pack fetch
fol code check
fol code build
fol code run
There is still a frontend-owned direct package path for compile-oriented use, but the grouped commands are the public workflow shape.
Output
Frontend summaries support:
humanplainjson
The frontend also owns workflow-level errors such as:
- missing workspace roots
- fetch/update/store failures
- clean/completion/workflow command failures
Compiler diagnostics stay separate and flow through compiler-owned diagnostic models.