← automation
sherpa-api#458 Done · In review ⏱ 2h 9m
Credit-check compliance integration
⎇ auto/api-458-credit-check-compliance-integrat
Portal localhost:3006Embed localhost:3106API localhost:4006
🔍 iterative-review ✓ (main-pass) 🧪 test:api failed 229 passed · 5 failed · 0 flaky · 12 skipped · report 🧑‍🔬 QA ✅ PASS

Feedback

Pull requests

loading…

QA evaluation

✅ PASS

PASS. Independently verified every acceptance behaviour in the live portal UI at http://localhost:3006 with a fresh Entra session (not implementer claims): the one-click 'Connect sample credit-check provider' button provisions a working credit_check provider (Active, env, request template, 200 dry-run); credit_check is selectable and fully configurable per product via the real Compliance form and persists; a Highrisk applicant (score 0.96) issues a policy that parks compliance_pending and is auto-flagged in the Compliance Checks Queue with the fail decision + score/topics visible; a Lowrisk applicant (score 0.05) proceeds to an active policy; and both results surface in the policy-detail Compliance section with the sanctions-identical UX. The 5 failing tests are pre-existing shared-DB drift unrelated to this 39-line capability-registration + sandbox-provider change, so tests_ok holds. Round-1's blocker (hollow provider that could never return a score) is genuinely resolved.

5/5 acceptance criteria passed
  • Connect a sample credit-check providerClicked the real 'Connect sample credit-check provider' button in Admin -> Integrations; portal routed to the integration detail page showing 'Sample Credit Bureau' (slug sample-credit-bureau, capability credit_check, generic_rest, Active) with a wired 'test' environment (baseUrl http://localhost:4006). Dry-run POST /test returned HTTP 200 with score 0.96 (real outbound round-trip). See eval-1-connect-sample.png.
  • credit_check selectable & configurable per productOn Product -> Compliance (Extended Warranty US) I drove the real form: 'Add check' -> selected 'Credit Check' -> chose the 'Sample Credit Bureau' integration in the dropdown -> enabled it -> Save. PUT /products/226 returned 200 and the config persisted (enabled=true, integrationId bound to the sample provider, triggers new_business/renewal, Pass/Review/Fail bands 0.5/0.85). See eval-2-product-compliance.png.
  • Policy with a failing score is auto-flagged for reviewIssued a policy for applicant 'Jane Highrisk' (sentinel -> risk score 0.96) via the real issuance API; policy returned status=compliance_pending. In the portal the Compliance Checks Queue (badge 2) shows a 'Credit Check' NEW_BUSINESS row for 'Jane Highrisk' with a red 'fail' badge; detail panel shows completed/fail, Findings score 0.96, topics credit.high_risk, datasets sherpa-sample-credit-bureau. The failing policy detail also shows Credit Check = fail in its Compliance section. See eval-3-review-queue.png and eval-4-policy-fail-compliance.png.
  • Passing score proceedsIssued a policy for applicant 'John Lowrisk' (sentinel -> risk score 0.05); policy returned status=active (not gated). Policy detail loads normally and its Compliance section shows Credit Check = pass (completed). See eval-5-policy-pass-compliance.png.
  • Result (score/decision) visible in the compliance sectionBoth policies surface the credit-check result in the policy-detail Compliance section: failing policy shows 'Credit Check / fail' (expand reveals score 0.96, topic credit.high_risk), passing policy shows 'Credit Check / pass' (score 0.05). UX is identical to sanctions screening (same ComplianceChecksSection / SanctionScreeningPanel). See eval-4 and eval-5.
tests_ok: true · quality: Small, surgical, architecturally sound. credit_check reuses the existing external-API-integration + compliance-gate framework (generic registerCapability + product.complianceChecks[capability]); only the runtime gate plus portal registry/labels were touched. The ENUM('sanction_screening')->VARCHAR(64) call-log migration mirrors prior precedent and the audit.ts createdAt fix repairs call-log persistence for ALL capabilities (was silently swallowed). The sandbox credit-bureau route is public/unauthenticated BY DESIGN but correctly gated to non-production (SHERPA_ENV !== 'production'); connectSampleProvider is idempotent on the sample slug and reversibly deactivates other active providers for the capability. No correctness/security issues that warrant failing the ticket. The 5 failing tests are pre-existing stateful-suite / shared-DB drift in plus-insurance (bulk-renewal eligiblePolicies, quote ledger counts, policy-order counts, translation coverage-per-locale, suspension-while-suspended) -- none in a domain the credit_check diff touches; corroborated by the round-1 QE baseline and test-results retry2 folders matching exactly those 5. credit_check contract cases in 08-compliance-checks pass. No new regressions.