QueryCaller

Who runs a query, and how: the explicit argument of every gateway operation and of QueryPolicy, in place of 9.x's Reactor ContextView. The identity is the Caller commands are admitted with: the HTTP edge resolves one per request and, for a Wow-Scope request, has QueryTargets decide the tenant and scope it acts in; the query adds only its execution context. In-process code passes IN_PROCESS.

• caller: who; null for trusted in-process code, which is bound to no tenant, owner or space. Policies read it: ScopeQueryPolicy restricts a query to its tenant (through the host's TenantPolicy) and its scope.

• entry: where the query came from, which picks its budget.

• selection: what a route names in its URL (an aggregate id, a version range): an operation constraint, not caller scope. Admission appends it at step 2 with the scope, after every QueryFilter, so a rewrite can neither see nor remove it, and it is neither budgeted as scope nor reported among the audit's scope fields.

• scope: the caller's scope as filters (tenant, owner, space) a trusted component stated, which admission step 2 appends to the query with what the policies add.

• crossTenant: the tenants a cross-tenant query reads in place of the caller's own; see CrossTenant.

• target: the scope the request named (Wow-Scope), which QueryTargets admitted: the caller then already acts in it.

An edge never decides the tenant, the scope or the cross-tenant reach itself: it builds the caller of a request through QueryTargets.of, the one home of those rules. The constructor that states the cross-tenant reach and the target is internal, and the engine checks both again for an HTTP caller (QueryTargets.recheck), so a caller built otherwise cannot reach further than QueryTargets lets it. Other code builds a plain caller with of, or uses IN_PROCESS.