docs: refine operation interfaces and batching

1-concept.md

@@ -18,7 +18,7 @@ Objectは、短いdescription、利用可能なOperation、子Object、必要に
 
 一般的なTool Callingでは、モデルは提示されたTool一覧から操作を選ぶ。
 
-WIPでは、モデルは既知のWorldspaceを辿り、目的に関連する対象を見つけ、公開されたOperationを確認して実行する。Operationの結果から未知のエントリやLinkを発見し、既知の世界へ追加できる。
+WIPでは、モデルは既知のWorldspaceを辿り、目的に関連する対象を見つけ、公開されたOperationを確認して実行する。Operation Resultの`entry`型から未知のpathを発見し、必要なものを取得してClientのKnown Spaceへ追加できる。
 
 中心となる問題を**Tool SelectionからWorld Explorationへ移す**ことがWIPの狙いである。
 
@@ -26,7 +26,7 @@ WIPでは、モデルは既知のWorldspaceを辿り、目的に関連する対
 
 Pathはidentityではなく、現在のWorldspace上の配置位置である。同一Objectが複数のエントリとして現れてもよい。
 
-親子関係は所有・内包を表す。所有関係にない意味的な関連はLinkとして扱い、Treeへ無理に押し込まない。
+親子関係は所有・内包を表す。所有関係にない意味的な関連は、それを表す名前付きOperationから関連エントリのpathを返し、Treeへ無理に押し込まない。
 
 Worldspace全体を事前にmaterializeする必要はない。Hostはlazy / virtualなTreeとして、必要な範囲だけを動的に公開できる。
 
@@ -36,27 +36,23 @@ WIPではObjectを受動的なJSON recordとして扱わない。
 
 本文を読む、metadataを取得する、検索する、状態を変更するといった行為はいずれもOperationとして表現する。例えばIssueであれば、`read_body()`、`get_metadata()`、`close(reason)`などを公開できる。
 
-Operationには、名前や型に加えて、用途を判断するための短いdescriptionを持たせる。長文documentationや大量のドメインデータをinterface metadataへ埋め込むことは想定しない。
+Operationには、名前や型に加えて、用途を判断するための短いdescriptionを持たせる。長文documentationや大量のドメインデータをInterfaceへ埋め込むことは想定しない。
+
+ObjectはOperation定義を直接埋め込まず、WIP IDLで記述されたInterfaceを参照する。一つのInterfaceに宣言された関数の集合がOperation一覧となり、複数のObjectが同じInterfaceを共有できる。
 
 ## 発見と既知世界
 
-Clientは、これまでに発見したエントリを既知のWorldspaceとして保持できる。既知のエントリはClient側で自由に辿り、Operation結果やLinkから得たエントリを追加して、さらに探索できる。
+Clientは、これまでに発見したエントリを既知のWorldspaceとして保持できる。既知のエントリはClient側で自由に辿り、Operation結果から得たエントリを追加して、さらに探索できる。
 
 機械的な広域探索の対象は、Hostがindexableとして公開した範囲に限定できる。これにより、大量の検索結果や動的Objectが自動的に探索indexへ流入することを防ぐ。
 
-## Guard
+## Operation Resultと新規発見
 
-Operationには、実行可否とpreconditionを示すGuardを持たせられる。
+OperationはHost背後の環境を変更し得るが、WIPはその状態遷移や変更差分をClientへ同期するprotocolではない。
 
-例えばPull Requestの`merge`について、「CIが成功していること」「Reviewが承認済みであること」「書き込み権限を持つこと」を提示できる。Guardはアクセス制御だけでなく、Goal達成に必要なSubgoalを推論する材料にもなる。
+Operation Resultは型付きの値であり、WIP IDLの`entry`型として、未観測だったエントリのpathを返せる。例えばRAG検索からResult群を発見したり、Agentへの問い合わせからConversationを発見したりできる。
 
-Guardの強制はLLMではなくHost / Runtime側で行う。
+Clientは必要に応じて返されたpathを取得し、変更後の状態を改めて観測する。
-
-## World State Transition
-
-Operationの結果は、単なるTool Responseに限らない。Worldspaceの状態変化や、新たなエントリの発見として表現できる。
-
-例えばRAG検索からResult群を発見したり、Agentへの問い合わせからConversationを発見したりできる。Operationは、Worldspaceを変化させ、未観測だった領域を可視化する行為でもある。
 
 ## Narrow Waist
 
@@ -64,6 +60,12 @@ WIPの目的は、Filesystem、GitHub、RAG、DBなどを一つの巨大APIへ
 
 任意のデジタル環境を共通のWorldspaceとして投影し、発見・観測・Operation実行という小さなInteraction Modelへ収束させる。Host内部のAPI、DB、RPC、永続化方式は規定せず、TransportもCore Protocolから分離する。
 
+## 状態管理の非目標
+
+WIPは、Host上の任意状態をClientへ同期するdata store protocolではない。Object propertyのreplication、change feed、reactive subscription、分散transaction、domain event deliveryはCore Protocolの規定対象外とする。
+
+Clientが保持するKnown SpaceとDiscoverable Spaceは、過去の観測から構成されたcacheであり、Host上の現在状態を同期したreplicaではない。HostがClientのcache状態を追跡または更新することを要求しない。Operationのauthorizationと実行条件はHostが実行時に評価する。
+
 ## Post-trainingとの仮説
 
 Tool Useが事後学習の対象になるなら、個別Tool名ではなくWorldspace上のinteraction policyを学習できる可能性がある。
@@ -71,8 +73,7 @@ Tool Useが事後学習の対象になるなら、個別Tool名ではなくWorld
 1. 既知の世界を探索する。
 2. 対象の意味とOperationを理解する。
 3. 必要ならOperationから未知のエントリを発見する。
-4. Guardやpreconditionを満たす。
+4. Operationを実行する。
-5. Operationを実行する。
+5. 必要ならOperation Resultやentry pathをもとに対象を再観測する。
-6. 変化・発見されたWorldspaceを再び観測する。
 
 最も強い仮説は、**未知のToolを使えるモデルではなく、未知のDigital Environmentを探索できるモデルを作れるのではないか**という点にある。

2-core-model.md

@@ -6,7 +6,7 @@ Worldspaceは、LLMが探索できる**ObjectのTree**として公開される
 
 WIPではObjectとエントリを別の構造として定義しない。**ObjectをWorldspaceのTree上の位置として扱うとき、そのObjectをエントリと呼ぶ。**
 
-したがって、ObjectはTree上で親子関係を持ち得るし、途中のNodeもそのまま操作対象になってよい。例えば`articles`はCollection Objectとして`query`等を公開でき、その配下に個別Articleが配置され得る。
+したがって、ObjectはTree上で親子関係を持ち得るし、途中のNodeもそのまま操作対象になってよい。例えば`articles`はCollection Objectとして、そのInterfaceに`query`等を宣言し、配下に個別Articleを配置できる。
 
 ## Object / エントリ
 
@@ -20,6 +20,14 @@ Tree上の位置はpathで表される。Pathは恒久的なIdentityではなく
 
 同じObjectが複数の位置に現れる場合、一つのObjectが複数のエントリとして観測され得る。
 
+## Interface
+
+ObjectはOperation定義を直接持たず、一つのInterfaceを参照する。
+
+Interfaceの実体は一つのWIP IDL documentであり、document内に宣言された関数の集合が、そのInterfaceのOperation集合となる。複数のObjectが同じInterfaceを共有できる。
+
+ObjectとInterfaceを分離することで、Collection内の多数の同種Objectに同じOperation定義を重複して持たせず、ClientがInterface定義を参照単位でcacheできる。
+
 ## `ref`
 
 Objectは必要に応じて`ref`を公開できる。
@@ -34,7 +42,9 @@ Objectは必要に応じて`ref`を公開できる。
 
 ## 観測整合性
 
-エントリ自体をObjectとは別実体として扱わなくても、**あるpath上のObjectを観測した後、操作を行うまでの間に、そのpathが別のObjectを指すようになってはならない**。
+エントリ自体をObjectとは別実体として扱う必要はない。ただし、あるpath上のObjectを観測した後、Operationを実行するまでの間に、そのpathが別のObjectを指すことはあり得る。
+
+その場合、Client / Runtimeは、以前のObjectを対象としたOperationを新しいObjectへ黙って適用してはならない。実行前に観測時の対応関係を検証し、変化していればOperationを中止する。この性質を**observation consistency**と呼ぶ。
 
 例えば、AIが`/issues/current`を観測した時点ではIssue Aだったが、`invoke`時にはIssue Bへ差し替わっていた場合、AIはIssue Aへ作用するつもりでIssue Bを操作してしまう可能性がある。
 

2.1-object-tree-schema.md

@@ -20,16 +20,24 @@ ObjectがTree上に配置されることでエントリとなり、pathはその
 
 ## 2.1.3 公開情報
 
-Object / エントリが公開する情報は、Worldspaceを探索し、対象に対して何ができるかを理解するための**interface metadata**である。
+Object / エントリが公開する情報は、Worldspaceを探索し、対象に対して何ができるかを理解するための最小限のmetadataである。
 
 現時点では、少なくとも次の情報を想定する。
 
 - `name` — Objectの短い名前。Tree上ではエントリ名としても用いられる。
 - `description` — Objectが何を表すかを説明する短い自然言語。長文documentationではなく、探索・判断に必要な最小限のsemantic metadataとする。
-- `operations` — Objectが公開するOperation。詳細は [2.2. Operation](2.2-operation.md) で定義する。
+- `interface` — Objectが実装するInterfaceへの参照。
 - `children` — Tree上でindexableとして公開される子Object / エントリ。
 - `ref` — 必要に応じて公開される、同一Objectを再参照するための外部Handle。
 
+Interfaceの実体は[WIP IDL](draft/wip-idl.md) documentである。IDL内に宣言された関数の集合が、そのInterfaceのOperation集合となる。ObjectはOperation定義を個別に埋め込まず、一つのInterface参照だけを持つ。
+
+複数のObjectが同じInterfaceを参照できる。これにより、Collectionから多数の同種エントリを取得する場合でも、Operation名、documentation、parameter、return typeを各エントリへ重複して送る必要がない。
+
+Interface参照は、HostがそのClientへ投影したInterfaceを識別する。同じObjectでも主体のroleや権限により異なるInterfaceを参照し得るが、頻繁に変化する実行可否を表すためには使用しない。
+
+ClientはInterface参照をcacheと比較し、未知のInterfaceだけを`fetch_interface`で取得する。HostはClientのcache状態を推測せず、ObjectのresponseへInterface定義を先行同梱しない。複数のInterface取得はTransport Bindingでbatchできる。
+
 WIPではドメインデータそのものをpropertiesとして直接公開することを前提としない。本文、metadata、状態などを読む行為もOperationとして表現する。
 
 ## 2.1.4 Tree
@@ -38,9 +46,9 @@ Worldspaceは、Objectが親子関係によって配置されたTreeとして観
 
 Tree上のObjectをエントリとして呼び、その位置をpathで表す。
 
-子エントリは所有・内包関係を表す。非内包の意味的関係はLinkとして扱う。
+子エントリは所有・内包関係を表す。非内包の意味的関係は、それを表すOperationから関連エントリのpathを返す。
 
-例えばRepository配下の`issues`は子エントリとして自然だが、Issueから関連Pull Requestへの参照はLinkとして表現する。
+例えばRepository配下の`issues`は子エントリとして自然だが、Issueから関連Pull Requestを得る場合は`get_related_pull_requests`のようなOperationで表現する。
 
 Treeはmaterializedな全世界ではなく、HostがそのClientに対して公開する**lazy / virtual tree**である。Hostは全Objectを事前保持する必要はなく、`fetch`や`fetch_tree`に応じて動的に解決してよい。
 
@@ -54,15 +62,9 @@ indexableな子エントリは、Worldspaceの構造理解に必要で、通常
 
 一方、大量のIssue、検索結果、一時的なObject群などはindexable childとして露出しない。必要なエントリはCollection Objectの`query` / `list`等のOperation結果として返す。
 
-## 2.1.6 Link
+Operation結果として返されることは、実行対象との親子関係を意味しない。Collectionの要素を返す場合だけでなく、親、兄弟、関連Objectなど、Worldspace内の別の位置にあるエントリを発見するためにもOperationを利用できる。
 
-LinkはTree上の所有・内包ではない意味的関係を表す。
+## 2.1.6 Core Protocolとの対応
-
-Linkによって未知のエントリが発見された場合、ClientはそのエントリをKnown Spaceへ追加できる。ただし、それだけではDiscoverable Spaceには追加しない。
-
-そのエントリを起点に`fetch_tree`を行い、indexableなTreeを取得した場合にのみ、その範囲をdiscover対象として扱える。
-
-## 2.1.7 Core Protocolとの対応
 
 `fetch(entry)`は、指定されたTree上の位置にあるObjectの公開情報を取得する。
 
@@ -70,4 +72,4 @@ Linkによって未知のエントリが発見された場合、Clientはその
 
 探索が`depth`または`limit`により打ち切られた場合は、レスポンスで`truncated`を必ず明示する。
 
-Operationを実行した結果として、新しいエントリ、エントリツリー、Linkが返る場合がある。Clientはそれらを構造化された発見結果としてKnown Spaceへ統合する。
+Operationを実行した結果には、WIP IDLの`entry`型として新しいエントリのpathが含まれる場合がある。Clientはそれらを一時的な発見結果として扱い、後続の参照に必要なものだけを取得してKnown Spaceへ統合できる。

2.2-operation.md

@@ -2,46 +2,65 @@
 
 ## 2.2.1 目的
 
-Operationは、Objectが外部へ公開する意味的な操作を表す。WIPではドメインデータをpropertiesとして常時露出するのではなく、読み取り・検索・更新を含む行為をOperationとして公開する。
+Operationは、Objectに対して実行できる操作を表す。
 
-## 2.2.2 基本形
+WIPでは、本文を読む、metadataを取得する、検索する、状態を変更するなど、Objectに対する行為をOperationとして公開する。
 
-Operationは少なくとも次の情報を持つ。
+## 2.2.2 Interface
 
-- `name` — Operationを識別する名前。
+ObjectはOperation定義を直接持たず、一つのInterfaceを参照する。
-- `description` — 何を行う操作かを説明する短い自然言語。
-- `input` — 呼び出し時に受け取る入力の型。
-- `output` — 呼び出し結果の型。
-- `guard` — 必要に応じて公開される実行条件・precondition。
 
-Operation名や型だけに意味を担わせず、`description`をinterface metadataの一部として扱う。長文documentationを埋め込むことは想定しない。
+Interfaceの定義は[WIP IDL](draft/wip-idl.md) documentそのものである。IDL documentに宣言された関数の集合が、そのInterfaceのOperation集合となる。Operation名、parameter、return type、短いdocumentationは一つの関数宣言としてまとめて定義し、別のOperation descriptorへ重複して記述しない。
 
-## 2.2.3 入出力型
+複数のObjectが同じInterfaceを参照できる。これにより、Collectionから多数の同種Objectを取得する場合でも、Operation定義を各Objectへ重複して埋め込む必要がない。
 
-Operationのinput / outputは、Wire Protocol上で機械的に検証・解釈できる構造化された型として定義する。
+HostはInterfaceについて、参照、IDLのlanguage identifier、source、およびcacheや同一性確認に利用できるdigestをClientへ提供する。ObjectはInterface参照だけを持ち、Clientは未知のInterface定義だけを取得してcacheできる。
 
-ただしWIPは任意のドメインデータをObjectのpropertiesとしてモデル化するものではない。ここでの型はOperation境界の値を記述するためのものである。
+## 2.2.3 Operation declaration
 
-具体的な型システム、primitive type、record / list / optional / union、ObjectやLinkを結果として返す場合の表現はこのページで定める。
+Operationは、WIP IDL内で関数形式により宣言する。
+
+```wip
+/// Returns items related to this Object.
+operation get_related_items(
+  relation: Relation,
+  limit?: integer,
+) -> {
+  items: [entry],
+  next_cursor?: string,
+};
+```
+
+Parameterは常に名前付きとし、位置引数は用いない。引数を持たないOperationは空のparameter list `()`で宣言する。
+
+```wip
+operation refresh() -> unit;
+```
+
+Return typeには任意のWIP IDL型を使用できる。ただし、将来fieldを追加する可能性があるOperationではrecordを基本とする。
+
+Operationの用途は`///` documentation commentで簡潔に説明する。長文documentationや大量のdomain dataをInterfaceへ埋め込むことは想定しない。
 
 ## 2.2.4 可視性
 
-Hostは、主体の権限やrole / capabilityに基づいて、その主体へ公開するOperation集合を決定してよい。
+Hostは、主体の権限やrole / capabilityに基づいて、その主体へ公開するInterfaceを決定してよい。
 
-Operationの可視性は、頻繁に変化する実行可否やdomain stateを表すものではなく、**その主体に対してどのinterfaceを公開するか**というprojectionとして扱う。
+Operationの可視性は、頻繁に変化する実行可否やdomain stateを表すものではなく、**その主体に対してどのInterfaceを公開するか**というprojectionとして扱う。
 
-例えばread-only主体には読み取り系Operationのみを公開し、maintainerやadminには追加の更新・管理Operationを公開できる。
+同じObjectでも、主体ごとに異なるInterface参照を返してよい。
 
-WIPはOperationの`available` / `disabled`のような揮発的状態をinterface metadataとして同期することを前提としない。現在の実行可否やpreconditionは、必要に応じてdomain固有のOperationで観測し、最終的なauthorizationや実行条件は`call_operation`時にHostが検証する。
+WIPはOperationの`available` / `disabled`のような揮発的状態をInterfaceへ同期することを前提としない。現在状態を判断する必要がある場合は、必要に応じてdomain固有のOperationで観測する。最終的なauthorizationと実行条件の判定は`call_operation`時にHostが行う。
 
-## 2.2.5 Guard
+## 2.2.5 Operation Result
 
-Guardを設ける場合は、現在時点のavailabilityを同期する仕組みではなく、Operationに一般的に課されるpreconditionやconstraintを説明するsemantic metadataとして扱う。
+`call_operation`は、対象ObjectのInterfaceに宣言されたOperation名と、parameter listに従う名前付きargumentsを受け取る。結果はOperationのreturn typeに従う型付きvalueとして返す。
 
-Guardの具体的schemaは未解決事項として管理する。
+Operation Resultには、WIP IDLの`entry`型として新しいエントリのpathが含まれ得る。
 
-## 2.2.6 Operation Result
+`entry`は同じWorldspace内のcanonical absolute pathであり、wire上では文字列として表現する。Clientはreturn typeに従って`entry`型の位置を認識し、返されたpathを一時的な発見結果として扱う。通常の`string`や任意JSON値に含まれるpathらしい文字列を、エントリとして推測してはならない。
 
-Operationの結果には通常の値だけでなく、新しいObject / エントリやLinkの発見が含まれ得る。
+Clientは発見したpathを必要に応じて`fetch`または`fetch_tree`する。複数pathの取得は、それぞれ独立したCore操作をTransport Bindingでbatchする。Operation Resultへエントリ公開情報を先行同梱しない。
 
-ClientがそれらをKnown Spaceへ統合できるよう、発見されたWorldspace要素は構造化された結果として表現する。
+Operationの実行対象と、結果として発見されたエントリのTree上の位置は独立している。発見されたエントリは実行対象の子である必要はなく、親、兄弟、またはWorldspace内の任意の位置にあるエントリであってよい。
+
+Operationがエントリpathを返したこと自体から、実行対象との間に親子関係や意味的関係を推論してはならない。親子関係はTree上の配置で表し、非内包の意味的関係はOperation名、resultのfield名、またはdomain固有のrelation型で表現する。

3-core-protocol.md

@@ -10,7 +10,7 @@ WIP上の主要な登場主体は**Client**と**Host**である。
 
 ClientはHostが提供するWorldspaceをユーザーまたはAIへ提示する。
 
-Hostから取得したエントリを既知の空間として保持・キャッシュし、`ref`によるObject同一性の追跡や、観測時と操作時の対応関係の検証を行う。
+Hostから取得したエントリとInterface定義を既知の空間として保持・キャッシュし、`ref`によるObject同一性の追跡や、観測時と操作時の対応関係の検証を行う。
 
 GUI、AI用Tools、PTC / REPL向けAPIなどへの投影はClient実装の責務とする。
 
@@ -18,7 +18,7 @@ GUI、AI用Tools、PTC / REPL向けAPIなどへの投影はClient実装の責務
 
 HostはClientに対して一つのWorldspaceを提供する。
 
-どのObject、エントリ、Operation、Guard、可視性を公開するかを決定し、そのClientから見えるWorldspaceを構成する。
+どのObject、エントリ、Interface、可視性を公開するかを決定し、そのClientから見えるWorldspaceを構成する。
 
 Host内部でGitHub API、Database、Filesystem、RAG、他Agent、別プロトコルなどをどう接続・集約するかはWIPの規定対象外とする。
 
@@ -32,11 +32,14 @@ ClientとHostの境界は通信境界であると同時に、ある主体へど
 
 ## 3.3 基本操作
 
-現時点では次の3操作をCore Protocolの基本とする。
+現時点では次の4操作をCore Protocolの基本とする。
 
-- `fetch(entry)` — 1つのエントリにあるObjectの公開情報を取得する。
+- `fetch(entry)` — 1つのエントリにあるObjectの公開情報とInterface参照を取得する。
 - `fetch_tree(entry, depth, limit)` — 指定エントリを起点に、indexableな子エントリを幅優先探索してエントリツリーとして取得する。
-- `call_operation(target, operation, input)` — Objectが公開するOperationを実行する。
+- `fetch_interface(interface)` — Interface参照からWIP IDL documentを取得する。
+- `call_operation(target, operation, arguments)` — Objectが参照するInterfaceに宣言されたOperationを実行する。
+
+Interfaceの定義は[WIP IDL](draft/wip-idl.md) documentそのものであり、そこに宣言された関数の集合がOperation一覧となる。`call_operation`の`arguments`は選択したOperationのparameter listに従う名前付きの型付き値であり、引数がない場合は空のrecordとする。Core Protocolはこの値をJSONに限定せず、Transport Bindingが具体的なencodingを定める。
 
 ## 3.4 `fetch_tree`
 
@@ -50,9 +53,15 @@ ClientとHostの境界は通信境界であると同時に、ある主体へど
 
 ## 3.5 Operation実行と発見
 
-`call_operation`の結果は単なる値に限らない。新しいエントリ、エントリツリー、Linkなどを返し得る。
+`call_operation`の結果は、選択したOperationのWIP IDL return typeに従う型付き値である。Return type上で`entry`として宣言された位置には、同じWorldspace内のエントリを指すcanonical absolute pathを返せる。
 
-ClientはOperation結果として発見したエントリを既知の空間へ統合し、そこからさらにWorldspaceを探索できる。
+Clientはreturn typeに従って`entry`型の位置を認識する。通常の`string`や任意JSONに含まれるpathらしい文字列を、エントリとして推測してはならない。
+
+返されたエントリpathのTree上の位置はOperationの実行対象から独立しており、実行対象の子に限定されない。Operationの実行対象と返されたエントリの間に、暗黙の親子関係や意味的関係を作ってはならない。
+
+ClientはOperation結果として発見したpathを一時的に扱い、必要なものを`fetch`または`fetch_tree`して既知の空間へ統合できる。
+
+複数の`fetch`または`fetch_interface`は、Core Protocol上ではそれぞれ独立した操作である。Transport Bindingは、個別に実行した場合と同じ意味を保ったまま、Clientが選択した複数の操作を一つのrequestへbatchしてよい。HostがClientの既知状態を推測して追加情報を先行同梱することはCore Protocolの一部としない。
 
 ## 3.6 Transportとの分離
 

4-client.md

@@ -2,29 +2,52 @@
 
 ## 役割
 
-Clientは、Hostが提供するWorldspaceをユーザーへ提示する実装主体である。WIPのCore Protocolを直接利用しつつ、用途に応じたViewやAPIへ投影する。
+Clientは、Hostが提供するWorldspaceをユーザーへ提示する実装主体である。WIPのCore Protocolを直接利用しつつ、Objectが参照するInterfaceを解決し、用途に応じたViewやAPIへ投影する。
 
-ClientはHostから得た情報をそのまま一時表示するだけでなく、これまでに発見したエントリを保持し、ユーザーから見た**既知の空間**を構成する。
+ClientはHostから得た情報をそのまま一時表示するだけでなく、rootからindexable edgeを辿って構成したエントリツリーと、必要に応じて選択したエントリを保持し、ユーザーから見た**既知の空間**を構成する。
 
 ## Known Space
 
-Clientは、これまでに発見したエントリをKnown Spaceとして保持・キャッシュしてよい。
+Known Spaceは、Clientが**現在保持しているエントリの集合**である。過去に発見したすべてのエントリを単調に蓄積する集合ではない。
 
-Known Spaceには、次のような経路で得られたエントリが含まれる。
+Known SpaceとDiscoverable SpaceはClientが過去の観測から構築したcacheであり、Host上の現在状態を同期したreplicaではない。HostはClientのcache状態を追跡または更新しない。
+
+次のような経路で得られたエントリをKnown Spaceへ追加できる。
 
 - `fetch`または`fetch_tree`で取得したエントリ
-- Operationの結果として返されたエントリまたはエントリツリー
+- Operation結果の`entry`型pathを`fetch`して取得したエントリ
-- Operation結果に含まれるLinkから発見したエントリ
+
+Operationを通して発見されたpathは、必ずしもKnown Spaceへ追加する必要はない。Clientは現在の結果として一時的に扱うことも、取得後に必要なエントリだけを選択して保持することもできる。
 
 既知エントリ間の移動や参照はClient側で処理できる。既知の空間を辿るたびにHostへ問い合わせる必要はない。
 
+## Interface cache
+
+Objectの公開情報はOperation定義を直接含まず、Interface参照を持つ。Clientは未知のInterface参照を`fetch_interface`で解決し、取得したWIP IDL documentを参照ごとにcacheする。
+
+一つのInterface documentに宣言された関数の集合が、そのInterfaceのOperation一覧である。複数のObjectが同じInterfaceを参照する場合、ClientはIDLを一度だけ取得・parseすればよい。
+
+ClientはInterface cacheとObjectのInterface参照を比較し、未知のInterfaceだけを取得する。複数の`fetch_interface`は、Transport Bindingが提供するbatchを利用してまとめてよい。
+
 ## Discoverable Space
 
-Clientは、Hostから`fetch_tree`で取得したindexableなエントリツリーをDiscoverable Spaceとして保持してよい。
+Clientは、Hostから`fetch_tree`で取得したindexableなエントリツリーをDiscoverable Spaceとして保持する。Discoverable Spaceとして扱う間、Clientはそのtreeの構造を保持する必要がある。
 
-Discoverable SpaceはKnown Spaceの部分集合であり、AI向け`discover`などの機械的探索に利用する。
+Discoverable SpaceはKnown Spaceの部分集合であり、AI向け`discover`などの機械的探索に利用する。Worldspace rootまたはClientが選択した起点からindexable edgeで到達できる、materialize済みの範囲によって構成される。
 
-OperationやLinkを通して偶発的に発見されたエントリはKnown Spaceには追加されるが、それだけではDiscoverable Spaceには追加しない。そのエントリを起点として`fetch_tree`を取得した場合に、そのindexableな範囲をDiscoverable Spaceへ追加できる。
+Clientが`fetch_tree`を再実行した結果、以前存在した親のindexable edgeが返されなくなった場合、その子エントリをDiscoverable Spaceから除外する。その結果、保持しているどの起点からも到達不能になったsubtreeは、その場で破棄できる。ただし、別の経路から到達できるエントリ、Clientがpinしたエントリ、実行中のOperationが参照しているエントリは引き続き保持してよい。
+
+Operationを通して発見されたpathは、それだけではDiscoverable Spaceへ追加しない。そのエントリを起点として`fetch_tree`を取得した場合に、そのindexableな範囲をDiscoverable Spaceへ追加できる。
+
+## 一時的な発見とpin
+
+Clientは、Operation Resultの`entry`型として発見したpathを現在の結果として一時的に扱える。標準的なClientはOperationのreturn typeからentry pathを抽出して重複を除去し、Known Spaceと比較して必要なpathだけを取得する。複数の`fetch`はTransport Bindingが提供するbatchを利用してまとめてよい。
+
+一時的に取得したエントリは、結果の利用が終わった時点で破棄してよい。
+
+後続のInteractionでも必要なエントリは、Client側でpinしてKnown Spaceへ保持できる。PinはClient内部の保持方針であり、Host上のObject lifetimeやCore Protocol上の状態を変更しない。
+
+単純なClientは発見したエントリをすべて保持してもよいが、WIPはそれを必須としない。具体的な容量制限やeviction algorithmはClient実装に委ねる。
 
 ## Tree取得
 

4.1-ai-tools-example.md

@@ -10,27 +10,28 @@ AI用Toolsは、WIP ClientがAIへ提供する想定インターフェースで
 
 `discover(scope, query)` は、Clientが保持するDiscoverable Spaceから目的に関連するエントリを探す。
 
-検索対象は、Hostから`fetch_tree`によって取得されたindexableなエントリ公開情報に限定する。OperationやLinkによって新たに発見されたエントリはKnown Spaceには追加されるが、それだけでは`discover`の検索対象にはならない。
+検索対象は、Hostから`fetch_tree`によって取得されたindexableなエントリ公開情報に限定する。Operationによって新たに発見されたentry pathは、一時的な結果として扱うか、取得してKnown Spaceへ保持できるが、それだけでは`discover`の検索対象にはならない。
 
 `discover`はドメインデータを検索する操作ではない。Issue本文やRAG corpusなどを検索する場合は、その能力を持つObjectのOperationを`invoke`する。
 
 ## `inspect`
 
-`inspect(target)` は、対象エントリ / Objectについて**何ができるか**を把握するための操作である。
+`inspect(target)` は、対象エントリ / Objectについて**何ができるか**を把握するための操作である。ClientはObjectのInterface参照を解決し、WIP IDL documentに宣言されたOperationを提示する。
 
 Objectのドメインデータをpropertiesとして直接公開することは前提としない。データを読む行為もOperationとして表現する。
 
 例えばIssueでは、次のような操作が示され得る。
 
 - `read_body()` — 本文を読む。
-- `get_metadata()` — 期日、担当者、ラベル、関連ObjectへのLinkなどを取得する。
+- `get_metadata()` — 期日、担当者、ラベルなどを取得する。
+- `get_related_items()` — 関連Objectのentry pathを取得する。
 - `close(reason: string)` — 理由を添えてIssueをクローズする。
 
-Operationはシグネチャだけでなく、AIが用途を判断できる短いdescriptionを持つ。長文ドキュメントを埋め込むことは想定しない。
+Operationの関数宣言と短いdocumentationは、Objectが参照する[WIP IDL](draft/wip-idl.md) documentから取得する。ClientはIDLをparseし、利用するAI providerが要求するTool schemaへ変換する。JSON Schema等への変換はAI向けClient adapterの責務であり、HostがWIP Interfaceとして提供する必要はない。
 
 ## `invoke`
 
-`invoke(target, operation, input)` は、`inspect`によって発見したOperationを実行する。
+`invoke(target, operation, arguments)` は、`inspect`によって発見したOperationを実行する。`arguments`はOperationのWIP IDL parameter listに従う名前付きfieldのrecordであり、位置引数は用いない。引数を持たないOperationには空のrecordを渡す。
 
 PTC / REPL bindingでは、通常のメソッド呼び出しへ投影してよい。
 
@@ -46,13 +47,12 @@ AIが新しいエントリを知る経路は複数ある。
 
 - `discover`によってDiscoverable Spaceから見つける。
 - Known Space上の既知エントリを辿る。
-- Operationの結果としてエントリまたはエントリツリーを受け取る。
+- Operation Resultの`entry`型としてpathを受け取る。
-- Operation結果に含まれるLinkから別エントリを知る。
 
-新たに発見されたエントリの保持、Treeへの統合、indexableな範囲の管理はClientの責務とし、このページではAI向けToolの意味論だけを扱う。
+ClientはOperation Resultからentry pathを抽出し、必要なpathを`fetch`または`fetch_tree`する。新たに取得したエントリの保持、Treeへの統合、indexableな範囲の管理はClientの責務とし、このページではAI向けToolの意味論だけを扱う。
 
 ## ドメイン検索
 
 全文検索、semantic retrieval、外部API検索などはWIP固有のToolにはしない。
 
-検索能力を持つObjectが`query`や`search`などのOperationを公開し、AIはそれを`invoke`する。結果としてエントリやエントリツリーが返された場合、それらはClientを通して新たなKnown Spaceとして利用可能になる。
+検索能力を持つObjectのInterfaceが`query`や`search`などのOperationを宣言し、AIはそれを`invoke`する。結果として`entry`型のpathが返された場合、Clientは必要なpathを取得し、一時的な発見結果として利用するかKnown Spaceへ保持できる。

draft/unresolved-issues.md

@@ -6,19 +6,31 @@
 
 対象: [2.1. Object tree / Schema](../2.1-object-tree-schema.md)
 
-- Object / エントリ公開情報の具体的なwire schema。
+- Object / エントリ公開情報とInterface参照の具体的なwire schema。
 - `name`とpath segmentの関係。
-- `description`の長さや必須性をprotocol上でどこまで規定するか。
+- entry pathのcanonicalization規則。
-- Linkの標準表現。
+- Object `description`の長さや必須性をprotocol上でどこまで規定するか。
-- Operation Result内でエントリ / エントリツリー / Linkをどう統一的に表現するか。
 
-## 2.2. Operation
+## 2.2. Operation / WIP IDL
 
-対象: [2.2. Operation](../2.2-operation.md)
+対象: [2.2. Operation](../2.2-operation.md)、[WIP IDL](wip-idl.md)
 
-- input / outputに使う型システム。
+- WIP IDL sourceのcanonicalization、digest algorithm、Interface参照の形式とscope。
-- `description`の必須性と長さ。
+- WIP IDLのversion間における互換性規則。
-- optional / union / enum / record等の表現。
+- String length、numeric range、pattern等のconstraintを導入するか。
-- Object / Linkを値として返す場合の標準表現。
+- Recursive named typeを許可するか。
-- Guardの具体的schema。
+- `i64`、`u64`、`bigint`、`decimal`等を追加するか。
-- error型をOperation outputに含めるか、Protocol errorとして分離するか。
+- Operation documentationの必須性と長さ。
+- Effect annotationを採用するか、および構文と標準effectの集合。
+- `fail<E>`を採用する場合のdomain failure表現。
+- domain errorをOperationのreturn typeに含めるか、Protocol errorとして分離するか。
+
+## WIP over HTTPS
+
+対象: [WIP over HTTPS](wip-over-https.md)
+
+- `fetch_interface`のrequest / response wire schema。
+- Effect annotationを採用した場合に、副作用のない`call_operation`をbatch対象へ加えるか。
+- Batch件数、request / response byte size、timeoutの上限。
+- Batch envelope自体が不正な場合のHTTP statusとerror body。
+- Subrequest共通のProtocol error schema。

draft/wip-idl.md

@@ -0,0 +1,335 @@
+# WIP IDL
+
+WIP IDLは、Objectが実装するInterfaceを記述するための小さなinterface definition languageである。
+
+一つのWIP IDL documentが一つのInterfaceを定義する。Documentに宣言された関数の集合が、そのInterfaceのOperation集合となる。Operation名、parameter、return type、documentationはIDL内の一つの宣言としてまとめ、別のOperation descriptorへ重複して記述しない。
+
+WIP IDLのsourceそのものをInterface定義のcanonicalな交換形式とする。HostとClientの間でJSON SchemaやIDLを変換したJSON ASTを交換することは前提としない。Clientはsourceをparseして内部表現を構築し、必要に応じてAI Tool schemaやGUI formへ投影する。
+
+この文書では、WIP IDLの初期文法と型を定義する。
+
+## 設計方針
+
+- 一つのdocumentで一つのInterfaceを定義する。
+- Document内のOperation declarationを、そのInterfaceのOperation一覧とする。
+- Operationを関数として、parameterとreturn typeを一体で表現する。
+- 文法を小さく保ち、一般的なschema validation languageにはしない。
+- Wire上の値表現はTransport Bindingが定める。
+- JSON SchemaはWIPの交換形式にせず、必要なClientが生成する。
+- Worldspaceのエントリは、そのpathを表す`entry`型として扱う。
+
+## Source
+
+WIP IDL sourceはUTF-8 textとする。ASCII space、tab、LFによる空白は、tokenを分離する場合を除いて意味を持たない。
+
+`//`から行末までは通常のcommentとし、parserは無視する。
+
+`///`から行末まではdocumentation commentとする。Operationまたはtype declarationの直前に連続するdocumentation commentは、そのdeclarationのdocumentationとしてparserが保持する。
+
+```wip
+/// Returns entries related to the target Object.
+operation get_related_items() -> {
+  items: [entry],
+};
+```
+
+IdentifierはASCIIの英字または`_`で始まり、以降にASCIIの英数字または`_`を含められる。
+
+```text
+identifier = (ALPHA | "_") { ALPHA | DIGIT | "_" };
+```
+
+Keyword、primitive type名、Worldspace固有型名はidentifierとして使用できない。
+
+Named typeにはUpperCamelCase、Operation、parameter、field、enum case、union caseにはsnake_caseを使用する。
+
+## Grammar
+
+以下のEBNFは空白とcommentを省略して示す。
+
+```ebnf
+document = { declaration } ;
+
+declaration = [ documentation ],
+              ( type-declaration | operation-declaration ) ;
+
+documentation = doc-comment, { doc-comment } ;
+
+type-declaration = "type", type-name, "=", type-definition, ";" ;
+
+type-definition = type-expression | enum-type | union-type ;
+
+operation-declaration =
+  "operation", identifier,
+  "(", [ parameter, { ",", parameter }, [ "," ] ], ")",
+  "->", type-expression, ";" ;
+
+parameter = identifier, [ "?" ], ":", type-expression ;
+
+type-expression =
+    primitive-type
+  | worldspace-type
+  | type-name
+  | record-type
+  | list-type ;
+
+record-type =
+  "{", [ record-field, { ",", record-field }, [ "," ] ], "}" ;
+
+record-field = identifier, [ "?" ], ":", type-expression ;
+
+list-type = "[", type-expression, "]" ;
+
+enum-type =
+  "enum", "{", identifier, { ",", identifier }, [ "," ], "}" ;
+
+union-type =
+  "union", "{", union-case, { ",", union-case }, [ "," ], "}" ;
+
+union-case = identifier, [ "(", type-expression, ")" ] ;
+
+primitive-type =
+    "unit"
+  | "boolean"
+  | "integer"
+  | "number"
+  | "string"
+  | "bytes"
+  | "json" ;
+
+worldspace-type = "entry" ;
+
+type-name = identifier ;
+```
+
+同じdocument内でtype名またはOperation名を重複して宣言してはならない。同じOperation内でparameter名を重複してはならない。Named typeは同じdocument内で宣言されたtypeを参照する。
+
+## Primitive types
+
+| Type | 意味 | WIP over HTTPSでの表現 | 制約 |
+| --- | --- | --- | --- |
+| `unit` | 値を持たない | JSON `null` | Optional parameter / fieldの省略とは区別する |
+| `boolean` | 真偽値 | JSON boolean | — |
+| `integer` | 符号付き整数 | 小数部を持たないJSON number | `-9007199254740991`以上、`9007199254740991`以下 |
+| `number` | IEEE 754 binary64値 | JSON number | NaN、positive infinity、negative infinityは不可 |
+| `string` | Unicode string | JSON string | — |
+| `bytes` | 任意のoctet列 | RFC 4648 Section 4のbase64を格納したJSON string | paddingを含む |
+| `json` | opaqueな任意のJSON value | JSON value | Clientは内部構造をschemaとして解釈しない |
+
+`integer`の範囲は、異なる言語のClient間で正確に交換できる範囲に制限している。この範囲を超える整数は`integer`としてencodeしない。`i64`、`u64`、`bigint`等の追加型とlosslessなwire表現は将来の拡張として扱う。
+
+`json`は外部APIの応答など構造を事前に固定できない値のためのescape hatchであり、通常のOperationではより具体的な型を優先する。
+
+## Composite types
+
+| Type | 構文 | 意味 | WIP over HTTPSでの表現 |
+| --- | --- | --- | --- |
+| Record | `{ field: Type }` | 名前付きfieldの集合 | JSON object |
+| List | `[Type]` | 同じ型の順序付き値 | JSON array |
+| Named type | `type Name = Type;` | 型への名前付け | 参照先と同じ表現 |
+| Enum | `enum { first, second }` | payloadを持たないcaseの集合 | case名のJSON string |
+| Union | `union { case(Type), empty }` | discriminatorを持つcaseの集合 | `$case`を持つJSON object |
+
+### Record
+
+Recordは名前付きfieldの集合である。
+
+```wip
+type QueryResult = {
+  items: [entry],
+  next_cursor?: string,
+};
+```
+
+`?`を持たないfieldはrequired、`?`を持つfieldはoptionalである。Optionalはparameterまたはrecord fieldにのみ適用し、一般化しない。
+
+WIP over HTTPSではrecordをJSON objectとしてencodeする。Optional fieldに値がない場合はfield自体を省略する。FieldをJSON `null`にすることは省略と同じ意味ではなく、そのfieldの型が`unit`または`json`として`null`を許す場合に限る。
+
+宣言されていないfieldをrecordに含めてはならない。
+
+### List
+
+Listは同じ型の0個以上の順序付き値を表す。
+
+```wip
+[entry]
+```
+
+WIP over HTTPSではJSON arrayとしてencodeする。
+
+### Named type
+
+`type`宣言によって型へ名前を付けられる。
+
+```wip
+type IssueList = [entry];
+```
+
+Aliasを参照する値のwire表現は、参照先の型と同じである。
+
+### Enum
+
+Enumはpayloadを持たないcaseの集合である。
+
+```wip
+type Relation = enum {
+  parent,
+  sibling,
+  related,
+};
+```
+
+WIP over HTTPSではcase名をJSON stringとしてencodeする。
+
+```json
+"sibling"
+```
+
+### Union
+
+Unionはdiscriminatorを持つcaseの集合である。Caseは0個または1個のpayloadを持つ。
+
+```wip
+type LookupResult = union {
+  found(entry),
+  not_found,
+  ambiguous([entry]),
+};
+```
+
+WIP over HTTPSでは`$case` discriminatorを持つJSON objectとしてencodeする。Payloadを持つcaseは`value` fieldに値を格納する。
+
+```json
+{
+  "$case": "found",
+  "value": "/items/123"
+}
+```
+
+Payloadを持たないcaseには`value`を含めない。
+
+```json
+{
+  "$case": "not_found"
+}
+```
+
+## Worldspace type
+
+| Type | 意味 | WIP over HTTPSでの表現 |
+| --- | --- | --- |
+| `entry` | 同じWorldspace内のエントリを指すcanonical absolute path | JSON string |
+
+```json
+"/items/123"
+```
+
+Wire上では通常の`string`と同じ表現だが、WIP IDL上で`entry`と宣言された位置にある値だけをClientがエントリとして認識する。通常の`string`やopaqueな`json`に含まれるpathらしい文字列を、Clientがエントリとして推測してはならない。
+
+Operation Resultから`entry`を発見したClientは、そのpathを一時的に利用し、必要に応じて`fetch`または`fetch_tree`する。複数のpathを効率的に取得する場合は、Clientが必要なpathを選択した後、Transport Bindingが提供するbatchを利用する。Operation Resultへエントリ公開情報を先行同梱しない。
+
+Operationが返したpathは、Operationの実行対象の子に限定されない。親、兄弟、関連Objectなど、Worldspace内の任意のエントリを指してよい。Operationの実行対象と返されたpathの間に、暗黙のTree edgeや意味的関係を推論してはならない。
+
+`fetch`が返すエントリ公開情報と、`fetch_tree`が返すindexableなtreeはCore Protocolのresponseであり、WIP IDLの値型としては定義しない。
+
+## Operation declarations
+
+Operationは名前付きparameterとreturn typeを一つの関数宣言として定義する。
+
+```wip
+type Relation = enum {
+  parent,
+  sibling,
+  related,
+};
+
+/// Returns entries related to the target Object.
+operation get_related_items(
+  relation: Relation,
+  limit?: integer,
+) -> {
+  items: [entry],
+  next_cursor?: string,
+};
+```
+
+Operationのparameterは、WIP over HTTPSでは一つのJSON objectへencodeする。Parameter名がobjectのfield名になる。位置引数は定義しない。
+
+引数を持たないOperationは空のparameter listで宣言し、空のJSON objectをargumentsとして渡す。
+
+```wip
+operation refresh() -> unit;
+```
+
+Return typeには任意のtype expressionまたはNamed typeを使用できる。ただし、将来fieldを追加する可能性があるOperationではrecordを推奨する。
+
+`///` documentation commentは、AIやユーザーがOperationの用途を判断するための短いdescriptionとして扱う。長文documentationをIDLへ埋め込むことは想定しない。
+
+## Effect annotation（検討案）
+
+Operationがdomain-levelな副作用や失敗を発生させ得ることを、関数宣言上のeffect rowとして表す案を検討する。この節は確定仕様ではなく、前掲のEBNFにもまだ含めない。
+
+構文は、return typeの後に`! { ... }`を付ける形を候補とする。
+
+```wip
+operation get_item(
+  id: string,
+) -> Item ! {};
+
+operation update_item(
+  id: string,
+  value: Item,
+) -> Item ! {
+  write,
+  fail<UpdateError>,
+};
+```
+
+| Annotation | 意味の候補 |
+| --- | --- |
+| `! {}` | 宣言上、domain-levelな副作用およびfailureを持たない |
+| `write` | 外部から観測可能な副作用を発生させ得る |
+| `fail<E>` | `E`型のdomain failureを返し得る |
+| annotationなし | Effect情報が未指定 |
+
+Network error、authorization失敗、target消失、Protocol decode errorなど、すべてのremote callで起こり得るProtocol errorは`fail<E>`に含めない。`fail<E>`はOperation固有のdomain failureだけを表す候補とする。
+
+Effect annotationは、ClientによるOperationの説明や、HTTP batchへ安全に含められるOperationの判定材料として利用できる可能性がある。ただし、具体的なbatch可否規則はまだ確定しない。
+
+この案はKokaのeffect rowやUnisonのability requirementのように、関数が起こし得るeffectをsignatureへ表す記法を参考にしている。ただしWIP IDLへ導入するのは宣言上のannotationだけであり、effect handler、`perform`、continuation、resume、handlerへのnetwork転送、algebraic effect runtimeは導入しない。
+
+## Interface identity and sharing
+
+一つのWIP IDL documentが一つのInterfaceを定義する。ObjectはOperation定義ではなく、そのInterfaceへの参照を持つ。
+
+複数のObjectが同じInterface参照を共有できる。Clientは未知のInterfaceだけを`fetch_interface`で取得し、参照ごとにIDL sourceとparse済み表現をcacheできる。
+
+Hostは主体のroleや権限に応じて異なるOperation集合を投影する場合、異なるWIP IDL documentとInterface参照を返してよい。Interfaceは頻繁に変化するOperationの実行可否を表すものではない。
+
+Interface参照をcontent-addressed digestにすることが想定されるが、参照形式、sourceのcanonicalization、digest algorithmはTransport Bindingで定義する。
+
+## Interface exchange
+
+HostはInterfaceについて、少なくとも次をClientへ提供する。
+
+| 項目 | 内容 |
+| --- | --- |
+| Interface reference | Objectが保持し、`fetch_interface`の対象となる参照 |
+| Language identifier | 初期versionは`wip-idl/1` |
+| Source | WIP IDL source |
+| Digest | Cacheと同一性確認に利用するdigest |
+
+交換されるInterface定義の正本はWIP IDL sourceである。HostはJSON SchemaやIDL ASTを併記する必要はない。
+
+ClientはIDLを内部ASTへparseし、必要に応じてAI provider用JSON Schema、GUI form、言語固有の型などを生成できる。
+
+ClientはObjectのInterface参照をcacheと比較し、未知のInterfaceだけを`fetch_interface`する。複数のInterface取得はTransport Bindingでbatchできる。HostはClientのcache状態を推測せず、ObjectのresponseへInterface定義を先行同梱しない。
+
+## 未解決事項
+
+- Sourceのcanonicalizationとdigestの厳密な計算方法。
+- Interface参照の具体的な形式とscope。
+- String length、numeric range、pattern等のconstraintを導入するか。
+- Recursive named typeを許可するか。
+- `i64`、`u64`、`bigint`、`decimal`等を追加するか。
+- `entry`が参照するpathのcanonicalization規則。

draft/wip-over-https.md

@@ -8,11 +8,11 @@ Core Protocolの意味論を変えずに、既存のWebインフラを利用し
 
 ## 方針
 
-標準bindingとしてHTTPSを採用することを第一候補とする。
+初期の標準bindingはHTTPS上のrequest / responseのみを規定する。TLS、認証、Proxy、Gateway、Observability、Caching、connection reuse、multiplexing、compression等の既存機構を利用してよいが、特定のHTTP versionや実装方式を必須にしない。
 
-HTTPSを利用することで、TLS、認証、Proxy、Gateway、Observability、Caching、Streamingなど既存の仕組みを再利用できる。
+OperationがWebSocket等のendpointを通常のdomain valueとして返すことは妨げない。そのendpoint上のprotocol、状態、lifecycleはWIPの規定対象外であり、ClientとHost固有実装の責務とする。
 
-必要に応じてHTTP/2、HTTP/3、SSE、WebSocket等を利用してよい。ただし、これらは通信上の最適化または補助機構であり、WIP Core Protocolの意味論を変更しない。
+双方向socket transportをWIP bindingとして標準化する場合は、将来の独立した拡張として定義する。
 
 ## Binding対象
 
@@ -20,9 +20,133 @@ HTTPSを利用することで、TLS、認証、Proxy、Gateway、Observability
 
 - `fetch`
 - `fetch_tree`
+- `fetch_interface`
 - `call_operation`
 
-具体的なHTTP method、endpoint、content type、error mapping、認証方式、streaming表現などは、このbinding仕様側で定義する。
+具体的なHTTP method、endpoint、content type、error mapping、認証方式、batch表現などは、このbinding仕様側で定義する。
+
+## Interfaceの取得
+
+Objectの公開情報はOperation定義を直接含まず、[WIP IDL](wip-idl.md) documentで定義されたInterfaceへの参照を持つ。`fetch_interface`は、その参照に対応するInterfaceのlanguage identifier、source、digestを返す。
+
+HTTPS response全体をJSON envelopeにする場合、IDL sourceをJSON stringとして格納してよい。ただし、これはIDLをJSON ASTへ変換するものではない。BindingはIDL sourceを専用resourceおよびcontent typeで直接取得する方法を定義してもよい。
+
+ClientはObjectのInterface参照をcacheと比較し、未知のInterfaceだけを`fetch_interface`する。HostはClientのcache状態を推測せず、`fetch`や`fetch_tree`のresponseへInterface定義を先行同梱しない。複数のInterface取得はHTTP batchingでまとめられる。
+
+## Operation valueのJSON encoding
+
+WIP over HTTPSでは、`call_operation`のargumentsとresultを、選択したOperation declarationに従うJSON valueとしてencodeする。JSONはHTTPS binding上の値表現であり、WIP CoreのInterface定義形式ではない。
+
+`arguments`はOperationのparameter名をfield名とするJSON objectとする。位置引数は用いず、引数を持たないOperationには空のobjectを渡す。
+
+概念的なrequest bodyは次の形になる。
+
+```json
+{
+  "target": "/items/current",
+  "operation": "get_related_item",
+  "arguments": {
+    "relation": "sibling",
+    "limit": 10
+  }
+}
+```
+
+IDL型からJSONへのmappingはbindingで一意に定める。少なくとも次の規則を持つ。
+
+- `boolean`、`string`、`number`、record、listは対応するJSON valueで表す。
+- optionalなparameterまたはrecord fieldはfieldの省略で表し、`null`とは区別する。
+- unit形式のenumはstring、payloadを持つunionは明示的なdiscriminatorを持つobjectで表す。
+- `bytes`はbase64でencodeしたstringとして表す。
+- 通常のJSON numberで表す`integer`は相互運用可能な安全範囲に制限する。それを超える整数型を設ける場合はdecimal string等のlosslessな表現を定義する。
+- WIP IDLの`entry`は、同じWorldspace内のcanonical absolute pathをJSON stringとして表す。
+
+ClientはWIP IDLに従ってvalueをdecodeし、IDL上で`entry`と宣言された位置にある文字列だけをエントリとして認識する。通常の`string`や任意JSON値に含まれるpathらしい文字列を、エントリとして推測してはならない。
+
+## HTTP batching
+
+WIP over HTTPSは、複数の独立したCore取得requestを一つのHTTP requestへまとめるbatch形式を提供する。Batchingは通信上のpackagingであり、Core Protocolへ新しい操作や意味論を追加しない。
+
+Clientは、Known SpaceとInterface cacheをもとに必要なrequestだけを選択してbatchを構成する。HostはClientの既知状態を推測して、要求されていないentry公開情報やInterface定義をresponseへ追加しない。
+
+Batch endpointは概念的に`POST {wip-endpoint}/batch`とし、bodyに一意な`id`を持つsubrequestの配列を格納する。
+
+```json
+{
+  "requests": [
+    {
+      "id": "entry-123",
+      "method": "fetch",
+      "arguments": {
+        "entry": "/items/123"
+      }
+    },
+    {
+      "id": "entry-456",
+      "method": "fetch",
+      "arguments": {
+        "entry": "/items/456"
+      }
+    },
+    {
+      "id": "item-interface",
+      "method": "fetch_interface",
+      "arguments": {
+        "interface": "sha256:item-interface"
+      }
+    }
+  ]
+}
+```
+
+Hostは各subrequestを、単独で受け取った場合と同じ規則で処理する。Responseは同じ`id`で対応付けたsubresponseの配列を返す。
+
+```json
+{
+  "responses": [
+    {
+      "id": "entry-123",
+      "result": {
+        "name": "123",
+        "description": "First item",
+        "interface": "sha256:item-interface"
+      }
+    },
+    {
+      "id": "entry-456",
+      "error": {
+        "code": "not_found",
+        "message": "Entry not found"
+      }
+    },
+    {
+      "id": "item-interface",
+      "result": {
+        "interface": "sha256:item-interface",
+        "language": "wip-idl/1",
+        "digest": "sha256:item-interface",
+        "source": "..."
+      }
+    }
+  ]
+}
+```
+
+Batchには次の規則を適用する。
+
+- Request内の`id`は一意なstringとする。
+- Responseの順序に意味を持たせず、`id`でcorrelateする。
+- 各subrequestは独立して成功または失敗し、一つの失敗によって他のresultを破棄しない。
+- Batch全体はtransactionではなく、atomicity、共通snapshot、実行順序を保証しない。
+- Hostはsubrequestを直列または並列に実行してよい。
+- Subrequest間で、先行requestのresultを後続requestのargumentsとして参照できない。
+- 各`result`は対応するCore操作を単独で呼んだ場合と同じvalueとする。
+- 各`error`は通常のProtocol errorと同じschemaを使用する。
+- HostはClientが要求していないsubresponseを追加してはならない。
+
+初期のbatch形式に格納できるのは`fetch`、`fetch_tree`、`fetch_interface`とし、`call_operation`は含めない。将来、WIP IDLのEffect annotationを採用する場合に、副作用を持たないと明示されたOperationをbatch対象へ加えるかを改めて検討する。
+
+Batch件数、request / response byte size、timeoutの上限、およびbatch envelope自体が不正な場合のHTTP statusはbindingの詳細として定める。
 
 ## 非目標