# NexusCRM runtime range evidence for terminal POST/409 recovery

This evidence is bound to downstream release PR #4188 and compares the exact
NexusCRM tuple refs:

- previous: `53b28079137b90302e0e7e0e021d22fbc8c4e45a`
- candidate: `ac632bb85208c61548eec85a48500a5f437b5106`

The range contains exactly three merge commits. It is not represented as a
single-fix diff.

## Complete commit range

1. `d74a228f59a9f73696f0fe6c073c23ef75325ba1` — PR
   `pingcap-inc/NexusCRM#3810`, neutral Runtime CRM query execution. The PR
   states that production routing is unchanged until a later atomic activation.
   Its final exact-head standard and adversarial reviews both approved, and its
   separate-process TiDB walking slice covered RLS, FLS, typed values,
   cancellation, unavailable-runtime and invalid-object fail-closed behavior.
2. `c29409f660e21ff9c150ec764bd28d396b7a51da` — PR
   `pingcap-inc/NexusCRM#3814`, test-only expansion of the same walking slice to
   queryAll, locator continuation and IssueHistory. Both final reviews approved;
   the PR changes no production route, contract, Runtime implementation,
   publisher or deployment behavior.
3. `ac632bb85208c61548eec85a48500a5f437b5106` — PR
   `pingcap-inc/NexusCRM#3817`, the terminal POST/409 recovery required by this
   release.

## Target behavior delta

Before #3817, inbound finalization failed whenever a historical
`terminal_failed` create attempt still occupied the exact LinkKey, even when
the inbound transaction held current exact authorship evidence for the remote
record.

The candidate changes only that branch. It supersedes the historical attempt
and publishes the finalized link in the same transaction only when all of the
following remain true under lock:

- same LinkKey, `terminal_failed`, POST and HTTP 409;
- no remote ID, conflict fingerprint, create-conflict PATCH intent, dispatch
  intent, claim, lease, successor or earlier supersession;
- no materialized link already owns the LinkKey;
- exact active inbound authorship evidence exists for the same local source and
  remote ID under the currently installed pack snapshot.

All other attempt shapes retain the old fail-closed result. The recovery does
not consult Email and does not adopt or transfer an existing finalized owner.

## Exact behavior evidence

The source change at #3817 passed:

- real TiDB rollback/commit/idempotency coverage for the atomic attempt,
  evidence and finalized-link write set;
- a real TiDB fail-closed matrix for 14 non-eligible shapes, including pending,
  wrong method/status, pre-existing identity, fingerprint/intent, claim/lease,
  successor and prior-supersession states;
- `go test ./nexuscrm-automation/... -count=1`;
- standard and adversarial Codex Review with no blockers at source head
  `45a4d33a19ed35f426f53c79895d16c63c230c8c`.

For the complete old-to-new tuple range, the historical downstream Release Tuple Gate run
`29714087139` passed tuple validation, resolved frontend build, clean-install
SIT and deterministic mirror regeneration against the exact candidate ref.
The official app-packs ref remains unchanged at
`6f8fd36460f52df4261e92b96f91d640ea1feaa7`.

This is source and release-candidate evidence only. Staging and production
runtime acceptance remain separate gates.