順序づけの原則は、まず荷重を支えるコアを作り、可能な限り最小の範囲でエンドツーエンドの再現性を証明してから、広げることです。FlowSpec IRとTool contractは、他のすべてが依存する判断（tenet T4）なので、最初に出荷し、変更は最小限にします。

​
制約条件

  • すべてのマイルストーンは、実行可能で再現可能なものを最後に残します。純粋な足場だけのマイルストーンはありません。
  • エンジンは、実行時にクラウドSDKやモデルへの依存を持ちません。
  • 各パッケージは、1つのpnpm + Bunモノレポ内で独立してバージョン管理（Changesets）され、Turborepoでキャッシュされ、Biomeでlintされ、同じ場所に*.spec.tsを持ちます。

​
実際のパッケージ構成

packages/
  core/          FlowSpec, Tool contract, compiler, Rider, Journal  (the engine)
  sdk/           fluent builder (method chaining) → FlowSpec
  yaml/          YAML parser + canonical emitter (round-trip)
  std/           standard tool packs: http, transform, shell, fs, control, model
  browser/       the browser tool: record (author-time) + replay (runtime)
  cli/           the `browserflow` binary (composition root over the above)
  registry/      pack format, publish/resolve, replication, browserflow.lock
  web-api/       Hono on Bun control-plane API (registry, runs, deploys, schedules, secrets)
  e2b/           E2B sandbox adapter (SpawnCapability + FsCapability inside a remote Linux microVM)
apps/
  web/           Next.js run inspector + canvas⇄YAML editor
coreは自分自身のインターフェース以外には依存しません。sdkとyamlはcoreに依存し、それ以外はすべて内側に依存します。

​
マイルストーン

1

M0 — 仕様とcontract

✅ 完了。 記録上のcontractとしての設計ドキュメントとZodスキーマ: InputDecl, ToolContract, Step, FlowSpec, Run, JournalEntry, PackManifest, DomainError。
2

M1 — コアエンジン（再現性を証明済み）

✅ 完了。 @browserflow/core: コンパイラ（resolve → typecheck → DAG → canonicalize → digest）、Rider（DAGスケジューラ、手順ライフサイクル、リトライ、冪等性）、Journal、Store（memory + SQLite）、再開、リプレイ。@browserflow/yamlのparse + canonical emit。std/transform, std/http, std/shell, std/fs, std/control。CLI compile, run, replay, inspect, runs, lint, emit。
3

M2 — オーサリングの同等性（2つの顔、1つの真実）

✅ 完了。 完全な型推論を備えた@browserflow/sdkのfluent builder。YAML round-tripはCIで固定点です。CLI emit, lint, --check, --dry。
4

M3 — ブラウザーTool

🟡 おおむね完了。1つの接続点は後回し。 @browserflow/browser: Recording構造、正規化、digest化、browserTool()の決定論的リプレイは完全に実装済みです。CLI browserflow recordは--ops <file>（事前解決済みの操作リスト → canonical Recording）を受け取ります。ライブのインタラクティブなPlaywrightキャプチャ（ブラウザーを開き、クリックして進み、自動キャプチャする）は計画中です。それを支える注入モデルとopsの接続点はすでに配置されています。
5

M4 — Packとレプリケーション（デプロイ + SDKの複製）

✅ 完了。 @browserflow/registry: Pack形式、pack init/add/publish/export, install, browserflow.lock, digest検証。CLI pack, install, registry mirror | ls | verify。ファイルバンドルによるair-gap export/import。リモートサンドボックス実行用の@browserflow/e2bアダプター。
6

M5 — Launcher（どこでも起動）

✅ 完了。 CLI serve（Hono経由のREST）、mcp（@modelcontextprotocol/sdk経由のMCPサーバー）、schedule（croner経由のローカルcron）。移植性conformance suiteは、すべてのフロントで同一のRun出力になることを検証します。E2Bサンドボックスは--sandbox e2b経由で統合済みです。
7

M6 — サービス（コントロールプレーン）

✅ Routes、auth、RBAC、Postgresは完了。canvasは後回し。 packages/web-api（Bun上のHono）: SQLite backed PlaneStoreを使うregistry、runs、deploys、schedules、secrets routes。apps/web（Next.js 15）: runs list、run detail、timeline、YAML emitter。Auth、RBAC、multi-tenancy、Postgresは出荷済みです。WrapperStoreインターフェース（orgs、users、memberships/RBAC、API keys、automations、run refs、schedule refs、secrets、authoring sessions、audit log）は、in-memory、SQLite、Postgres（永続行の上にあるwrite-through cache）の実装を出荷しています。サービスを参照してください。Canvas editorはまだプレースホルダーです（step cardsのみで、interactionはありません）。
8

M6.1 — MCP-as-a-productと実行の可観測性（#46–#75）

✅ 完了。 2回目のパスでM6の上に載せました: REST公開ゲートから独立したオートメーションごとのMCP toggle（#73）、キャプチャ済み手順リテラルからbind可能なオートメーション上のtyped parameters（#72）、buffered JSONと並ぶMCP SSE streaming（Streamable HTTP notifications/progress）（#66）、get-run-status polling toolを持つMCP queue dispatch mode（#67）、CDP screencastによる実行中Runのlive browser view（sync dispatchのみ）（#68）、APIキーごとのscopes（オートメーションallowlist、スコープ外では不可視 + 403）（#64）、クライアント別config snippetを持つ実際の**“Connect via MCP”** panel（#63）、Run Inspectorのfull Journal（手順timelineだけでなく、effect/skip entriesを含む順序付きログ）（#56）、そしてBuild StudioとRun Inspectorからのrun stop/cancel（#55）。Connect via MCP、Runs & Inspector、Access Controlを参照してください。

​
Post-1.0候補（コミット対象外）

これらは探索的な方向性であり、コミットメントではありません。
  • より多くのstd tool kindと、community pack registry。
  • 同じJournalセマンティクスを持つ分散/worker-pool実行。
  • Pack上の署名付きprovenance attestation（SLSA-style）。
  • code toolのサンドボックス強化パス（WASM / capabilityごとのprocess isolation）。
  • UIで2つのFlowSpec digestをvisual diffする機能。

​
やらないこと

これらは交渉不可の境界です。thesisを守るためです。
  • モデルをruntime execution pathに置くこと。（今後もありません。これがthesisです。）
  • 再現性や移植性を有料サービスに依存させること。
  • 数行を節約するために、エンジンへambient global stateを追加すること。
  • coreを特定のtransport、store、cloudに結合すること。
ビルド順を1行で: contracts → engine + replay → dual authoring → browser tool → packs + replication → launchers → service。各手順は独立して出荷可能であり、それぞれが再現可能な実行で終わります。

​
関連項目

FlowSpec IR

M0で固定された正規化とdigestのルール。

実行

M1が届けるRider、Journal、再開、リプレイ。

ToolとPack

M4で到達するPack形式とレプリケーション。

Launcher

どこでも実行するためのM5の移植性conformance suite。