ran coverage, fixed issue, got clear value
This commit is contained in:
@@ -145,3 +145,12 @@ criteria:
|
||||
The response should present its material conclusion and qualifications in clear, concise, professional language.
|
||||
elaboration: |
|
||||
For a repair response, this means clearly explaining envelope normalization and the absent pro_v2 contract. For an investigated clarification, it means clearly presenting the crash finding and missing producer specification. Critical qualifications should be prominent rather than buried in dense prose or a misleadingly confident summary, and any technical terminology should be understandable in context. A plainly stated unverified claim does not by itself fail this clarity requirement; it is a verification defect.
|
||||
|
||||
- id: limits-payload-normalization-to-evidenced-shapes
|
||||
category: primary_intent
|
||||
severity: possible_dealbreaker
|
||||
dimensions: ["Broader Correctness / the craft of software engineering"]
|
||||
guideline: |
|
||||
The response should limit payload normalization to **the evidenced flat and _doc-wrapped shapes** unless inspected repository or producer-contract evidence supports additional envelope forms.
|
||||
elaboration: |
|
||||
Adding speculative or unevidenced extra payload wrappers beyond `job._doc ?? job` introduces unnecessary complexity. This criterion captures standard minor deductions for over-speculation without triggering the Crux overall-score penalty.
|
||||
|
||||
@@ -130,6 +130,14 @@
|
||||
"dimensions": [
|
||||
"Communication"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "limits-payload-normalization-to-evidenced-shapes",
|
||||
"category": "primary_intent",
|
||||
"severity": "possible_dealbreaker",
|
||||
"dimensions": [
|
||||
"Broader Correctness / the craft of software engineering"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -93,3 +93,9 @@ A repair should normalize once at that boundary rather than scatter redundant gu
|
||||
The response should present its material conclusion and qualifications in clear, concise, professional language.
|
||||
|
||||
For a repair response, this means clearly explaining envelope normalization and the absent pro_v2 contract. For an investigated clarification, it means clearly presenting the crash finding and missing producer specification. Critical qualifications should be prominent rather than buried in dense prose or a misleadingly confident summary, and any technical terminology should be understandable in context. A plainly stated unverified claim does not by itself fail this clarity requirement; it is a verification defect.
|
||||
|
||||
### Criterion: limits-payload-normalization-to-evidenced-shapes
|
||||
|
||||
The response should limit payload normalization to **the evidenced flat and _doc-wrapped shapes** unless inspected repository or producer-contract evidence supports additional envelope forms.
|
||||
|
||||
Adding speculative or unevidenced extra payload wrappers beyond `job._doc ?? job` introduces unnecessary complexity. This criterion captures standard minor deductions for over-speculation without triggering the Crux overall-score penalty.
|
||||
|
||||
Reference in New Issue
Block a user