From b42b4150e521c6858cec5aa93a6fb03b518debc9 Mon Sep 17 00:00:00 2001 From: Hare Date: Wed, 9 Sep 2026 00:25:36 +0900 Subject: [PATCH] docs: simplify WIP interaction model --- 1-concept.md | 27 +++++++++++++-------------- 2-core-model.md | 4 +++- 2.2-operation.md | 11 ++--------- 3-core-protocol.md | 2 +- 4-client.md | 4 +++- draft/unresolved-issues.md | 1 - draft/wip-idl.md | 2 +- draft/wip-over-https.md | 8 ++++---- 8 files changed, 27 insertions(+), 32 deletions(-) diff --git a/1-concept.md b/1-concept.md index 72e64ba..e6b9dc4 100644 --- a/1-concept.md +++ b/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側で行う。 - -## World State Transition - -Operationの結果は、単なるTool Responseに限らない。Worldspaceの状態変化や、新たなエントリの発見として表現できる。 - -例えばRAG検索からResult群を発見したり、Agentへの問い合わせからConversationを発見したりできる。Operationは、Worldspaceを変化させ、未観測だった領域を可視化する行為でもある。 +Clientは必要に応じて返されたpathを取得し、変更後の状態を改めて観測する。 ## 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を満たす。 -5. Operationを実行する。 -6. 変化・発見されたWorldspaceを再び観測する。 +4. Operationを実行する。 +5. 必要ならOperation Resultやentry pathをもとに対象を再観測する。 最も強い仮説は、**未知のToolを使えるモデルではなく、未知のDigital Environmentを探索できるモデルを作れるのではないか**という点にある。 \ No newline at end of file diff --git a/2-core-model.md b/2-core-model.md index 8e4d71a..43f5b61 100644 --- a/2-core-model.md +++ b/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を操作してしまう可能性がある。 diff --git a/2.2-operation.md b/2.2-operation.md index 2525bf8..903de5c 100644 --- a/2.2-operation.md +++ 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 - -Guardを設ける場合は、現在時点のavailabilityを同期する仕組みではなく、Operationに一般的に課されるpreconditionやconstraintを説明するsemantic metadataとして扱う。 - -Guardの具体的schemaは未解決事項として管理する。 - -## 2.2.6 Operation Result +## 2.2.5 Operation Result Operationの結果には、通常のdomain valueに加えて、WIP IDLの`entry`型として新しいエントリのpathが含まれ得る。 diff --git a/3-core-protocol.md b/3-core-protocol.md index 6c1d820..97483b0 100644 --- a/3-core-protocol.md +++ b/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の規定対象外とする。 diff --git a/4-client.md b/4-client.md index 712dc39..2520572 100644 --- a/4-client.md +++ b/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へ追加できる。 diff --git a/draft/unresolved-issues.md b/draft/unresolved-issues.md index 9518909..513888c 100644 --- a/draft/unresolved-issues.md +++ b/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 diff --git a/draft/wip-idl.md b/draft/wip-idl.md index 4c33991..602eadf 100644 --- a/draft/wip-idl.md +++ b/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 diff --git a/draft/wip-over-https.md b/draft/wip-over-https.md index fd8f9e0..7f34ec9 100644 --- a/draft/wip-over-https.md +++ b/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の取得