39 lines
1.4 KiB
Markdown
39 lines
1.4 KiB
Markdown
---
|
|
title: Task 5.6 Telegram Escrow Delivery Dispute Release Actions
|
|
tags: [taskmaster, telegram, escrow, disputes, release]
|
|
created: 2026-05-24
|
|
status: planned
|
|
---
|
|
|
|
# Task 5.6 Telegram Escrow Delivery Dispute Release Actions
|
|
|
|
Task 5.6 is not complete in this first Task 5 pass. This document defines the
|
|
implementation boundary required before Telegram shortcuts can affect escrow
|
|
state.
|
|
|
|
## Required behavior
|
|
|
|
- Telegram users can view current escrow state and next allowed actions.
|
|
- Delivery confirmation, evidence upload, refund request, dispute open/respond,
|
|
and release approval route through existing backend precondition checks.
|
|
- High-risk actions require fresh confirmation and audit logging with Telegram
|
|
context.
|
|
- Disputed or held funds cannot be released through Telegram shortcuts.
|
|
|
|
## Required backend constraints
|
|
|
|
- Use canonical purchase request, payment, dispute, and ledger state.
|
|
- Reject release/refund actions unless the funds state machine says the action is
|
|
allowed.
|
|
- Apply the same step-up and two-person policy as web/admin flows.
|
|
- Record Telegram user ID, chat/update ID, deep-link source, and callback token
|
|
ID in audit metadata.
|
|
|
|
## Required tests
|
|
|
|
- Buyer cannot confirm delivery before delivery state.
|
|
- Disputed funds cannot be released.
|
|
- Replayed Telegram callback cannot create a second action.
|
|
- Stale callback token is rejected.
|
|
- Telegram release/refund action emits the same audit fields as web release.
|