Copy pack
Build from the verified source Master Prompt and Build Contract for this backend starter. Preserve the API contract, fixtures, validation, idempotency, and no-dashboard boundary.
Master Prompt Build Contract
Master Prompt
# Master Build Prompt: RiskCheck API
Build RiskCheck API as a backend-only invoice-risk scoring service with an API contract workbench for local demo and QA. The product is the API contract and behavior, not a finance dashboard, approval app, payment product, marketing site, or analytics surface.
Required facts to preserve:
- Product surface: backend API plus an API contract workbench only. If any visible demo surface exists, it must be a request/response workbench with fixtures, not a dashboard or finance approval UI.
- Endpoint: POST /v1/invoice-risk.
- Request schema accepts JSON invoice data: invoiceId, vendor.name, vendor.taxId, amountCents, currency, dueDate, poStatus, duplicateSignals.sameInvoiceIdSeen, duplicateSignals.sameVendorAmountWithin30Days, and attachmentPresent.
- Response schema returns status, riskLevel, numeric score, reasonCodes, nextAction, idempotency state, and rate-limit state when relevant.
- Deterministic scoring must explain the score with reason codes. Include rules for high amount, missing/mismatched PO, duplicate signals, missing attachment, and incomplete vendor data.
- Validation must reject malformed JSON and incomplete payloads with stable field-level errors instead of silently scoring partial data.
- Duplicate invoice handling and idempotency must be explicit: duplicate signals affect risk, repeated idempotency keys return the cached decision, and conflicting repeats are handled as a documented error.
- Rate-limit behavior must return a documented 429 response with retry guidance.
- QA fixtures must cover low, medium, high, invalid, duplicate, idempotent replay, and rate-limited requests.
- Demo data must be labeled as placeholder API data; do not imply real production risk checks, real invoice history, compliance readiness, or payment approval.
API workbench preview requirements:
- Main product surface only: one API contract workbench with endpoint header, scenario fixture rail, request JSON editor, response panel, sandbox state, and a compact contract strip.
- Scenario controls: Low risk, Medium risk, High risk, Invalid, Duplicate, Rate limit, and Replay. Selecting a scenario must change the request JSON and expected response.
- Request interaction: users can edit the JSON body and click Send request. Malformed JSON returns 400. Missing required fields returns 422. Valid fixtures return a deterministic scored response. Rate-limit fixture returns 429. Replay fixture shows cached idempotency behavior.
- Response panel: show HTTP status, risk level, score bar, reason codes, validation errors when present, nextAction, idempotency state, and rate-limit state.
- Copy cURL and Reset sandbox controls must visibly change state. Copy cURL can mark the cURL as ready even if clipboard permission is blocked. Reset sandbox returns to the low-risk fixture and clears demo call count.
- Keep the copy surface on the migrated library route to Master Prompt and Build Contract only. Do not show the Step Guide, repo bundle, QA/Fix walkthrough, or Build Companion region there.
UI style and color tokens:
- Overall feel: precise API workbench, calm, dense enough for developers, and visibly backend-only.
- Primary deep green: #143C2B for endpoint identity, active fixture, Send request, and primary copy actions.
- Accent green: #16A36B for successful risk responses, focused editor rings, and live contract highlights.
- Backgrounds: #EEF5F0 page, #F8FCF9 workbench, #EAF4EF fixture rail, #102019 request editor.
- Borders and dividers: #B8D8C8, #C6D8CE, #D8E7DE.
- State colors: #ECFDF3 / #166534 for low/success, #FFFBEB / #92400E for medium/warnings/4xx, #FEF2F2 / #B42318 for high risk and validation errors, #F1F5F9 / #475569 for not-scored states.
- Typography: normal UI text for labels and headings, monospace only for JSON, reason codes, endpoint names, and cURL-like strings.
- Layout: full-width API workbench, not a card gallery. Left fixture rail, center request editor, right response panel, bottom contract strip.
Acceptance criteria:
- The first visible preview is the API contract workbench itself, not a dashboard, marketing page, approval queue, payment UI, analytics screen, or decorative scene.
- Every visible control changes state: fixture buttons, editable JSON, Send request, Copy cURL, Reset sandbox, Master Prompt tab, and Build Contract tab.
- The Master Prompt and Build Contract both preserve endpoint, schemas, deterministic scoring, reason codes, validation, duplicate/idempotency, rate limits, QA fixtures, placeholder data honesty, and no-dashboard/payment boundaries.
- The implementation must include tests or fixtures for each required response path.
Non-goals:
- No dashboard, admin panel, payment approval UI, accounting sync, bank sync, Stripe, checkout, invoicing workflow, analytics/KPI screen, team workspace, or marketing site.
- No ML model, fraud/compliance guarantee, legal review, production-readiness claim, or fake proof that real invoices were checked.
- No auth/account system beyond a minimal API key or server-side guard if needed for local API testing.
- No persistence layer beyond the smallest local/in-memory fixture store needed to demonstrate idempotency and rate limiting. 