Follow-up from the cross-PR interaction analysis of the open security PRs (2026-07-24). This gap does not exist in either PR alone at this cost — it is created by the combination of #264 and #343, so it becomes real the moment both merge.
Finding
Combined effect: a user duplicating a pending CR (same registrant, same selected field, same proposed value) can add one throwaway edit to any other mapped detail field. The changed-field sets now differ → similarity scores 0.0 → duplicate detection is bypassed. Thanks to #264, the padding field is never applied, so the padding is free and side-effect-less.
Under #343 alone this padding had a real cost (the padded field would actually be written on apply). #264 removes that cost. Conflict detection is not evadable the same way — padding only grows proposed ∩ conflict_fields — this affects the duplicate-similarity path only.
Severity: Low-Medium
Requires an authenticated CR user editing their own draft CR. Duplicate detection is a warn-level control (it flags rather than blocks), so the impact is suppression of a reviewer warning, not direct approval bypass. Still, it is exactly the class of steering #343 set out to close.
Suggested fix
Score similarity on the intersection of the two changed-field sets (or on selected ∩ diff), rather than exact set equality — padding then cannot zero the score. Alternatively (or additionally), hardening the writability of detail fields post-creation would remove the free padding vector.
Best coordinated with #344, which covers the sibling sink (dynamic-approval routing) of the same "user-steerable inputs to detection/routing" root cause.
Source: internal/plans/security-prs-interaction-analysis.md (CR cluster review, 264×343). Related: #343, #264, #344.
Follow-up from the cross-PR interaction analysis of the open security PRs (2026-07-24). This gap does not exist in either PR alone at this cost — it is created by the combination of #264 and #343, so it becomes real the moment both merge.
Finding
selected_field_nameand instead derive the proposed change server-side:_proposed_changed_fields()diffs detail-vs-registrant viaapply_mapping_ids. Its duplicate-similarity check then requires exact equality of the full changed-field sets:if my_changed != other_changed or not my_changed: return 0.0(spp_change_request_v2/models/conflict_mixin.py, similarity path, on the security(cr): writable selected_field bypasses CR conflict checks #343 branch).field_mappingapply strategy so that apply writes only the selected field's mapping (spp_change_request_v2/details/field_mapping.py,_effective_mappings), not every changed mapped field.Combined effect: a user duplicating a pending CR (same registrant, same selected field, same proposed value) can add one throwaway edit to any other mapped detail field. The changed-field sets now differ → similarity scores 0.0 → duplicate detection is bypassed. Thanks to #264, the padding field is never applied, so the padding is free and side-effect-less.
Under #343 alone this padding had a real cost (the padded field would actually be written on apply). #264 removes that cost. Conflict detection is not evadable the same way — padding only grows
proposed ∩ conflict_fields— this affects the duplicate-similarity path only.Severity: Low-Medium
Requires an authenticated CR user editing their own draft CR. Duplicate detection is a warn-level control (it flags rather than blocks), so the impact is suppression of a reviewer warning, not direct approval bypass. Still, it is exactly the class of steering #343 set out to close.
Suggested fix
Score similarity on the intersection of the two changed-field sets (or on
selected ∩ diff), rather than exact set equality — padding then cannot zero the score. Alternatively (or additionally), hardening the writability of detail fields post-creation would remove the free padding vector.Best coordinated with #344, which covers the sibling sink (dynamic-approval routing) of the same "user-steerable inputs to detection/routing" root cause.
Source:
internal/plans/security-prs-interaction-analysis.md(CR cluster review, 264×343). Related: #343, #264, #344.