fluid-telegram/SCOPE.md

# SCOPE

## One-liner

The deterministic delivery interface that publishes composed HelixForge posts to
Telegram, under a governed contract with a reconstructible audit trail.

## Core Idea

A caller submits a **composed post** — already written, already reviewed,
carrying a consent basis and a citation to its source entry. This interface
validates it, renders it into the Telegram form the serving revision calls for,
delivers it through the Bot API, and reports how it performed.

Everything about *what to say and when* lives elsewhere. Everything about *how
it is carried and proven* lives here.

## In Scope

- The R-1 contract (`contracts/r1.openapi.yaml`) and its revisions.
- The adapter: rendering, delivery, idempotency on `post_id`, custody of the bot
  token for the duration of a call.
- Validation and refusal: no reviewer, no consent basis, or a body that exceeds
  the limit for the form being published → refused, never truncated.
- Delivery experiments (`E-tg-delivery`, cohort `telegram-subscribers`) and the
  hypotheses behind them.
- Per-variant engagement reporting back to the campaign.
- Observation and redaction policy (`docs/observation.md`).
- Bot and channel configuration, and the provisioning of that configuration from
  a declared specification (FT-WP-0002).
- Operational recovery: token rotation, channel administration, revision
  rollback (`docs/runbook.md`).

## Out of Scope

- **Composition and editorial voice.** Condensing an entry into a post, choosing
  which work is worth publishing, the publishing cadence, variant strategies.
  These belong to `pr-hall-of-helix`.
- **Consent records and the review queue.** The campaign obtains and holds them;
  this interface only refuses a post that arrives without one.
- **Reading `hall-of-helix`.** The adapter's only knowledge of an entry is the id
  and URL a post cites, which it renders as a link.
- **Autonomous administration.** Creating, renaming or deleting channels, groups
  or bots, and changing membership or permissions, are forbidden to the Daimon
  (IEI-1 §7). Where such acts are automated at all, they run in the separate,
  human-approved provisioning plane, never in the request path.
- Owning unrelated adjacent systems.

## Current State

Design-complete, not yet live. Governance, the R-1 contract, the adapter's
connector contract, observation configuration, the seed pressure record and two
competing hypotheses are in place. The bot, the channels and the adapter are
not.

- Work: `workplans/FT-WP-0001-telegram-identity-and-hall-channel.md` (active)
- Provisioning: `workplans/FT-WP-0002-*` (declared-presence provisioning; supersedes
  the manual T01–T03 route)
- Depends on: `fluid-core` `FLUID-WP-0008` (handover)
- Not yet created: `pr-hall-of-helix`

## Getting Oriented

- Why it exists: `INTENT.md`
- What may change and what may not: `InterfaceEvolutionIntent.md` (IEI-1)
- What the adapter owes: `docs/adapter-contract.md`
- Platform capability reference: `TelegramCapabilityCanon.md`
- Agent instructions: `AGENTS.md`
- Workplans: `workplans/`