Update to Go: Fintech

{
  "description": "Use only for financial request identity, replay, retention, and ambiguity. Do not use for non-financial effects.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 263
    },
    {
      "relative_path": "evals.json",
      "size_in_bytes": 4945
    },
    {
      "relative_path": "references/idempotency-record.md",
      "size_in_bytes": 697
    },
    {
      "relative_path": "references/provider-idempotency-contract.md",
      "size_in_bytes": 4288
    },
    {
      "relative_path": "skill.json",
      "size_in_bytes": 2501
    }
  ],
  "name": "go-financial-idempotency",
  "skill_md_contents": "---\nname: go-financial-idempotency\ndescription: \"Use only for financial request identity, replay, retention, and ambiguity. Do not use for non-financial effects.\"\nlicense: Apache-2.0\ncompatibility: \"Go 1.24 or newer; external idempotency guarantees must match the active provider contract.\"\n---\n\n# Go financial idempotency\n\nIdempotency means equivalent retries under one authenticated operation identity produce at most one committed financial effect and a consistent outcome.\n\n## Define identity and scope\n\nScope the key by tenant/principal, operation type, and target resource. Bind it to a canonical fingerprint of semantic input. Reject same-key different-input reuse. Never put PII or secrets in the key.\n\n## Serialize first use\n\nUse a durable unique constraint or equivalent atomic claim. Store state such as processing, succeeded, failed-final, and ambiguous; include response/result evidence, canonical fingerprint, attempt owner, lease/version, and provider operation identity. Check-then-insert without a constraint races. A process-local mutex or cache cannot survive replicas and crashes.\n\n## Couple effect and record\n\nWhen local state is the effect, write idempotency record, domain transition, ledger journal, and stored result in one transaction. For an external provider, persist the attempt before calling, reuse the same provider identity, and reconcile ambiguity before issuing a new operation.\n\nRecover abandoned `processing` ownership with a bounded lease and compare-and-swap or fencing transition. Lease expiry proves only that the prior worker lost local ownership; it never proves an external effect failed. A taker-over must first query or reconcile using the stable provider identity, then either record the discovered result or repeat only under the provider's same-identity guarantee.\n\n## Retention and replay\n\nRetain records for the maximum credible client, webhook, and operational replay window. Define behavior after expiry explicitly. Do not prune while in-flight or ambiguous operations can still resolve. Return the stored outcome only if authorization and current disclosure policy allow it.\n\nRead [references/idempotency-record.md](references/idempotency-record.md) for a state model.\n\nWhen the effect crosses a payment-provider API, read [references/provider-idempotency-contract.md](references/provider-idempotency-contract.md). Provider keys differ in supported operations, scope, retention, concurrency, response replay, and regional behavior; encode the deployed endpoint contract instead of assuming a generic header supplies permanent deduplication.\n\n## Output contract\n\nState key scope, fingerprint, concurrency control, atomic boundary, result replay, ambiguity, and retention. Treat mismatched reuse and duplicate financial effects as critical failures.\n"
}