Module lint 

Blueprint lint: the checks Blueprint::validate deliberately does not make.

Blueprint::validate answers “is this manifest structurally coherent” - the layout fits, the graph resolves, fan-out wiring points at real stages. It says nothing about the fields whose absence quietly changes what a run does, and those are what actually bite:

• a stage with no [stages.<name>.model] table parses fine, because the parser substitutes a default, and then runs on whatever the user’s default provider happens to be
• an agent-level [model] block is never read at all, so the author’s model choice is discarded silently
• a typo in available_tools matches nothing, and the stage just advertises one tool fewer - the model is told the tool does not exist
• an autonomous stage granting ask_user_text parks in WaitingInput the first time it asks, with nobody there to answer

Each of those is invisible on inspection and shows up hours later as a stuck run. This module names them at author time instead.

Questions about what the author declared (“is there a mode key?”) are answered from the manifest text, not from the parsed Blueprint: by then the parser has already filled in its defaults, and asking the struct cannot tell “wrote autonomous” apart from “wrote nothing”.

Structs

LintEnv

Facts about the machine the blueprint will run on, which the manifest alone cannot supply.

LintFinding

One thing worth telling the author about.

Enums

LintSeverity

How much a finding matters. Only LintSeverity::Error fails lev validate; warnings are printed and the command still exits zero (unless --deny-warnings is passed); notes never fail anything.

Functions

lint_manifest

Lint blueprint, which was parsed from content.