スプリント 1 — 9 月 14 〜 18 日

英語版が原文です。

KR1 レビュー後の最初のスプリントです。期限は 9 月 18 日（金）、できたものをデモします。計画は 9 月 14 日に向きを変えました。9 月 12 日の KPT はアーキテクチャと価値のストーリー 1 つ、エンドツーエンドのデモ 1 本、計測されたベースライン、本番での検証を求め、9 月 14 日のレビューは、強みを顧客に向けて定義し、実データと検査できる結果で裏づけること、新機能はそのストーリーを強めるところにだけ足すことを求めました。ルーターはそのストーリーの部品であって目的ではなく、このページはその順序で書かれています。

7 つのストーリー、優先度の高い順です。それぞれ成果をユーザーストーリーとして、受け入れを Given / When / Then として、完了の定義と検証方法を持ちます。金曜までに終わらないものは引き延ばさず持ち越します。

KPT の求めのうち 2 つはすでにリポジトリにあり、やり直すのではなくその旨を報告します。すべてのデプロイワークフローは、デプロイしたホストに対して公開スモークと @deployed 受け入れシナリオを実行しています（デプロイ）。ベンチマークはすでに速度、コスト、ルーティング精度を計測しています。欠けていたのはそれらを語るストーリーと、精度の数値が拠って立つラベルのレビューです。

金曜時点の進捗

各ストーリーがどこにあるか。git log を引かずに週を読めるように置きます。完了の定義を満たしたものが 完了、まだ残りがあるものが 進行中、着手前が 計画中 です。

ストーリー	状態	現状
1. 強みを 1 ページで	進行中	エンジニアリング側は完了。ルートの Web アプリ、/docs/ のドキュメント（#167、#168、#169）。6 つのステップとそのスクリーンショット（#179）は、木曜に、出力を説明するのではなく見せるページに置き換わりました（ADR-0060、ページの変遷）。ページは 3 つのホストすべてのルートで公開されています。残るのは CEO の文言です。
2. モックを取り除いたアプリとデモ 1 本	完了	モックパッケージの削除と、全画面を本番接続か無効化のどちらかに（#170、#171）、ページごとのパーサー（#172）、5 つのビュー（#173）、検索（#174）、エンコードキャッシュ（#175）、2 パーサーのシナリオとデモ台本（#176）。
2b. ドキュメントのプレイグラウンドを閉じる	完了	/docs/playground/ と日本語ルートはアプリのプレイグラウンドへリダイレクトし、ドキュメントの本番向けスペックは退役しました（#177）。
3. ラベルに依らない 3 つの数値	完了	ベンチマークページとドキュメントのトップは、1 ページあたりの秒数、1 ページあたりの費用、CPU のみの割合を先頭に置きます。精度の数値はすべて、断言ではなくレビュー済みラベルを数える注記の後ろにあります。ラベルのレビューそのものはチームの仕事で、その数がどこまで進んだかを語ります。
4. 本番は UI を含めて自らを証明する	完了	just frontend::e2e-deployed が、スモークと @deployed シナリオと並んで 3 つのデプロイワークフローすべてで動きます（#178）。
5. デッキ 1 つを入れて Draw.io ファイル 1 つ	完了	パーサー自身のディストリビューションがファイルを書き、デモホストが配信し、チャートタブがダウンロードします（ADR-0058）。tests/fixtures/office-process-chart.drawio をバイト単位で比較しています。
6. Azure と GCP を時間を区切って	完了	両方のワークフローを 9 月 18 日の金曜に実行し、スモーク、@deployed のシナリオ、Web アプリのスペックまで緑です。Azure は everything.az.indx.jp、GCP は everything.g.indx.jp。どちらも半日には収まらず、破棄せずに動かし続けています（結果）。

どのストーリーでもないのに金曜を左右するものが 2 つあります。公開する数値がその週の実行になるよう just bench::run を回し直すこと、そして上のすべてを公開ホストへ送る AWS デプロイです。デモはその ホストだけを相手にします。

金曜の夕方時点のデプロイです。いずれもワークフロー自身の実行で、それが名指しするホスト名に対して、 公開スモーク、@deployed のシナリオ、Web アプリのスペックまで緑です。

クラウド	ホスト名	デプロイ	実行
AWS	everything.indx.jp	9 月 17 日（木）	35197782500
Azure	everything.az.indx.jp	9 月 18 日（金）	35301036896
GCP	everything.g.indx.jp	9 月 18 日（金）	35312480073

ドキュメントのサイトはイメージに組み込まれるので、ホストが見せるこのページは、そのホストを デプロイしたコミットの時点のものです。ドキュメントの変更は、次のデプロイでホストに届きます。

月曜時点の現状

• 価値のストーリー。 1 ページの資料はまだありません。最も近いのは仕組み、目標、目標アーキテクチャです。
• デモ。 ドキュメントのプレイグラウンドは、デプロイ済みホスト上で実際のアップロードを計画・エンコード・検索し、スコープごとに選ばれたパーサー、その理由、保持されたフォールバックを表示します。Web アプリは「ドキュメントをエンコード」1 つが本番接続で、ルーティングの結果は固定の例です。
• 数値。 コミット済みレポートは usage からのレイテンシとコスト、CPU のみで処理したページの割合、そしてまだ誰もレビューしていないラベルに対する精度を持ちます。
• 本番の検証。 スモークと @deployed は 3 つのデプロイワークフローで動いています。ドキュメントと Web アプリの本番向け Playwright スペックは存在しますが、手で動かすだけです。
• 3 つのクラウド。 AWS・Azure・GCP の Terraform は CI で検証され、それぞれページがあります。AWS はデプロイ済みで稼働中。Azure と GCP のワークフローは一度も実行されていません。
• ページ単位のパーサー。 ルーターはスコープごとに決定し、フォールバックを保持します。ページごとに異なるパーサーへルーティングされるコミット済み文書はなく、固定もありません（ADR-0050、未実装）。
• few-shot と Draw.io。 コードには何もありません。工程系統図パーサーはグラフをページブロックの metadata["process_chart"] に書きます（ADR-0043）。

1. 強みを 1 ページで、各ステップの背後に証拠を

営業として、顧客データ → ページ単位の理解 → 最適パーサー → 構造化データ → 顧客固有のカスタマイズ → 検索 / エージェント、と歩く 1 ページが欲しい。Index Everything を一目で説明し、各ステップで証拠に飛べるように。

• Given 本番ホスト、when そのルートを開く、then 6 つのステップそれぞれに 1 文、実データのスクリーンショット 1 枚、それを生んだプレイグラウンドの状態へのリンク 1 つがある。
• Given あるステップ、when その証拠をクリックする、then JSON ファイルではなく、その文書が読み込まれたプレイグラウンドに着く。
• Given 物語は CEO が持ち、週は短い、when 火曜が始まる、then エンジニアリングは下記の提案（流れと 6 文）を投稿済みで、CEO が編集または却下できる。ページが白紙を待つことはない。
• Given そのページ、when CEO がレビューする、then 文言は CEO が残したもの、証拠はエンジニアリングのもので、どちらも相手の半分を断りなく変えない。
• Given ドキュメントではなく営業サイトが望まれ、見せたいのは Web アプリである、when 金曜が来る、then Web アプリが AWS 本番ホストのルートになり、ドキュメントサイトは /docs/ の下に置かれる。/ は /en/ にリダイレクトし、営業ページはアプリのトップページとして /en/ と /ja/ にあり、「ドキュメント」と「プレイグラウンドを開く」の 2 つのボタンと言語切り替えを持つ。デプロイ済みで、本番の URL でフィードバックのために見せる。
• Given アプリがルートに移る、when ビルドする、then ベースパスは空になり、examples/app2.py はドキュメントのエクスポートを /docs に、アプリのエクスポートを / にマウントし、今日 /app を /app/en/ に送るリダイレクトは代わりに / を /en/ に送る。スモークスクリプト、Web アプリの Playwright スペック、ドキュメントのページにある /app/ の参照も追従し、新しい ADR がこの配置を記録し、ADR-0051 の /app マウントと ADR-0052 のロケールルート＝概要を置き換える。どちらの記録も編集しない。
• Given ドキュメントはリンクを絶対パスで書き、今日ベースを設定していない、when 移す、then Astro のベースが /docs になり、1 つのスクリプトがすべての絶対リンクを書き換え、ルートの検査とドキュメントの Playwright 設定がプレフィックスを知る。機械的なプルリクエスト 1 つ。
• Given 営業ページはアプリのトップページである、when 描画する、then 他と同じ画面パッケージ（frontend/packages/screen-home、screen-overview を手本に）として、ロケールのルートにアプリのシェルなしで置く。今日の概要画面は /overview/ に移り、ナビゲーションはそこを指す。ボタンは /docs/ja/getting-started/ と /ja/playground/ のプレイグラウンドにリンクし、ストーリー 2b がそれを唯一のプレイグラウンドにする。
• Given 各ステップの証拠はリンクである、when クリックする、then アプリのプレイグラウンドがそのサンプルと機能をクエリ文字列から選択済みの状態で開く。ストーリー 2 が追加する。
• Given AWS のデプロイはブランチからイメージをビルドし、Dockerfile はすでにドキュメントサイトと Web のエクスポートをビルドしている、when プルリクエストがマージされデプロイワークフローを実行する、then インフラの変更なしにこの配置が出荷される。
• Given AWS と Azure/GCP のスモークスクリプトは / で HTML を検証する、when / がリダイレクトになる、then それに追従し、AWS のスモークはさらにトップページのマーカーを検証して退行を捕まえる。
• Given 本番のページ、when CEO が反応する、then それを営業サイトの範囲としてスプリント 2に書く。

確かめるべき点は残らない。アプリは配信されるルートに向けてエクスポートされるので、前の案にあったベースパスの問題は消える。

提案する流れと 6 文。 CEO が編集するまでの作業版で、各ステップは証拠を名指しします。

1. あなたのデータを、ある場所のままで。 ファイル共有、S3、URL からファイルが入り、サービスはあなたのクラウドの中で動く。何も外に出ない。証拠：稼働中のケイパビリティスナップショットを読むデプロイ画面と、AWS のページ。
2. 高価な処理の前に、すべてのページを理解する。 安価なプリフライトが各ページが何かを見る。ネイティブテキスト、スキャン、図のあるスライド、図面。証拠：混在サンプルの計画、ページごと。
3. ページごとに最適なパーサーと、その理由。 ルーターはそのページを読める最も安いパーサーを選び、フォールバックを保持し、理由を述べる。証拠：2 つのページ、2 つのパーサー、理由の表示。
4. 1 つの構造化された結果。 テキスト、ボックス、エンティティ、言語、タグ、そして図の記号と接続が、1 つの契約の下の 1 つの文書に。証拠：スライドの上に描かれた工程系統図、テキスト中のエンティティのスパン。
5. あなたの形式を、あなたの例から。 顧客固有の出力形式は設定と例から生まれ、エンジニアリングからではない。今週の証拠：スライドからの Draw.io ファイル。次は few-shot ライブラリ。
6. 検索とエージェントに、すぐ使える。 ボックスと埋め込みを持つチャンクが、エンコードが終わった瞬間に検索できる。証拠：ページとボックスを名指しする検索ヒット。

6 つの上の見出し：Index Everything は、すでにあるドキュメントを、あなたのクラウドの中で、ページごとに正しいパーサーを選びながら、検索とエージェントが使えるデータに変える。

完了の定義。 Web アプリが AWS 本番ホストのルートにあり、ドキュメントは /docs/ の下。営業ページが /en/ と /ja/ で稼働し、/ はそこへリダイレクト。2 つのボタンと言語切り替えが動く。6 つの証拠がリンクされている。トップページが見出しを表示し両ボタンが解決することを検証する Playwright スペック 1 つ。スモークスクリプトがリダイレクトに追従しトップページのマーカーを検証。ADR を記録。金曜のデモで本番の URL 上で CEO のフィードバックを集める。

検証。 just frontend::ci が緑で、境界チェックが他の画面と同様に新しい画面のエッジを持つ。ベースを設定した just docs::ci が緑で、すべてのローカライズされたルートが /docs/ の下で検証される。新しいスペックがローカルで緑。プルリクエストに両言語のスクリーンショット。デプロイ後、AWS の公開スモークと just frontend::e2e-deployed <url> がホストに対して緑。

セールスページの変遷

上の受け入れは、月曜に計画した時点のページを述べています。ページは週のうちに 2 度変わりました。これはその理由の記録です。

1. 9 月 15 日（火）— 見出しと 6 つのステップ。 アプリがホストのルートを取り、ドキュメントは /docs/ の下へ移りました（ADR-0056）。screen-home は見出しと、下に提案した 6 つのステップを描き、それぞれがプレイグラウンドの状態へリンクしました（#167、#168、#169）。
2. 9 月 16 日（水）— 実際の実行のスクリーンショット 6 枚。 各ステップに、e2e/capture.spec.ts と just frontend::capture がプレイグラウンドから撮ったスクリーンショットが付きました（#179）。正確ではあるものの、スクリーンショットが何を意味するかは営業がまだ説明しなければなりませんでした。
3. 水曜と木曜 — コンセプト。 アプリの外でページのコンセプトを 2 巡書き、比較のためにリポジトリに残しました。examples/landing-claude/（a から h）と examples/landing-chatgpt/（01 から 08）です。下書きはストーリーを語るもの（ステップごとのページ、証拠のパネル）から、見せるものへと移りました。コンセプト G は訪問者に実際のページへカーソルを合わせさせ、コンセプト H は 3 つのページを舞台に置き、それぞれに indx が選んだ経路を添えました。
4. 9 月 17 日（木）— アプリの中のコンセプト H。 screen-home をコンセプト H として作り直しました（3c02e1d0）。サンプルから、表のある通知のページ、スキャンされた別紙、工程系統図のスライド。ページごとに indx が今日とる経路（テキスト層、OCR、工程系統図パーサー、フォールバック付き）。どのブロックにカーソルを合わせても、舞台は indx が渡すブロックを示します。章節と定義語を持つ段落全体、正規化されたセルを持つ表、図のノードとエッジ。その出力は目標であり、今日の行チャンクから手でまとめたもので、ページにもそう書いてあります。ADR-0060 は、ワークスペースの画面がすべて ADR-0057 に縛られたままで、なぜセールスページはそれを見せてよいかを記録し、6 枚のスクリーンショットと撮影レシピを削除しました。ページは独自の配色と書体、英語と日本語の文言、ライトとダークの切り替えを持ちます。
5. 9 月 17 日（木）— 訪問者自身のファイルのために。 舞台上のファイル名を、サンプルの実名ではなく言語ごとの例の名前にしました（2c7fc3e2）。訪問者が自分の文書を思い浮かべられるようにです。またアプリのシェルのライト・ダーク・システムのメニューを、セールスページと同じワンクリックの切り替えにしました（1f6506cc）。

これがストーリーにとって変えること。 完了の定義にある 6 つの証拠は、満たされたのではなく ADR-0060 によって置き換えられました。上に提案した 6 つの文は CEO の作業用の原稿として残ります。舞台はいま、encode が返す以上のことを約束しています。段落・見出し・表・図のブロック、章節、ページの付属物、ページをまたぐ続き、OCR 補正、定義語、相互参照、画像の説明。それぞれが機能の計画中の項目であり、ロードマップでページと突き合わせて並べられ、実装順で順序づけられています。レイアウトを舞台に近づけるプレイグラウンドの作業も一緒です。実行を上に、ページを出力の隣に、ブロックに合わせて読む。

2. モックを取り除いた Web アプリと、そのプレイグラウンドでのエンドツーエンドのデモ 1 本

見込み客として、Web アプリのすべての画面が API の返したものだけを示し、そのプレイグラウンドで文書 1 セットをアップロードするか選び、ページごとに選ばれたパーサーとその理由が見える形で構造化されて出てくるのを見たい。見えるものが何も偽らず、パーサーを選んだのが人ではなく機械だと信じられるように。

現状。 プレイグラウンドの機能ドロップダウンには 9 項目あり、API を呼ぶのは「ドキュメントをエンコード」だけです。残り 8 つは作り置きの結果を示し、うち 2 つは API に存在しない形です。エンコードのレスポンスはすでにページごとの計画（選ばれたパーサー、理由、保持されたフォールバック）、各ページブロックの来歴（実際に読んだパーサー）、エンティティのスパン、分類とエンリッチメントのタグ、チャンクのボックス、工程系統図のグラフを運びますが、アプリが描画するのはボックスだけです。スペース、ソース、エンドポイント、エンコードの実行は本番接続。概要と機能は本番とモックが混在。ライブラリ、ガイド、デプロイはブラウザ内ストアを読みます。

今週のルール：アプリは API が返さなかったものを何も示さない。

• Given API に接続済みの画面、when 開く、then そのまま。
• Given 本番とモックが混在する画面（概要、機能）、when モックの部分を取り除く、then API が答えるものだけが残る。
• Given まだバックエンドのない画面（ライブラリ、ガイド、デプロイ、月曜の点検で見つかるその他）、when ナビゲーションを見る、then そのボタンはあるが無効で、「まだ利用できません」のヒントを持つ。青写真は見えたまま、何も偽らない。
• Given プレイグラウンド、when 開く、then 機能ドロップダウンはない。アップロードまたはサンプルに対するエンコード 1 回で、結果はレスポンスから供給される表示を持つ。ページ：画像、チャンクのボックス、ページごとに計画されたパーサー、理由、保持されたフォールバック、実際に読んだパーサー。エンティティ：テキスト中に印を付けたスパン。タグ：分類のファセットとエンリッチメントのタグ。図：ページの process_chart メタデータからの記号と接続の数とノード一覧。重ね描きは余力があれば。検索：本番接続。ブラウザ内で 2 つのレーンを順位で統合する。チャンクが持つ語と、実行が埋め込みを作った場合は POST /v1/embed に送ったクエリとチャンクベクトルとの比較。ヒットはページ、ボックス、見つけたレーンを名指しし、埋め込みをオフにした実行もテキストで検索できる。
• Given 検索はブラウザ内で動く、when 検索する、then 索引はこのブラウザがエンコードした文書だけで、それ以外は含まない。ベクトルはブラウザ自身のストレージに保持され、再読み込みしても残り、サーバーには送られず、訪問者間で共有されない。検索の表示はその範囲を 1 行で述べる（「このデプロイでこのブラウザがエンコードした文書を検索します」）。デモホストのエンコードキャッシュはここに何も変えない。同じバイト列をアップロードした人にだけ答え、何も一覧しない。
• Given デモホストが提供するのは default-text だけで、それはモデルを持たない CRC32 ハッシュの文字トライグラム 256 次元である、when クエリを埋め込む、then ベクトルレーンの価値はそのハッシュの価値を超えない。テキストレーンがあるのはそのためである。別のプルリクエストで fastembed エクストラを入れて minilm-multilingual を提供し、auto がテキスト検索向けの空間を優先するようにする。sourcesFrom は次元の降順で並べるため、そのエクストラが入ったホストでは clip-vit-b32（512）が minilm-multilingual（384）より前に来るが、CLIP のテキスト側はトークン上限 77 のキャプション用エンコーダーであって検索用モデルではない。
• Given ページが異なるコミット済みサンプル（ネイティブテキストのページ、スキャンページ、工程系統図のスライド）、when エンコードする、then 少なくとも 2 ページで異なるパーサーが理由とともに示される。
• Given 「few-shot 検出」と「関係性」にはバックエンドがない、when モックの経路を削除する、then プレイグラウンドから消え、ロードマップに計画中として残る。
• Given モックのパッケージとブラウザ内ストア、when 最後の画面がそれらを読まなくなる、then 削除され、境界チェックはそのエッジを落とし、青写真の Playwright スペックは本番接続の画面と無効なボタンを検証する形に書き直される。
• Given シェルにはまだ青写真の作り物の装飾（パンくずのルートでもある名前付きワークスペース、アバター、バッジ、タグライン）が残っている、when モックが消える、then ワークスペースカードはこのホストにある唯一のワークスペースとデモモードの注記を持つメニューになり、バッジ、アバター、タグラインは消え、ステータスピルは /health とスナップショットが答えるものを示すヘルスページを開き、残りはデプロイ画面へのリンクで示す。エンドポイント画面はホストが配信するリファレンス（Scalar、Swagger）へリンクし、各操作を Python、TypeScript、HTTP のリクエスト例に開き、デプロイ画面のメディアタイプは系統ごとに一色のバッジとして読め、ホバーで完全な型名を示す。
• Given すでに試した文書、when 誰かがもう一度エンコードする、then 即座に答えが返る。デモホストはすでにダイジェストをキーにしたレンダリングのキャッシュを持っており、エンコードのレスポンスも、実行ごとのリクエスト ID を除いたリクエスト本文のダイジェストをキーに、同じ上限でメモリにキャッシュする。ヒットはレスポンスに印が付き、「キャッシュから提供、計算時刻 …」と表示され、本番の実行と取り違えられない。事前のウォームアップはせず、デプロイ後のリハーサルがサンプルを温める。デモホストの便宜であり、製品の機能ではない。
• Given サンプルをクエリ文字列に持つプレイグラウンドへのリンク、when 開く、then 選択済みであり、run=encode を持つリンクは着地と同時にエンコードする（?sample=<id>&<lane>=<off|auto|id>&run=encode、サンドボックスの文法）。ストーリー 1 の証拠が指すのはこれ。
• Given デモ台本、when チームの誰かが本番ホストに対して実行する、then 5 分以内で終わり、すべてのステップが API がすでに提供するリクエストである。

完了の定義。 モックのパッケージがワークスペースから消え、すべてのナビゲーションボタンが本番接続の画面を開くか無効である。シェルはホストが答えるものだけに減り、ステータスピルの先にヘルスページがある。エンドポイントの詳細とリファレンスへのリンク。メディアタイプのバッジ。examples/samples/ の混在サンプル。エンコード結果の 5 つの表示。本番接続の検索。ラベル付きのデモホストのエンコードキャッシュ。クエリ文字列による事前選択と実行。2 つのページが 2 つのパーサーにルーティングされることを検証する受け入れシナリオ 1 つ。ストーリーの隣に番号付きページとしてのデモ台本。録画 1 本。エンコードの Playwright スペックを拡張してページ単位のパーサー行と機能ドロップダウンの不在を検証。パーサーの固定（ADR-0050）は今週ではありません。

検証。 just ci と just frontend::ci、次いで just test::bdd::deployed <url> で本番ホストに対するシナリオ。

2b. 金曜のデプロイでドキュメントのプレイグラウンドを閉じる

チームとして、プレイグラウンドは 1 つであってほしい。すべてのデモ、リンク、スクリーンショットが同じ面を見せるように。

• Given アプリのプレイグラウンドがルーティング、図の数、検索を示す、when 金曜のイメージが出荷される、then /docs/playground/ と /docs/ja/playground/ はアプリのプレイグラウンドにリダイレクトする。examples/app2.py でルートのものの隣に置く 2 つのルートとして。
• Given ドキュメントのページはドキュメントのプレイグラウンドにリンクしている、when リダイレクトが入る、then それらのリンクは同じプルリクエストでアプリのプレイグラウンドに向け直される。
• Given just docs::e2e-deployed はドキュメントの本番向けスペックをドキュメントのプレイグラウンドに対して実行する、when リダイレクトが入る、then そのレシピとスペックは退役し、ストーリー 4 は Web アプリの本番向けスペックだけを組み込む。
• Given ドキュメントのサンドボックスのコードとフィクスチャの取得はその時点で到達不能になる、when スプリント 2 を計画する、then それらの削除が最初の候補になる。今週はリダイレクトのみで、削除はそれ自体でレビューできる 1 つのプルリクエストにする。

完了の定義。 2 つのリダイレクト、リンクの向け直し、ドキュメントの本番向けスペックの退役。ストーリー 2 の後に順序づけ、決して前ではない。

検証。 リダイレクト先のパスで HTML を検証する AWS の公開スモークと、ホストに対する Web アプリの本番向けスペック。

3. 営業が口に出せる 3 つの数値、精度はまだ含めない

営業として、速度、コスト、リソース使用量を、注意書きが 1 クリック先にある 3 つの見出し数値として欲しい。ストーリーに数字があり、言い過ぎないように。

• Given ベンチマークページ、when 開く、then 最初に、ラベルに依らない 3 つの数値がある。ページあたりの秒数、全ページを視覚モデルに通した場合に対するルーティング後のページあたりコスト、CPU のみで処理したページの割合。それぞれコミット済みレポートを言い直すだけで、何も再計算しない。
• Given ある数値、when 展開する、then それが拠って立つケース数と、既知のギャップが 1 文で見える。
• Given ラベルはまだレビューされていない、when ページを読む、then すべての精度の数値は「ラベルはレビュー中」の注記の後ろにあり、ストーリーのページはどれも引用しない。
• Given ラベル付きケース、when あるラベルがレビューされる、then マニフェストが誰がいつレビューしたかを記録し、精度の数値はスプリント 2 に向けて解禁されるか、ラベルが直される。
• Given 9 月 11 日の計画の 7 つの軸、when 数値の下の表を読む、then 各軸は「計測済み」「計測済み、ラベルはレビュー中」「未計測、X が必要」のいずれかを言う。同種の数値が存在するまで競合の列はない。
• Given 参照顧客のデッキは顧客データである、when それを持つマシンでベンチマークを実行する、then 再配布不可のケースとして採点され、それ以外の場所では失敗せずにスキップされる。

完了の定義。 ラベルに依らない 3 つの数値と軸の表がベンチマークページにある。精度はレビューまで降格。ラベルのレビューが始まり、マニフェストにレビュー者の欄がある。benchmarks/README.md がレポートに対して古くない。再配布不可のケースが登録されている。

検証。 just bench::run が表示された数値を再生成し、注記の上に精度の数値が現れない。

4. 本番は UI を含めて、デプロイのたびに自らを証明する

チームとして、サイトやアプリがデモを実行できなければデプロイワークフローが失敗して欲しい。「デプロイ済み」が「デモが動く」を意味するように。

• Given 3 つのクラウドのいずれかへのデプロイ、when 終わる、then スモーク、@deployed シナリオ、Web アプリの本番向け Playwright スペックがすべて公開ホストに対して実行済みで、赤があればワークフローが失敗する。
• Given ストーリー 2 のデモ台本、when デプロイが実行される、then 少なくとも 1 つの @deployed シナリオがその最初の 2 ステップ（混在サンプルを計画し、2 つのパーサーを検証）を歩く。

完了の定義。 just frontend::e2e-deployed を 3 つのデプロイワークフローに組み込む。ストーリー 2 のシナリオに @deployed タグ。ドキュメントの本番向けスペックはストーリー 2b とともに退役。大半は既存で、「未着手」ではなく「完了」として報告できるよう列挙しています。

検証。 デプロイワークフロー自身の実行、AWS で緑。

5. 顧客固有の出力：デッキ 1 つを入れて Draw.io ファイル 1 つを出す

製造業の顧客として、Index Everything がスライドから読んだ工程系統図を .drawio ファイルとして欲しい。構造化された結果が、エンジニアがすでに使っているツールに届くように。

• Given 工程系統図のサンプル、when プレイグラウンドでエンコードする、then ダウンロードで得たファイルが diagrams.net で開き、同じ記号と接続を持つ。
• Given コミット済みデッキ、when テストが実行される、then 生成されたファイルがフィクスチャとバイト単位で一致する。

今週唯一の新機能です。ストーリーのステップ 5 を具体化するものだからです。レシピ形式、例のストア、シグネチャによる検索は対象外で、スプリント 2 の候補です。ベンチマークは few-shot のセットアップを未実装と報告し続けます。

完了の定義。 tests/fixtures/ の期待ファイル。プレイグラウンドでのダウンロード。

検証。 just test::unit でフィクスチャをバイト単位に比較。ファイルを diagrams.net で手で開く。

6. Azure と GCP を一度だけ、時間を区切って試す

チームとして、Azure と GCP のデプロイワークフローをテスト用のサブスクリプションとプロジェクトに対して試したい。3 つのクラウドパターンが 1 日で済むのか 1 スプリントかかるのかを、今週を食いつぶさずに知るように。

• Given ストーリー 1 〜 5 が順調、when 木曜が始まる、then 1 人が Azure のワークフローを、次に GCP のワークフローを、それぞれ半日の締め切りで実行する。
• Given 実行がそのホスト名で公開スモークと @deployed シナリオの緑に達する、then そのクラウドはデプロイページに日付とホスト名とともに実証済みと記録される。
• Given 実行が失敗するか半日が終わる、then 到達点とブロッカーをページに記録し、修正はスプリント 2 の候補とし、今週はそれ以上時間を使わない。
• Given どちらかのスタックが適用された、when 金曜が終わる、then 破棄され、破棄も記録に含まれる。

完了の定義。 2 つのワークフローがそれぞれ一度実行されるか、ストーリー 1 〜 5 に時間が必要だったため明示的にスキップされる。いずれにせよ結果を各デプロイページに。スキップは週の評価に響きません。

検証。 Azure と GCP のページからリンクされたワークフローの実行。緑、赤、スキップのいずれか、結果のまま。

結果

両方のクラウドで実証できました。そしてストーリーが定めた 2 つの限度は守られませんでした。その両方の記録です。

• Azure、9 月 18 日（金）。 4 回目のデプロイで everything.az.indx.jp が緑になりました。最初のプランは通り、アイデンティティとステートのバックエンドが証明されました。その後、apply が Consumption だけの環境での 4 vCPU と 8 GiB を拒み（#191）、プランのアイデンティティは Container Apps Operator なしではアプリをリフレッシュできず（#192）、証明書の束ねには先にホスト名を加える必要がありました（#193）。
• GCP、9 月 18 日（金）。 3 回目のデプロイで everything.g.indx.jp が緑になりました。最初のプランは通りました。apply は、組織のドメイン制限共有のポリシーのもとでの allUsers の invoker と、サーバーレス NEG 上のバックエンドサービスのタイムアウトを拒みました（#196）。続いてサービスのスケーリングのブロックに恒常的な差分が出ました（#197）。
• どちらも走る前に形が変わりました。 両方のホスト名はゾーンの 2 ラベル下にあり、Cloudflare の無料の証明書はそこを覆いません。運用者は Cloudflare のトークンも持ちません。そのためどちらのクラウドもプロキシの背後にはありません。レコードは DNS のみで手で作り、証明書はそれぞれのプラットフォームが発行し、どちらにも境界はありません（ADR-0064、ADR-0065、#190、#195）。それぞれの最初のデプロイは 2 サイクルで、1 回目がレコードを印字し、2 回目が束ねるか証明書を待ちます。
• 半日は守られませんでした。 2 つでそれぞれ半日ではなく金曜 1 日を使いました。上の失敗はどれも terraform validate にもローカルのプランにも見えず、apply だけが表に出したからです。ストーリーの問いへの答えは、クラウドあたり 1 日であり、1 スプリントではありません。
• どちらのスタックも破棄していません。 ストーリーは金曜の夕方の破棄を求めていました。どちらも、デモを見せられるホストがさらに 2 つあるものとして、判断のうえで動かし続けています。GCP のグローバル転送ルールは、リクエストが来ても来なくても時間で課金されます。Azure はゼロにスケールし、待機中はレジストリとログの分だけかかります。

今週はやらないこと

• ラベルがレビューされるまで、精度の数値を公開すること。
• ドメインや DNS の変更。ホストの URL 配置は変わる（アプリがルート、ドキュメントは /docs/ の下）が、ホスト名は変わらない。
• Azure や GCP の保証。ストーリー 6 は締め切り付きの試行。
• パーサーの固定とフォールバック禁止フラグ（ADR-0050）。
• 比較表の競合の列。
• CAD の範囲のページ。スプリント 2 に持ち越し。
• ドキュメントのサンドボックスのコードの削除。今週はリダイレクトのみ（ストーリー 2b）で、削除はスプリント 2 の最初の候補。
• 無効化した画面（ライブラリ、ガイド、デプロイ）のバックエンド。今週は無効なボタンで、その後スプリント 2 の候補。
• 製品レベルの結果キャッシュ。今週のキャッシュはデモホストにのみ置く。

金曜日

デモはこの順で見せます。AWS ホストのルートで開いた営業ページ、ドキュメントのプレイグラウンドがリダイレクトする中での、アプリのプレイグラウンドでの AWS 本番のエンドツーエンドの実行、ラベルに依らない 3 つの数値、AWS で緑のデプロイ後チェック、Draw.io のダウンロード、そして同じチェックが緑でどちらも公開中の Azure と GCP のホスト。ページへの CEO のフィードバックはその場で集めます。完了の定義に届かなかったものはスプリント 2への持ち越しとして名指しされ、デモの終わりに計画します。