fused-verifylisted

# Scanning, testing, and validation in fused > **Part of the Fused skill set — don't work from it alone.** Fused is `workspace ⊃ > project ⊃ UDF`. If you're validating code that belongs to a project, load > **`fused-projects`** for the end-to-end flow (specs, run, deploy) and > **`fused-execute`** for how code runs. See **`fused-guide`** for the full set. ## What exists today | Layer | Command | What it checks | |---|---|---| | Static scan | `fused code verify` | Code patterns, dependency CVEs/typosquats, input-file names and zip bombs | | Spec conformance | `fused code verify --spec "..."` | LLM check: does the code match the stated intent? | | Test suite | `fused code test --test-file …` | Pytest + line/branch coverage in the real execution environment | | Audit | `fused audit log` | Reads the local audit store (see below for what is still recorded) | > **Verify does not run automatically.** `fused code run` and `fused code test` > execute code **without** any pre- or post-execution scan. Nothing blocks a run, > no output firewall inspects results, and no `execute_code` / `verify_code` > audit events are written. The environment's verify settings (`--verify`, > `--require-spec`, `--audit-bucket`, `verify.enabled`, `block_on_warn`, > `typecheck`, `expectations`) do **not** gate or check executions. If you want a > scan, run `fused code verify` yourself before `code run`. > > There is also no CLI replacement for the old data-quality `expectations` > contract (schema / nul