{"schema_version":2,"skill":"go-payment-lifecycles","cases":[{"id":"route-payment-machine","kind":"routing","split":"development","prompt":"Design Go authorization, partial capture, refund, timeout ambiguity, webhook, and chargeback transitions.","should_activate":true,"reason":"Payment lifecycle evidence dominates."},{"id":"avoid-ledger-balance","kind":"routing","split":"development","prompt":"Enforce per-currency balanced double-entry journals.","should_activate":false,"reason":"Ledger invariants belong to go-money-and-ledgers.","confuses_with":["go-money-and-ledgers"]},{"id":"avoid-nonfinancial-remote-review","kind":"routing","split":"development","prompt":"Review a Go shard lease where a non-financial remote call may succeed after its response is lost.","should_activate":false,"reason":"Non-financial cross-boundary review belongs to review-go-distributed-change.","confuses_with":["review-go-distributed-change"]},{"id":"quality-timeout","kind":"quality","split":"development","prompt":"Provider authorization timed out after request transmission. The user retries.","expected_invariants":["Persists ambiguous attempt with same provider identity","Reconciles or same-identity replays"],"forbidden_outcomes":["Creates a fresh authorization immediately"],"graders":[{"id":"payment-ambiguity","kind":"contains","required":["ambiguous","same"],"weight":1}]},{"id":"quality-late-event","kind":"quality","split":"development","prompt":"Fix the fixture so refund evidence arriving before capture is persisted and reevaluated after its predecessor.","fixture":"evaluations/fixtures/payment-ordering","expected_invariants":["Classifies future evidence separately from invalid evidence","Reevaluates persisted evidence after prerequisites arrive"],"forbidden_outcomes":["Drops or permanently quarantines a valid future event"],"graders":[{"id":"late-evidence","kind":"go-test","target":"./...","weight":1}]},{"id":"quality-authorization-adjustment-review","kind":"quality","split":"development","prompt":"Review a Go multi-provider card authorization model for financial integrity. It stores only AuthorizedAmount, CapturedAmount, and Canceled. A 100.00 request partially approved for 60.00 is stored as AuthorizedAmount=100.00. Concurrent capture retries use fresh IDs. Capturing 40.00 sets Canceled=true and frees the remainder because Provider A auto-releases unused holds after partial capture; the same code serves Provider B, which requires an explicit authorization reversal. Voiding an unsubmitted capture also marks the authorization released. A replica timer marks every authorization expired, but provider capture evidence can arrive late. State the portable invariants without choosing product policy or assuming either provider contract applies to the other.","expected_invariants":["Persists requested and actually approved amounts separately and uses approved amount as the starting authority","Tracks exact incremental approvals reversals or releases captures and remaining capturable amount rather than one canceled Boolean","Serializes cumulative capture and reversal predicates so concurrent operations cannot exceed current authority","Uses a stable identity and canonical payload for each follow-on operation and reconciles ambiguous retries","Records provider rail region payment-method and version capabilities for partial capture and unused-hold release","Distinguishes voiding an eligible unsubmitted capture from reversing the underlying authorization hold","Uses authoritative provider expiry and operation evidence rather than a replica timer as financial finality","Persists late or unknown capture and reversal evidence for conditional application or reconciliation","Retains immutable linkage among the original authorization and every capture void and reversal"],"forbidden_outcomes":["Treats the requested amount as approved authority after partial approval","Copies Provider A automatic remainder release into Provider B without verified evidence","Treats void capture authorization reversal and local expiry as one canceled transition"],"graders":[{"id":"authorization-adjustment-contract","kind":"contains","required":["approved","reversal"],"weight":1}]},{"id":"quality-stripe-dispute-evidence-review","kind":"quality","split":"development","prompt":"Review a Go Stripe card-dispute service. It stores one Chargeback boolean per charge, so a second partial dispute overwrites the first. Duplicate and out-of-order charge.dispute events directly debit or reinstate the payment ledger from current status. An evidence submission timeout sets Submitted=false and immediately sends a different packet. A local timer closes every case at evidence_details.due_by. If the merchant issues a refund or the customer says the dispute was withdrawn, the service marks the case won and ignores later Stripe events. State the case, evidence, money, deadline, and reconciliation invariants. Keep the answer Stripe-specific and do not transfer it to another acquirer or rail.","expected_invariants":["Uses Stripe's unique dispute identity as the case key and permits multiple partial disputes linked to one charge","Persists exact disputed amount currency reason challengeability authoritative status and evidence deadline per case","Keeps dispute status funds withdrawal fees reinstatement refunds and ledger postings as separate evidence-bearing events","Deduplicates webhook event identities and applies out-of-order case and money evidence conditionally so funds cannot move twice","Versions and fingerprints the exact evidence packet attachments and provider receipt or submission count","Treats a timed-out evidence submission as ambiguous and retrieves authoritative dispute evidence details or uses only a verified idempotent replay before changing the packet","Uses the provider deadline to stop unsafe new submissions while still persisting and reconciling authoritative late events","Does not infer a won case from a refund or customer withdrawal and continues the Stripe evidence workflow required by the current contract","Records final won or lost decision provenance without discarding later funds or settlement adjustments","Labels Stripe event names fee behavior and withdrawal rules as provider-specific rather than portable chargeback semantics"],"forbidden_outcomes":["Deduplicates disputes by charge or payment ID alone","Treats refund customer withdrawal or local elapsed time as authoritative dispute victory","Replays a materially different evidence packet immediately after an ambiguous submission"],"graders":[{"id":"stripe-dispute-contract","kind":"contains","required":["dispute","evidence"],"weight":1}]},{"id":"quality-stripe-multicapture-refund-review","kind":"quality","split":"development","prompt":"Review a Go Stripe fulfillment service that enables multicapture for some PaymentIntents but stores only AuthorizedAmount, CapturedAmount, Captured, RefundedAmount, and Refunded. Concurrent shipment workers read the same capturable balance and use a new idempotency key after any timeout. The first partial capture sets Captured=true and releases every shipment. A later capture always sends final_capture=true. The refund consumer ignores refund.created while charge.refunded is false. Connect refunds always request both refund_application_fee and reverse_transfer. Webhooks can be duplicate and out of order. State the exact amount, operation, fulfillment, capability, ambiguity, event, and reconciliation invariants; keep Stripe-specific rules scoped to Stripe.","expected_invariants":["Persists requested approved capturable captured released refunded disputed and settled amounts as distinct exact values","Represents every capture and refund as its own stable amount-bearing operation linked to the PaymentIntent and affected shipment or item","Reuses one provider idempotency identity only for an exact replay of the same capture or refund payload","Serializes or conditionally owns concurrent local capture allocations before the provider call","Treats a capture or refund timeout as ambiguous until authoritative Stripe evidence resolves it","Grants fulfillment only for the shipment or item amount durably allocated and captured","Persists Stripe account payment-method API-version and multicapture capability evidence with the payment","Treats final_capture as ending further capture and releasing remaining authorization under the verified Stripe contract","Does not use payment-wide Captured or Refunded booleans as component-level amount authority","Ingests partial refund events even while charge.refunded remains false","Applies duplicate and out-of-order capture and refund evidence conditionally without moving money twice","Models application-fee refunds and transfer reversals as separate connected-account legs with their documented eligibility and outcomes","Reconciles local component operations to Stripe amount_capturable amount_received capture charge and refund evidence","Does not transfer Stripe multicapture remainder-release or Connect restrictions to another provider"],"forbidden_outcomes":["Issues a fresh idempotency key immediately after an ambiguous capture timeout","Fulfills the uncaptured remainder after the first partial capture","Ignores partial refunds until the charge-wide refunded flag is true","Assumes every Stripe manual-capture payment supports multiple captures"],"graders":[{"id":"stripe-multicapture-refund-review","kind":"contains","required":["final_capture","fulfill"],"weight":1}]}]}