# Daedro tools: shared Hub rollout

## Scope and acceptance

Reuse existing Daedro/AIP implementations rather than adding catalog-only placeholders. This increment connects dataset preparation, bounded offline ingestion and a private read-only Telegram connector through the browser and the common OAuth MCP endpoint. Public display names use Daedro; existing catalog identifiers remain stable so saved links and connections survive. Source provenance retains its original project names.

A tool is available only when its runtime is installed and it completes a real synthetic-input execution. Provider connections additionally require the user's own valid credential and explicit Authenticator-confirmed grant. Synthetic protocol fixtures are not evidence of a real provider login.

## Dataset preparation and ingestion

- Dataset input consists of bounded records with input, label and explicit train/validation/test split. The user attests that they may process the submitted data. The server supplies fixed provenance/configuration; callers cannot inject filesystem paths, executable options or source authority.
- Dataset preparation returns the actual implementation's artifacts and manifest. It does not train a model or persist a dataset in the Hub.
- Offline ingestion parses submitted text or supported exports. It is distinct from connecting to a live Telegram account.
- Inputs/results have finite byte/record/time/concurrency limits; no source text is logged or retained in account/session state. Temporary files are per-call and removed.

## Telegram and Daedro Secret

- A Telegram user session belongs to one account/profile. It is never the globally configured operator daemon or another user's session.
- API ID, API hash and session material are typed Telegram credentials encrypted by Daedro Secret. Create/replace/grant/revoke/delete use the existing action-bound Google Authenticator workflow.
- Only `auth_status` and a bounded `dialogs_list` are admitted initially. Sending messages, joining chats, deleting messages, arbitrary Telegram methods and administrator operations are excluded.
- The Hub receives an opaque, short-lived, one-use execution ticket. A separate OS worker identity redeems it over a separate local delivery socket. S3 credentials and Telegram credentials cannot be redeemed interchangeably.
- A worker starts with a clean environment and in-memory Telegram session, validates its destination, bounds output/concurrency/deadline, and returns sanitized errors. Failure to reach Secret fails closed.

## Release gates

Real implementation tests; two-account/two-profile rejection before worker execution; wrong credential-kind and ticket replay rejection; secret absence from responses/logs; UI input/confirmation/result checks; existing S3 regression checks; full repository tests and CI; deploy to the existing VM without opening new public ports. Confirm the existing resource budget and stop window. Public live provider success must be reported separately from module installation and fixture success.