shaping

Shaping の方法論

問題を協働で定義し、解決策の選択肢を検討するための体系的なアプローチです。

---

複数レベル間の一貫性（重要）

Shaping では、抽象度の異なる文書を作成します。すべてのレベルで事実に一貫性を保つ必要があります。

文書の階層（上位から下位）

1. Shaping 文書 — R、Shape、パート、適合性チェックの基準となる情報
2. Slices 文書 — スライスの定義、ブレッドボードの基準となる情報
3. 個々のスライス計画（V1-plan など）— 実装詳細の基準となる情報

原則

各レベルは、その下のレベルの内容を要約するか、そこから見た情報を示します。下位のレベルほど詳細が多く、上位のレベルは、すばやく背景を把握できるように設計されたビューです。

変更は両方向に波及します。

• 上位レベルの変更 → 下位へ波及： Shaping 文書のパーツ表を変更した場合は、Slices 文書も更新します。
• 下位レベルの変更 → 上位へ波及： スライス計画で新しいメカニズムが明らかになった場合や、スライスの範囲が変わった場合は、Slices 文書と Shaping 文書にも反映する必要があります。

実践方法

変更を行う際は、必ず次の手順に従います。

1. どのレベルに変更を加えるのかを特定する
2. 「この変更は、上位または下位の文書に影響するか？」と確認する
3. 影響を受けるすべてのレベルを同じ作業で更新する
4. 文書間に不整合を生じさせない

この仕組みが機能するのは、各レベルに一貫性がある場合に限られます。

---

セッションの開始

新しい Shaping セッションを始める際は、ユーザーに次の2つの開始方法を提示します。

• R（Requirements）から始める — 問題、困っている点、制約を説明します。要件を組み立て、そこから Shape を導き出します。
• S（Shapes）から始める — すでに考えている解決策の概要を示します。それを Shape として記録しながら、要件を抽出します。

順序に決まりはありません。Shaping は反復的なプロセスであり、R と S は全体を通じて互いに影響し合います。

既存の Shaping 文書を扱う

Shaping 文書ですでに Shape が選択されている場合は、次のようにします。

1. 選択された Shape の適合性チェックのみを表示する — すべての Shape ではなく、R ×［選択された Shape］（例：R × F）を表示します
2. 未解決の内容を要約する — Undecided の要件、または選択された Shape で ❌ となっている要件を示します

これにより、Shaping の現状と注意が必要な点を、ユーザーがすぐに把握できます。

---

基本概念

R：要件

問題空間を定義する番号付きの項目群です。

• R0、R1、R2... は要件群のメンバーです
• 要件は自動的に埋めるものではなく、協働で合意します
• ステータスを記録します：Core goal、Undecided、Leaning yes/no、Must-have、Nice-to-have、Out
• 適合性チェックから抽出した要件は、単独で成立するようにします（特定の Shape に依存させません）
• R が示すのは必要なものです。満たされているものではありません — 要件が満たされているかどうかは、常に適合性チェック（R × S）に示します
• グループ化の方針： 最上位の要件は9個を超えないようにします。R が9個を超えた場合は、関連する要件をサブ要件（R3.1、R3.2 など）を持つグループにまとめ、最上位を9個以下に保ちます。これにより、要件を一覧しやすくし、意味のあるグループ化を促します。

S：Shapes（解決策の選択肢）

互いに排他的な解決策のアプローチを文字で表します。

• A、B、C... は最上位の Shape の選択肢です（いずれか1つを選びます）
• C1、C2、C3... は Shape C のコンポーネント／パーツです（組み合わせて使用します）
• C3-A、C3-B、C3-C... はコンポーネント C3 の代替アプローチです（いずれか1つを選びます）

Shape のタイトル

アプローチの特徴を表す、簡潔で説明的なタイトルを付けます。Shape を示す際は、タイトルも表示します。

## E: Modify CUR in place to follow S-CUR

| Part | Mechanism |
|------|-----------|
| E1 | ... |

良いタイトルは、アプローチの本質を数語で捉えています。

• ✅「E：S-CUR に従うよう CUR をその場で変更する」
• ✅「C：ハイブリッドページネーションを用いた2つのデータソース」
• ❌「E：解決策」（曖昧すぎます）
• ❌「E：widget-grid に検索を追加するために、入れ替えて...」（長すぎます）

表記の階層

レベル	表記	意味	関係
要件	R0, R1, R2...	問題の制約	集合 R の要素
形状	A, B, C...	解決策の選択肢	S から 1 つ選択
コンポーネント	C1, C2, C3...	形状の構成要素	形状内で組み合わせる
代替案	C3-A, C3-B...	コンポーネントへのアプローチ	コンポーネントごとに 1 つ選択

表記の継続性

監査証跡として、表記を一貫して使用してください。最終化する際は、以前のコンポーネントを参照して新しい選択肢を構成します（例：「形状 E = C1 + C2 + C3-A」）。

フェーズ

シェーピングは次の 2 つのフェーズで進みます。

Shaping → Slicing

フェーズ	目的	成果物
シェーピング	問題と解決策の空間を探索し、形状を選択して詳細化する	R、形状、適合性チェック、ブレッドボードを含むシェーピング文書
スライシング	実装のために分割する	デモ可能な UI を備えた垂直スライス

フェーズの移行

シェーピング → スライシングへの移行は、次の場合に行います。

• 形状が選択されている（適合性チェックに合格し、しっくりくる）
• 形状がブレッドボード化され、具体的なアフォーダンスになっている
• 実装順序を計画する必要がある

ブレッドボード化された形状がなければ、スライスできません。

---

適合性チェック（判断マトリックス）

適合性チェックは、すべての形状をすべての要件と比較する唯一の表です。要件を行に、形状を列に配置します。これを使って、どの形状を進めるかを決定します。

形式

## Fit Check

| Req | Requirement | Status | A | B | C |
|-----|-------------|--------|---|---|---|
| R0 | Make items searchable from index page | Core goal | ✅ | ✅ | ✅ |
| R1 | State survives page refresh | Must-have | ✅ | ❌ | ✅ |
| R2 | Back button restores state | Must-have | ❌ | ✅ | ✅ |

**Notes:**
- A fails R2: [brief explanation]
- B fails R1: [brief explanation]

規則

• 要件の全文を必ず表示してください — 適合性チェックでは、要件を省略したり要約したりしないでください
• 適合性チェックは二者択一です — 合格には ✅、不合格には ❌ を使用します。それ以外の値は使用しません。
• 形状の列には ✅ または ❌ のみを記載します — インラインでのコメントは不可です。説明は「メモ」セクションに記載します
• 適合性チェックでは ⚠️ やその他の記号を使用しないでください — ⚠️ はパーツ表の「フラグ付き」列でのみ使用します
• メモは最小限にし、不合格の説明だけを記載します

コンポーネント内の代替案の比較

特定のコンポーネントの代替案（例：C3-A と C3-B）を比較する場合は、対象をそのコンポーネントに限定して、同じ形式を使用します。

## C3: Component Name

| Req | Requirement | Status | C3-A | C3-B |
|-----|-------------|--------|------|------|
| R1 | State survives page refresh | Must-have | ✅ | ❌ |
| R2 | Back button restores state | Must-have | ✅ | ✅ |

要件の不足

形状がすべてのチェックに合格しても、なおしっくりこない場合は、要件が不足しています。暗黙の制約を新しい R として明確にし、適合性チェックを再実行します。

マクロ適合性チェック

標準の適合性チェックとは別のツールです。要件を大きなまとまりで扱い、ほとんどの仕組みがまだ ⚠️ の初期段階の形状を検討する際に使用します。明示的に求められた場合に使用してください。

マクロ適合性チェックでは、形状ごとに列を 1 つではなく 2 つ設けます。

• 対応済み？ — 形状の一部が、この要件に大まかなレベルで応えているように見えますか？
• 回答済み？ — 具体的な方法をたどれますか？仕組みが実際に明記されていますか？

形式：

## Macro Fit Check: R × A

| Req | Requirement | Addressed? | Answered? |
|-----|-------------|:----------:|:---------:|
| R0 | Core goal description | ✅ | ❌ |
| R1 | Guided workflow | ✅ | ❌ |
| R2 | Agent boundary | ⚠️ | ❌ |

規則：

• トップレベルの要件（R0、R1、R2...）のみを表示し、サブ要件は表示しません
• メモ列は設けません — 表を狭く、一覧しやすく保ちます
• 「対応済み」には ✅（はい）、⚠️（部分的）、❌（いいえ）を使用します
• 「回答済み」には ✅（はい）または ❌（いいえ）を使用します
• マクロ適合性チェックの後に、具体的な不足箇所と関連するサブ要件を記載した別のギャップ表を置きます

実行可能なアクション

次のアクションは、どの順序でも実行できます。

• R を記入する - 要件が明らかになるたびに収集する
• 形状をスケッチする - 高レベルのアプローチを提案する（A、B、C...）
• 詳細化する（コンポーネント） - 形状をコンポーネントに分解する（B1、B2...）
• 詳細化する（アフォーダンス） - 選択した形状を、具体的な UI／非 UI のアフォーダンスと配線に展開する
• 代替案を検討する - コンポーネントの選択肢を特定する（C3-A、C3-B...）
• 適合性を確認する - R と選択肢を照合する適合性チェック（判断マトリックス）を作成する
• R を抽出する - 適合性チェックで暗黙の要件が判明したら、独立した項目として R に追加する
• ブレッドボード化する - システムをマッピングして変更箇所を把握し、形状をより具体化する
• スパイクする - 不明点を調査し、必要な具体的な手順を特定する
• 決定する - 代替案を選び、最終的な解決策を構成する
• スライスする - ブレッドボード化された形状を、実装用の垂直スライスに分割する

コミュニケーション

テーブルをすべて表示する

R（要件）または任意の S（シェイプ）を表示する際は、必ずすべての行を表示してください。要約や省略はしないでください。テーブル全体が成果物であり、一部だけの表示では情報が失われ、共同作業のプロセスが損なわれます。

• 要件が多くても、すべて表示する
• サブパーツ（E1.1、E1.2...）を含め、シェイプのすべてのパーツを表示する
• 適合性チェックの代替案をすべて表示する

これが重要な理由

シェイピングは共同で行う交渉です。ユーザーが全体像を確認できるようにする必要があります。

• 要件の不足を見つける
• 矛盾に気づく
• 情報に基づいて判断する
• 決定事項を追跡する

要約は詳細を隠し、主導権をユーザーから遠ざけます。

変更箇所に 🟡 を付ける

変更後に要件テーブルまたはシェイプテーブルを再表示する際は、変更または追加した行すべてに 🟡 を付け、ユーザーが変更点をすぐに見つけられるようにしてください。変更したセルの内容の先頭に 🟡 を置きます。これにより、反復的な改善の内容を簡単に追えます。ユーザーにテーブルの差分を頭の中で比較させてはいけません。

スパイク

スパイクとは、既存のシステムの仕組みと、コンポーネントを実装するために必要な具体的な手順を把握するための調査タスクです。仕組みや実現可能性に不確実な点がある場合は、スパイクを使用してください。

ファイル管理

スパイクは必ず専用のファイルに作成してください（例：spike.md または spike-[topic].md）。スパイクは独立した調査ドキュメントであり、シェイピングドキュメントとは別に共有したり、作業したりできます。

目的

• 該当領域で既存のシステムがどのように動作するかを把握する
• 結果を達成するために何をする必要があるかを特定する
• 進めるかどうかについて、情報に基づいた判断を可能にする
• 工数を見積もるものではありません。工数は手順そのものに含まれます
• 提案の前に調査する — すでに存在するものを確認してください。システムがすでに要件を満たしている場合もあります

構成

## [Component] Spike: [Title]

### Context
Why we need this investigation. What problem we're solving.

### Goal
What we're trying to learn or identify.

### Questions

| # | Question |
|---|----------|
| **X1-Q1** | Specific question about mechanics |
| **X1-Q2** | Another specific question |

### Acceptance
Spike is complete when all questions are answered and we can describe [the understanding we'll have].

受け入れ基準のガイドライン

受け入れ基準では、結論や判断ではなく、得られる情報や理解を記述します。

• ✅ 「...ユーザーが言語を設定する方法と、英語以外のタイトルが表示される場所を説明できる」
• ✅ 「...［コンポーネント］を実装する手順を説明できる」
• ❌ 「...これがブロッカーかどうか答えられる」（これは情報ではなく判断です）
• ❌ 「...進めるべきかどうかを判断できる」（判断はスパイクの後に行います）

スパイクでは情報を収集し、その情報に基づいて後から判断します。

質問のガイドライン

適切なスパイクの質問では、仕組みについて尋ねます。

• 「［X］のロジックはどこにありますか？」
• 「［Y］を実現するには、どのような変更が必要ですか？」
• 「［Z］はどのように実行しますか？」
• 「［アプローチ］に影響する制約はありますか？」

避ける質問：

• 工数の見積もり（「どれくらい時間がかかりますか？」）
• 曖昧な質問（「これは難しいですか？」）
• 仕組みが明らかにならない、はい／いいえで答えられる質問

ブレッドボード

/breadboarding スキルを使って、既存システムをマッピングしたり、シェイプを具体的なアフォーダンスに落とし込んだりします。ブレッドボーディングでは、次のものを作成します。

• UI アフォーダンステーブル
• 非 UI アフォーダンステーブル
• Place ごとにグループ化した配線図

次のような場合にブレッドボーディングを実施してください。

• 既存のコードをマッピングして、変更箇所を把握する
• 高レベルのシェイプを具体的なアフォーダンスに変換する
• 直交する関心事（互いに独立したパーツ）を明らかにする

テーブルが信頼できる情報源

アフォーダンステーブル（UI と非 UI）がブレッドボードを定義します。Mermaid 図はそれらを描画したものです。

ブレッドボードへのフィードバックを受けた場合：

1. 最初に — アフォーダンステーブルを更新します（アフォーダンスの追加／削除／変更、Wires Out の更新）。
2. 次に — 変更を反映するよう Mermaid 図を更新します。

図を主要な成果物として扱ってはいけません。変更はテーブルから図へと反映し、その逆ではありません。

予約済みのシェイプ名としての CURRENT

既存のシステムを表すには CURRENT を使用してください。これにより、提案された変更がどこに当てはまるかを理解するための基準点になります。

シェイプパーツ

不明点のフラグ付け（⚠️）

仕組みは、具体的には理解できていなくても、概要レベルで説明できます。Flag 列でこれを記録します。

Part	Mechanism	Flag
F1	ウィジェットを作成する（コンポーネント、定義、登録）
F2	マジック認証ハンドラー	⚠️

• 空欄 = 仕組みを理解している — 具体的な構築方法がわかっています
• ⚠️ = 不明点のフラグ — 何をするかは説明できていますが、どう実現するかはまだわかっていません

不明点にフラグを付けると適合性チェックに不合格となる理由：

1. ✅ は知識があるという主張です — 「この形でこの要件を満たす方法がわかっている」という意味です
2. 要件を満たすには仕組みが必要です — 要件を具体的に満たす何らかの要素が必要です
3. フラグは方法がわからないことを示します — 望むものは説明できていますが、構築方法は説明できていません
4. 知らないことを主張することはできません — したがって、❌ でなければなりません

適合性チェックは常に二択で、✅ または ❌ のみです。第三の状態はありません。不明点は、解決されるまで不合格です。

これにより、「概略がある」ことと「実際に実現方法がわかっている」ことを区別できます。初期段階の形（A、B、C）には、不明点のフラグが多く付くことがよくあります。探索段階では問題ありません。ただし、選択された形にはフラグがなく（すべての ❌ が解決済み）、または解決するための明示的なスパイクが設定されている必要があります。

パーツは仕組みでなければなりません

形のパーツでは、意図や制約ではなく、構築または変更するものを説明します。

• ✅ 「childType === 'letter' を typesenseService.rawSearch() にルーティングする」（仕組み）
• ❌ 「型は変更しない」（制約 — R に記載します）

R と S の間で同語反復を避ける

R は必要なことや制約（どのような結果が必要か）を示します。S は仕組み（どのように実現するか）を説明します。同じことを述べている場合、その形のパーツは情報を加えていません。

• ❌ R17：「管理者がメンバーに一括署名依頼できる」＋ C6.3：「管理者はメンバーに一括署名依頼できる」
• ✅ R17：「管理者が既存メンバーを免責同意書の追跡対象に追加できる」＋ C6.3：「メンバーのフィルターを備えた一括依頼 UI。WaiverRequests を一括作成する」

要件では必要な機能を説明します。形のパーツでは、その機能を提供する具体的な仕組みを説明します。R のテキストを S にコピーしていることに気づいたら、そこで止めてください。形のパーツでは、どのように実現するかを具体的に説明する必要があります。

パーツは垂直スライスにします

すべてのテーブルをまとめる「データモデル」のような水平レイヤーは避けてください。代わりに、データモデルを、それが支える機能と一緒に配置します。

• ❌ B4：データモデル — Waivers テーブル、WaiverSignatures テーブル、WaiverRequests テーブル
• ✅ B1：署名ハンドラー — WaiverSignatures テーブルとハンドラーロジックを含む
• ✅ B5：依頼の追跡 — WaiverRequests テーブルと追跡ロジックを含む

各パーツは、仕組みとそれに必要なデータを含む垂直スライスである必要があります。

共通ロジックを切り出す

同じロジックが複数のパーツに現れる場合、独立したパーツとして切り出し、他のパーツから参照します。

• ❌ B1 と B2 で「署名ハンドラー：WaiverSignature を作成し、ブール値を設定する」を重複させる
• ✅ B1：署名ハンドラー として切り出し、B2 と B3 には「→ B1 を呼び出す」と記述する

| **B1** | **Signing handler** |
| B1.1 | WaiverSignatures table: memberId, waiverId, signedAt |
| B1.2 | Handler: create WaiverSignature + set member.waiverUpToDate = true |
| **B2** | **Self-serve signing** |
| B2 | Self-serve purchase: click to sign inline → calls B1 |
| **B3** | **POS signing via email** |
| B3.1 | POS purchase: send waiver email |
| B3.2 | Passwordless link to sign → calls B1 |

階層表記

まずフラットな表記（E1、E2、E3...）を使います。次の場合に限り、階層表記（E1.1、E1.2...）を導入してください。

• パーツが多すぎて、簡単に把握できなくなった場合
• 結論に近づき、構造を示したい場合
• 関連する仕組みをグループ化すると、意思疎通に役立つ場合

表記	意味
E1	形 E のトップレベルコンポーネント
E1.1、E1.2	E1 のサブパーツ（必要に応じて後から追加）

階層的なグループ化の例（形が成熟した段階で使用）：

Part	Mechanism
E1	データソースを切り替える
E1.1	バックエンドのインデクサーを変更する
E1.2	レターを新しいサービスにルーティングする
E1.3	投稿を新しいサービスにルーティングする
E2	検索入力欄を追加する
E2.1	デバウンス機能を備えた入力欄を追加する

形の詳細化

形を選択したら、それを具体的な実装手段へと展開できます。これを詳細化と呼びます。

表記

新しい文字ではなく「Detail X」を使い、別の選択肢ではなく形 X の内訳であることを示します。

## A: First approach
(shape table)

## B: Second approach
(shape table)

## Detail B: Concrete affordances
(affordance tables + wiring)

詳細化で作成するもの

/breadboarding スキルを使って、次のものを作成します。

• UI アフォーダンス表 — ユーザーが目にし、操作するもの（入力欄、ボタン、表示）
• 非 UI アフォーダンス表 — データストア、ハンドラー、クエリ、サービス
• 配線図 — 各場所にあるアフォーダンスのつながり

「C」ではなく「詳細化 X」とする理由

シェイプの文字（A、B、C など）は相互に排他的な選択肢であり、そのうちの1つを選びます。詳細化は選択肢ではなく、選択したシェイプをさらに詳しく分解するものです。新しい文字を使うと、兄弟となる選択肢であるかのように誤解されます。

A, B, C = alternatives (pick one)
Detail B = expansion of B (not a choice)

ドキュメント

シェーピングでは、最大4つのドキュメントを作成します。それぞれ役割が異なります。

ドキュメント	内容	目的
フレーム	ソース、問題、成果	「なぜ」を簡潔にまとめた、ステークホルダー向けの内容
シェーピングドキュメント	要件、シェイプ（CURRENT/A/B/...）、アフォーダンス、ブレッドボード、適合性チェック	作業用ドキュメント — ここで探索と反復を行います
スライスドキュメント	スライスの詳細、スライスごとのアフォーダンス表、配線図	実装計画 — 段階的な構築方法を示します
スライス計画	V1-plan.md、V2-plan.md など	各スライスの個別の実装計画

ドキュメントのライフサイクル

Frame (problem/outcome)
    ↓
Shaping (explore, detail, breadboard)
    ↓
Slices (plan implementation)

フレームは最初に作成できます。ソリューションに取り組む前に、「なぜ」を記録します。次の内容を含みます。

• ソース — 作業のきっかけとなった元のリクエスト、引用、資料（原文のまま）
• 問題 — 何が壊れているのか、どのような課題があるのか（ソースから抽出）
• 成果 — 成功がどのような状態か（高レベルで、ソリューションに依存しない内容）

ソース資料の記録

ユーザーがフレーミング中にソース資料（ユーザーからのリクエスト、引用、メール、Slack メッセージなど）を提供した場合は、必ずフレームドキュメントの先頭にあるソースセクションに原文のまま記録してください。

## Source

> I'd like to ask again for your thoughts on a user scenario...
>
> Small reminder: at the moment, if I want to keep my country admin rights
> for Russia and Crimea while having Europe Center as my home center...

> [Additional source material added as received]

---

## Problem
...

これが重要な理由：

• ソースは事実の根拠であり、問題や成果はその解釈です
• 後で関連する可能性のある背景を保持できます
• 要約によって何かが抜け落ちた場合に、元のリクエストを見直せます
• フレーミング中に届いた複数のソースを追加できます

記録するタイミング：

• ユーザーがリクエストや引用を貼り付けたとき
• ユーザーがステークホルダーからのメールやメッセージを共有したとき
• ユーザーが伝え聞いたシナリオを説明したとき
• フレームに役立つあらゆる生の資料

シェーピングドキュメントで実作業を進めます。探索、要件の収集、シェイプの比較、ブレッドボーディング、適合性チェックはすべてここで行います。これは作業用ドキュメントであり、R、シェイプ、パーツ、適合性チェックの信頼できる情報源です。

選択したシェイプのブレッドボーディングが完了し、構築の準備が整ったら、スライスドキュメントを作成します。スライスの分割、スライスごとのアフォーダンス表、詳細な配線を記載します。

ファイル管理

• シェーピングドキュメント：反復に合わせて自由に更新します — 信頼できる情報源です
• スライスドキュメント：スライス分割の準備が整ったときに作成し、スライスの範囲が明確になるにつれて更新します
• スライス計画：実装の詳細を記載した個別ファイル（V1-plan.md など）

フロントマター

すべてのシェーピングドキュメント（シェーピングドキュメント、フレーム、スライスドキュメント）には、YAML フロントマターに shaping: true を含める必要があります。これにより、ドキュメント間の一貫性の維持に役立つツールのフック（例：ripple-check のリマインダー）が有効になります。

---
shaping: true
---

# [Feature Name] — Shaping
...

ドキュメント間の同期

このドキュメントの冒頭にあるマルチレベルの一貫性を参照してください。どのレベルで変更を行った場合も、影響を受ける上下のレベルに反映する必要があります。

スライス

シェイプをブレッドボーディングした後、垂直方向の実装単位にスライスします。スライスの手順には /breadboarding スキルを使用してください。このスキルでは、垂直スライスとは何か、作成手順、可視化形式を定義しています。

流れ：

1. パーツ → シェイプ内の高レベルなメカニズム
2. ブレッドボード → 配線を含む具体的なアフォーダンス（/breadboarding を使用）
3. スライス → それぞれデモできる垂直方向の実装単位（/breadboarding のスライスのセクションを使用）

重要な原則： すべてのスライスは、デモ可能な UI で終わる必要があります。目に見える出力のないスライスは、垂直スライスではなく水平レイヤーです。

ドキュメントの成果物：

• スライスのドキュメント — スライスの定義、スライスごとのアフォーダンス表、スライス化されたブレッドボード
• スライス計画 — 個別の実装計画（V1-plan.md、V2-plan.md など）

例

ユーザーが検索機能をシェイプしています：

---
shaping: true
---

## Requirements (R)

| ID | Requirement | Status |
|----|-------------|--------|
| R0 | Make items searchable from index page | Core goal |
| R1 | State survives page refresh | Undecided |
| R2 | Back button restores state | Undecided |

---

## C2: State Persistence

| Req | Requirement | Status | C2-A | C2-B | C2-C |
|-----|-------------|--------|------|------|------|
| R0 | Make items searchable from index page | Core goal | — | — | — |
| R1 | State survives page refresh | Undecided | ✅ | ✅ | ❌ |
| R2 | Back button restores state | Undecided | ✅ | ✅ | ✅ |

**Notes:**
- C2-C fails R1: in-memory state lost on refresh
- C2-B satisfies R2 but requires custom popstate handler