# Catalog reconciler range evidence for the D2A v3 capability set

This evidence is bound to the Catalog ref change in downstream PR #4214 and
compares the exact `nexuscrm-controlplane` revisions:

- previous: `d7121468ebb1c73e96f5c22496e120edc02a6a8a`
- candidate: `2178447f7e69f844d685ca688c8d9582067edb03`

The full Git range contains 35 commits, including merge commits. Most of that
range implements unrelated source-revision lifecycle work in the control-plane
root package; it is not compiled into `cmd/catalog-reconcile`.

## Deployed command closure

`GOWORK=off go list -deps -json ./cmd/catalog-reconcile` reports the same five
first-party packages and Go source-file sets at both revisions:

1. `releaseartifact` (`artifact.go`, `compatibility.go`)
2. `catalogapp` (the 13 release, installation, binding and serving-authority
   files reported by `go list`)
3. `strictjson` (`strictjson.go`)
4. `catalogreconcile` (`artifacts.go`, `config.go`, `metadata.go`, `output.go`,
   `reconcile.go`, `release.go`)
5. `cmd/catalog-reconcile` (`main.go`)

Within those first-party package directories, the complete old-to-new Git log
contains exactly one change: `2178447f...`, merged from
`pingcap-inc/nexuscrm-controlplane#165`. The only changed compiled package is
`catalogreconcile`; `catalogapp`, `releaseartifact`, `strictjson` and the
command entry point are unchanged.

The range also advances the module inputs used by that command. PR #164 pins
`nexuscrm-contract v0.1.23` and the exact NexusCRM kernel needed by the selected
metadata model. PR #165 pins the D2A Runtime-aligned shared and metadata module
revisions. No root-package source-revision lifecycle file is in the command's
dependency closure.

## Behavior delta

The previous command accepts the existing v1/v2 single-capability profiles.
The candidate preserves those profiles and adds one bounded v3 profile:

- exactly the CRM query plus record-access App capabilities;
- exactly their two declared Runtime capability mappings;
- one metadata source and one committed Catalog snapshot;
- one deterministic v3 output containing both capability receipts;
- query-required relationship metadata in the Runtime view.

The candidate fails before Catalog mutation when the request is incomplete,
mixes the singular and plural representations, swaps either App-to-Runtime
mapping, or disagrees with the immutable AppRelease frontend mode. Direct
`Reconcile` callers therefore cannot bypass the same AppRelease mapping checks
performed by the configuration builder.

This is the capability grammar selected by the checked-in desired v3 BOM. It
does not change the existing v1/v2 output semantics and does not add an
unbounded or generic capability-list protocol.

## Exact verification

Both exact revisions passed:

```text
GOWORK=off go test ./catalogapp ./catalogreconcile ./cmd/catalog-reconcile -count=1
```

At the candidate revision, the test inventory additionally contains and passes:

- complete synchronous-read capability-family validation;
- query lookup/relationship metadata closure;
- App-to-Runtime mapping mismatch rejection before mutation;
- frontend-shape mismatch rejection before mutation;
- incomplete or ambiguous capability representation rejection before mutation;
- deterministic output, retry, committed-snapshot and activation-race coverage.

The candidate's exact-head standard and adversarial reviews reported no
blockers. The exact-main owner publisher run
[`29777153620`](https://github.com/pingcap-inc/nexuscrm-controlplane/actions/runs/29777153620)
then ran package tests, race tests and vet, built only
`./cmd/catalog-reconcile`, checked its host-compatibility file, produced
provenance and SBOM, signed with the Catalog owner's KMS key, independently
verified the signature, and committed the immutable source-SHA tag.

The resulting owner-signed image is:

```text
ghcr.io/pingcap-inc/nexuscrm-controlplane-catalog-reconcile@sha256:a7849c8183b9ff9da4d2082d072183813fb0466c63326c8b256391c871374c61
```

This file is review evidence, not a deployment receipt or a second release
authority. The checked-in desired BOM remains non-deployable. After merge, the
existing resolved-BOM producer must still fetch this exact source-SHA image and
verify it against the Catalog owner's policy and public key before recording
the authenticated receipt in a deployable resolved BOM.