​

階層検証プレイブック

​

なぜこの手順が必要か

1. Harness ランタイム層（オープンソースのランタイム、server から呼び出される）
2. オープンソースの製品層（myrm-agent-server + myrm-agent-frontend）
3. ユーザーが感じ取れる表現層（docs + 公式サイトobesの訴求コピー）

​

階層と証拠の対応

​

第一歩：まずマシンを止まらないようにする

/usr/bin/time -l bash scripts/dev/run-pytest-safe.sh -- ./myrm test <target> -q

• /usr/bin/time -l のピーク RSS
• 現在のマシンで利用できるメモリ（available、used_percent）
• 連続再実行で単調なメモリ増加が起きていないか

​

第二歩：harness の起動経路を検証する

bash scripts/dev/run-pytest-safe.sh -- ./myrm test myrm-agent-harness/tests/toolkits/acp/test_backend_detector.py -q --cov=myrm_agent_harness.toolkits.acp.core.backend_detector --cov-report=term

• テストが通る
• 定向カバレッジがキャッシュ / リフレッシュの重要経路を十分に覆っている
• 再実行で異常なメモリ傾向がない

​

第三歩：製品層の TTFT 経路を検証する

bash scripts/dev/run-pytest-safe.sh -- ./myrm test myrm-agent/myrm-agent-server/tests/services/agent/stream_session/test_stream_loop_ttft.py myrm-agent/myrm-agent-server/tests/api/statistics/test_usage_aggregation_coverage.py -q --cov=app.services.agent.stream_session.stream_loop --cov=app.api.statistics.usage_aggregation --cov-report=term

bash scripts/dev/run-pytest-safe.sh -- ./myrm test myrm-agent/myrm-agent-server/tests/api/agent/test_stream_collector_coverage.py -q --cov=app.services.agent.streaming_support.stream_collector --cov-report=term

• 可視テキスト payload 上の TTFT 収集が通る
• TTFT が message_end に注入され、統計集計がそれを読み取れる
• カバレッジが主要経路を実テストで覆っていることを示しており、外周の mock だけではない

​

第四歩：ブラウザ実景での受入（リソースが許す場合）

• new_page で WebUI を開く
• take_snapshot で可視状態を確認する
• evaluate_script で操作結果を確認する

​

第五歩：証拠を公開し、過度な宣伝を避ける

1. temp-docs/materials/*_ADVANTAGE.md（完全な証拠）
2. docs の競合比較ページ（最新の検証スナップショット）
3. 公式サイトのランディングページの訴求コピー（ユーザー表現）

• 競合に関する結論はテスト証拠に紐付ける
• 「何を測り、何を測らなかったか」を明示する
• 公式サイトコピーは下層の専門用語の羅列を避ける。明示の要望が無い限り「六項のコア能力」セクションは変更しない

​

合格基準

• 定向テストが通る
• リソース境界が許容範囲
• TTFT / プローブ契約に隠れたフォールバックが無い
• docs と公式サイトコピーが実測証拠と一致している