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
69 lines
3 KiB
Markdown
69 lines
3 KiB
Markdown
# 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/`
|