# Dynamic Worldspace Projection ## Status 動的なWorldspaceを運用するには、Hostが何を解決し、どの範囲のObjectを投影し、どうOperationを実行するかを整理する必要がある。このdraftは、Rust / TypeScript Host APIの設計に先立って、その責務、処理モデル、要件をまとめたものである。 具体的なtrait、class、function、decorator、macro、builderのsyntaxは、ここでは定義しない。`Projection Provider`、`Projection Resolution`、`Projected Object`等もHost内部の設計を検討するためのworking terminologyであり、canonicalなProtocol typeではない。 Protocol上の確定事項は[Core Model](../2-core-model.md)、[Object tree / Schema](../2.1-object-tree-schema.md)、[Operation and Interface](../2.2-operation-and-interface.md)、[Protocol](../3-protocol.md)に従う。言語別のconceptual API modelは[Rust API Model](rust-api-model.md)と[TypeScript API Model](typescript-api-model.md)で扱う。 ## 目的 WIP Hostは、事前に列挙した静的endpointだけでなく、実行時に存在と状態が決まる空間をWorldspaceへ投影できなければならない。Filesystem、database row、repository内容、検索結果、外部service上のentityなどが、その実装対象になる。 そのために、すべてのObjectを常駐instanceとして保持する必要はない。Backend dataをrequest時に解決し、必要な範囲だけObjectとして投影できることを基本とする。 固定pathに登録するObjectやservice endpointも、同じ動的projection modelで表現できるべきである。この場合はrouting / resolution structureが固定されているが、返すObject representationやvalidatorは、現在の主体やbackend stateに応じて変化してよい。静的登録を基本形にして大量のObject登録で動的空間を模倣するのではなく、動的な解決の特殊ケースとして静的登録を扱う。 ## 基本的な分離 Host実装APIでは、少なくとも次の責務を区別する必要がある。ただし、責務ごとに一つのpublic type、trait、objectを設けるかどうかは未決定である。 ### Interface Declaration Interface Declarationは、Operation名、parameter、return type、documentation等の宣言である。その宣言からInterface Descriptor、Value codec、boundary validationを生成する。 多数のObjectが共有できる、比較的静的なcapability schemaとして扱う。Objectの列挙とbackend dataのlifecycleは、Interface Declarationの責務には含めない。 ### Worldspace Projection Worldspace Projectionは、Clientから受け取ったpathを現在の主体とbackend stateに基づいて解決し、Protocol上のObject projectionを生成する処理である。投影するObjectは、Host固有のentityを持たないvirtual nodeでも、一つのbackend entityに対応するものでも、複数のbackend entityを集約したものでもよい。 Projectionで決定する内容には、少なくとも次が含まれる。 - そのpathのObjectを現在の主体へ公開するか。 - 公開する`name`、optionalな`description`、`ref`、`validator`。 - Objectの`interfaces` fieldへ設定するInterface参照のordered set。 - `observe`から列挙可能なindexable children。 - Operation実行時に現在のProjected Objectへ作用するために、Host内部で何を再解決または確立する必要があるか。 ### Host Runtime Host RuntimeはProtocol requestを受け取り、ProjectionとInterface registryを協調させる。Operation callでは、現在のProjected Objectが公開するInterface集合からClient指定のDescriptorを一つ固定し、そのDescriptorに宣言されたOperationをObjectのHost内implementationへ適用する。 また、Protocol validation、Interface Descriptorの公開、Value validation、error mapping、resource limit等も担う。一方、backend固有のprojection resolutionやdomain operation implementationそのものは、Provider等のHost componentへ委譲できる。 Object implementationとOperation実装を接続する具体的なAPIは、各言語のSDK側で決める。これはHost内の実装を接続するためのAPIであり、新たなProtocol conceptとしては追加しない。 ## Working terminology Host内部の投影処理を検討するため、次の語を使う。 - **Backend Entity** — File、database row、issue、repository、remote entity等、projectionの入力になり得るHost固有の実体。一つのProjected Objectと一対一に対応するとは限らない。 - **Projection Resolution** — 現在の主体とpathについて、公開するObject representationと、後続処理に必要なHost-private情報を得るrequest-timeの解決結果。 - **Projection Provider** — Pathと主体からProjection Resolutionを生成し、indexable childrenの発見を支援するHost component。 - **Projected Object** — その時点でClientへ返すProtocol `Object`。Backend Entityを持たないvirtual Object、一つのentityのprojection、複数entityのaggregateのいずれでもよく、Host内の常駐instanceを意味しない。 Operationの実装に使うRust struct、TypeScript object、backend handle、transaction context等はHost-privateである。これらに共通するHost abstractionは必須としない。また、Protocolの`Target { path, validator }`、canonical path、Objectの`ref`として公開したり、それらへ流用したりしない。 ## 運用モデル ### `observe` `observe(path, depth)`では、要求された範囲のObjectを現在の状態から投影する。Hostが概念的に行う処理は次のとおりである。 1. Requestの主体とpathをProjection Providerへ渡す。 2. Providerが現在のbackend stateから、そのpathで公開するProjected ObjectのProjection Resolutionを生成する。 3. 非公開または存在しない場合は`NotFound`とする。 4. 公開する場合は、現在のObject metadata、Interface参照のordered set、optionalな`ref`と`validator`を生成する。 5. Nodeのdepthがrequested depthより小さい場合、その主体へ公開するdirect indexable childrenをclean exhaustionまで列挙し、各childについて同じ処理を再帰的に行う。 6. Nodeがrequested depthに達した場合はchildrenを観測せず、responseの`children` fieldを省略する。 7. Requested depthまで完全な`ObjectObservation`を返す。 Providerには、Worldspace全体をmaterializeせず、処理中のparentのdirect childrenを遅延して発見できることが必要になる。Host内部ではstream、iterator、cursor等でchildrenを生成してよい。ただし、一つのparentの観測を成功とするには、その主体へ公開するindexable childrenをすべて調べ終える必要がある。 Backend failure、cancellation、resource budget超過は、列挙が正常に完了したclean exhaustionとは区別する。Requested depthまで完全なresponseを構築できなければ、Host Runtimeは部分的なsuccess responseではなく、対応するfailureを返す。 列挙した各childについては、現在のObject projectionを構築し、そのcanonical pathを後の`observe`や`call_operation`で再解決できなければならない。再解決の対象は、その時点のProjected Objectである。以前観測したbackend entityやHost内部instanceの再現は要求しない。 したがって、Hostが以前の`observe`で作ったObject instanceを保持する必要もない。内部cacheは利用してよいが、その有無でProtocol semanticsを変えてはならない。 ### `fetch_interface` ProjectionがObjectへ割り当てた各Interface参照は、その主体から取得可能なDescriptorへ解決されなければならない。複数のObjectで同じ参照を共有でき、一つのObjectに複数のInterfaceを組み合わせることもできる。 Descriptorの変更可否は、Interface参照がvalidatorを返すかどうかで分かれる。Validatorを返す参照ではDescriptorを変更でき、同じ参照とvalidatorの組が一つのDescriptor observationを表す。Validatorを返さない参照では、その参照が有効な間、Descriptorはimmutableである。 Interface参照のscopeは[2.2. Operation and Interface](../2.2-operation-and-interface.md#interfaceの識別とscope)に従う。登録API、生成時期、deduplication、cacheの具体実装は別途決める。 ### `call_operation` `call_operation`では、現在のObjectを解決する処理と、そのObjectへの実行を同じexecution boundary内で行う。HostはProviderまたはbackend固有のboundaryに入り、概念的に次を行う。 1. 現在の主体と`target.path`からProjection Resolutionを生成し、同じbackend対象を保持するstable handleまたはtransaction contextを取得する。 2. そのpathのProjected Objectを現在も公開するか確認する。 3. 指定されたObject validatorを現在のObject identityと状態へ照合する。 4. Clientが指定したInterface参照がObjectの現在の`interfaces`に含まれることを確認する。 5. `fetch_interface`で観測したInterface validatorを現在状態へ照合する。 6. 固定したInterface Descriptorで指定Operationが宣言されていることを確認する。 7. Argumentsを同じOperation Declarationに従って検証する。 8. 固定したObject implementation、Interface Descriptor、Operation implementationを、step 1で固定した同じbackend対象へ適用する。 9. Resultを同じOperation Declarationで検証し、nestedしたすべての`Entry`へ現在の主体のvisibility checkを適用してから、実行後Object validatorとともに返す。 Step 3から8までの間に、Object、Interface、Descriptor、Operation implementation、backend対象の対応が変わり得る実装では、この手順を満たせない。Host RuntimeとProviderがatomicityを実現できるよう、Projectionは必要なstable handle、transaction、conditional operation、lock等を使用できる必要がある。 解決には、過去の`observe`で作ったHost内部Object instanceを前提としない。Clientから届くprotocol-level Targetはpathとoptionalなvalidatorであり、Hostはcall時の現在状態からObject implementationを解決する。現在のOperationがvalidatorの省略を許可する場合、callは過去に観測したObjectではなく、実行時にpathが指す現在のObjectへ無条件に実行する。 一方、validatorが指定されたcallでは、Clientが観測したObject identityと保護対象状態を実行対象へ照合する。Path、`ref`、以前のProjection Resolution、cacheされたHost内部instanceは、いずれも単独ではProtocol上の永続的なObject identityとして扱わない。 ## Filesystem projectionの評価例 Filesystemを`/files`以下へ投影する場合も、全file / directory分のObject instanceを作成する必要はない。Request時の解決と投影を、次のように行える。 - `observe("/files/a.txt", depth = 0)`では、pathをfilesystem entryへ解決し、stat等からObject projectionを構築する。 - `observe("/files", depth = 1)`では、directory listingから直接のindexable childrenをすべて列挙する。 - Regular file、directory、symlink等に応じてInterface参照の集合を選択できる。 - 主体の権限に応じてObjectを非公開にしたり、read-only、writable等のcapability Interfaceを集合へ追加または除外できる。 - File Operationでは、call時にpathを現在のfilesystem entryへ解決し、Rust struct、TypeScript object、file descriptor等を使ってOperationを実装できる。 この場合のObjectは、fileをWorldspace上で発見・操作するためのprotocol-level projectionである。Fileそのものを渡すわけでも、file内容を複製したrecordを渡すわけでもない。 ## 要件 ### Lazyかつdata-drivenであること - Object集合を事前に列挙または常駐させなくてもよい。 - Backend dataからrequest時にObjectを生成できる。 - 大規模または無限に近いlogical spaceを、要求範囲だけ投影できる。 - Tree上でindexableでないObjectも、既知のpathを`depth = 0`で`observe`したときに直接解決できる。 - Operation resultの`Entry`等で新たに得たpathを、事前のObject登録なしに解決できる。 - 静的Objectも同じmodelで表現できる。 ### Protocol上有効なprojectionを生成すること - Rootと非rootに対する`name`規則を守る。 - 同じparentの公開childrenに重複する`name`を生成しない。 - Backend側の名前をそのままWIPのUnicode nameとして表現できない場合は、deterministicかつcanonicalで、同じparent内で衝突しないmappingを定義するか、そのentryを公開対象から除外する。 - Mappingしたnameは、親全体の無制限列挙を前提にせず、`depth = 0`の`observe`とOperation dispatchで同じchildへboundedに解決できなければならない。Encoding自体が可逆である必要はなく、boundedなbackend indexを利用してよい。 - Name mappingはchild enumeration、`observe`、`call_operation`で一貫させる。 - Objectの`interfaces`を重複のないordered setとして生成し、各参照を取得可能で有効なInterface Descriptorへ解決する。 - ProviderやOperation implementationの出力を信頼せず、Host RuntimeがProtocol boundaryで検証できる。 - Invalidなbackend dataを、Protocol上有効に見える別のObjectへ暗黙に衝突させない。 ### Object representationとbackend dataを分離すること - Protocol `Object`をbackend entity classやHost内のmutable instanceと同一視しない。 - Object projectionはrequestごとに再構築できるvalueとして扱える。 - Backend connection、database transaction、file descriptor、credential等をObject metadataへ混入させない。 - Host内部のObject implementation stateはwire representationへ露出させない。 ### Interface DeclarationとObject publicationを分離すること - Interface DeclarationはObjectの個数やpathに依存しない。 - 多数の動的Objectが同じInterface参照を共有でき、一つのObjectも複数のInterfaceをordered setとして組み合わせられる。 - Validatorを返すInterface参照は同じ参照でDescriptorを変更できるが、変更時にvalidatorを更新する。Validatorを返さない参照のDescriptorは、その参照が有効な間immutableとする。 - Projectionは主体、policy、resource kind、安定した公開capabilityに基づいて、Objectの`interfaces`へ含める参照と立項順を決定できる。 - 頻繁に変化する実行可否や通常のdomain stateを、Interface集合やOperation declarationへ同期しない。 - Operationを隠す場合はcapability Interfaceを集合から除外するか、そのOperationを宣言しないDescriptorを使用し、公開済みOperationの実行だけを拒否する場合は`PermissionDenied`を使用できる。 - Objectの`interfaces`に含まれる各Descriptorは、その主体から取得可能でなければならない。 - Interface参照からDescriptorを解決することと、そのInterfaceを実装するHost codeを区別する。 ### `observe`と`call_operation`で一貫すること - 同じ時点と主体について、異なるdepthの観測が矛盾したObject metadataを生成しない。 - 同じ`ref`を持つObjectを複数pathへ投影する場合も、一つの共有された現在状態として扱い、path固有の`name`、`description`、Interface集合を同時に返さない。 - 同じ`ref`と同じvalidator valueを持つObject projectionは、validatorが存在する場合、`name`、`description`、`interfaces`を含む全representationを一致させる。 - 同じ`ref`でvalidatorが異なる場合は同一Objectの異なる観測状態であり、別Objectとして扱わない。 - Validatorが存在しないObjectでは同validatorによるrepresentation equality checkを行えないため、Clientが最後に成功した観測を現在状態として扱えるようにする。 - 同じ`ref`を持つObjectの公開representationが変化する場合は、validatorが存在するなら以前と同じvalidatorのまま異なるrepresentationを返さない。 - 深い`observe`で得たpathを`depth = 0`で再観測した場合に、backend stateが変化していなければ同じObjectとして解釈できる。 - Operation call時には、その時点でpathが指す現在のProjected ObjectとInterface集合を再解決し、Clientが指定した参照のmembershipとvalidatorを確認する。 - 非公開Object、非公開Operation、公開済みだが実行拒否されたOperationをProtocolで定めたerrorへ一貫して対応付ける。 Backendが並行して変化する場合、複数request間で同じsnapshotを保証することまでは要求しない。観測したObject identityと状態を条件付き実行の対象へ対応付けるため、validatorを使う。Operationがvalidatorの省略を許可すれば、callは実行時の現在Objectへ無条件に実行する。Validatorを要求するOperationでは、省略されたcallを`ValidatorRequired`として拒否し、実行しない。 ### Operation解決と実行対象のatomicity Operation callでは、visibility、Object identityとvalidator、Interface membershipとvalidator、Interface Descriptor、Operation implementation、backend対象を、一つのlinearization pointで固定しなければならない。Object validatorなしの実行をOperationが許可する場合も、この固定は必要である。解決後にpathの指すProjected Objectが変わり、以前のDescriptorに基づくOperation implementationが現在の別Objectへ適用されることは許さない。 少なくとも次の処理を、一つのatomicなexecution boundaryとして扱える必要がある。 - Pathが現在指すObject identityと保護対象状態の確認。 - Object validatorの必須判定と比較。 - 指定Interfaceの現在のmembership確認。 - Interface validatorの必須判定と比較。 - Interface DescriptorとOperation implementationの固定。 - Authorizationの確認。 - 同じbackend対象へのOperation実行。 Pathを一度解決してvalidatorを比較しても、その後に同じpathを別途開き直して実行すると、比較と実行の間に対象が差し替わる可能性がある。 そのためHost APIには、Providerがbackendに適した方法でatomicityを実現できる境界が必要になる。Backend transaction、lock、revision付きconditional update、file descriptor、identity再確認等を利用できるようにするが、すべてのbackendに共通する特定のlocking方式は要求しない。 ### Host内部Object stateのlifecycleを限定できること - Rust struct、TypeScript object、backend handle等をrequestまたはOperation execution scopeだけで構築できる。 - Hostは全Object分のimplementation instanceを保持しなくてよい。 - Providerは必要に応じてconnection poolやmetadata cache等を共有できる。 - Request終了後の内部state保持、再利用、破棄はbackend entity、connection、transaction等の安全性を損なわない。 - Clientが保持する`ref`やvalidatorからHost内部instanceを直接復元することを要求しない。 ### 認可をrequest時に評価できること - Projectionは主体に基づいてObject visibilityと、Objectの`interfaces`へ含める参照の集合を決定できる。 - 非公開ObjectとそのObjectだけを経由するsubtreeを`observe` responseから省略し、存在や省略数を示すmarkerを生成しない。 - Requested depthより浅いnodeでは、その主体へ公開されたindexable childrenを完全に返す。 - Operation implementationまたはその前段で、call時のauthorizationを再評価できる。 - 以前の`observe`時に許可されていたことだけを根拠にOperationを実行しない。 - 非公開Objectの存在や非公開Operationを内部error、log、timing等から不用意に漏らさない実装が可能である。 - Operation resultへ`Entry` pathを含める場合もObject visibilityを迂回せず、result生成時点でその主体に認識させてよいpathだけを返す。この規則はRecord、List、Union等へnestedしたすべての`Entry`位置へ再帰的に適用する。 - `Entry` argumentや既知pathの所持をauthorizationの証明として扱わず、参照先へ作用するOperationは現在の主体と状態に基づいて認可する。 - Result取得後のstateまたは権限変更により、その`Entry`への後続`observe`が`NotFound`になることは許容する。 ### Backend固有のidentityを強制しないこと - Providerは適切なbackend identityがある場合に`ref`へ利用できる。 - Backend EntityとProtocol Objectを常に一対一対応させず、例えば同じfilesystem identityが異なる名前で同時に現れ、Object representationの整合性規則を満たせない場合は、同じ`ref`を機械的に再利用しない。 - Backendに安定したUIDがなくてもObjectを投影できる。 - Host内部のexecution identityとClient-facingな`ref`を同一形式にする必要はない。 - `ref`をHost内部instanceのhandleやdereference keyとして使用することを要求しない。 - `ref`を持たないObjectでもvalidatorを用いた安全なOperationを実装できる。 - Validatorは状態だけでなく現在のObject identityにも結び付け、pathが別Objectを指す場合は内容が同じでも一致させない。 ### Resource limitとcancellationを適用できること - Child enumeration、backend lookup、descriptor生成、Value変換へboundedなresource limitを適用できる。 - `observe`のdepthをProvider側の無制限な再帰列挙へ変換せず、request全体へboundedなresource budgetを適用する。 - Client disconnect、timeout、Host shutdown等に応じてbackend処理へcancellationを伝播できる。 - `call_operation`をdispatchする前にresource limitへ達した場合は`ResourceLimitExceeded`として拒否し、Operationを実行しない。 - Dispatch後のcancellation、timeout、implementation failure、result encoding failureについて、Operationが未実行またはrollback済みであると保証できる場合だけ`Internal`または`ResourceLimitExceeded`を返す。保証できない場合は`OperationOutcomeUnknown`を返す。 - Side effectを持つOperationでは、cancellationやtimeoutを未実行またはrollback済みの証明として扱わず、Host RuntimeもClientも実行結果が不明なcallを自動retryしない。 - Partial backend failureをProtocol上の成功したObject observationへ黙って変換しない。 ### RustとTypeScriptで同じsemanticsを表現できること RustとTypeScriptでAPI syntaxが異なっても、次の処理や制約は両方で実現できなければならない。 - Asyncなpath resolutionとchild enumeration。 - Data-drivenなObject projection。 - Interface Declarationの共有と、Objectへの0個以上のInterfaceのcomposition。 - Type-safeまたはruntime-validatedなOperation dispatch。 - Host-privateなObject implementation stateをrequest-timeに構築および利用できること。 - Object validator、Interface membershipとvalidator、Descriptor、Operation implementation、backend対象の一貫したlinearization point。 - Request context、主体、cancellation、resource limitの伝播。 - Protocol errorとbackend / implementation errorの分離。 Rustのtrait、generic、associated type、type erasureや、TypeScriptのobject definition、generic inference、runtime schema libraryの選択は、これらの要件を満たすAPIを設計する段階で決める。 ## Host内部cache Host内部のcacheは性能最適化であり、Protocol contractではない。Path resolution、backend metadata、Object projection、Interface Descriptor、Host内部Object state等をcacheしてよいが、次の条件を守る必要がある。 - Cacheがなくても正しく動作しなければならない。 - Visibilityとauthorizationを異なる主体間で誤って共有してはならない。 - Stale cacheによってvalidator比較を迂回してはならない。 - Descriptor cacheは同じInterface参照とvalidatorの組に異なるDescriptorを対応付けず、validatorを返さない参照をimmutableとして扱う。 - Resource handleをcacheする場合は、そのlifecycleとidentityの再確認をbackendに適した方法で行う。 ## Composition 一つのHostで、Filesystem、database、remote API等の複数Providerを一つのWorldspaceへ合成できることが望ましい。 合成する場合も、同じ主体へ公開するWorldspace全体で`ref`とInterface参照のProtocol semanticsを保たなければならない。Provider-local identityやInterface keyをそのまま公開すると衝突し得るため、Hostはnamespace、変換、中央発行等によって次を保証する。 - 異なるObjectへ同じ有効な`ref`を割り当てない。 - 同じ有効なInterface参照とvalidatorの組を異なるDescriptorへ対応付けない。 - Validator比較がProvider routingの変更によって別Objectへ適用されない。 Interface参照には、[2.2. Operation and Interface](../2.2-operation-and-interface.md#interfaceの識別とscope)の構造化参照を使う。Objectの祖先制約と、合成後のscope・path・typed `entry`の変換は、[ProtocolのWorldspace composition](../3-protocol.md#worldspace-composition)に従う。Objectの`ref`を具体的にどう発行するかは、引き続き未決定である。 ScopeはそのpathのObjectに紐づき、self-scopeも許可する。RuntimeはDescriptorとscope Objectのoptionalな`ref`を一つのInterface observationとして公開する。Callで指定された`scope_ref`は、routing・implementationの固定と一貫して確認する。`ref`のないscopeも許可し、そのidentityの追跡は要求しない。 Host内部の合成方法については、mount API、path routing、Provider間のparent / child関係、同名entry conflict、cross-provider Operation、transaction boundaryが未決定である。ProtocolではHost内部のcomposition方式を公開しないため、これらをHost APIでどこまで標準化するかは別途検討する。 ## 非目標 動的projectionの要件には、次を含めない。 - Worldspace全体の事前materialization。 - Objectごとの常駐class instanceまたはactor。 - Backend entityとProtocol Objectの一対一対応。 - Host内部Object state、database key、file descriptor等のwire公開。 - Client cacheとHost stateの同期。 - Provider間にまたがる分散transaction。 - すべてのObjectに対する`ref`の発行。 - 特定のdependency injection framework、schema library、async runtimeの採用。 ## API設計前に評価するシナリオ 具体API案は、少なくとも次のシナリオで評価する。不自然な大量登録や、永続Object instanceの保持を要求しないことを確認する必要がある。 1. 数百万entryを持つFilesystemを、directory listingに応じて遅延投影する。 2. Database tableのrowをObjectとして投影し、row keyからcall時に再解決する。 3. 検索Operationが、Treeではindexableでない結果Objectの`Entry` pathを返す。 4. 同じbackend dataを元に、主体ごとに異なるObject visibilityまたはInterface集合を公開する。 5. 観測後にpathの指すProjected Objectが変化し、validator付きOperationを拒否する。 6. 公開済みOperationをcall時のauthorizationで`PermissionDenied`にする。 7. 固定pathの静的service endpointを、動的modelの特殊ケースとして公開する。 8. 複数Providerを一つのWorldspaceへ合成し、Provider-localなidentityの衝突を防ぐ。 9. Backend entityを持たないvirtual Objectと、複数entityを集約するObjectへOperation implementationを適用する。 10. 深い`observe`がresource budgetを超える場合、部分的なresponseを返さず`ResourceLimitExceeded`にする。 11. Operation resultのnestedな`Entry`から、現在の主体へ非公開のObject pathが漏れないようにする。 ## 未決定事項 - Projection ProviderをHostへ登録・合成する単位。 - Path routingおよびmountに相当する概念を標準Host APIへ含めるか。 - Path resolutionとchild discoveryの具体的な戻り値。 - Projected Objectがzero / one / multiple backend entityから導出される場合のHost内部Object implementation表現。 - Child discoveryがObject projectionを返すか、遅延解決用の内部keyを返すか。 - Clean exhaustion、failure、cancellationを区別し、requested depthまで完全な観測だけをsuccessとして返せる内部contract。 - Rust structやTypeScript objectを、Interface DeclarationおよびOperation implementationへ接続する言語別API。 - DynamicなProjected Object implementationをProviderから返すときのgeneric、type erasure、runtime representation。 - Interface DeclarationとOperation implementationを同じAPIにするか分離するか。 - Validator比較とOperation実行を囲むtransaction / callback / guardの抽象化。 - Backendがatomic conditional executionを提供できない場合に、そのOperationをどう制限するか。 - Subject-specificなInterface参照の選択、Descriptor生成、参照発行、cache方法。 - Descriptorを事前登録するか必要時に生成するか、および構造的に等しいDescriptorをinternするか。 - Operation result内のnestedな`Entry` visibilityを、Operation implementation、Projection、Host Runtimeのどこで検証するか。 - Backend nameをWIP nameへmappingする場合のencoding、index、collision処理。 - 複数Provider間で`ref`、Interface参照、validator identityをnamespace化する方法。 - Projection、Operation implementation、Host Runtimeが返すerrorとProtocolErrorの対応付け。 - Enumerationのstreaming、pagination、backpressureをHost内部APIでどう表すか。 - Provider composition時のconflict、ownership、lifecycle、shutdown順序。 - Observability、tracing、auditで非公開Objectやsecretを漏らさないための標準hook。 これらの決定に先立ち、Rust / TypeScript双方で複数のAPI sketchを作る。各案をここに挙げた評価シナリオと要件に照らして比較し、具体的なAPIを検討する。