29 KiB
29 KiB
Phase 15.75 Bootstrap戦略統合ドキュメント
📚 ← ../INDEX.md に戻る | 🔒 安全性保証・Rollback戦略 + 🔧 ツールチェーン要件
最終更新: 2025-10-14 ステータス: Phase 15.75計画段階 目的: MIRの疎結合を活用したゼロリスクBootstrap戦略とツールチェーン要件の完全定義
📋 目次
- Executive Summary
- MIR疎結合の技術的仕組み
- Stage 0/1/2 並行運用戦略
- Rollback手順の詳細
- パフォーマンス境界の詳細
- "Chicken and Egg"問題の解消
- Bootstrap戦略の実装手順
- リスク評価の修正
- ツールチェーン要件
- 将来の開発環境
- まとめ
📋 Executive Summary
Phase 15.75のRust脱却は不可逆的な書き換えではなく、実行バックエンドの追加です。
🎯 核心原則
MIR = 疎結合ポイント
→ Stage 0/1/2 は並行運用可能
→ いつでもRollback可能
→ パフォーマンス境界はMIRレベル
hakorune.exe が自分自身をビルド・テスト・デバッグできる環境
= 外部依存最小化 + 段階的自己実装
⚠️ 従来の誤解 vs 正しい理解
❌ 誤解（従来の"コンパイラ書き換え"モデル）
Stage 0 ──→ Stage 1 ──→ Stage 2 （一方通行）
(Rust) (Hybrid) (Hakorune)
↑
戻れない危険地帯
✅ 正しい理解（Hakorune MIRモデル）
MIR (疎結合)
↓
┌─────────┼─────────┐
↓ ↓ ↓
Stage 0 Stage 1 Stage 2
(Rust VM) (LLVM AOT)(Hako VM AOT)
← いつでも切替可能 →
重要: すべてのStageが同じMIRを実行するため、バックエンドはいつでも交換可能
🚀 優先度定義
- P0 (Critical): なければ開発不可能（1週間以内に必要）
- P1 (High): 生産性に大きく影響（1ヶ月以内）
- P2 (Medium): あると便利（将来実装）
- P3 (Low): Nice-to-have（需要次第）
🔧 1. MIR疎結合の技術的仕組み
1.1 MIRとは何か
MIR (Mid-level Intermediate Representation): Hakoruneの中間表現
{
"functions": [{
"name": "main",
"blocks": [{
"id": 0,
"instructions": [
{"op": "const", "dst": 1, "value": {"Int": 42}},
{"op": "const", "dst": 2, "value": {"Int": 10}},
{"op": "binop", "dst": 3, "kind": "Add", "lhs": 1, "rhs": 2}
],
"terminator": {"op": "ret", "value": {"Register": 3}}
}]
}]
}
1.2 MIRが提供する疎結合
Source Code (.hako)
↓
[Parser] ← Stage 0: Rust / Stage 1-2: Selfhost
↓
★ MIR (JSON) ★ ← 疎結合ポイント（安定インターフェース）
↓
[Execution Backend]
├─ Rust VM (Stage 0)
├─ LLVM AOT (Stage 1)
└─ Hakorune VM AOT (Stage 2)
重要な特性:
- 安定性: MIRフォーマットは凍結済み（16命令で完結）
- 独立性: Parser と Execution は完全に分離
- 交換可能性: 同じMIRなら、どのバックエンドでも同じ結果
1.3 実行例：同じMIRを3つのバックエンドで実行
# MIR生成（どのStageでもOK）
./hakorune-stage0.exe --emit-mir-json test.mir.json test.hako
# Stage 0: Rust VM実行
./hakorune-stage0.exe test.mir.json
→ 出力: 52
# Stage 1: LLVM AOT実行
./hakorune-stage1.exe test.mir.json
→ 出力: 52
# Stage 2: Hakorune VM AOT実行
./hakorune-stage2.exe test.mir.json
→ 出力: 52
結論: MIRが正しければ、すべてのバックエンドで同じ結果
🚀 2. Stage 0/1/2 並行運用戦略
2.1 3つのStageの役割分担
| Stage | 実装 | 用途 | 開発速度 | 最適化 | デバッグ |
|---|---|---|---|---|---|
| Stage 0 | Rust VM + Rust Parser | デバッグ・最終Rollback | 遅 | 低 | ★★★★★ |
| Stage 1 | LLVM AOT + Selfhost Parser | 本番推奨・開発 | 中 | ★★★★★ | ★★★★ |
| Stage 2 | Hakorune VM AOT + Selfhost Parser | 実験的・将来 | 高 | ★★★ | ★★ |
2.2 並行運用の具体例
ケース1: 通常開発（Stage 1メイン）
# コード編集
vim selfhost/compiler/parser.hako
# ビルド＆テスト（Stage 1）
./hakorune-stage1.exe build --target selfhost/
./hakorune-stage1.exe test --profile quick
# 問題なければcommit
git commit -m "feat: improve parser error messages"
ケース2: デバッグ必要（Stage 0にRollback）
# Stage 1でバグ発見
./hakorune-stage1.exe buggy_code.hako
→ Segmentation fault（原因不明）
# Stage 0で詳細トレース
HAKO_VM_TRACE="op=*;regs=1" ./hakorune-stage0.exe buggy_code.hako
→ [vm] bb=3 inst=7 boxcall recv=v%5(null) ← NULL参照発見！
# 修正後、Stage 1でテスト
./hakorune-stage1.exe buggy_code.hako
→ 正常動作
ケース3: パフォーマンス検証（Stage 2実験）
# Stage 1で基準測定
time ./hakorune-stage1.exe benchmark.hako
→ 1.2秒
# Stage 2で比較
time ./hakorune-stage2.exe benchmark.hako
→ 2.5秒（遅い）
# 結論: Stage 1を継続使用（問題なし）
2.3 hakorune.exe の維持戦略
方針: 3つの hakorune 実行ラインを並行維持
hakorune-selfhost/
├── bin/
│ ├── hakorune ← `target/release/nyash` ラッパー（現行実体）
│ ├── hakorune-stage0 ← Rust VM（現行は `nyash` に委譲）
│ └── hakorune-stage1 ← LLVM ライン（現行は `nyash --backend llvm`）
├── src/ ← Stage 0用 Rust コード（ブランチ保存）
├── selfhost/ ← Stage 1-2用 Hakoruneコード
└── hako.toml
ビルド手順
Stage 0: Rust Bootstrap（初回のみ）
# 初回ビルド
cargo build --release
cp target/release/hako bin/hakorune-stage0
# 以降は保存のみ（更新不要）
git checkout -b stage0-preserved
git commit -m "chore: preserve Stage 0 for debugging"
備考: 現時点の実体は nyash。bin/ のラッパー経由で名称を hakorune に統一しつつ、徐々に本体も置換していく（段階移行）。
Stage 1: LLVM ライン（メイン開発）
# Selfhost Parserでビルド
./bin/hakorune-stage0 build --target selfhost/ --backend llvm
→ bin/hakorune-stage1 生成
# 以降は Stage 1で自己ビルド可能
./bin/hakorune-stage1 build --target selfhost/ --backend llvm
→ bin/hakorune-stage1 更新
Stage 2: Hakorune VM AOT（将来）
# Hakorune VM実装後
./bin/hakorune-stage1 build --target selfhost/ --backend hakorune-vm
→ bin/hakorune-stage2 生成
# Stage 2で自己ビルド可能
./bin/hakorune-stage2 build --target selfhost/ --backend hakorune-vm
→ bin/hakorune-stage2 更新
🔄 3. Rollback手順の詳細
3.1 Rollback Level 1: バックエンド切替（即座）
状況: Stage 1実行時に問題発生
# 問題発生
./hakorune-stage1.exe problem.hako
→ エラー（原因不明）
# 即座にStage 0へ切替
./hakorune-stage0.exe problem.hako
→ 正常動作 or 詳細エラーメッセージ
所要時間: 0秒（バイナリ切替のみ）
3.2 Rollback Level 2: Parser Rollback（MIR経由）
状況: Selfhost Parserにバグ（Stage 1-2共通）
# Selfhost Parserでパースエラー
./hakorune-stage1.exe new_syntax.hako
→ Parse error（Selfhost Parserのバグ）
# Stage 0（Rust Parser）で回避
./hakorune-stage0.exe new_syntax.hako
→ 正常動作
# Selfhost Parserのバグ修正
vim selfhost/compiler/parser.hako
# Stage 0でテスト（Rust VM）
./hakorune-stage0.exe test tests/test_parser.hako
→ PASS
# Stage 1で再ビルド
./hakorune-stage0.exe build --target selfhost/ --backend llvm
→ hakorune-stage1.exe 更新
# 修正確認
./hakorune-stage1.exe new_syntax.hako
→ 正常動作
所要時間: 5-10分（修正 + テスト）
3.3 Rollback Level 3: Full Rollback（Git branch切替）
状況: Phase 15.75全体を巻き戻し
# 現在: Phase 15.75完了後（Stage 1運用中）
git branch
* phase-15.75-complete
stage0-preserved
main
# 問題発生（致命的）
./hakorune-stage1.exe critical_app.hako
→ Runtime panic（修正不可能）
# Stage 0ブランチへ完全Rollback
git checkout stage0-preserved
# Rustビルド
cargo build --release
# Stage 0で動作確認
./target/release/hako critical_app.hako
→ 正常動作
# 問題修正後、再度Phase 15.75へ
git checkout phase-15.75-complete
所要時間: 10-30分（ブランチ切替 + ビルド）
📊 4. パフォーマンス境界の詳細
4.1 パフォーマンス劣化の境界
ユーザーの指摘：「パフォーマンス劣化のラインはそこ（MIRレベル）でキレます」
┌─────────────────────────┐
│ Source Code (.hako) │
│ │ ← 正しさの領域
│ ↓ Parser │ （パフォーマンス影響なし）
├─────────────────────────┤
│ ★ MIR (JSON) ★ │ ← ★パフォーマンス境界★
├─────────────────────────┤
│ ↓ Execution Backend │
│ - Rust VM (遅) │ ← 最適化の領域
│ - LLVM AOT (高速) │ （バックエンド選択で変動）
│ - Hakorune VM (中速) │
└─────────────────────────┘
4.2 MIR品質 = パフォーマンス上限
重要な意味:
-
Selfhost Parserが生成するMIR = Rust Parserと同等 → パフォーマンス上限は保証される
-
実行バックエンドの違い = 最適化レベルの差 → Stage 0（Rust VM）: 最適化なし → Stage 1（LLVM AOT）: 最適化あり（推奨） → Stage 2（Hakorune VM）: 将来的に最適化予定
-
MIRを改善すれば、すべてのStageで性能向上
# MIR最適化パス追加 ./hakorune-stage1.exe --mir-opt-level 2 program.hako → すべてのバックエンドで高速化
4.3 実測パフォーマンス比較（予測）
| バックエンド | ビルド時間 | 実行速度 | デバッグ性 | 推奨用途 |
|---|---|---|---|---|
| Stage 0 (Rust VM) | 2秒 | 1.0x（基準） | ★★★★★ | デバッグ・検証 |
| Stage 1 (LLVM AOT) | 5秒 | 10-50x | ★★★★ | 本番・開発 |
| Stage 2 (Hako VM) | 3秒 | 2-5x（予測） | ★★ | 実験的 |
結論: Stage 1（LLVM AOT）が最速 → メイン開発推奨
🎯 5. "Chicken and Egg"問題の解消
5.1 従来の誤解
誤解: 「Stage 2に移行したら、Stage 1でビルドできなくなる（循環依存）」
❌ 誤ったモデル:
hakorune-stage1.exe（LLVM AOT）
↓ 削除
hakorune-stage2.exe（Hakorune VM）のみ
↓
Stage 2で問題発生 → Stage 1がない！（詰み）
5.2 正しい理解
正しいモデル: 「Stage 1-2は並行維持、削除しない」
✅ 正しいモデル:
hakorune-stage1.exe（LLVM AOT） ← 削除しない！
↓ 並行
hakorune-stage2.exe（Hakorune VM） ← 実験的に追加
↓
Stage 2で問題発生 → Stage 1に戻る（問題なし）
5.3 実際のビルドフロー
Phase 5完了時（Stage 1確立）
# Stage 0でStage 1ビルド（初回のみ）
./hakorune-stage0.exe build --backend llvm
→ hakorune-stage1.exe 生成
# Stage 1で自己ビルド可能
./hakorune-stage1.exe build --backend llvm
→ hakorune-stage1.exe 更新（自己再生産）
Phase 8完了時（Stage 2追加）
# Stage 1でStage 2ビルド
./hakorune-stage1.exe build --backend hakorune-vm
→ hakorune-stage2.exe 生成
# Stage 2で自己ビルド可能
./hakorune-stage2.exe build --backend hakorune-vm
→ hakorune-stage2.exe 更新
# Stage 1も維持
./hakorune-stage1.exe build --backend llvm
→ hakorune-stage1.exe 更新（並行維持）
重要: Stage 0/1/2すべてが自己再生産可能 → 循環依存なし
📋 6. Bootstrap戦略の実装手順
6.1 Phase 1-2: Stage 1確立
目標: hakorune-stage1.exe（LLVM AOT）を自己ビルド可能に
Week 1-2: Selfhost Parser実装
├─ Stage 0でテスト（Rust VM）
├─ MIR出力確認（Rust Parser と一致）
└─ Stage 0でStage 1ビルド
Week 2終了時:
✅ hakorune-stage0.exe（保存）
✅ hakorune-stage1.exe（自己再生産可能）
Rollback可能性: いつでもStage 0に戻れる
6.2 Phase 3-5: Rust削減
目標: Rust 99,406行 → 10,400行
Week 3-4: Box移行 + Rust VM削除 + Runtime薄層化
├─ Stage 1で開発（メイン）
├─ Stage 0で検証（並行テスト）
└─ スモークテスト全pass確認
Week 4終了時:
✅ hakorune-stage0.exe（ブランチ保存）
✅ hakorune-stage1.exe（10,400行 Rust kernel）
Rollback可能性: いつでもStage 0ブランチに戻れる
6.3 Phase 6-8: Stage 2実装（オプション）
目標: hakorune-stage2.exe（Hakorune VM AOT）を実験的に追加
Week 5-8: Hakorune VM実装（オプション）
├─ Stage 1で開発（メイン継続）
├─ Hakorune VM実装（新規）
└─ Stage 2ビルド（実験的）
Week 8終了時:
✅ hakorune-stage0.exe（ブランチ保存）
✅ hakorune-stage1.exe（メイン開発）
✅ hakorune-stage2.exe（実験的）
Rollback可能性: Stage 1-2両方維持、いつでも切替可能
🚨 7. リスク評価の修正
7.1 従来のリスク評価（誤解ベース）
| リスク | レベル | 理由 |
|---|---|---|
| Rollback不可 | HIGH | Stage 2移行後は戻れない |
| 循環依存 | HIGH | Chicken and Egg問題 |
| デバッグ劣化 | MEDIUM | Rust VMがなくなる |
7.2 修正後のリスク評価（MIR疎結合ベース）
| リスク | レベル | 理由 | 対策 |
|---|---|---|---|
| Rollback不可 | NONE | MIR疎結合により常にRollback可能 | Stage 0保存 |
| 循環依存 | NONE | Stage 1-2並行維持 | 削除しない |
| デバッグ劣化 | NONE | Stage 0永久保存 | ブランチ保存 |
| MIR品質劣化 | LOW | Selfhost Parserのバグ | Stage 0で検証 |
| パフォーマンス劣化 | LOW | Stage 2が遅い可能性 | Stage 1継続使用 |
結論: MIR疎結合により、すべての致命的リスクが解消
🔧 8. ツールチェーン要件
Phase 15.75でRustを削減（99,406行 → 10,400行 or 3,500行）する際、開発継続性を保証するために必要なツールチェーンを定義します。
用語と実体（現時点の対応）
- 実行バイナリ実体:
target/release/nyash - 呼称/ラッパー:
bin/hakorune,bin/hakorune-stage0,bin/hakorune-stage1 - Cargo alias（開発導線）:
build-rust/run-rust（legacy）,build-hako/run-hako（plugin-only）.cargo/config.tomlに定義済み（Phase 15.75 名称分離）。- 将来は実体名も
hakoruneに移行（ラッパー→本体置換の段階移行）。
8.1 ビルドシステム（P0 - Critical）
HakoBuildBox - Build Orchestrator
目的: cargo build の代替として、Hakoruneプロジェクトをビルド
必要機能:
static box HakoBuildBox {
// プロジェクト構造解析
parse_project(root_path) -> ProjectBox
// 依存関係解決
resolve_dependencies(project) -> DependencyGraphBox
// ビルド実行
build(project, config) -> BuildResultBox
// インクリメンタルビルド
incremental_build(project, changed_files) -> BuildResultBox
// クリーン
clean(project) -> Result
}
実装戦略:
Phase 5.1: 最小実装（1週間）
# 目標: hakorune.exe 自己ビルド可能に
hako build.hako --target selfhost/compiler/pipeline_v2/
# 機能:
- ファイル列挙（*.hako）
- using依存解決（トポロジカルソート）
- MIR生成（hakorune.exe呼び出し）
- LLVM AOT実行（python llvm_builder.py）
実装サイズ見積もり: 500-800行（Hakorune）
依存ライブラリ:
- FileBox (plugin) - ファイルIO
- ArrayBox, MapBox (builtin) - データ構造
- StringBox (builtin) - パス操作
代替案:
# 暫定: Makefileで代用（Phase 1-4期間）
make -f hakorune.mk build
hako.toml パーサー（P0）
目的: プロジェクト設定読み込み
必要機能:
static box HakoTomlBox {
parse(content) -> ConfigBox
get_dependencies(config) -> ArrayBox
get_build_settings(config) -> MapBox
get_module_paths(config) -> ArrayBox
}
実装戦略:
# Phase 5.1: 最小TOMLサブセット
[package]
name = "hakorune-selfhost"
version = "0.1.0"
[dependencies]
selfhost = { path = "./selfhost" }
[build]
target = "llvm"
実装サイズ見積もり: 300-500行
代替案:
- JSON設定ファイル（hako.json） - TOMLより簡単
- Hakorune内埋め込み設定
8.2 コードエディタサポート（P1 - High）
HakoLspBox - Language Server Protocol
目的: VSCode/Vim等でコード補完・エラー表示
必要機能:
static box HakoLspBox {
// 初期化
initialize(root_uri) -> Result
// 補完
textDocument_completion(params) -> CompletionListBox
// 定義ジャンプ
textDocument_definition(params) -> LocationBox
// エラー診断
textDocument_publishDiagnostics(uri) -> DiagnosticsBox
// ホバー情報
textDocument_hover(params) -> HoverBox
}
実装戦略:
Phase 6.1: 最小LSP（2週間）
機能:
✅ 構文エラー表示（赤波線）
✅ using 解決（定義ジャンプ）
✅ 基本補完（static box メソッド名）
実装方法:
- JSON-RPC over stdio
- Parser再利用（--check-syntax mode）
- シンボルテーブル構築（using追跡）
実装サイズ見積もり: 1,200-2,000行
優先度判断:
- P1 - エディタなしは生産性激減
- ただし Phase 1-5 は既存エディタで可能
- Phase 6 で実装開始でOK
代替案:
# 暫定: 構文チェックスクリプト
hako --check-syntax file.hako
HakoFmtBox - Code Formatter（P2）
目的: コード整形統一
実装サイズ見積もり: 400-800行
優先度判断:
- P2 - 現状手動整形で対応可能
- 複数人開発開始後に必要
8.3 テストフレームワーク（P0 - Critical）
HakoTestBox - Unit Test Framework
目的: cargo test の代替
必要機能:
static box HakoTestBox {
// テスト実行
run_tests(test_dir) -> TestResultBox
// アサーション
assert_eq(actual, expected) -> Result
assert_ne(actual, expected) -> Result
assert(condition, message) -> Result
// テストレポート
report(results) -> StringBox
}
実装戦略:
Phase 5.2: 最小実装（3日）
// テストファイル: tests/test_parser.hako
using "hakorune/test" as Test
static box TestParser {
test_basic_expression() {
local result = Parser.parse("1 + 2")
Test.assert_eq(result.is_Ok(), 1)
}
test_invalid_syntax() {
local result = Parser.parse("1 +")
Test.assert(result.is_Err())
}
}
# 実行
hako test tests/
# 出力
Running test_basic_expression... PASS
Running test_invalid_syntax... PASS
Test Results: 2 passed, 0 failed
実装サイズ見積もり: 200-400行
代替案:
# 暫定: スモークテストスクリプト流用
bash tools/smokes/v2/run.sh --profile quick
8.4 デバッグツール（P0 - Critical）
MIRダンプツール（P0 - 実装済み✅）
現状: --dump-mir で実装済み
# 既存機能
hako --dump-mir program.hako
hako --emit-mir-json debug.json program.hako
追加で必要な機能:
# MIR最適化レベル確認
hako --dump-mir --mir-opt-level 2 program.hako
# MIR diff（最適化前後）
hako --dump-mir-diff program.hako
実装サイズ見積もり: 100-200行（追加分のみ）
VM Trace Debugger（P0 - 実装済み✅）
現状: 既に実装済み
# Rust VM トレース
HAKO_VM_TRACE="op=compare,binop;regs=1" hako program.hako
# Rust VM ステッパ
HAKO_VM_STEP=1 hako program.hako
# Selfhost Mini-VM トレース
# （MiniVmEntryBox.run_trace() 使用）
追加で必要な機能:
# ブレークポイント
HAKO_VM_BREAK="block=5,inst=3" hako program.hako
# レジスタウォッチ
HAKO_VM_WATCH="v%3,v%5" hako program.hako
実装サイズ見積もり: 200-300行（追加分のみ）
Performance Profiler（P2）
目的: ボトルネック特定
実装サイズ見積もり: 800-1,200行
優先度判断:
- P2 - 最適化フェーズで必要（Phase 8以降）
- 暫定:
timeコマンドで代用
8.5 パッケージマネージャー（P2 - Medium）
HakoPkgBox - Package Manager
目的: 外部ライブラリ管理（cargo install 代替）
実装サイズ見積もり: 1,000-1,500行
優先度判断:
- P2 - Phase 1-6 は
usingで十分 - 外部ライブラリエコシステム成長後に必要
代替案:
# Git submodule
git submodule add https://github.com/user/hako-json-parser libs/json_parser
8.6 コード解析ツール（P3 - Low）
HakoLintBox - Static Analyzer（P3）
実装サイズ見積もり: 600-1,000行
優先度判断:
- P3 - Nice-to-have
- 現状: コードレビューで対応
HakoDocBox - Documentation Generator（P3）
実装サイズ見積もり: 800-1,200行
優先度判断:
- P3 - 手動ドキュメント管理で十分（当面）
🚀 9. 将来の開発環境
9.1 ツールチェーン実装優先度マトリックス
| ツール | 優先度 | 実装時期 | 実装サイズ | 依存 | 代替案 |
|---|---|---|---|---|---|
| HakoBuildBox | P0 | Phase 5.1 (Week 3) | 500-800行 | FileBox | Makefile |
| HakoTomlBox | P0 | Phase 5.1 (Week 3) | 300-500行 | - | JSON設定 |
| HakoTestBox | P0 | Phase 5.2 (Week 3) | 200-400行 | - | Bashスクリプト |
| MIRダンプ | P0 | ✅実装済み | +100-200行 | - | - |
| VM Trace | P0 | ✅実装済み | +200-300行 | - | - |
| HakoLspBox | P1 | Phase 6.1 (Week 5-6) | 1,200-2,000行 | - | --check-syntax |
| 統合テスト | P1 | Phase 7 (Week 7-8) | 600-1,000行 | - | 既存Bash |
| HakoFmtBox | P2 | Phase 7 (Week 8) | 400-800行 | - | 手動整形 |
| HakoPkgBox | P2 | Phase 7-8 (Week 9+) | 1,000-1,500行 | - | Git submodule |
| Profiler | P2 | Phase 8+ | 800-1,200行 | - | time コマンド |
| HakoLintBox | P3 | 将来 | 600-1,000行 | - | レビュー |
| HakoDocBox | P3 | 将来 | 800-1,200行 | - | 手動 |
9.2 実装工数見積もり
P0ツール（必須 - 1ヶ月以内）
HakoBuildBox: 5日（Week 3）
HakoTomlBox: 3日（Week 3）
HakoTestBox: 3日（Week 3）
MIRダンプ強化: 2日（Week 4）
VM Trace強化: 2日（Week 4）
合計: 15日 ≈ 3週間（Week 3-4）
P1ツール（重要 - 2ヶ月以内）
HakoLspBox: 10日（Week 5-6）
統合テスト: 5日（Week 7）
合計: 15日 ≈ 3週間（Week 5-7）
P2ツール（便利 - 3ヶ月以内）
HakoFmtBox: 5日（Week 8）
HakoPkgBox: 10日（Week 9-10）
Profiler: 8日（Week 11）
合計: 23日 ≈ 5週間（Week 8-12）
9.3 最小実装セット（Phase 15.75完了に必要）
✅ P0ツール（Week 3-4）
- HakoBuildBox（500行）
- HakoTomlBox（300行）
- HakoTestBox（200行）
- MIRダンプ（+100行）
- VM Trace（+200行）
合計: 約1,300行 + 既存デバッグツール
期間: 2週間（Phase 5期間中に並行実装）
結論: Phase 15.75（1ヶ月計画）完了に必要なツールチェーンはすべて実現可能
9.4 段階的実装アプローチ
Week 1-2: Phase 1-2 (Selfhost Parser)
→ 既存 hakorune.exe 使用（ツール不要）
Week 3: Phase 5.1 (P0ツール実装)
→ HakoBuildBox（5日）
→ HakoTomlBox（3日）
→ HakoTestBox（3日）
※並行作業: Parser開発 + ツール開発
Week 4: Phase 3-4 (Box移行 + Rust VM削除)
→ 既存ツール使用
→ MIRダンプ強化（2日）
Week 5-6: Phase 6 (P1ツール実装)
→ HakoLspBox（10日）
※オプション: Phase 5完了後でもOK
Week 7+: P2ツール（将来実装）
→ 需要に応じて追加
9.5 ツール間依存関係
┌─────────────────┐
│ hakorune.exe │ ← 最優先（常に動作保証）
└────────┬────────┘
│
┌────┴────┐
│ MIR │ ← 疎結合ポイント
└────┬────┘
│
┌────────┴────────┐
│ HakoBuildBox │ ← ビルド統括
│ ├─ HakoTomlBox │ 設定読込
│ ├─ FileBox │ ファイルIO
│ └─ hakorune.exe│ MIR生成呼出
└─────────────────┘
│
┌────┴────┐
│ HakoTestBox │ ← テスト実行
│ └─ hakorune.exe
└─────────┘
│
┌────┴────┐
│ HakoLspBox │ ← エディタ支援
│ └─ Parser │ 構文解析再利用
└─────────┘
重要: すべてのツールが hakorune.exe と MIR に依存
→ MIRの安定性がツールチェーン全体の安定性を保証
9.6 ツールチェーン品質保証戦略
// tests/test_hako_build.hako
using "hakorune/test" as Test
using "hakorune/build" as Build
static box TestHakoBuild {
test_simple_project() {
local project = Build.parse_project("./test_fixtures/simple")
Test.assert_eq(project.name(), "simple")
local result = Build.build(project, null)
Test.assert(result.is_Ok())
}
test_dependency_resolution() {
local project = Build.parse_project("./test_fixtures/with_deps")
local deps = Build.resolve_dependencies(project)
Test.assert_eq(deps.size(), 3)
}
}
🎯 10. まとめ：ゼロリスクBootstrap戦略
10.1 核心原則（再確認）
1. MIR = 疎結合ポイント
→ Parser と Execution Backend は完全分離
2. Stage 0/1/2 = 並行運用
→ いつでも切替可能、削除しない
3. hakorune.exe = 常に動作保証
→ 開発継続性100%維持
4. パフォーマンス境界 = MIRレベル
→ MIRが正しければパフォーマンス保証
5. Rollback = 即座に可能
→ バイナリ切替（0秒）〜 ブランチ切替（30分）
6. ツールチェーン = 段階的自己実装
→ P0（1ヶ月）→ P1（2ヶ月）→ P2（3ヶ月）
10.2 Phase 15.75の成功条件
✅ hakorune-stage1.exe が自己ビルド可能
✅ Rust 99,406行 → 10,400行削減
✅ スモークテスト全pass
✅ Stage 0/1並行維持
✅ いつでもRollback可能
✅ P0ツールチェーン完備（Build/Test/Debug）
10.3 最終確認
Q: Phase 15.75完了後、問題が起きたらどうする？
# A: 即座にStage 0へRollback（0秒）
./hakorune-stage0.exe problem.hako
Q: Selfhost Parserにバグがあったらどうする？
# A: Stage 0（Rust Parser）で開発継続（問題なし）
./hakorune-stage0.exe build --target selfhost/
Q: Stage 2（Hakorune VM）が遅かったらどうする？
# A: Stage 1（LLVM AOT）を継続使用（問題なし）
./hakorune-stage1.exe program.hako
Q: ツールチェーンが間に合わなかったらどうする？
# A: 代替案で継続（Makefile/Bash/既存ツール）
make -f hakorune.mk build
bash tools/smokes/v2/run.sh --profile quick
結論: すべてのケースでRollback可能 + ツールチェーン段階実装 → ゼロリスクBootstrap戦略
🔗 関連ドキュメント
- Phase 15.75 INDEX
- Phase 15.75 Master Roadmap
- Implementation Phases
- TODO Roadmap
- Timeline Analysis
- Velocity Analysis
📝 変更履歴
- 2025-10-14: BOOTSTRAP_STRATEGY_MIR_ROLLBACK.md と TOOLCHAIN_REQUIREMENTS.md を統合
- MIR疎結合によるRollback能力の詳細説明
- Stage 0/1/2並行運用戦略の定義
- "Chicken and Egg"問題の解消
- パフォーマンス境界の明確化
- ツールチェーン要件の完全定義
- 段階的実装アプローチの統合
- 2025-10-13: 元の2ファイル作成（Claude Code + ユーザー指摘反映）