docs: simplify WIP interaction model

1-concept.md

@@ -18,7 +18,7 @@ Objectは、短いdescription、利用可能なOperation、子Object、必要に
 
 一般的なTool Callingでは、モデルは提示されたTool一覧から操作を選ぶ。
 
-WIPでは、モデルは既知のWorldspaceを辿り、目的に関連する対象を見つけ、公開されたOperationを確認して実行する。Operationの結果から未知のエントリを発見し、既知の世界へ追加できる。
+WIPでは、モデルは既知のWorldspaceを辿り、目的に関連する対象を見つけ、公開されたOperationを確認して実行する。Operation Resultの`entry`型から未知のpathを発見し、必要なものを取得してClientのKnown Spaceへ追加できる。
 
 中心となる問題を**Tool SelectionからWorld Explorationへ移す**ことがWIPの狙いである。
 
@@ -44,19 +44,13 @@ Clientは、これまでに発見したエントリを既知のWorldspaceとし
 
 機械的な広域探索の対象は、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 +58,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 +71,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

@@ -34,7 +34,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.2-operation.md

@@ -12,7 +12,6 @@ Operationは少なくとも次の情報を持つ。
 - `description` — 何を行う操作かを説明する短い自然言語。
 - `input` — 呼び出し時に受け取る入力の型。
 - `output` — 呼び出し結果の型。
-- `guard` — 必要に応じて公開される実行条件・precondition。
 
 Operation名や型だけに意味を担わせず、`description`をinterface metadataの一部として扱う。長文documentationを埋め込むことは想定しない。
 
@@ -36,15 +35,9 @@ Operationの可視性は、頻繁に変化する実行可否やdomain stateを
 
 例えばread-only主体には読み取り系Operationのみを公開し、maintainerやadminには追加の更新・管理Operationを公開できる。
 
-WIPはOperationの`available` / `disabled`のような揮発的状態をinterface metadataとして同期することを前提としない。現在の実行可否やpreconditionは、必要に応じてdomain固有のOperationで観測し、最終的なauthorizationや実行条件は`call_operation`時にHostが検証する。
+WIPはOperationの`available` / `disabled`のような揮発的状態をinterface metadataとして同期することを前提としない。現在状態を判断する必要がある場合は、必要に応じてdomain固有のOperationで観測する。最終的なauthorizationと実行条件の判定は`call_operation`時にHostが行う。
 
-## 2.2.5 Guard
+## 2.2.5 Operation Result
-
-Guardを設ける場合は、現在時点のavailabilityを同期する仕組みではなく、Operationに一般的に課されるpreconditionやconstraintを説明するsemantic metadataとして扱う。
-
-Guardの具体的schemaは未解決事項として管理する。
-
-## 2.2.6 Operation Result
 
 Operationの結果には、通常のdomain valueに加えて、WIP IDLの`entry`型として新しいエントリのpathが含まれ得る。
 

3-core-protocol.md

@@ -18,7 +18,7 @@ GUI、AI用Tools、PTC / REPL向けAPIなどへの投影はClient実装の責務
 
 HostはClientに対して一つのWorldspaceを提供する。
 
-どのObject、エントリ、Operation、Guard、可視性を公開するかを決定し、そのClientから見えるWorldspaceを構成する。
+どのObject、エントリ、Operation、可視性を公開するかを決定し、そのClientから見えるWorldspaceを構成する。
 
 Host内部でGitHub API、Database、Filesystem、RAG、他Agent、別プロトコルなどをどう接続・集約するかはWIPの規定対象外とする。
 

4-client.md

@@ -10,6 +10,8 @@ ClientはHostから得た情報をそのまま一時表示するだけでなく
 
 Known Spaceは、Clientが**現在保持しているエントリの集合**である。過去に発見したすべてのエントリを単調に蓄積する集合ではない。
 
+Known SpaceとDiscoverable SpaceはClientが過去の観測から構築したcacheであり、Host上の現在状態を同期したreplicaではない。HostはClientのcache状態を追跡または更新しない。
+
 次のような経路で得られたエントリをKnown Spaceへ追加できる。
 
 - `fetch`または`fetch_tree`で取得したエントリ
@@ -25,7 +27,7 @@ Clientは、Hostから`fetch_tree`で取得したindexableなエントリツリ
 
 Discoverable SpaceはKnown Spaceの部分集合であり、AI向け`discover`などの機械的探索に利用する。Worldspace rootまたはClientが選択した起点からindexable edgeで到達できる、materialize済みの範囲によって構成される。
 
-Treeの再取得やHostからの更新によって親のindexable edgeが削除された場合、その子エントリはDiscoverable Spaceから除外する。その結果、保持しているどの起点からも到達不能になったsubtreeは、その場で破棄できる。ただし、別の経路から到達できるエントリ、Clientがpinしたエントリ、実行中のOperationが参照しているエントリは引き続き保持してよい。
+Clientが`fetch_tree`を再実行した結果、以前存在した親のindexable edgeが返されなくなった場合、その子エントリをDiscoverable Spaceから除外する。その結果、保持しているどの起点からも到達不能になったsubtreeは、その場で破棄できる。ただし、別の経路から到達できるエントリ、Clientがpinしたエントリ、実行中のOperationが参照しているエントリは引き続き保持してよい。
 
 Operationを通して発見されたpathは、それだけではDiscoverable Spaceへ追加しない。そのエントリを起点として`fetch_tree`を取得した場合に、そのindexableな範囲をDiscoverable Spaceへ追加できる。
 

draft/unresolved-issues.md

@@ -22,7 +22,6 @@
 - Recursive named typeを許可するか。
 - `i64`、`u64`、`bigint`、`decimal`等を追加するか。
 - `description`の必須性と長さ。
-- Guardの具体的schema。
 - error型をOperation outputに含めるか、Protocol errorとして分離するか。
 
 ## WIP over HTTPS

draft/wip-idl.md

@@ -253,7 +253,7 @@ operation refresh {
 
 Outputには任意のtype expressionまたはNamed typeを使用できる。ただし、将来fieldを追加する可能性があるOperationではrecord outputを推奨する。
 
-Operationのname、description、Guardなど、input / output型以外のinterface metadataとの対応付けは[Operation schema](../2.2-operation.md)で定義する。
+Operationのnameやdescriptionなど、input / output型以外のinterface metadataとの対応付けは[Operation schema](../2.2-operation.md)で定義する。
 
 ## Schema exchange
 

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対象
 
@@ -22,7 +22,7 @@ HTTPSを利用することで、TLS、認証、Proxy、Gateway、Observability
 - `fetch_tree`
 - `call_operation`
 
-具体的なHTTP method、endpoint、content type、error mapping、認証方式、streaming表現などは、このbinding仕様側で定義する。
+具体的なHTTP method、endpoint、content type、error mapping、認証方式、batch表現などは、このbinding仕様側で定義する。
 
 ## WIP IDLの取得