Finding
Canonical owner is #64. Application ports previously exact-gated result objects but did not prove that structurally valid results named an authoritative HR identity associated with the governed command. Test-first 0daa68a… established foreign exact-valid result rejection for Employment/Position/Assignment/hire. Verification of the first equality repair found a second checked-versus-used defect: rereading a port-mutable command after executable port work could redefine expected result authority. Test-first 6142f7d… captured that; production abd5492…/62a6b7ac… detached exact target UUID snapshots before port execution.
That repair was correct for ordinary creates and for confirmed-hire, but subsequent real hosted acceptance exposed an over-broad assumption for generic People idempotent retries. Protected docs/API_CONTRACT.md and docs/TEST_STRATEGY.md deliberately exclude generated Employment/Position/Assignment record IDs from the semantic command digest so a same semantic retry may allocate fresh UUIDs yet must return the first committed record identity. Unconditional equality to the retry command ID therefore contradicts the pre-existing idempotency contract.
#246 refinement
Issue #246 owns that reconciliation. Exact predecessor 8f986853a6f234c317e29080c4982bab34f3dc51 produced a real Foundation RED in run 33947715482 / job 101256719960: People API 232 passed / 1 failed, 99.48%, because the documented same-key replay returned the first committed Employment identity and #229 rejected it as different from the retry's fresh generated ID.
Current #64 successor a61617f0cdd6f1a2e29b512b2a3c66872af5ccc4 preserves #229 for unexplained foreign results while adding explicit replay_command_digest evidence for generic Employment/Position/Assignment. A different returned identity is accepted only when exact result revalidation succeeds and the application independently recomputes the same semantic digest from its detached command plus authorization. PostgresPeopleMutationPort emits that evidence only after the stored idempotency digest already matched the current semantic digest. Normal creates still require command identity; confirmed-hire remains exact-identity-bound because its published contract requires repeated materialization identities.
Current exact-head workflows are Foundation 33964015934, Security 33964015937, SAST 33964015913, and CodeQL PR 33964015914; Foundation Repository quality 101300767068 was queued before checkout at the latest read. An exact-head CodeRabbit review has been requested. No current-head hosted GREEN or qualifying APPROVED review is claimed.
Keep #229 and #246 open until a verified successor carrying both the result-integrity and idempotent-replay semantics reaches protected truth. No force-push, destructive rebase, self-approval, routine administrator bypass, gate weakening, mutable-owner source copy, or predecessor-evidence transfer.
Finding
Canonical owner is #64. Application ports previously exact-gated result objects but did not prove that structurally valid results named an authoritative HR identity associated with the governed command. Test-first
0daa68a…established foreign exact-valid result rejection for Employment/Position/Assignment/hire. Verification of the first equality repair found a second checked-versus-used defect: rereading a port-mutable command after executable port work could redefine expected result authority. Test-first6142f7d…captured that; productionabd5492…/62a6b7ac…detached exact target UUID snapshots before port execution.That repair was correct for ordinary creates and for confirmed-hire, but subsequent real hosted acceptance exposed an over-broad assumption for generic People idempotent retries. Protected
docs/API_CONTRACT.mdanddocs/TEST_STRATEGY.mddeliberately exclude generated Employment/Position/Assignment record IDs from the semantic command digest so a same semantic retry may allocate fresh UUIDs yet must return the first committed record identity. Unconditional equality to the retry command ID therefore contradicts the pre-existing idempotency contract.#246 refinement
Issue #246 owns that reconciliation. Exact predecessor
8f986853a6f234c317e29080c4982bab34f3dc51produced a real Foundation RED in run33947715482/ job101256719960: People API 232 passed / 1 failed, 99.48%, because the documented same-key replay returned the first committed Employment identity and #229 rejected it as different from the retry's fresh generated ID.Current #64 successor
a61617f0cdd6f1a2e29b512b2a3c66872af5ccc4preserves #229 for unexplained foreign results while adding explicitreplay_command_digestevidence for generic Employment/Position/Assignment. A different returned identity is accepted only when exact result revalidation succeeds and the application independently recomputes the same semantic digest from its detached command plus authorization.PostgresPeopleMutationPortemits that evidence only after the stored idempotency digest already matched the current semantic digest. Normal creates still require command identity; confirmed-hire remains exact-identity-bound because its published contract requires repeated materialization identities.Current exact-head workflows are Foundation
33964015934, Security33964015937, SAST33964015913, and CodeQL PR33964015914; Foundation Repository quality101300767068was queued before checkout at the latest read. An exact-head CodeRabbit review has been requested. No current-head hosted GREEN or qualifyingAPPROVEDreview is claimed.Keep #229 and #246 open until a verified successor carrying both the result-integrity and idempotent-replay semantics reaches protected truth. No force-push, destructive rebase, self-approval, routine administrator bypass, gate weakening, mutable-owner source copy, or predecessor-evidence transfer.