Show HN: AIエージェント向け検証ブラウザ – 13msのウィンドウ、ワンコールチェック

hwatu AIエージェントのハーネスループを、リアルな目を与えることで瞬時に高速化します。 エージェントが「ピクセルパーフェクト」と主張するのを止めさせましょう。97.49%を証明させましょう。 ページチェックごとに5回のツールコールを支払うのを止めましょう。hwatuのチェックはワンコール、約35msです（ウォームサーバーのPlaywrightを約9倍上回ります）。 ブラウザウィンドウがフォーカスを奪うのを止めましょう。デフォルトでヘッドレスなので、あなたはタイピングを続けられます。 Chromiumの170MBを配布するのを止めましょう。1つの静的バイナリとあなたのディストリビューションのwebkitgtkのみです。 ドキュメント ビジョン: 耐久性のある製品原則、ネイティブプラットフォーム戦略、スウォームモデル エージェントガイド: プロトコル、プリミティブ、検証ループ ヒューマンガイド: タイリングWMブラウザサイド ベンチマーク: 全ての数値、測定済み、方法論付き ロードマップ: 記録された計画、優先順位、非目標 継続的改善: アクティベーションメトリック、フィードバックループ、週次ケイデンス ローンチキット: 再利用可能なコピー、チャネル、測定計画 クイックスタート インストール → ワークフローを検出 → エージェントを接続 → ページを検証 → 人間に引き継ぐ curl -fsSL https://raw.githubusercontent.com/hongnoul/hwatu/main/scripts/install.sh | bash hwatu setup 1つの静的バイナリとあなたのディストリビューションのwebkitgtk-6.0（インストーラーがチェックします）。 Archの場合: yay -S hwatu。 ソースから: cargo build --release。 インストーラーはバイナリのみをインストールします。 hwatu setupはサポートされているコーディングエージェントを検出し、設定を変更せずに利用可能な接続を表示します。 準備ができたらクライアントを明示的に選択してください: hwatu doctor hwatu setup --client claude --scope project --dry-run hwatu setup --client claude --scope project hwatu demo インストール: 2つのバイナリをダウンロードし、WebKitGTKをチェックします。 検出: Claude Code、Cursor、Jcode、または汎用MCPワークフローを見つけます。 接続: Jcodeのネイティブソケット、MCP、またはCLIフォールバックを使用します。 検証: doctorまたはdemoでヘッドレスレンダリングされたスモークテストを実行します。 引き継ぎ: 人間が必要な場合にのみ、同じライブセッションを具体化します。 セットアップはプレビュー可能で、冪等性があり、同じクライアントとスコープに--undoを追加することで元に戻すことができます。 プロジェクトスコープは共有可能な設定を作成します。ユーザー スコープは個人的な設定を保持します。 Claude Codeは、各ユーザーにプロジェクトスコープのMCPサーバーを承認するように求めます。 手動MCP設定は、1つのポータブルエントリのままです: { "mcpServers": { "hwatu": { "command": "hwatu", "args": ["mcp"] } } またはMCPを完全にスキップします。全てのコマンドは短いCLI呼び出し、またはUnixソケット経由の1行の改行区切りJSONラインです。 hwatu localhost:3000 # ターミナルを開くようにウィンドウを開く hwatuを試しましたか？ 成功したチェック、失敗したインストール、見つからないワークフローはすべて有用なシグナルです。 2分間の使用レポートを共有するか、バグを報告してください。 機能 ピクセル差スコアリング: 一致率 + 差分領域 + ヒートマップ（差分） アニメーションを数値化: 期間、イージング、速度（モーション） 決定論的なアニメーションフレーム: 全てのアニメーションを時間tで固定（シーク） ページの状態をJSONで、ピクセルではなくトークンで（スナップショット） 構造化されたエラー付きのリアルな入力イベント（クリック/タイプ/スクロール/アップロード） JSエラー、コンソール出力、失敗したリクエスト（コンソール） JSONラインまたはMCP通知としてのプッシュイベントサブスクリプション（ウォッチ） ポーリング付きのワンコールページアサーション（expect） ヘッドレス/バックグラウンド/フォーカスを各ウィンドウのプロパティとして、ライブで切り替え可能 人間への引き継ぎ: hwatu focus <id> は、ライブセッションをタイリングWMにドロップします 構造化された待機/再開（チャレンジ）付きのCAPTCHA / アンチボット検出 MCPサーバー、プレーンCLI、および1行のJSONソケットプロトコル 人間向けの最小限のWebKitブラウザ: ネイティブ広告ブロック、vimスタイルのバー、クラッシュ復旧 なぜPlaywrightやchrome-devtools-mcpではないのか？ エージェントにブラウザを提供するには3つの方法がありますが、そのうち2つはうまく機能しません。 どのように実行されるか | エージェントループにどれだけコストがかかるか コールドライブラリ（Playwright、タスクごとに起動） | エンジンはスクリプトが開始すると起動します 呼び出しは速いが、実行は遅い: 各チェックでエンジンの起動コストが発生し、タスク間で状態は引き継がれません ウォームブラウザ（あなたのChrome + devtools-mcp） | フルヒューマンブラウザが常駐します リソースはタブ、拡張機能、同期、UIに費やされます あなたはレンダリングせず、作業中にウィンドウがフォーカスを奪います hwatu 「最もコールドなウォームデーモン」: エンジンはホット、他はすべて不在 8msの起動、35msの検証済みチェック、要求されるまで見えない（フォーカス）、双方向に中断可能 hwatuはチェックを瞬時に行うために必要なもの（エンジン、GPUコンテキスト、コンパイル済み広告ブロッカー、事前にウォームアップされたWebView）を保持し、前に座っている人間には役立たないものはすべて排除しています。 だからこそ、タブバーなしでウォーム状態を維持し、同じ方法で駆動されたウォーム状態のPlaywrightサーバーがクライアントあたり341msかかるのに対し、hwatuは39msで済むのです（ベンチマーク）。 2つ目の違いは、返ってくるものです。Playwrightとchrome-devtools-mcpは、その核となる部分ではオートメーションAPIです。エージェントがブラウザを操作できるようにし、生のスクリーンショットとDOMをエージェントに渡して確認させます。 hwatuは異なります。これは検証ブラウザです。測定プリミティブが組み込まれており、ブラウザ自体はウォームデーモンであり、ウィンドウのコストは13ms、ヘッドレスは起動モードではなくウィンドウのプロパティです。 だからこそ、ループは実際のコマンド、実際の出力のように見えます。 hwatu --headless localhost:3000 # そのウィンドウ; あなたは決して見ない hwatu --headless staging.example.com # 参照 hwatu diff --id 2 --other 1 --heatmap /tmp/heat.png # {"match_percent":85.13,"regions":[{"x":0,"y":160,"w":2048,...}]} hwatu motion --id 1 # 参照のアニメーションを数値で # イージング cubic-bezier(0.25,1,0.5,1), 300ms, マーキー 29.78px/s ... # ...エージェントがコードを編集... hwatu diff --id 2 --other 1 # {"match_percent":97.49} # クローリングは推測を上回る stripe.comのランディングページのクローンに対してこのループを実行しました。エージェントは85.1%から98.8%のピクセル一致率に向上させました。再現するには: scripts/demo/。 完全な検証パス（オープン、ロード、評価、スクリーンショット、クローズ）は、1つのコマンド、1つのツールコール、約35msの中央値です（ベンチマーク）。 hwatu check localhost:5173 --eval 'document.title' --shot=/tmp/after.png # {"title":"My App","eval":"My App","shot":"/tmp/after.png", # "console":[...],"load_ms":13,"total_ms":35} 生成されたHTMLを手元に持ち、サーバーがない場合？ hwatu renderは、マークアップを入力として同じワンコールパスを実行します。一時ファイルなし、python3 -m http.serverなし: echo '<h1>generated</h1>' | hwatu render --stdin --shot=/tmp/gen.png # {"rendered":true,"shot":"/tmp/gen.png","load_ms":5,"total_ms":28} ロード、コンソール、ダウンロード、ウィンドウイベントにポーリングなしで反応します。 hwatu watch --kinds load,console # {"event":"load","seq":1,"window_id":7,"data":{"state":"started",...}} MCPクライアントは、通知/hwatu/eventと同じストリームのsubscribe_eventsを呼び出すことができます。 各接続はゼロから始まる厳密に単調増加するシーケンスを取得します。接続のクローズまたは停止は、デーモンをブロックせずにサブスクリプションをドロップします。 PlaywrightのウォームインプロセスCDP接続の同じパス、その最良ケースは82msで5つのAPIコールです。 hwatuが実際に実行する方法（チェックごとに新しいクライアント、ウォーム状態のエンジン）で整形されたPlaywrightのパスは、341ms対hwatuの39msです。 hwatuは設計上ウォームデーモンであり、Playwrightは自分でウォーム状態を保つ必要があるライブラリです。 そして、エージェントがCAPTCHAや判断の難しい状況に遭遇したとき、hwatu focusはそのライブセッション（クッキーと状態をそのままに）をあなたのタイリングWMに具体化します。あなたは10秒間操作します。そして、それは再び引き継ぎます。 これは他のどのツールも主張できない形容詞です: 中断可能。 他のどこでも、ヘッドレスは起動時に決定され、人間はどんな犠牲を払ってもセッションを見ることはできません。 hwatuでは、それはウィンドウのプロパティであり、双方向にライブで切り替え可能です。 速度は同じ設計決定から来ています。hwatuはウォームデーモンであり、起動するライブラリではありません。 エンジン、GPUコンテキスト、コンパイル済みの広告ブロックルールセット、および事前にウォームアップされたWebViewは、すべてのタスクを超えて存続するため、チェックはコールドプロセスではなくホットパイプラインから開始されます。 Playwrightはライブラリであり、本質的にコールドです。それをウォーム状態に保つことは、あなたが構築するもの（サーバープロセス、接続管理、コンテキストプーリング）です。hwatuはデフォルトでウォーム状態のまま出荷され、唯一のモードです。 hwatuの比較 凡例: ✅ はい / 組み込み · 🟡 部分的 / 限定的 · ❌ いいえ 機能 | Playwright | chrome-devtools-mcp | hwatu 検証パス（ロード+評価+スクリーンショット）、ウォームインプロセス | 82ms | n/a | 35ms ウォームサービスとしての検証パス（チェックごとに新しいクライアント） | 341ms | n/a | 39ms 検証パスあたりのツールコール数 | 5 | 5 | 1 ピクセル差スコア + 再