browserflow がコンパイル時に発生させうるすべてのエラーは、小さな名前付きカタログの一部です。コンパイルは純粋関数、つまり compile(source, registry) → FlowSpec | Diagnostic[] です。そのため、flow は1つの正規の FlowSpec か、正確な diagnostics のリストのどちらかを生成し、半端に構築された artifact は決して生成しません。参照サイクル、未知の手順、宣言されていない入力、漏えいしたシークレットはここで、実行時ではなくオーサリング時に捕捉されます。

​
カタログ

カタログには、以下の8つのコンパイル時 diagnostics があります（03 §7）。それぞれはコンパイラの初期フェーズ、つまり resolve、type-check、または静的な taint/skip 解析のいずれかで発生し、適用しているルール名を示すため、修正方法が明確です。各項目を開くと、発生するタイミングと修正方法がわかります。
発生するタイミング: 手順の use: が、アクティブな registry にまったく存在しない tool を指定している。修正方法: tool 名と pack を確認します。その tool を提供する pack を取得するために browserflow install を実行するか、use: 参照を修正します。
発生するタイミング: use: は tool 名に解決できるが、要求された pin または range を満たすバージョンがない（例: 1.2.0 だけが公開されているときの search-price@^2）。修正方法: バージョン range を緩めるか修正し、必要なバージョンを公開または mirror するか、range が記録済みバージョンに解決されるように browserflow.lock を更新します。
発生するタイミング: binding の型が、利用側 tool の入力 schema を満たさない。生成側 step の出力型と入力 slot の schema が一致していない。修正方法: 期待される型を emit するように生成側 step の transform を修正するか、default(0, …) のような guard で binding を包みます。
発生するタイミング: 式が、step ではない x を steps.x として指定している、または生成側 step の出力 schema に存在しない path（steps.x.output.foo）を読んでいる。修正方法: step の id または field path を修正します。tool contract の出力 schema に有効な path が列挙されています。
発生するタイミング: with、when、foreach、needs から導出された参照グラフが非循環ではない。修正方法: cycle path で示された依存ループを切ります。FlowSpec DAG は非循環でなければなりません（03 §6）。
発生するタイミング: secret. 参照が operator や function で変換されている、secrets capability を宣言していない tool に bound されている、または output に流れている。修正方法: シークレットを opaque に保ちます。全体をそのまま、secrets 対応 tool input の引数としてだけ bind します。シークレットを参照してください。
発生するタイミング: binding が、条件付きで skip される step X の steps.X.output を、default(…) / ?? fallback なしで読んでいる。修正方法: 参照が null を返して step が実行されるように fallback を追加するか、分岐を組み直します。制御フローを参照してください。
発生するタイミング: 必須の tool input に with 内の binding がなく、default もない。修正方法: step の with で input を bind するか、tool contract が許可する default を指定します。
これらは daily-price-watch flow をエンドツーエンドでカバーします。search-price@1.2.0 を解決できなければ unknown_tool または unresolved_version、http.post body が number を必要とする場所に transform が string を渡せば type_mismatch、webhook URL が全体として bind されず式で組み立てられていれば secret_leak、条件付きの notify step の出力が fallback なしで読まれていれば unguarded_skip です。
これらの diagnostics のうち2つは、このプロジェクトで最も強い保証を強制しており、専用ページがあります。
  • secret_leak は taint rule を強制します。シークレットは opaque な whole-binding であり、expression layer で組み立てられることはありません。シークレットを参照してください。
  • unguarded_skip は分岐を total に保ちます。flow の出力が暗黙に null になることはありません。制御フローを参照してください。

​
構造化エラーのレンダリング

compile error は正確な YAML 行または SDK frame を指し、ルール名を示し、修正方法を提案します。以下は 08 §4 の type_mismatch 例をそのまま引用したものです。daily-price-watch flow で、notify step の http.post input は number を期待していますが、上流の shape transform は string を emit しています。 
error[type_mismatch]: flows/price.yaml:9:18
  step "notify" input "json" expects { price: number }
  but steps.shape.output is typed { price: string, at: string }
  └ hint: wrap with `default(0, …)` or fix `shape`'s transform to emit a number
最初の行には、角括弧内の機械可読 code と、file、line、column からなる source pointer が含まれます。本文は関係する2つの schema の観点から mismatch を説明し、hint が具体的な修正を提案します。

​
Diagnosticsは文字列ではなくデータ

diagnostic はデータです。コンパイラが返す Diagnostic[] array の member であり、特定の consumer 向けに format されて throw される文字列ではありません。この1つの性質により、すべての surface がカタログを同一にレンダリングできます。

CLI

browserflow compile --check は上記の構造化形式を出力し、YAML 行または SDK frame を指します。

LSP

YAML language server は同じ diagnostics を inline に、赤い波線として、同じ code と hint 付きで表示します。

UI

inspector は同じ array、つまり同じ code、同じ location、同じ fix を、別の code path なしでレンダリングします。
すべての consumer が prose を parse するのではなく1つの array を読むため、code ごとに rule は1つであり、そのレンダリングもどこでも1つです。

​
Source-mapping

すべての diagnostic は、誤りが書かれた場所へ source-mapped されます。その場所はオーサリング surface によって異なります。
diagnostic は、上記の flows/price.yaml:9:18 pointer とまったく同じように、source file 内のline と columnを持ちます。LSP はこれを使って、問題のある token に inline の波線を置きます。
CI と pre-commit で browserflow compile <flow> --check を実行してください。これは pure です。type-check して digest を出力し、pinned tools の解決時だけ network に触れます。そのため、何らかの effect が発火する前に diagnostics カタログ全体が実行されます。

シークレット

secret_leak が強制する taint rule、つまりシークレットが値ではなく境界である理由。

制御フロー

分岐、when、skip propagation、つまり unguarded_skip の背後にあるルール。

FlowSpec & IR

すべての diagnostic を生成する compilation pipeline と §7 validation。

CLIリファレンス

compile --check、lint、そして役立つ structured errors。