feat(connector): add Telegram /uta panel for pending trade approval

[luokerenx4]

Why

Pending UTA commits still required a click in OpenAlice → Trading as Git. Telegram already has an inline-button form for /settings and /inbox; /uta should be the same kind of owner control for the approval wall.

What

• Catalog: every adapter now advertises /uta plus a uta capability.
• Telegram: /uta opens a review panel. Pending accounts show Approve / Reject, with a confirm step before a live push. Refresh reloads the snapshot. Callback data is page-local (u:a:0), never a raw account id.
• Alice: a Connector action queue (review | push | reject) is drained by the existing action bridge. Writes go through UTAManagerSDK so lite mode, readonly mode, and pending-hash conflicts stay on the Alice/UTA boundary. Connector never talks to UTA.
• Discord / Slack: placeholder replies, same as /inbox.

Out of scope

• Proactive “a commit is waiting” push into the owner chat
• Staging or placing new orders from Telegram
• Discord / Slack button forms

Verification

• npx tsc --noEmit
• cd ui && npx tsc -b
• pnpm -F @traderalice/connector-protocol typecheck
• pnpm test — 563 files / 4780 tests

Live Telegram delivery still needs a linked bot; CI does not send a real DM.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openalice-demo	Ready	Preview	Aug 19, 2026 5:06am

[luokerenx4]

Blocking audit feedback — please do not merge until these items are addressed.

The owner-only Telegram state machine and the Alice/Connector/UTA separation are a solid direction. However, this surface can authorize live broker writes, and two approval-integrity gaps need to be closed before merge.

Required changes:

1. Make pending-hash validation atomic at the UTA write boundary. The current Alice-side status/check followed by a separate push/reject request is vulnerable to a check-to-use race. Extend the UTA push/reject API and SDK to carry an expected pending hash, validate it inside the same UTA request immediately before mutation, and return a typed conflict without executing when it differs. Connector push/reject requests should require the reviewed hash rather than treating it as optional.

2. Never enable approval for operations the Telegram panel did not disclose. The review currently serializes only the first eight staged operations, while push executes the complete staging area. Either paginate all operations before enabling confirmation, or disable remote push/reject for oversized commits and direct the owner to Trading as Git. The UI must clearly show the exact total and whether any operations are hidden.

3. Add regression coverage for both boundaries:

   • more than eight staged operations cannot be approved from a partial presentation;
   • a hash change between review and push/reject produces conflict and makes no mutation;
   • missing expected hash cannot reach push/reject;
   • readonly still rejects push at both Alice and UTA boundaries;
   • duplicate/stale Telegram callbacks cannot cause a second write.

4. This change touches order writes/UTA permissions, so complete the repository's live-paper acceptance lane using a confirmed demo/paper account, exercise the linked Telegram flow, and record that positions/orders were flat after cleanup. Also exercise readonly and stale-hash behavior. Do not use a real-money account.

The focused unit suite is currently green (45/45 locally), and the main CI build/test jobs are green; this is an approval-correctness block rather than an existing test failure.

Note: this is submitted as COMMENT only because GitHub does not allow the PR author account to submit REQUEST_CHANGES on its own PR. Treat the findings as merge-blocking.

[luokerenx4]

Review fixes are in 3e92219.

1. Atomic hash at the UTA write boundary. TradingGit.push/reject take expectedPendingHash, check it (and an in-flight lock) before mutating, and throw PENDING_HASH_CONFLICT with no write. HTTP /wallet/push and /wallet/reject require the hash (409 if missing or stale). Connector actions require it too. Trading as Git and AI tradingPush pass the pending hash.

2. No approval of undisclosed ops. Reviews carry hiddenOperationCount. More than 8 staged operations: Telegram shows the total/hidden count, no Approve/Reject, and Alice refuses the write.

3. Regressions.

   • oversized commit cannot expose Push/Reject
   • hash change on push/reject is 409 / conflict, staging stays
   • missing hash cannot reach push/reject
   • readonly still blocks push at Alice (uta-review) and UTA (UnifiedTradingAccount + trading-proxy)
   • consumed Telegram confirm is expired; a second confirm does not enqueue

4. Live-paper. Not run in this lane. accounts.json here is sealed, so I cannot confirm a demo/paper account without decrypting operator secrets, and there is no linked Telegram bot in this worktree. Remaining: on a verified paper/demo account, OPENALICE_UTA_LIVE_PAPER=1 plus a linked /uta Approve/Reject (including readonly + stale hash), then leave the account flat.

npx tsc --noEmit, cd ui && npx tsc -b, and pnpm test (4793 passed) are green.

[luokerenx4]

Follow-up approval-integrity fix pushed in 0c250f4b.

Additional invariant closed after re-audit:

• a pending commit is immutable; further staging is refused until push/reject;
• staging and recommit are refused while a wallet write is in flight;
• push / reject require expectedPendingHash at the domain, SDK, UI, and HTTP call sites;
• commit failures no longer attempt an unauthenticated reject without a returned hash.

Verification on this commit:

• focused approval/UTA/UI suite: 238 tests passed;
• npx tsc --noEmit;
• pnpm -F @traderalice/connector-protocol typecheck;
• cd ui && npx tsc -b;
• pnpm test: 564 files passed, 4797 tests passed, 9 skipped;
• pnpm test:e2e: 4 files passed, 30 tests passed, 3 skipped (MockBroker/non-trading; required building @traderalice/guardian-runtime first).

Live-paper and linked Telegram acceptance were not run because this worktree has no operator-confirmed demo/paper account or linked bot. That residual gate remains explicit; no real-money account was touched.