> **Historisch** (Stand DR, unverändert übernommen). Die hier genannten Module `integration_gateway`, `secure_orchestrator`, `telegram_dryrun`, `real_codex` und der `AriaOrchestrator` sind im V3-Kern entfernt; der einzige Ausführungspfad ist `aria_router.gateway.Gateway.handle()`. Aktueller Stand: `../docs/ARCHITEKTUR.md`.

# Aria V3 Phase 4: Telegram routing dry-run (offline)

This is an **offline integration prototype**, not a production deployment or a live Telegram bridge.

## Included

- All source files and tests from `aria_v3_gateway_staging.zip`, including the existing secure gateway.
- `aria_router/telegram_dryrun.py`: simulate a single-poller Telegram routing decision *after* an authorized inbound event. It never opens a Telegram connection or invokes a model.
- `tests/test_telegram_dryrun.py`: 13 extra tests covering per-chat `/auto`, `/claude`, Codex tie-break, handling of existing `/status`, privacy denials, duplicate message IDs, attachments, group restrictions and no-delivery invariants.

## Verified in creation environment

`python3 -m unittest discover -s tests -q`: **100 tests passed**.

## Server validation (staging only)

1. Transfer the ZIP from Mac to server via `scp`.
2. Unpack into a **new directory** (not `/home/aria`, not your running gateway):

```bash
set -e
mkdir -p /root/aria-v3-dryrun-stage
python3 -m zipfile -e /root/aria_v3_telegram_dryrun.zip /root/aria-v3-dryrun-stage
cd /root/aria-v3-dryrun-stage
python3 -m unittest discover -s tests -v
```

The bundle contains no Telegram token or live credentials. Do not mount `.env` or `auth.json` in the test environment.

## Critical gaps before production

1. The only actual Telegram poller is still the existing Claude plugin (`server.ts`). The routing dry-run does not change this.
2. The input allowlist and privacy tier in this simulator are supplied by its caller, **not authenticated**. Production must preserve and reuse the existing Telegram `gate(ctx)`, with a separately authenticated local handoff.
3. The mock `RoutingPlan` does not execute models. There is no verified Codex tool sandbox on the host, and the separate Codex container has not completed authenticated inference.
4. Telegram `/status` is **already** used for pairing state. It is deliberately handed back to the existing plugin rather than overwritten.
5. Group chat, attachments, permission requests, memory, hooks, health monitoring, logs, budgets and restart/replay safety require independent acceptance testing.
6. Before modifying the production Telegram plugin, build a separate candidate copy, implement a single-owner local broker, unit test the full `handleInbound` gate, exercise a separate **test bot** or fixture, document rollback, then request operator approval.
7. End-to-end acceptance requires a successful authorized Telegram request, exactly one provider call, exactly one reply, no loss of legacy Claude capabilities, and audited policy/side-effect behavior.

No existing production files or services should be overwritten or restarted simply because these tests pass.