Module scan 

Static scanning — the first of the three evidence sources behind keel init and keel doctor (dx-spec §2). No code runs: we read the project’s source and find where effects enter.

Two scanners, one merged result:

• python shells an ast-walker out to python3 - for precise Python parsing (imports of known effect libraries, URL/DSN string literals).
• js parses JS/TS/JSX in-process with oxc (no Node toolchain needed) for fetch/undici/node:http usage, provider-SDK imports, effect-lib call sites, and URL literals.

Both label every finding with file:line, so the generated keel.toml can cite where each target was found and trust stays inspectable.

Modules

js

The JS/TS static scan — a real parse on oxc.

python

The Python static scan: an ast-walker executed out-of-process via python3 -.

Structs

CallSite

One effect call site with enclosing-function attribution — an internal detail of the JS/TS pass (js), which uses it to verify its real scope-chain tracking (dotted paths like Class.method) independently of the coarser top-level-only FunctionFacts attribution keel flows suggest consumes. Not exposed on ScanResult. Field order is the sort order (file, then line).

FunctionFacts

Per-function effect attribution — the evidence behind keel flows suggest.

LangFindings

One language scanner’s raw findings before host-gating.

ScanResult

The merged output of both scanners.

Sighting

One place a target was seen: a project-relative path and 1-based line.

TargetEvidence

A target and everywhere the static scan saw it, deduplicated and ordered.

Enums

TargetClass

What kind of target a sighting resolves to. Governs the policy block keel init writes (an llm:* target gets the LLM pack; a host gets the outbound pack).

Functions

scan

Scan project with both scanners and merge. Host targets are only emitted when the language pass also saw an HTTP client in use (a bare URL in a non-networked file is not evidence of an outbound call), keeping the output honest.