feat: add Astro reference site and organize book contents

contents/draft/dynamic-worldspace-projection.md

@@ -0,0 +1,321 @@
+# Dynamic Worldspace Projection
+
+## Status
+
+この文書は、Rust / TypeScript Host APIを設計する前に、動的なWorldspaceを運用するための責務、処理モデル、要件を整理するdraftである。
+
+具体的なtrait、class、function、decorator、macro、builderのsyntaxは定義しない。この文書で使用する`Projection Provider`、`Projection Resolution`、`Projected Object`等の名称も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だけではない。Filesystem、database row、repository内容、検索結果、外部service上のentityなど、実行時に存在と状態が決まる空間をWorldspaceへ投影できなければならない。
+
+HostがWorldspace内のすべてのObjectを常駐instanceとして保持することは要求しない。Backend dataをrequest時に解決し、必要な範囲だけObjectとして投影できることを基本とする。
+
+固定pathへ登録されたObjectやservice endpointは、同じ動的projection modelにおいてrouting / resolution structureが固定された特殊ケースとして扱えるべきである。現在の主体やbackend stateに応じて、そこで返すObject representationやvalidatorが変化することは妨げない。静的登録だけを基本形とし、動的空間を大量のObject登録によって模倣する設計にはしない。
+
+## 基本的な分離
+
+Host実装APIでは、少なくとも次の責務を区別する必要がある。この区別を一対一のpublic type、trait、objectへ分割することまでは決定しない。
+
+### Interface Declaration
+
+Operation名、parameter、return type、documentation等を宣言し、Interface Descriptor、Value codec、boundary validationを生成する。
+
+Interface Declarationは、多数のObjectが共有できる比較的静的なcapability schemaである。Objectの列挙やbackend dataのlifecycleは担当しない。
+
+### Worldspace Projection
+
+Clientから受け取ったpathを、現在の主体とbackend stateに基づいて解決し、Protocol上のObject projectionを生成する。一つのProjected 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
+
+Protocol requestを受け取り、ProjectionとInterface registryを協調させる。Operation callでは、現在のProjected Objectが公開するInterface集合からClientが指定した一つのDescriptorを固定し、そこに宣言されたOperationをObjectのHost内implementationへ適用する。
+
+Host RuntimeはProtocol validation、Interface Descriptorの公開、Value validation、error mapping、resource limit等を担う。Backend固有のprojection resolutionやdomain operation implementationそのものはProvider等のHost componentへ委譲できる。Object implementationとOperation実装を接続する具体的なAPIは各言語のSDK側で決定し、Protocol conceptとして追加しない。
+
+## Working terminology
+
+このdraftでは、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を意味しない。
+
+Hostが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)`では、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を遅延して発見できる必要がある。Childrenをstream、iterator、cursor等のHost内部表現で生成してよいが、一つの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を利用してもよいが、cacheの有無によってProtocol semanticsを変えてはならない。
+
+### `fetch_interface`
+
+ProjectionがObjectへ割り当てた各Interface参照は、同じ主体から取得可能なDescriptorへ解決されなければならない。
+
+複数のObjectは同じInterface参照を共有でき、一つのObjectも複数のInterfaceを組み合わせられる。Validatorを返すInterface参照では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`では、HostはProviderまたはbackend固有のexecution boundaryへ入り、その同じ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対象の対応が変化し得る実装は、この手順を満たさない。Projectionは、Host RuntimeとProviderがこのatomicityを実現するために必要なstable handle、transaction、conditional operation、lock等を使用できるようにしなければならない。
+
+過去の`observe`で作成したHost内部Object instanceの存在を前提にしてはならない。Clientから届くprotocol-level Targetはpathとoptionalなvalidatorであり、Hostはcall時の現在状態からObject implementationを解決する。Validatorを省略したcallを現在のOperationが許可する場合は、過去に観測したObjectではなく、実行時にpathが指す現在のObjectへ無条件に実行する。
+
+Validatorを指定した場合は、Clientが観測したObject identityおよび保護対象状態と実行対象を照合する。Path、`ref`、以前のProjection Resolution、cacheされたHost内部instanceのいずれも、単独ではProtocol上の永続的なObject identityとして扱わない。
+
+## Filesystem projectionの評価例
+
+Filesystemを`/files`以下へ投影する場合、Hostが全file / directoryに対応するObject instanceを作成する必要はない。
+
+- `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そのものでも、file内容を複製したrecordでもない。FileをWorldspace上で発見および操作するためのprotocol-level projectionである。
+
+## 要件
+
+### 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で保護する。Validatorを省略したcallをOperationが許可する場合は実行時の現在Objectへ無条件に実行し、Operationがvalidatorを要求する場合は`ValidatorRequired`として実行しない。
+
+### Operation解決と実行対象のatomicity
+
+Operation callでは、visibility、Object identityとvalidator、Interface membershipとvalidator、Interface Descriptor、Operation implementation、backend対象を一つのlinearization pointで固定しなければならない。ValidatorなしのObject実行を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を別途開き直してOperationを実行する実装では、比較と実行の間に対象が差し替わる可能性がある。
+
+Host APIは、backend transaction、lock、revision付きconditional update、file descriptor、identity再確認等、Providerがbackendに適した方法でatomicityを実現できる境界を提供する必要がある。すべての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を表現できること
+
+言語ごとの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は性能最適化として、path resolution、backend metadata、Object projection、Interface Descriptor、Host内部Object state等をcacheしてよい。ただし、cacheはProtocol contractではない。
+
+- 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へ合成できることが望ましい。
+
+Composition後も、同じ主体へ公開された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の追跡を要求しない。
+
+ただし、mount API、path routing、Provider間のparent / child関係、同名entry conflict、cross-provider Operation、transaction boundaryは未決定である。ProtocolはHost内部のcomposition方式を公開しないため、Host APIでこれらをどこまで標準化するかを別途検討する。
+
+## 非目標
+
+このdraftは次を要求しない。
+
+- 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を作り、上記の評価シナリオと要件に照らして比較する。