fluid-telegram/SCOPE.md
tegwick 1e9481e108 Finish the provisioner's remaining plane: honest check, adapter config, IEI-2
plan --check treated BotFather profile reassertion as drift, so a scheduled
check could never go quiet. Reassertion is now its own kind; a changed spec
digest is the drift signal. apply reasserts the profile, updates channel copy
when the spec changes, and is tested against a fake Telegram surface.

The adapter reads its chat id from resolved state and its token from OpenBao,
never the operator session. IEI-2 records that an approved provisioning plan
is not autonomous Daimon action.

Assistant: grok
Assistant-Session: 01a09d5a-92c1-7802-915b-92bee57fc9f0
2026-09-14 02:55:58 +02:00

69 lines
3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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-2 §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-2)
- What the adapter owes: `docs/adapter-contract.md`
- Platform capability reference: `TelegramCapabilityCanon.md`
- Agent instructions: `AGENTS.md`
- Workplans: `workplans/`