# Runtime request-cache ingress evidence

This evidence is bound to the Runtime source change in this downstream PR and
compares the exact `NexusCRM` revisions:

- previous: `e736aa34b918888ada128aa7fc61aa8ea4f0a121`
- candidate: `41cfdfd13edd1d82b59d74256941d3e27ee593c2`

The source range contains exactly three commits: the production correction in
[`pingcap-inc/NexusCRM#3836`](https://github.com/pingcap-inc/NexusCRM/pull/3836)
and source-backed integration-fixture updates in
[`pingcap-inc/NexusCRM#3837`](https://github.com/pingcap-inc/NexusCRM/pull/3837)
and [`pingcap-inc/NexusCRM#3839`](https://github.com/pingcap-inc/NexusCRM/pull/3839).

The candidate exact-main revision passed
[`go-ci` run `29798205804`](https://github.com/pingcap-inc/NexusCRM/actions/runs/29798205804),
including the real-repository identity-exchange gate and the separate-process L1
walking slice. The unchanged Runtime owner publisher then built, KMS-signed,
independently verified, and committed the stable image in
[`29799182492`](https://github.com/pingcap-inc/NexusCRM/actions/runs/29799182492):

```text
ghcr.io/pingcap-inc/nexuscrm-runtime-api@sha256:0031ab2f86d95ce23b3e2c1bc39699a5568b68df120d609c483936e207b5f863
```

## Real failure and ownership decision

The signed D2A test2 run
[`29793493222`](https://github.com/pingcap-inc/nexuscrm-pingcap-pack/actions/runs/29793493222)
verified the release tuple, rebuilt the exact L2 metadata tree in isolated TiDB,
passed Catalog reconcile, started all four independently published processes,
and passed the semantic baseline before its first query request. That request
then failed with a CRM-owned HTTP 504 and the following sanitized owner deltas:

```text
identity_rpc_delta=1
records_rpc_delta=1
runtime_admission_delta=2
query_repository_delta=1
history_repository_delta=0
query_sql_delta=65
history_sql_delta=0
```

The request crossed each process boundary once and invoked the query repository
once, but the Runtime executed 65 SQL statements for a three-field `User`
query. The independent gRPC process had not installed the neutral,
request-scoped permission-input cache that the legacy HTTP ingress installs.
Field-level visibility evaluation therefore performed repeated effective-FLS
loads inside the single repository operation.

The Runtime process owner now installs the existing permission-input and
record-read request caches after security and serving admission and before the
handler. The fix adds no cache implementation, capability, RPC, timeout,
fallback, L1 dependency, or query semantic. Existing permissions tests retain
ownership of the fail-closed, bounded per-object FLS projection behavior.

## Exact source range

The GitHub comparison from the previous source to the candidate is three
commits and four files:

```text
813df892 runtime: install request caches at gRPC ingress (#3836)
88623b78 test(runtime): exercise request-cache repository path (#3837)
41cfdfd1 test(runtime): update P4 permission projection fixture (#3839)
backend/internal/runtimeapi/process.go
backend/internal/runtimeapi/process_test.go
backend/internal/runtimeapi/real_repository_integration_test.go
backend/distributions/crm/runtime_l1_integration_test.go
```

The current BOM grammar intentionally binds the frontend build and Runtime
image to the same NexusCRM source revision, so those two desired-source fields
advance together. No frontend file changed in this source range.

## Verification contract

The NexusCRM process integration test proves the authoritative Runtime adapter
receives both request caches. The source-backed TiDB test now also requires one
object-bounded field-permission load and zero point field-permission loads for
the first cross-process read. The downstream desired-BOM tests prove that the
Runtime and frontend source tuple advances together without changing Gateway,
AppService, Catalog, AppRelease, metadata, or capability facts.

The owner-signed Runtime image is published from the candidate exact-main
commit. The resolved-BOM producer remains the sole deployable-digest resolver
and must independently verify that owner publication. The real test2 rerun
remains the executable proof that the fix removes the observed SQL
amplification without changing the service boundary.