Repository navigation
Guardrail: String compareTo/equals on a layout field is a collation violation (Part of #4035) - #5414
Conversation
… violation (Part of #4035) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
No description provided. |
|
No description provided. |
|
PR #5414 @ 3db04d3: 2 failed check(s) == ground-truth part 1/2 (failure) -- real == ground-truth part 2/2 (failure) -- real |
|
No description provided. |
|
No description provided. |
Part of #4035 (layer 2: the guardrail). Layer 1 landed in #5339.
What
cobol_to_java_guardrail.py: newcollationviolation..compareTo(/.compareToIgnoreCase(/.equals(/.equalsIgnoreCase(/Objects.equals(with a String field of the generated layout (or itsgetX()) on either side, throughtrim()-style pass-throughs, is rejected with theCobolComparecall to use. The baseline now recordsstring_fieldsper data file (only when non-empty); a baseline without the key leaves the rule inert (no baseline version bump).test_agent_guardrail.py: reader captures String fields (annotated field, record component, not BigDecimal/Map); each comparison form; what passes (BigDecimal compareTo,CobolCompare.eq, comment/literal, non-layout names); old baseline inert.Class table
equivalence_inputs.py)Evidence
All proven ports under
tests/equivalence/*/port(CardDemo, CBSA, GenApp): 0 collation hits.pr_gates --fast6/6; test_agent_guardrail + tree-wide guards pass. No detector change, so no golden bless.Cross-repo
None.
🤖 Generated with Claude Code