The --smart Pipeline

--smart runs on error only — no cost, no model inference, nothing happens on a clean compile — entirely locally via a small quantized model loaded through llama.cpp. No network call, no external dependency.

turf my_program.tr --smart -o my_program

When a diagnostic fires with --smart enabled, this is what actually happens, in order.

1. The error already carries structural context

As described in Diagnostic Engine Architecture, every diagnostic class that has something meaningful to point to attaches a RelatedLocation at the exact point in the Resolver/TypeChecker/Codegen where that information is already known. --smart doesn’t do anything special to obtain this — it’s simply the first consumer downstream of data the compiler was already producing for the ordinary diagnostic-rendering path.

2. Context is built from that data, not from guessing

An earlier iteration of this feature scanned raw source lines for patterns like fn name( or a declaration keyword to guess where something relevant might be. That approach is gone. Context assembly now just reads the RelatedLocation list off the diagnostic and pins those exact lines into the model’s prompt, labeled with why each one matters. The size of the surrounding sliding window — how many lines before/after the error line itself — is sized per error category: tighter for self-contained errors like a syntax mistake, wider for errors like a type mismatch where the relevant declaration may be far away in the file.

3. Category classification is resolved deterministically first

A rule-based classifier — not the model — assigns each error to a category before any model call happens. Only when that fails to produce a specific category does the category get folded into the same model call that produces the fix, via a category field in the same JSON response, rather than spending a second, separate model invocation on classification alone.

What happens next

Steps 4–6 — grammar-constrained sampling, computed (not self-reported) confidence, and sandboxed validation of the suggested fix — are covered in SLM Integration, since they’re specifically about the model-serving layer rather than the diagnostic/context-assembly layer this page covers.

Scope and opt-in

All of this is strictly opt-in via --smart — a plain turf file.tr -o file never touches the model at all, and the deterministic compiler behavior described in Compiler Architecture is unaffected either way. Subsequent errors in the same compile pass, after the first, just note that they may be a cascading effect of the first one rather than triggering another model call. Warnings never invoke this pipeline at all.