lessons: rename JA predict callout to 「考えてみよう」

「予測してみよう」 was a literal rendering of EN "Predict" that
read like a school textbook prompt — fine grammar but stiff
register for a technical audience.

「考えてみよう」 is the standard JA pedagogical "stop and think
about it" phrasing. Pairs naturally with the callout body's
「スクロール前に: …」 / 「スクロールする前に: …」 lead-in.

Applied across all 14 lesson files where the callout appears
(L0 doesn't use Predict callouts).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: psyto

drafts/openhl_l10_ja.md

@@ -68,7 +68,7 @@ crates/consensus/src/bridge.rs            — ConsensusBridge trait + InMemoryEv
 
 このレッスンが教えるのは **actor-message-loop パターン**。ほとんどの consensus engine (CometBFT、Hotstuff、Aura) は **何らかの** 「application interface」を持つが、形は様々: callback、gRPC service、FFI バインディング。Malachite のアプローチは型付きメッセージの `tokio::mpsc` チャネル — 強型、async-native、チャネルごとに single-threaded。`run_engine_app` はそれらメッセージの **consumer**; engine actor は **producer**。**このパターンを理解すれば、どの chain フレームワークの「application interface」もそのバリアントに帰着する。**
 
-> 🛑 **予測してみよう。** スクロールする前に: engine が `AppMsg::GetValue` (「次の block を propose しろ」) を送るとき、app はなぜ `BlockHash` だけでなく `LocallyProposedValue(height, round, value)` で reply するのか? ヒント: engine が rest-of-consensus を通じて wire する value は、commit する value。hash だけ送ったら、engine は他の validator に proposal の内容を gossip したり certificate に含めたりする手段がない。**ラップが value を BFT machine 内で first-class にする。**(我々の single-validator devnet では他の validator は gossip を受け取らないが — engine は自分が solo で走っていることを **知らない**。)
+> 🛑 **考えてみよう。** スクロールする前に: engine が `AppMsg::GetValue` (「次の block を propose しろ」) を送るとき、app はなぜ `BlockHash` だけでなく `LocallyProposedValue(height, round, value)` で reply するのか? ヒント: engine が rest-of-consensus を通じて wire する value は、commit する value。hash だけ送ったら、engine は他の validator に proposal の内容を gossip したり certificate に含めたりする手段がない。**ラップが value を BFT machine 内で first-class にする。**(我々の single-validator devnet では他の validator は gossip を受け取らないが — engine は自分が solo で走っていることを **知らない**。)
 
 ## 手順
 
@@ -283,7 +283,7 @@ Engine は「height H で value が decide された — certificate がこれ
 4. **exit 条件チェック** — `stop_after_decisions` に達したら `Next::Start(next_height, ...)` で reply (engine が hang しないように) して return。**これがテストを 0.02 秒でクリーンに exit させる。**
 5. **そうでなければ** `Next::Start(next_height, validator_set)` で reply — 「はい、次の height で続けてください、validator set はこれ」 — して loop。
 
-> 🛑 **予測してみよう。** Exit path なのになぜ reply を送る? **`oneshot::Sender::send` が、reply を待っている engine actor を unblock する唯一の方法だから。** 単に `return Ok(decided)` すると、engine actor は今 drop された sender に対して `await` で stuck になり、tear-down が遅くなる (やがて `kill_and_wait` がクリーンアップする)。先に reply すれば engine actor は自然に終了し、`handle.kill(None)` は inevitable を確認するだけ。
+> 🛑 **考えてみよう。** Exit path なのになぜ reply を送る? **`oneshot::Sender::send` が、reply を待っている engine actor を unblock する唯一の方法だから。** 単に `return Ok(decided)` すると、engine actor は今 drop された sender に対して `await` で stuck になり、tear-down が遅くなる (やがて `kill_and_wait` がクリーンアップする)。先に reply すれば engine actor は自然に終了し、`handle.kill(None)` は inevitable を確認するだけ。
 
 ### Step 6: その他 7 arm — stub と no-op
 
@@ -635,5 +635,5 @@ L10 が参照する openhl コミット (§答え合わせ):
 - **「app loop」「engine」「bridge」** はそのまま (専門語)。
 - **「routing」「ルーティング」** は混在 — 文脈で読みやすい方を選択。
 - **「value-payload mode」「ProposalOnly モード」** はそのまま (Malachite の用語)。
-- **「予測してみよう」「やりがちな勘違い」** は L4-L9 で確立した訳語と統一。
+- **「考えてみよう」「やりがちな勘違い」** は L4-L9 で確立した訳語と統一。
 - **タイトル/コードコメントは英語のまま** (OSS 実装にコピーされる前提)。

drafts/openhl_l11_ja.md

@@ -67,7 +67,7 @@ bin/openhl/             — 空のバイナリ stub
 
 このレッスンが教えるのは **依存共存の検証パターン**。大きなインフラ crate 2 つに依存する (我々の場合 Reth と Malachite) 場合、衝突が判明するのは integration コードを書いてから — その時点で、**動くべき** だが compile しないコードに大量投資済み。**検証パターンは、integration を書く前に、両方を同時に exercise する最小のテストを書くこと。** Test が pass すれば両 dep が resolve・link する。失敗すれば失敗が即座に visible になり、blast radius が小さい。
 
-> 🛑 **予測してみよう。** スクロールする前に: なぜゴールコマンドで bootstrap test を `--release` でマークする? ヒント: compile time とその支配要因を考える。Reth の MDBX bindings + libp2p + alloy + rocksdb 系ストレージスタックは **巨大** — debug mode の初回コンパイルは ~2:34、release も同程度だが結果バイナリが大幅に高速。Test 自体は bootstrap と chain-ID チェックだけなので、**初回コンパイル後** は fast compile より fast runtime が欲しい。初回 cold ビルド後は `--release` で走る。
+> 🛑 **考えてみよう。** スクロールする前に: なぜゴールコマンドで bootstrap test を `--release` でマークする? ヒント: compile time とその支配要因を考える。Reth の MDBX bindings + libp2p + alloy + rocksdb 系ストレージスタックは **巨大** — debug mode の初回コンパイルは ~2:34、release も同程度だが結果バイナリが大幅に高速。Test 自体は bootstrap と chain-ID チェックだけなので、**初回コンパイル後** は fast compile より fast runtime が欲しい。初回 cold ビルド後は `--release` で走る。
 
 ## 手順
 
@@ -467,6 +467,6 @@ L11 が参照する openhl コミット (§答え合わせ):
 - **「load-bearing」「dependency-coexistence」「bootstrap」** は専門語として英語のまま保持。
 - **「stale」「blast radius」「validation」** はそのまま (ニュアンス保持)。
 - **「post-merge」「hardfork」「Shanghai」** は Ethereum 専門語そのまま。
-- **「予測してみよう」「やりがちな勘違い」** は L4-L10 で確立した訳語と統一。
+- **「考えてみよう」「やりがちな勘違い」** は L4-L10 で確立した訳語と統一。
 - **タイトル/コードコメントは英語のまま** (OSS 実装にコピーされる前提)。
 - **「インフラ」「サブシステム」** はカタカナ (一般定着語)。

drafts/openhl_l12_ja.md

@@ -67,7 +67,7 @@ crates/consensus/                — フル BFT engine + run_engine_app
 
 このレッスンが教えるのは **provider-に対してジェネリックなパターン**、bridge を isolation で testable にする。`LiveRethEvmBridge<P>` は `P: BlockNumReader + Clone + Sync + 'static` に対してジェネリック。Production では `P` は live node の `BlockchainProvider`。テストでは `P` は決定的な `(hash → number)` マッピングを返す `MockProvider` でもよい。**Bridge 自体はどちらか気にしない** — ただ `provider.block_number(...)` を呼ぶ。これは L10 の `run_engine_app<B: ConsensusBridge>` と同じパターン: 具象型ではなく trait に依存する。
 
-> 🛑 **予測してみよう。** スクロールする前に: `build_payload` が live provider から読むのに、なぜ `LiveRethEvmBridge` は依然として `pending`, `chain`, `head` フィールドを持つ内部 `Mutex<State>` を保持する? ヒント: `build_payload` は `PayloadId` を返し、engine は後で `payload_ready(id)` を呼んで実際の block を fetch する。Pending 状態がこれら 2 つの呼び出しを橋渡しする — Reth の payload-builder は block を組み立てるのに 10-50ms かかり、engine が待つ間 bridge は **結果** をどこかに保持する必要がある。**L13 でこのインメモリ pending 状態を Reth の実 payload-builder に置き換える。** 今のところは build-then-fetch shape が動くことを証明する placeholder。
+> 🛑 **考えてみよう。** スクロールする前に: `build_payload` が live provider から読むのに、なぜ `LiveRethEvmBridge` は依然として `pending`, `chain`, `head` フィールドを持つ内部 `Mutex<State>` を保持する? ヒント: `build_payload` は `PayloadId` を返し、engine は後で `payload_ready(id)` を呼んで実際の block を fetch する。Pending 状態がこれら 2 つの呼び出しを橋渡しする — Reth の payload-builder は block を組み立てるのに 10-50ms かかり、engine が待つ間 bridge は **結果** をどこかに保持する必要がある。**L13 でこのインメモリ pending 状態を Reth の実 payload-builder に置き換える。** 今のところは build-then-fetch shape が動くことを証明する placeholder。
 
 ## 手順
 
@@ -549,5 +549,5 @@ L12 が参照する openhl コミット (§答え合わせ):
 - **「load-bearing」「provider」「bridge」** は専門語として英語のまま保持。
 - **「generic-over-trait」「protocol vs operational failure」** はそのまま (ニュアンス保持)。
 - **「happy path」「negative path」「sad path」** は英語のまま (CS / QA 慣用語)。
-- **「予測してみよう」「やりがちな勘違い」** は L4-L11 で確立した訳語と統一。
+- **「考えてみよう」「やりがちな勘違い」** は L4-L11 で確立した訳語と統一。
 - **タイトル/コードコメントは英語のまま** (OSS 実装にコピーされる前提)。

drafts/openhl_l13_ja.md

@@ -71,7 +71,7 @@ pub struct LiveRethEvmBridge<P> {
 
 このレッスンが教えるのは **producer-consumer の自己整合性パターン**。同じ artifact の builder と validator がある場合、**両者は同じルールを使わなければならない**。`build_payload` が 1 つの base-fee 公式を使い `validate_payload` が別のを使うなら、すべての block が validation に失敗する。これを確保する方法は **両方を同じソースから導出すること** — ここでは `ChainSpec`。`ChainSpec::next_block_base_fee()` が build に使われ、`EthBeaconConsensus::validate_against_parent_eip1559_base_fee` の中で同じヘルパーが check に使われる。**Source-of-truth の共有がシステムを自己整合にする。**
 
-> 🛑 **予測してみよう。** スクロールする前に: なぜ `EthBeaconConsensus::validate_header_against_parent` は parent の **full** sealed header (gas_limit、timestamp、base_fee_per_gas、すべて) を必要とするが、`BlockNumReader::block_number` は `u64` しか返さない? ヒント: Reth の validator が走らせる 4 つの sub-check を考える。Number monotonicity は parent.number だけでいい。Timestamp monotonicity は parent.timestamp が必要。Gas-limit drift は parent.gas_limit が必要。EIP-1559 base fee は parent.base_fee_per_gas + parent.gas_used + parent.gas_limit が必要。**Validate する瞬間に、header 全体が必要 — number だけではない。** だから L13 で trait bound を `BlockNumReader` から **加えて** `HeaderProvider<Header = Header>` に拡張する。
+> 🛑 **考えてみよう。** スクロールする前に: なぜ `EthBeaconConsensus::validate_header_against_parent` は parent の **full** sealed header (gas_limit、timestamp、base_fee_per_gas、すべて) を必要とするが、`BlockNumReader::block_number` は `u64` しか返さない? ヒント: Reth の validator が走らせる 4 つの sub-check を考える。Number monotonicity は parent.number だけでいい。Timestamp monotonicity は parent.timestamp が必要。Gas-limit drift は parent.gas_limit が必要。EIP-1559 base fee は parent.base_fee_per_gas + parent.gas_used + parent.gas_limit が必要。**Validate する瞬間に、header 全体が必要 — number だけではない。** だから L13 で trait bound を `BlockNumReader` から **加えて** `HeaderProvider<Header = Header>` に拡張する。
 
 ## 手順
 
@@ -553,5 +553,5 @@ L13 が参照する openhl コミット (§答え合わせ):
 - **「source of truth」「source-of-truth」** はそのまま (DDD/データエンジ慣用)。
 - **「short-circuiting」「orchestration」「fallthrough」** はそのまま (専門語)。
 - **「monotonicity」「monotonic」** はそのまま (数学/CS 慣用)。
-- **「予測してみよう」「やりがちな勘違い」** は L4-L12 で確立した訳語と統一。
+- **「考えてみよう」「やりがちな勘違い」** は L4-L12 で確立した訳語と統一。
 - **タイトル/コードコメントは英語のまま** (OSS 実装にコピーされる前提)。

drafts/openhl_l14_ja.md

@@ -82,7 +82,7 @@ pub struct LiveRethEvmBridge<P> {
 
 Step 2 が失敗してもログするが伝播しない — Step 1 はすでに起きたから、roll back すると不整合状態に陥る。**成功の **後** に続く副作用は、成功を **gate する** 副作用とは異なる。**
 
-> 🛑 **予測してみよう。** スクロールする前に: なぜテストは `commit().await.expect(...)` が成功することだけを assert し、Reth の canonical chain head が動いたことは assert しない? ヒント: `build_payload` の出力に何が欠けているか考える。Engine に渡す `ExecutedBlock` は header だけ — トランザクションなし、receipt なし、state root なし。Reth の engine は canonical chain を advance するために **実際の block body** が必要。`engine_newPayload` を先に送らないと、`fork_choice_updated` は `SYNCING` (「この block をまだ知らない、body を fetch しろ」) を返す。Wire は接続されている; データは違う。**L14 は接続を証明する; payload execution は将来コースに先送り。**
+> 🛑 **考えてみよう。** スクロールする前に: なぜテストは `commit().await.expect(...)` が成功することだけを assert し、Reth の canonical chain head が動いたことは assert しない? ヒント: `build_payload` の出力に何が欠けているか考える。Engine に渡す `ExecutedBlock` は header だけ — トランザクションなし、receipt なし、state root なし。Reth の engine は canonical chain を advance するために **実際の block body** が必要。`engine_newPayload` を先に送らないと、`fork_choice_updated` は `SYNCING` (「この block をまだ知らない、body を fetch しろ」) を返す。Wire は接続されている; データは違う。**L14 は接続を証明する; payload execution は将来コースに先送り。**
 
 ## 手順
 
@@ -514,5 +514,5 @@ L14 が参照する openhl コミット (§答え合わせ):
 - **「source of truth」「downstream」「primary store」** はそのまま (DDD/データエンジ慣用)。
 - **「fork choice」「forkchoice」** はそのまま (Ethereum 用語)。
 - **「SYNCING」「VALID」「INVALID」** は Engine API レスポンス名そのまま。
-- **「予測してみよう」「やりがちな勘違い」** は L4-L13 で確立した訳語と統一。
+- **「考えてみよう」「やりがちな勘違い」** は L4-L13 で確立した訳語と統一。
 - **タイトル/コードコメントは英語のまま** (OSS 実装にコピーされる前提)。

drafts/openhl_l1_ja.md

@@ -52,7 +52,7 @@ L0 のセットアップを済ませている前提だ。手元には:
 
 **先にアプリケーションコードではなく依存グラフを組む理由**: Rust workspace で最も摩擦が多いのは依存解決だ。Reth と Malachite はどちらも巨大で transitive な依存ツリーが深い。**「あとでやる」にすると、アプリケーションコードを書いている最中に衝突を発見して巻き戻すことになる。** 先に依存を確定させておけば、その後のレッスンはレッスンの本題に集中できる。
 
-> 🛑 **予測してみよう。** スクロール前に sketch せよ: workspace の Cargo.toml に書く `members` は何個で、それぞれ何か? ヒント: 10 個のライブラリ crate + 1 個の binary crate。L0 §3 で 5 つのサブシステムを学んだ; それを実装するのは具体的に 10 個のうちのどの crate か? (必要なら L0 §4 を見返す。)
+> 🛑 **考えてみよう。** スクロール前に sketch せよ: workspace の Cargo.toml に書く `members` は何個で、それぞれ何か? ヒント: 10 個のライブラリ crate + 1 個の binary crate。L0 §3 で 5 つのサブシステムを学んだ; それを実装するのは具体的に 10 個のうちのどの crate か? (必要なら L0 §4 を見返す。)
 
 ## 手を動かす walk-through
 
@@ -342,7 +342,7 @@ alloy-rlp                 = { version = "0.3", default-features = false }
 
 **なぜ main HEAD ではなく release-tag SHA に pin するのか?** Main HEAD はいつでも壊れる可能性がある。Release tag はテストされた安定版だ。ファイル中のコメント (`# Bump は専用 PR で行う。release-tag SHA を必ず pin、main HEAD には絶対 pin しない。`) は将来 bump するときの process discipline メモだ。
 
-> 🛑 **予測してみよう。** いまの状態で `cargo check --workspace` を実行すると何が起こるか? スクロール前に 1 つ選べ:
+> 🛑 **考えてみよう。** いまの状態で `cargo check --workspace` を実行すると何が起こるか? スクロール前に 1 つ選べ:
 > - (a) 何も変わらない — まだどの crate も Reth の依存を使っていないから
 > - (b) 初回は劇的に遅くなる — Reth の transitive な ~600 crate を fetch + compile する
 > - (c) エラー — Reth は明示的な configuration が必要で、まだ与えていない
@@ -518,6 +518,6 @@ L1 が引用する openhl の commit は 2 つ (§答え合わせ で参照):
 - **翻訳 policy**:
   - Cargo / Rust の用語 (`workspace`、`resolver`、`feature`、`dependency`、`target`、`profile` 等) は英語のまま
   - コードブロック、コマンド、TOML キーは英語のまま
-  - 🛑 callout: 予測してみよう (Predict)、やりがちな勘違い (Anti-fluency)
+  - 🛑 callout: 考えてみよう (Predict)、やりがちな勘違い (Anti-fluency)
   - 「依存」「依存グラフ」「依存解決」は日本語、「dependency」が文脈で必要な場合は併記
   - 「resolver」「pin する」「fetch」「compile」「fork」「Stage」「commit」「workspace」は英語のまま — Rust エンジニアにとって直感的