docs(phase-29y): tighten lifecycle vocab consult packet

docs/development/current/main/investigations/phase-29y-mir-lifecycle-vocab-consult.md

@@ -1,5 +1,5 @@
-Status: Active  
-Date: 2025-12-26  
+Status: Draft (docs-first, post self-host)  
+Date: 2025-12-27  
 Scope: Self-host後に “脱Rustランタイム（NyRT/.hako）” を進めるため、MIR命令語彙と runtime ABI（lifecycle/RC/weak）の境界をどう固めるべきか相談するパケット  
 Related:
 - docs/reference/language/lifecycle.md
@@ -18,6 +18,14 @@ self-host後に脱Rustを進める前提で、**MIRのどこまでを語彙と
 - “脱Rust” はゴールだが、**実装移行（NyRT/.hako化）は別フェーズ**でやる（この文書はその設計SSOTの下敷き）。
 - Phase 285（weak conformance / hidden root 根治）が未解決なら、先に Phase 285 を優先する。
 
+## 0.1 現時点で確定した事実（Phase 285 からの入力）
+
+ソースを見ずに議論できるように、「現実に起きたこと」を短く固定する。
+
+- weak は `weak_to_strong()` で生死が観測できるため、**SSA last-use = 言語寿命**は意味論として成立しない。
+- hidden root は実装の細部（VMのレジスタ/一時値保持など）で起きうるため、**“root面” と観測点（診断/ABI）**を設計で固定する必要がある。
+- LLVM harness は stdout にログが混入し得るため、smoke は **exit code SSOT**（出力比較に依存しない）へ寄せた方が安定する。
+
 ## 1. 背景（いま分かったこと）
 
 - weak/strong の意味論は言語SSOT（`docs/reference/language/lifecycle.md`）で定義されている。
@@ -26,7 +34,11 @@ self-host後に脱Rustを進める前提で、**MIRのどこまでを語彙と
 
 ## 2. 相談したい焦点
 
-### Q1. MIRに参照カウンタ（retain/release）を載せるべきか？
+この文書の目的は “決めたいことを増やす” ではなく、論点を減らして設計SSOTの入口を作ること。
+
+相談したい論点は **5つだけ**に絞る（追加しない）。
+
+### Q1. RC/weak の実体はどこに置くべきか？（runtime vs MIR vocab）
 
 候補:
 - A) **MIRは寿命を語らず**、runtime ABI で retain/release/weak を表現する（MIR→loweringがABI呼び出しへ）
@@ -35,7 +47,31 @@ self-host後に脱Rustを進める前提で、**MIRのどこまでを語彙と
 求める回答:
 - “移植性（LLVM/wasm）” と “実装コスト/破綻リスク（PHI/early-exit/例外）” の観点で、段階移行のおすすめ。
 
-### Q2. “観測点” をどこに置くべきか？
+### Q2. retain/release/weak_drop の “発火点” をどこで決めるべきか？
+
+候補:
+- `Frag` 直前/直後の **1回の pass**（CFG確定後）で RC event 列を挿入する
+- lowering 各所に分散する（非推奨）
+
+求める回答:
+- PHI/loop/early-exit を踏まえた “壊れにくい置き場所” の推奨
+
+### Q3. 関数 ABI（args borrowed / return owned）は妥当か？
+
+求める回答:
+- 代替案があるなら “語彙が増えない最小案” を提示してほしい
+
+### Q4. weak handle の表現（token/handle/tag）と等価性をどう固定すべきか？
+
+求める回答:
+- identity（同一性）/比較/ログ表示の契約をどう置くのが安全か
+
+### Q5. finalizer/GC はどの層に置くべきか？（非目標を明確にする）
+
+求める回答:
+- まず “未対応を仕様として固定する” べき境界（VMのみ/LLVM未対応 等）
+
+## 2.1 “観測点” をどこに置くべきか（Q2の補足）
 
 目的は「weak_to_strong が成功する理由（strong root の残留）」を追えること。
 
@@ -171,3 +207,10 @@ Milestone D（implementation）:
 - runtime に root summary API を置くのが妥当か？
 
 5) 破綻しやすい罠（特に PHI/early return/cleanup）を列挙してほしい
+
+## 7. Done 条件（Phase 29y を “締める”）
+
+この相談パケットの完了条件は実装ではなく、次フェーズへ切れること。
+
+- docs が `lifecycle.md` と矛盾しない
+- 次に実装するタスクが **3つ以内**に分割されている（例: ABI固定 / RC挿入pass設計 / 診断SSOT）