Update to Fina

{
  "description": "Investigate missing, duplicated or incorrect Fina records; correct purchases, link refunds, resolve review items and associate completed own-account transfers or debt payments. Use for record discrepancies and corrections, preserving evidence and existing history.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 496
    },
    {
      "relative_path": "references/fina-core.md",
      "size_in_bytes": 7447
    },
    {
      "relative_path": "references/financial-facts.md",
      "size_in_bytes": 5203
    },
    {
      "relative_path": "references/host.md",
      "size_in_bytes": 4255
    },
    {
      "relative_path": "references/refresh-and-scheduling.md",
      "size_in_bytes": 6117
    }
  ],
  "name": "reconcile-financial-records",
  "skill_md_contents": "---\nname: reconcile-financial-records\ndescription: Investigate missing, duplicated or incorrect Fina records; correct purchases, link refunds, resolve review items and associate completed own-account transfers or debt payments. Use for record discrepancies and corrections, preserving evidence and existing history.\n---\n\n# Review and correct records\n\nRead [Fina's shared workflow](references/fina-core.md) and [financial facts](references/financial-facts.md). Check or reuse setup; missing setup must not prevent repairing the facts needed to complete it.\n\n## Find the actual record\n\nStart with bounded `search_transactions(detail=summary)` for the specified date/account/concept. Use the literal `query` when the user quotes a label; `merchant` alone cannot search concepts. If an expected record is absent, inspect relevant `list_events` / `get_event` for received, processing, omitted or review activity. An empty search does not prove data was never received. Read full evidence and versions only for candidates that matter.\n\nDo not convert processing delay into a request for the user to re-enter everything. Explain relevant excluded review items; category-only uncertainty does not mean a recorded purchase is excluded. Read actual evidence before claiming a duplicate.\n\n## Use the narrow operation\n\n| User's intent | Operation and boundary |\n| --- | --- |\n| Correct a recorded purchase/payment/income | `correct_transaction` with current transaction version and the supported patch. Keep independent evidence and unchanged fields. |\n| Resolve a received event missing facts | `resolve_event` with current event version and evidence-supported extraction. |\n| Remove/restore a record's effect in Fina | `cancel_transaction` / `restore_transaction`, current version and reason. This does not reverse a bank charge or create a refund. |\n| Relate existing refund to purchase | `link_refund`, current refund version and the actual original transaction; no duplicate refund. |\n| Confirm/reject possible duplicate evidence | `resolve_transaction_match`, current event version and the supported target or null; never merge across owners or based solely on approximate FX. |\n| Retry a failed received event | `reprocess_event` after reading the failure and determining a retry can help; reuse the event instead of resubmitting it. |\n| Link a completed own transfer or card payment | `link_account_transfer` with observed legs and current versions, as described below. |\n| Remove an incorrect transfer link | `unlink_account_transfer` with returned link ID/version and reason; preserve independent observed evidence. |\n| Dismiss an incorrect card-payment suggestion | `dismiss_card_payment_suggestion` with current version, only on explicit rejection. |\n| Link an existing movement to a loan | `propose_debt_payment`, then `resolve_debt_payment_suggestion` for the user's supported confirm/dismiss decision. `record_debt_payment_evidence` requires an actual observation, not an inferred principal allocation. |\n\nFor a linked transaction requiring correction/cancellation, inspect and unlink the existing relationship first when required by the live contract. Do not erase evidence to make totals agree. Resolve version conflicts with a re-read; never blindly overwrite newer facts.\n\n## Own-account transfers and debt payments\n\nSearch the other account for the counterpart first. Prefer two existing observed legs with their exact IDs and versions. Preserve both amounts and currencies. If the other leg does not exist, `counterpart_evidence` is permitted only for a completed transfer with explicit full user/document evidence: amount, currency, date, account and reason. Never invent a leg, fixed stablecoin parity or issuer settlement.\n\nIf the user already identified the pair, reuse that authorization to correct missing direction/type and link the observed records without asking again. Backend automatic links are existing facts, not pending proposals. `automatic_debt_payment_notices` with `requires_confirmation=false` need no new confirmation. Relevant unresolved suggestions can be raised briefly once; matching a statement minimum/total is not proof of purpose or settlement. Dismissal requires an actual rejection.\n\nConfirm the resulting change from the returned result and a focused refreshed read. Explain any remaining uncertainty, especially statement settlement or principal/interest allocation. Stop when the specific discrepancy is resolved; do not turn one correction into an unsolicited audit.\n"
}