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
2.6 KiB
| repo | updated |
|---|---|
| fluid-telegram | 2026-09-14 |
INTENT
Why it exists
fluid-telegram is the FLUID interface helix-forge-telegram-publishing: the
deterministic outbound surface through which HelixForge material reaches
Telegram.
It exists because publishing under an organisation's name to an audience of strangers is a governed act, not a side effect of having a bot token. The interface makes that act legible: every publication carries a named reviewer, a recorded consent basis, and a citation to the work it describes, and every one of them is reconstructible afterwards from the evidence store.
What it is not
It is not a content system. The channel does not republish hall entries. A hall entry is a considered first-person account written for a colleague reading a repository; a channel post is short, personal and written to travel. The post is composed from the entry and is a different piece of writing.
Composition therefore happens before this interface is called, and belongs
to the campaign repository pr-hall-of-helix. The boundary is architectural —
ArchitectureBlueprint.md §48.1 forbids an LLM in the mandatory request path —
and editorial, because a post speaks about a named person's work in HelixForge's
voice and deserves a human read before it goes out.
This repository renders and delivers what it is given. It never writes, selects, shortens or embellishes. A post that will not fit is refused, not truncated.
Governing principle
InterfaceEvolutionIntent.md (IEI-2) is the constitutional constraint on this
interface and takes precedence over this file where they touch. It is
subordinate in turn to helix-forge/INTENT.md.
Operational authority is FLUID-2 (Advisory) by deliberate choice: the Daimon may observe, classify pressure and propose adaptations, but may not generate implementations, run experiments unattended, or promote anything. Raising that mode is a governance change under IEI-2 §20, not an operational decision.
Work that changes this repository's authority, ownership boundaries, or operational promises is captured in a workplan before implementation.
What it enables
- HelixForge can publish to Telegram under a stated intent, with a contract, a revision history, and an audit trail that reconstructs any publication.
- A campaign (
pr-hall-of-helix) can publish through a delivery surface it does not have to own, and receive per-variant engagement back. - Delivery questions — attach a portrait or not, which form travels further — can be settled by experiment rather than by preference.
- The interface is reusable by any HelixForge campaign, not only the Hall of Helix.