# Runtime capability canonicalization evidence

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

- previous: `3b122a40cb791f5e3808b821f32c274e31a197c1`
- candidate: `e736aa34b918888ada128aa7fc61aa8ea4f0a121`

The production correction is
[`pingcap-inc/NexusCRM#3834`](https://github.com/pingcap-inc/NexusCRM/pull/3834).
The test-only follow-up is
[`pingcap-inc/NexusCRM#3835`](https://github.com/pingcap-inc/NexusCRM/pull/3835).

## Real failure and ownership decision

The signed D2A test2 run
[`29786271997`](https://github.com/pingcap-inc/nexuscrm-pingcap-pack/actions/runs/29786271997)
verified the release tuple, rebuilt the exact L2 metadata tree in isolated TiDB,
created the complete 201-row query fixture, passed the legacy record-access
oracle, and completed Catalog reconcile. The Runtime API then failed before
readiness with:

```text
runtime delegation: supported capabilities must be canonical
```

Catalog canonically orders its serving document by L1 App capability. The
Runtime delegation verifier owns a different set and canonical order: sorted
L0 Runtime capability identifiers. Runtime production composition had passed
the App-ordered sequence directly to that verifier.

The Runtime owner now sorts the already validated, unique Runtime-capability
set before verifier construction. Catalog ordering, AppRelease facts,
delegation semantics, wire contracts, L2 metadata, and the independent metadata
input revision are unchanged.

## Regression proof

The exact reviewed #3835 test creates valid workload-token and signing-key
fixtures, supplies the real App order (`query`, then `record-access`), and
requires assembly to advance through delegation verification to the later TLS
identity boundary. Removing the production sort makes that same test fail with
the original test2 error, so it guards the actual failure rather than an
earlier configuration exit.

Both #3834 and #3835 passed standard and adversarial exact-head review with no
blocking issue. The exact-main user-owned CI run
[`29788349548`](https://github.com/pingcap-inc/NexusCRM/actions/runs/29788349548)
is the publication handoff for candidate source `e736aa34...`.

The full source range is not described as a one-file release. It also contains
the already-reviewed #3710 backend OAuth change and the #3827/#3832 immutable
mutation-metadata substrate. The OAuth handler package is not in the
`cmd/runtime-api` dependency closure; its existing JWT dependency changes only
from indirect to direct in `backend/go.mod`. The metadata packages are in the
Runtime binary closure, but their mutation substrate is not selected or invoked
by this query-only activation. The only change in the serving Runtime assembly
path required by this failure is
`backend/internal/runtimeproduction/assemble.go`, followed by its regression
test. No `frontend/` path changes in the source range even though the current
BOM grammar intentionally binds the frontend build and Runtime image to the
same NexusCRM source revision.

`scripts/ci/check-runtime-process-boundary.sh` continues to pass, so the
Runtime image remains L1-free. The exact-main source-backed TiDB gate and the
real downstream test2 rerun remain the executable proof that the complete
published range preserves the selected query path.

## Owner artifact

The exact-main owner publisher
[`29789475644`](https://github.com/pingcap-inc/NexusCRM/actions/runs/29789475644)
validated the resolver-owned CI receipt, built the Runtime image, produced
provenance and SBOM, KMS-signed the exact digest, independently verified it,
and committed the immutable source-SHA tag. The owner-signed image is:

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

This file is range evidence, not a second release authority. The desired BOM is
non-deployable; the existing resolved-BOM producer must resolve this exact
source tag and independently verify its owner signature before emitting the
deployable digest tuple.