以下の質問は、チームが初めて browser-flow を評価するときに最もよく出るものです。各回答では、正準的な daily-price-watch Flow（browser:search-price@1.2.0 による検索、transform、そしてシークレット webhook への条件付き http.post）を再利用し、その挙動が完全に仕様化されている箇所へリンクしています。
いいえ。実際に何かを実行する唯一のコンポーネントである Rider はモデルを実行せず、制御フローを決めるためにモデルを呼び出すコードパスもありません。エンジンは型付き手順のDAGをスケジュールし、注入されたcapabilityを通じてToolを呼び出し、Journalを書き込みます。そのループの中でモデルに手を伸ばすものはありません。AIはFlowの作成を助けることがあります（手順の提案、YAMLの下書き、作成時のブラウザー記録のガイドなど）が、Flowが実行時に何をするかを決めることは決してありません。この省略は見落としではなく、この仕組みの主張そのものです。詳しくは実行と概要を参照してください。
はい。std/model と、その net および secrets capabilityを宣言する model.complete Toolを通じて呼び出せます。ただしモデル呼び出しは他と同じeffectです。リクエストとレスポンスはJournalに記録され、それ自体が制御フローを操ることはなく、hermeticなリプレイではネットワークなしで記録済みレスポンスが返ります。言い換えると、AIはpinできるデータソースであって、意思決定者ではありません。http.post に適用されるのと同じ記録ルールとredactionルールが、モデル呼び出しにも適用されます。詳しくは標準Packと実行を参照してください。
いいえ。Flowは任意のコードではなく、型付き手順のグラフです。各手順は kind:name@range でToolを参照し、型付き入力を出力へ配線し、境界でZodスキーマに対して検証されます。逃げ道として code Toolはありますが、基本経路は宣言的で検査可能です。多くの命令的ロジックを必要とする機能は、通常、Flow内にインラインで置くのではなく、カスタムToolやPackに置くべきです。詳しくはオーサリングとカスタムToolを参照してください。
いいえ。オープンソース境界は、再現性やポータビリティに不可欠なものがサービスの背後に置かれないように引かれています。エンジン、SDK、標準Pack、CLI、つまり author、compile、run、replay、pack、launch はすべてApache-2.0で、完全にセルフホスト可能です。無料のエンジン上で構築され検証されたFlowは、有料サービスでも同一に実行されます。サービスが追加するのは調整機能（ホスト型Registry、スケジューラ、シークレットブローカー、RBAC、Run Inspector、replication）であり、capabilityではありません。詳しくは実行とコントロールプレーンを参照してください。
参照先ではありますが、依存関係ではありません。兄弟プロジェクトの browser-flow は、単一の自然言語タスクを1つの決定論的なPlaywright Toolへコンパイルします。browser-flowはその哲学、つまり実行時にLLMを使わない、1度作成して永続的に実行する、content-addressed provenance、境界でのシークレット、を借りていますが、そのコードは一切取り込んでいません。browser-flowが1つの決定論的Toolを作るのに対し、browser-flowは多くのToolをFlowへ合成します。そこにFlowSpec IR、Rider、Journal、Pack、Launcherが加わります。ブラウザー検索から条件付きwebhook投稿へつなぐ daily-price-watch Flowは、まさにbrowser-flowが扱わない合成の話です。詳しくは概要を参照してください。
Toolの入力、出力、capabilityが変わるたびに、そのToolのcontract digestが変わります。そのため、互換性のない変更がパッチを装うことはできません。FlowはdigestによってToolにpinされているため、その変更は上位へ伝播します。同じ名目上のバージョンであってもFlowのdigestも変わり、digest不一致はコンパイル時に表面化します。contractの変更だけでなく挙動の変更を検出するには、Journalをfixtureとしてpinし、replay --verify を実行します。これはhermeticに再実行し、Toolのアップグレードによっていずれかの手順の出力が変わると失敗します。
browserflow replay <run-id> --verify
daily-price-watch では、search-price を新しいRecordingへアップグレードしたとき、抽出された価格の形が変われば、pinされた --verify が失敗するということです。新しいToolが出荷される前に検出できます。詳しくはToolとPackと実行を参照してください。
シークレットは境界に存在し、永続化されることはありません。secret: true とマークされた入力（Cookie、トークン、daily-price-watch のwebhook URL）は、FlowSpec、Journal、ログ、公開済みPackのいずれにも入りません。静的な taint rule によってシークレット値は式レイヤーから排除されるため、シークレットが実体化するのは、secrets capabilityを宣言したToolの内部、かつ実行時だけです。effectが記録されるとき、シークレット由来のバイト列は安定したプレースホルダー（{secret:<slot>}）へredactされます。再開時または --rerun 時には、シークレットはライブで再解決され、Journalから読み出されることはありません。詳しくはシークレットと実行を参照してください。
はい。すべてのPackとJournalはcontent-addressedであるため、FlowSpecとそのPack、記録済みJournalを隔離環境へ移し、接続性ゼロで結果を再現できます。
1

エクスポート

pack export でPackをファイルとしてバンドルします（ライブRegistryは不要です）。
2

インストール

隔離されたマシンでは、lockfileから browserflow install が取得を行い、何かを実行する前にすべてのdigestを検証します。
3

リプレイ

browserflow replay <run-id> --verify はhermeticに実行されます。net、clock、random、fs-read、browser capabilityは完全にJournalによって裏付けられるため、外部呼び出しは行われず、シークレットも不要です。
詳しくはエアギャップデプロイとToolとPackを参照してください。
エンジン、SDK、YAMLオーサリング、標準Pack、Registry、3つすべてのLauncher（serve、mcp、schedule）は実装済みでテストされています。@browserflow/browser のRecordingモデルと決定論的リプレイは完成しています。ライブのインタラクティブなPlaywrightキャプチャは計画中です（ops-from-file seam が browserflow record の現在の入口です）。web-apiコントロールプレーンのルートはSQLite向けに実装されています。Next.jsのRun Inspectorは機能しています。キャンバスエディタはプレースホルダーです。マイルストーンごとの状況はロードマップを参照してください。

​
関連

概要と原則

問題、設計原則、そして60秒でつかめるメンタルモデル。

境界でのシークレット

taint ruleと、シークレット値が永続化されない理由。

ロードマップ

仕様とcontractからコントロールプレーンまでのマイルストーン。