Interface PendingConfirm

Epoch ms when the companion asked.

exec_failed only (0.61.0): the flake was the execution DEADLINE, so the callee was left RUNNING and may still complete on its own — the opposite truth from a definite failure, and the reason status alone is not enough to write the honest sentence. Absent otherwise.

The scope of the op needing approval (e.g. skills.execute).

Which of the two still-actionable rows this is (0.61.0). pending is a request the user has never answered. exec_failed is one they ALREADY approved, whose execution then flaked — only the idempotent wallet pay tools reach it, and approving again re-runs the SAME request (keyed on confirmId) rather than starting a new one, which is the safe recovery. Render the two differently: before this field existed they arrived under one "Approve?" button and nothing said which. Absent from an older server; treat an absent or unrecognized value as pending.

Advisory, same meaning as ConfirmRequestPayload.stepUp (0.61.0): the first-party approval surface should require a passkey / Face ID before approving this one. Computed with the predicate the approve endpoint ENFORCES (the row's scope unioned with the executing tool's), so a card rebuilt from this snapshot announces exactly what the approval will demand — before this field existed a reload mid-wallet.spend rebuilt the card as an ordinary tap and the user met an unannounced biometric prompt. Absent from an older server.

A human, user-facing summary of what approving will do.

The same sentence as DATA — an i18n key (confirmSummary.*) plus its placeholder values — so a host that knows the user's language can render the approval in it. summary stays the English fallback and is always present; these two are absent for a tool that ships no keyed summary and on confirmations recorded before this field existed, so render summaryKey ? localize(summaryKey, summaryVars) : summary. The server cannot do this for you: the turn endpoint carries no locale.