Engineering Review
Remain read-only for a review-only request. If the user also asks to resolve
findings, that authorization includes in-scope fixes and local acceptance.
Apply BEP preferences directly to new projects. For existing projects, evaluate
against their established conventions and support promises; distinguish a
preference difference from a correctness, security, or compatibility defect.
Review on two independent axes:
- Outcome: compare observable behavior with the request, authorized scope,
supported contracts, and migration expectations.
- Engineering: compare the implementation with repository conventions and
only the narrow engineering skills relevant to the changed boundaries.
Classify each non-mechanical change before choosing review depth:
- High risk: public or cross-service contracts; authentication,
authorization, security, or privacy; money, billing, credit, or quota;
persisted data or migration; concurrency, transactions, distributed work;
production delivery or another hard-to-reverse decision.
- Low risk: localized, reversible, internal, and none of the high-risk
conditions.
- Medium risk: every other non-mechanical change.
Verify every finding against the artifact. Classify severity independently from
scope: blocking means the requested outcome is wrong or incomplete, a
supported contract breaks, security or data integrity is at risk, or an
applicable configured gate fails; otherwise it is non-blocking. A finding is
in-scope only when the current request authorizes its resolution.
Lead with findings ordered by severity and include precise file and line
locations. Then state assumptions, unanswered questions, verification evidence,
and a concise change summary. If there are no findings, say so and identify any
remaining test or review limitation.
1---2name: bep-engineering-review3description: Review a concrete software change for outcome correctness, engineering risk, and contract impact. Not an automatic implementation pass.4---56# Engineering Review78Remain read-only for a review-only request. If the user also asks to resolve9findings, that authorization includes in-scope fixes and local acceptance.10Apply BEP preferences directly to new projects. For existing projects, evaluate11against their established conventions and support promises; distinguish a12preference difference from a correctness, security, or compatibility defect.1314Review on two independent axes:15161. **Outcome:** compare observable behavior with the request, authorized scope,17 supported contracts, and migration expectations.182. **Engineering:** compare the implementation with repository conventions and19 only the narrow engineering skills relevant to the changed boundaries.2021Classify each non-mechanical change before choosing review depth:2223- **High risk:** public or cross-service contracts; authentication,24 authorization, security, or privacy; money, billing, credit, or quota;25 persisted data or migration; concurrency, transactions, distributed work;26 production delivery or another hard-to-reverse decision.27- **Low risk:** localized, reversible, internal, and none of the high-risk28 conditions.29- **Medium risk:** every other non-mechanical change.3031Verify every finding against the artifact. Classify severity independently from32scope: `blocking` means the requested outcome is wrong or incomplete, a33supported contract breaks, security or data integrity is at risk, or an34applicable configured gate fails; otherwise it is `non-blocking`. A finding is35`in-scope` only when the current request authorizes its resolution.3637Lead with findings ordered by severity and include precise file and line38locations. Then state assumptions, unanswered questions, verification evidence,39and a concise change summary. If there are no findings, say so and identify any40remaining test or review limitation.
saltbo