Trim open issues to materialization

doc/manual/souce/open-issues.md

@@ -1,60 +1,23 @@
 # 未確定事項
 
 今後決める必要がある事項を管理する。
-詳細化するときは、各項目を該当する仕様ファイルへ移動または反映する。
+実装または仕様方針が固まった項目は、該当する仕様ファイルへ反映してここから外す。
 
-## 構文
+## Materialize target and host projection
 
-- 正式な字句・構文仕様。
-- 演算子の優先順位。
-- `rec` の扱い。
-- コメント構文を `#` のみにするか。
+Decodal の評価結果は、制約・default・関数値を含む中間値になり得る。
+そのため、Decodal 単独で常に「最終成果物」を一意に決めるのではなく、host 側が期待する型や出力形式を与えて materialize / decode する経路を明確にする必要がある。
 
-## 型・制約
+決めること:
 
-- 配列要素の制約表現。
-- object の open/closed schema の扱い。
-- 正規表現を必須機能にするか optional feature にするか。
-- 代表的な組み込み述語の範囲。
+- Rust API で評価結果の field/path を選択して decode / materialize できるようにするか。
+- `decodal-derive` の struct schema と評価結果を合成して decode する経路を、主要な materialize path として位置づけるか。
+- CLI / WASM では target path を指定して JSON-compatible value へ materialize する形にするか。
+- 制約や関数値が残った値を出力したい場合、materialize ではなく inspect/debug API として分けるか。
 
-## default
+現時点の案:
 
-- `default` 同士の conflict 解決規則。
-- `&` による default 合成の厳密な規則。
-- `//` による default 置換の厳密な規則。
-- default thunk の評価失敗をどの段階で報告するか。
-
-## 演算子
-
-- `//` による制約・default の置換詳細。
-- `replace(...)` を採用するか、別構文を設けるか。
-- 配列に対する patch 操作を右辺置換だけにするか。
-- 配列 append / prepend / remove などを提供するか。
-
-## 関数
-
-- 関数値の最終出力可否。
-- 再帰関数を許可するか。
-- 関数同士の `&` の扱い。
-- 関数値の等価性。
-- 関数呼び出し結果の memoize 範囲。
-
-## 評価
-
-- thunk のエラー memoize 方針。
-- import cache の単位。
-- 循環 import の診断メッセージ。
-- materialize 対象の範囲指定方法。
-
-## match
-
-- match の網羅性チェックを行うか。
-- 到達不能分岐を警告するか。
-- パターン構文の範囲。
-
-## エラー処理
-
-- optional import を導入するか。
-- optional field access を導入するか。
-- optional fallback が捕捉できる失敗の範囲。
-- エラー報告に制約由来の説明をどこまで含めるか。
+- Rust では `evaluate -> select field/path -> expected schema と合成 -> decode` を主経路にする。
+- CLI / WASM では、明示された target path または module 全体を JSON-compatible value として materialize する。
+- materialize できない unresolved abstract value、default のない制約値、関数値は diagnostic にする。
+- Decodal 言語内には materialize 構文を追加せず、host API / CLI / WASM の責務として扱う。