init

1-concept.md

@@ -0,0 +1,78 @@
+# 1. コンセプト
+
+## 背景
+
+現在のLLMエージェントは、Filesystem、検索、Issue Tracker、データベース、外部API、他のAgentなどを、それぞれ別個のToolとして扱うことが多い。統合先が増えるほど、モデルに提示するTool SchemaとAction Spaceも増えていく。
+
+Unix filesystemは、異なる資源を単一の名前空間へ配置し、少数の操作で探索できる強い抽象化を持つ。一方、file / directoryとread / write中心の操作だけでは、`Issue.close()`、`PullRequest.merge()`、`Agent.ask()`のような意味的操作を自然に表現しにくい。
+
+## 中心アイデア
+
+WIPは、任意のデジタル環境を一つの**Worldspace**として公開する。
+
+WorldspaceはObjectのTreeとして構成される。本書では、Tree上に配置され、Pathで到達できるObjectを**エントリ**と呼ぶ。Objectとエントリは別スキーマではない。
+
+Objectは、短いdescription、利用可能なOperation、子Object、必要に応じて`ref`を公開できる。本文やmetadataなどのドメインデータは常時露出せず、Operationを通して取得・操作することを基本とする。
+
+## Tool DiscoveryではなくWorld Discovery
+
+一般的なTool Callingでは、モデルは提示されたTool一覧から操作を選ぶ。
+
+WIPでは、モデルは既知のWorldspaceを辿り、目的に関連する対象を見つけ、公開されたOperationを確認して実行する。Operationの結果から未知のエントリやLinkを発見し、既知の世界へ追加できる。
+
+中心となる問題を**Tool SelectionからWorld Explorationへ移す**ことがWIPの狙いである。
+
+## Worldspaceの構造
+
+Pathはidentityではなく、現在のWorldspace上の配置位置である。同一Objectが複数のエントリとして現れてもよい。
+
+親子関係は所有・内包を表す。所有関係にない意味的な関連はLinkとして扱い、Treeへ無理に押し込まない。
+
+Worldspace全体を事前にmaterializeする必要はない。Hostはlazy / virtualなTreeとして、必要な範囲だけを動的に公開できる。
+
+## 操作中心のモデル
+
+WIPではObjectを受動的なJSON recordとして扱わない。
+
+本文を読む、metadataを取得する、検索する、状態を変更するといった行為はいずれもOperationとして表現する。例えばIssueであれば、`read_body()`、`get_metadata()`、`close(reason)`などを公開できる。
+
+Operationには、名前や型に加えて、用途を判断するための短いdescriptionを持たせる。長文documentationや大量のドメインデータをinterface metadataへ埋め込むことは想定しない。
+
+## 発見と既知世界
+
+Clientは、これまでに発見したエントリを既知のWorldspaceとして保持できる。既知のエントリはClient側で自由に辿り、Operation結果やLinkから得たエントリを追加して、さらに探索できる。
+
+機械的な広域探索の対象は、Hostがindexableとして公開した範囲に限定できる。これにより、大量の検索結果や動的Objectが自動的に探索indexへ流入することを防ぐ。
+
+## Guard
+
+Operationには、実行可否とpreconditionを示すGuardを持たせられる。
+
+例えばPull Requestの`merge`について、「CIが成功していること」「Reviewが承認済みであること」「書き込み権限を持つこと」を提示できる。Guardはアクセス制御だけでなく、Goal達成に必要なSubgoalを推論する材料にもなる。
+
+Guardの強制はLLMではなくHost / Runtime側で行う。
+
+## World State Transition
+
+Operationの結果は、単なるTool Responseに限らない。Worldspaceの状態変化や、新たなエントリの発見として表現できる。
+
+例えばRAG検索からResult群を発見したり、Agentへの問い合わせからConversationを発見したりできる。Operationは、Worldspaceを変化させ、未観測だった領域を可視化する行為でもある。
+
+## Narrow Waist
+
+WIPの目的は、Filesystem、GitHub、RAG、DBなどを一つの巨大APIへ統合することではない。
+
+任意のデジタル環境を共通のWorldspaceとして投影し、発見・観測・Operation実行という小さなInteraction Modelへ収束させる。Host内部のAPI、DB、RPC、永続化方式は規定せず、TransportもCore Protocolから分離する。
+
+## Post-trainingとの仮説
+
+Tool Useが事後学習の対象になるなら、個別Tool名ではなくWorldspace上のinteraction policyを学習できる可能性がある。
+
+1. 既知の世界を探索する。
+2. 対象の意味とOperationを理解する。
+3. 必要ならOperationから未知のエントリを発見する。
+4. Guardやpreconditionを満たす。
+5. Operationを実行する。
+6. 変化・発見されたWorldspaceを再び観測する。
+
+最も強い仮説は、**未知のToolを使えるモデルではなく、未知のDigital Environmentを探索できるモデルを作れるのではないか**という点にある。

2-core-model.md

@@ -0,0 +1,61 @@
+# 2. コアモデル
+
+## 基本構造
+
+Worldspaceは、LLMが探索できる**ObjectのTree**として公開される。
+
+WIPではObjectとエントリを別の構造として定義しない。**ObjectをWorldspaceのTree上の位置として扱うとき、そのObjectをエントリと呼ぶ。**
+
+したがって、ObjectはTree上で親子関係を持ち得るし、途中のNodeもそのまま操作対象になってよい。例えば`articles`はCollection Objectとして`query`等を公開でき、その配下に個別Articleが配置され得る。
+
+## Object / エントリ
+
+**Object**はWIP上で観測・操作される対象そのものである。
+
+**エントリ**は、そのObjectをTree上の位置として見たときの呼び名である。
+
+エントリがObjectへの参照を別途持つ、という二重構造は前提としない。
+
+Tree上の位置はpathで表される。Pathは恒久的なIdentityではなく、その時点でのnavigation coordinateである。
+
+同じObjectが複数の位置に現れる場合、一つのObjectが複数のエントリとして観測され得る。
+
+## `ref`
+
+Objectは必要に応じて`ref`を公開できる。
+
+`ref`は内部IDそのものではなく、WIP上で同一Objectとして再参照するための外部Handleである。
+
+- Objectが`ref`を持つことは必須ではない。
+- 複数回のInteractionを通して同一Objectとして扱われることを意図する場合、同じ有効な`ref`を公開する。
+- `ref`のscopeや有効期間はWorldspaceまたは実装が定めてよい。
+- `ref`はグローバルかつ永続的なUIDである必要はない。
+- 同じObjectが複数のエントリとして観測される場合、同じ`ref`によって同一性を示せる。
+
+## 観測整合性
+
+エントリ自体をObjectとは別実体として扱わなくても、**あるpath上のObjectを観測した後、操作を行うまでの間に、そのpathが別のObjectを指すようになってはならない**。
+
+例えば、AIが`/issues/current`を観測した時点ではIssue Aだったが、`invoke`時にはIssue Bへ差し替わっていた場合、AIはIssue Aへ作用するつもりでIssue Bを操作してしまう可能性がある。
+
+この観測整合性は利用者に追跡させるのではなく、クライアントの責務とする。
+
+処理の流れは次の通り。
+
+1. Clientがpath上のObjectを観測する。
+2. Clientはその時点のpathとObjectの対応を内部的に記録する。
+3. モデルは観測したObjectについて推論する。
+4. モデルが同じpathを対象に操作を要求した場合、Client / Runtimeは実行前に対応関係が変化していないことを検証する。
+
+実装はETagやgeneration、opaque token等の内部メタデータを用いてよいが、それらを利用者へ露出する必要はない。
+
+対応関係が変化していた場合、Clientは新しいObjectに対して操作を自動的に再試行してはならない。操作を中止し、`target_changed`のような意味的エラーを返して再観測を要求する。
+
+## 同一性と観測整合性の分離
+
+WIPでは次の2つを分けて扱う。
+
+- **Object identity (`ref`)**: 複数の観測にまたがって同一Objectであることを明示するための任意の外部Handle。
+- **Observation consistency**: `ref`の有無に関わらず、観測したpath上のObjectと操作対象のObjectが一致していることをClient / Runtimeが保証する仕組み。
+
+したがって、`ref`を持たないObjectであっても安全な操作対象になり得る。`ref`は同一性を公開する仕組みであり、Observation consistencyは操作の安全性を担保する仕組みである。

2.1-object-tree-schema.md

@@ -0,0 +1,73 @@
+# 2.1. Object tree / Schema
+
+## 2.1.1 目的
+
+このページでは、WIP Core ModelにおけるObject treeと、それらをClientへ公開する際の最小スキーマを整理する。
+
+WIPでは、**Objectとエントリを別のデータ構造として定義しない**。ObjectをWorldspaceのTree上に配置されたものとして扱うとき、そのObjectをエントリと呼ぶ。
+
+## 2.1.2 Objectとエントリ
+
+**Object**はWIP上で観測・操作される対象そのものである。
+
+**エントリ**は、そのObjectをWorldspaceのTree上の位置として見たときの呼び名である。
+
+したがって、エントリがObjectへの参照を別途保持する、あるいはエントリ schemaとObject schemaを二重に定義することは前提としない。
+
+ObjectがTree上に配置されることでエントリとなり、pathはその配置位置を表すnavigation coordinateとなる。
+
+同じObjectが複数の位置に現れる場合、一つのObjectが複数のエントリとして観測され得る。
+
+## 2.1.3 公開情報
+
+Object / エントリが公開する情報は、Worldspaceを探索し、対象に対して何ができるかを理解するための**interface metadata**である。
+
+現時点では、少なくとも次の情報を想定する。
+
+- `name` — Objectの短い名前。Tree上ではエントリ名としても用いられる。
+- `description` — Objectが何を表すかを説明する短い自然言語。長文documentationではなく、探索・判断に必要な最小限のsemantic metadataとする。
+- `operations` — Objectが公開するOperation。詳細は [2.2. Operation](2.2-operation.md) で定義する。
+- `children` — Tree上でindexableとして公開される子Object / エントリ。
+- `ref` — 必要に応じて公開される、同一Objectを再参照するための外部Handle。
+
+WIPではドメインデータそのものをpropertiesとして直接公開することを前提としない。本文、metadata、状態などを読む行為もOperationとして表現する。
+
+## 2.1.4 Tree
+
+Worldspaceは、Objectが親子関係によって配置されたTreeとして観測される。
+
+Tree上のObjectをエントリとして呼び、その位置をpathで表す。
+
+子エントリは所有・内包関係を表す。非内包の意味的関係はLinkとして扱う。
+
+例えばRepository配下の`issues`は子エントリとして自然だが、Issueから関連Pull Requestへの参照はLinkとして表現する。
+
+Treeはmaterializedな全世界ではなく、HostがそのClientに対して公開する**lazy / virtual tree**である。Hostは全Objectを事前保持する必要はなく、`fetch`や`fetch_tree`に応じて動的に解決してよい。
+
+## 2.1.5 Indexable children
+
+子エントリには、機械的探索で辿ってよいものと、Operationによってのみ発見されるものがある。
+
+`fetch_tree`が辿るのは**indexableとして公開された子エントリのみ**とする。
+
+indexableな子エントリは、Worldspaceの構造理解に必要で、通常は件数が小さいものを想定する。
+
+一方、大量のIssue、検索結果、一時的なObject群などはindexable childとして露出しない。必要なエントリはCollection Objectの`query` / `list`等のOperation結果として返す。
+
+## 2.1.6 Link
+
+LinkはTree上の所有・内包ではない意味的関係を表す。
+
+Linkによって未知のエントリが発見された場合、ClientはそのエントリをKnown Spaceへ追加できる。ただし、それだけではDiscoverable Spaceには追加しない。
+
+そのエントリを起点に`fetch_tree`を行い、indexableなTreeを取得した場合にのみ、その範囲をdiscover対象として扱える。
+
+## 2.1.7 Core Protocolとの対応
+
+`fetch(entry)`は、指定されたTree上の位置にあるObjectの公開情報を取得する。
+
+`fetch_tree(entry, depth, limit)`は、指定エントリからindexable child edgeだけを幅優先探索し、Treeとしてまとめて返す。
+
+探索が`depth`または`limit`により打ち切られた場合は、レスポンスで`truncated`を必ず明示する。
+
+Operationを実行した結果として、新しいエントリ、エントリツリー、Linkが返る場合がある。Clientはそれらを構造化された発見結果としてKnown Spaceへ統合する。

2.2-operation.md

@@ -0,0 +1,47 @@
+# 2.2. Operation
+
+## 2.2.1 目的
+
+Operationは、Objectが外部へ公開する意味的な操作を表す。WIPではドメインデータをpropertiesとして常時露出するのではなく、読み取り・検索・更新を含む行為をOperationとして公開する。
+
+## 2.2.2 基本形
+
+Operationは少なくとも次の情報を持つ。
+
+- `name` — Operationを識別する名前。
+- `description` — 何を行う操作かを説明する短い自然言語。
+- `input` — 呼び出し時に受け取る入力の型。
+- `output` — 呼び出し結果の型。
+- `guard` — 必要に応じて公開される実行条件・precondition。
+
+Operation名や型だけに意味を担わせず、`description`をinterface metadataの一部として扱う。長文documentationを埋め込むことは想定しない。
+
+## 2.2.3 入出力型
+
+Operationのinput / outputは、Wire Protocol上で機械的に検証・解釈できる構造化された型として定義する。
+
+ただしWIPは任意のドメインデータをObjectのpropertiesとしてモデル化するものではない。ここでの型はOperation境界の値を記述するためのものである。
+
+具体的な型システム、primitive type、record / list / optional / union、ObjectやLinkを結果として返す場合の表現はこのページで定める。
+
+## 2.2.4 可視性
+
+Hostは、主体の権限やrole / capabilityに基づいて、その主体へ公開するOperation集合を決定してよい。
+
+Operationの可視性は、頻繁に変化する実行可否やdomain stateを表すものではなく、**その主体に対してどのinterfaceを公開するか**というprojectionとして扱う。
+
+例えばread-only主体には読み取り系Operationのみを公開し、maintainerやadminには追加の更新・管理Operationを公開できる。
+
+WIPはOperationの`available` / `disabled`のような揮発的状態をinterface metadataとして同期することを前提としない。現在の実行可否やpreconditionは、必要に応じてdomain固有のOperationで観測し、最終的なauthorizationや実行条件は`call_operation`時にHostが検証する。
+
+## 2.2.5 Guard
+
+Guardを設ける場合は、現在時点のavailabilityを同期する仕組みではなく、Operationに一般的に課されるpreconditionやconstraintを説明するsemantic metadataとして扱う。
+
+Guardの具体的schemaは未解決事項として管理する。
+
+## 2.2.6 Operation Result
+
+Operationの結果には通常の値だけでなく、新しいObject / エントリやLinkの発見が含まれ得る。
+
+ClientがそれらをKnown Spaceへ統合できるよう、発見されたWorldspace要素は構造化された結果として表現する。

3-core-protocol.md

@@ -0,0 +1,63 @@
+# 3. Core Protocol
+
+WIP Core Protocolは、ClientとHostの間でWorldspaceを観測・操作するための**transport-independentな意味論**を定義する。
+
+## 3.1 役割
+
+WIP上の主要な登場主体は**Client**と**Host**である。
+
+### Client
+
+ClientはHostが提供するWorldspaceをユーザーまたはAIへ提示する。
+
+Hostから取得したエントリを既知の空間として保持・キャッシュし、`ref`によるObject同一性の追跡や、観測時と操作時の対応関係の検証を行う。
+
+GUI、AI用Tools、PTC / REPL向けAPIなどへの投影はClient実装の責務とする。
+
+### Host
+
+HostはClientに対して一つのWorldspaceを提供する。
+
+どのObject、エントリ、Operation、Guard、可視性を公開するかを決定し、そのClientから見えるWorldspaceを構成する。
+
+Host内部でGitHub API、Database、Filesystem、RAG、他Agent、別プロトコルなどをどう接続・集約するかはWIPの規定対象外とする。
+
+## 3.2 規定範囲
+
+Core Protocolが規定するのは、ClientがHostからWorldspaceを観測し、操作するための契約である。
+
+特定のデータソース構成、内部RPC、永続化方式、Adapter構成、同期方式は規定しない。
+
+ClientとHostの境界は通信境界であると同時に、ある主体へどのWorldspaceを公開するかを決める信頼境界として扱える。
+
+## 3.3 基本操作
+
+現時点では次の3操作をCore Protocolの基本とする。
+
+- `fetch(entry)` — 1つのエントリにあるObjectの公開情報を取得する。
+- `fetch_tree(entry, depth, limit)` — 指定エントリを起点に、indexableな子エントリを幅優先探索してエントリツリーとして取得する。
+- `call_operation(target, operation, input)` — Objectが公開するOperationを実行する。
+
+## 3.4 `fetch_tree`
+
+`fetch_tree`は、Clientが機械的探索のために多数の`fetch`を連打することを避けるための操作である。
+
+探索対象はindexableな子エントリのみとし、幅優先探索（BFS）で辿る。Clientは探索深度`depth`と返却エントリ総数の上限`limit`を指定できる。
+
+探索が`depth`または`limit`によって途中で終了した場合、レスポンスは`truncated`であることを必ず明示する。Clientは取得結果を完全なツリーと誤認してはならない。
+
+件数が非常に多いCollectionの個々の要素は、通常indexableな子エントリとして自然露出させない。必要な要素はCollection Objectの`query`や`list`等のOperationによって発見する。
+
+## 3.5 Operation実行と発見
+
+`call_operation`の結果は単なる値に限らない。新しいエントリ、エントリツリー、Linkなどを返し得る。
+
+ClientはOperation結果として発見したエントリを既知の空間へ統合し、そこからさらにWorldspaceを探索できる。
+
+## 3.6 Transportとの分離
+
+Core ProtocolはHTTP、TCP、WebSocketなど特定のtransportを要求しない。
+
+通信方式への具体的な対応付けはTransport Bindingとして別に定義する。標準bindingは`WIP over HTTPS`で扱う。
+
+この分離により、Worldspaceの意味論と通信方式を独立して進化させる。

4-client.md

@@ -0,0 +1,61 @@
+# 4. クライアント
+
+## 役割
+
+Clientは、Hostが提供するWorldspaceをユーザーへ提示する実装主体である。WIPのCore Protocolを直接利用しつつ、用途に応じたViewやAPIへ投影する。
+
+ClientはHostから得た情報をそのまま一時表示するだけでなく、これまでに発見したエントリを保持し、ユーザーから見た**既知の空間**を構成する。
+
+## Known Space
+
+Clientは、これまでに発見したエントリをKnown Spaceとして保持・キャッシュしてよい。
+
+Known Spaceには、次のような経路で得られたエントリが含まれる。
+
+- `fetch`または`fetch_tree`で取得したエントリ
+- Operationの結果として返されたエントリまたはエントリツリー
+- Operation結果に含まれるLinkから発見したエントリ
+
+既知エントリ間の移動や参照はClient側で処理できる。既知の空間を辿るたびにHostへ問い合わせる必要はない。
+
+## Discoverable Space
+
+Clientは、Hostから`fetch_tree`で取得したindexableなエントリツリーをDiscoverable Spaceとして保持してよい。
+
+Discoverable SpaceはKnown Spaceの部分集合であり、AI向け`discover`などの機械的探索に利用する。
+
+OperationやLinkを通して偶発的に発見されたエントリはKnown Spaceには追加されるが、それだけではDiscoverable Spaceには追加しない。そのエントリを起点として`fetch_tree`を取得した場合に、そのindexableな範囲をDiscoverable Spaceへ追加できる。
+
+## Tree取得
+
+Clientは、機械的にエントリを探索する必要がある場合、個別の`fetch`を多数発行するのではなく`fetch_tree`を利用する。
+
+`fetch_tree`では起点エントリ、探索深度`depth`、返却エントリ総数の上限`limit`を指定する。Hostはindex edgeを幅優先探索してTreeを返す。
+
+レスポンスが`truncated`である場合、Clientは取得したTreeが完全ではないことを保持し、完全な空間として扱ってはならない。
+
+件数の非常に多いCollectionの個々の要素は、通常indexableな子エントリとして露出しない。個別要素はCollection Objectの`query`や`list`等のOperationを通して発見することを想定する。
+
+## Objectの同一性
+
+Objectが`ref`を公開している場合、Clientはそれを用いて複数のエントリや複数回の観測が同一Objectを指していることを追跡できる。
+
+`ref`はHost内部のIDそのものとは限らず、WIP上でObjectを再参照するための外部Handleとして扱う。
+
+## 観測整合性
+
+Clientは、エントリを観測した後にOperationを実行するまでの間に、そのエントリが別Objectを指すようになっていないことを検証する責務を持つ。
+
+この検証に必要なopaque token、generation、ETag等はClient / Host間で透過的に扱い、AIやユーザーに直接管理させる必要はない。
+
+対象が変化していた場合、Clientは新しいObjectに対してOperationを自動再試行せず、対象が変化したことを上位インターフェースへ通知して再観測を要求する。
+
+## 想定実装
+
+Clientは用途に応じて複数の上位インターフェースを提供できる。
+
+- GUI上のWorldspace View
+- AI向けTools
+- PTC / REPL向けスクリプティングAPI
+
+これらは同一のKnown Space、Discoverable Space、Object identity、観測整合性管理を共有してよい。

4.1-ai-tools-example.md

@@ -0,0 +1,58 @@
+# 4.1. 例：AI用Tools
+
+## 目的
+
+AI用Toolsは、WIP ClientがAIへ提供する想定インターフェースである。Core Protocolをそのまま露出せず、Clientが保持するKnown Space / Discoverable Spaceと組み合わせて、AIがWorldspaceを理解・探索・操作しやすい形へ投影する。
+
+現時点では、**discover / inspect / invoke** の3操作を基本とする。
+
+## `discover`
+
+`discover(scope, query)` は、Clientが保持するDiscoverable Spaceから目的に関連するエントリを探す。
+
+検索対象は、Hostから`fetch_tree`によって取得されたindexableなエントリ公開情報に限定する。OperationやLinkによって新たに発見されたエントリはKnown Spaceには追加されるが、それだけでは`discover`の検索対象にはならない。
+
+`discover`はドメインデータを検索する操作ではない。Issue本文やRAG corpusなどを検索する場合は、その能力を持つObjectのOperationを`invoke`する。
+
+## `inspect`
+
+`inspect(target)` は、対象エントリ / Objectについて**何ができるか**を把握するための操作である。
+
+Objectのドメインデータをpropertiesとして直接公開することは前提としない。データを読む行為もOperationとして表現する。
+
+例えばIssueでは、次のような操作が示され得る。
+
+- `read_body()` — 本文を読む。
+- `get_metadata()` — 期日、担当者、ラベル、関連ObjectへのLinkなどを取得する。
+- `close(reason: string)` — 理由を添えてIssueをクローズする。
+
+Operationはシグネチャだけでなく、AIが用途を判断できる短いdescriptionを持つ。長文ドキュメントを埋め込むことは想定しない。
+
+## `invoke`
+
+`invoke(target, operation, input)` は、`inspect`によって発見したOperationを実行する。
+
+PTC / REPL bindingでは、通常のメソッド呼び出しへ投影してよい。
+
+```python
+issue.close(reason="duplicate")
+```
+
+ClientはエントリをObjectへ解決し、WIPの`call_operation`を利用して実行する。Object同一性やエントリとObjectの観測整合性はClient側で処理し、AI自身に追跡させない。
+
+## エントリの発見
+
+AIが新しいエントリを知る経路は複数ある。
+
+- `discover`によってDiscoverable Spaceから見つける。
+- Known Space上の既知エントリを辿る。
+- Operationの結果としてエントリまたはエントリツリーを受け取る。
+- Operation結果に含まれるLinkから別エントリを知る。
+
+新たに発見されたエントリの保持、Treeへの統合、indexableな範囲の管理はClientの責務とし、このページではAI向けToolの意味論だけを扱う。
+
+## ドメイン検索
+
+全文検索、semantic retrieval、外部API検索などはWIP固有のToolにはしない。
+
+検索能力を持つObjectが`query`や`search`などのOperationを公開し、AIはそれを`invoke`する。結果としてエントリやエントリツリーが返された場合、それらはClientを通して新たなKnown Spaceとして利用可能になる。

draft/unresolved-issues.md

@@ -0,0 +1,24 @@
+# 未解決事項
+
+各設計ページに未解決事項を分散させず、このページで対象ページとともに一元管理する。
+
+## 2.1. Object tree / Schema
+
+対象: [2.1. Object tree / Schema](../2.1-object-tree-schema.md)
+
+- Object / エントリ公開情報の具体的なwire schema。
+- `name`とpath segmentの関係。
+- `description`の長さや必須性をprotocol上でどこまで規定するか。
+- Linkの標準表現。
+- Operation Result内でエントリ / エントリツリー / Linkをどう統一的に表現するか。
+
+## 2.2. Operation
+
+対象: [2.2. Operation](../2.2-operation.md)
+
+- input / outputに使う型システム。
+- `description`の必須性と長さ。
+- optional / union / enum / record等の表現。
+- Object / Linkを値として返す場合の標準表現。
+- Guardの具体的schema。
+- error型をOperation outputに含めるか、Protocol errorとして分離するか。

draft/wip-over-https.md

@@ -0,0 +1,29 @@
+# WIP over HTTPS
+
+WIP over HTTPSは、**WIP Core ProtocolをHTTPS上へ対応付ける標準Transport Binding**である。
+
+## 目的
+
+Core Protocolの意味論を変えずに、既存のWebインフラを利用してClientとHostを接続する。
+
+## 方針
+
+標準bindingとしてHTTPSを採用することを第一候補とする。
+
+HTTPSを利用することで、TLS、認証、Proxy、Gateway、Observability、Caching、Streamingなど既存の仕組みを再利用できる。
+
+必要に応じてHTTP/2、HTTP/3、SSE、WebSocket等を利用してよい。ただし、これらは通信上の最適化または補助機構であり、WIP Core Protocolの意味論を変更しない。
+
+## Binding対象
+
+少なくとも、Core Protocolの以下の操作をHTTP request / responseへ対応付ける。
+
+- `fetch`
+- `fetch_tree`
+- `call_operation`
+
+具体的なHTTP method、endpoint、content type、error mapping、認証方式、streaming表現などは、このbinding仕様側で定義する。
+
+## 非目標
+
+WIP over HTTPSはHost内部のAPIやデータソース接続方式を規定しない。また、WIP Core ProtocolそのものをHTTP依存のモデルへ変えることも目的としない。