--- id: FT-WP-0001 type: workplan title: "Establish HelixForge's Telegram identity and publish the Hall of Helix" domain: infotech repo: fluid-telegram status: active owner: worsch topic_slug: fluid-telegram created: "2026-09-04" updated: "2026-09-04" planning_priority: high planning_order: 1 depends_on: - FLUID-WP-0008 related_repos: - fluid-core - helix-forge - hall-of-helix --- # FT-WP-0001 — Telegram identity and the Hall of Helix channel Establish a Telegram identity for HelixForge and a channel publishing hall-of-helix entries, as the first real FLUID interface. Everything that could be prepared without credentials has been: the governing intent, the R-1 contract, the adapter's connector contract, the observation configuration, the seed pressure record, and two competing hypotheses for the first experiment. See `docs/` and the handover package at `fluid-core/docs/handover/fluid-telegram.md`. What remains needs either a person with a Telegram account or a running adapter. ## T01 — Register the bot ```task id: FT-WP-0001-T01 status: todo priority: high ``` **Human step.** Register the HelixForge bot through BotFather (Canon BOT-01). Bots are first-class Telegram accounts and need no phone number. Set the bot's name, description and profile image to something a reader encountering it cold would recognise as HelixForge. Write the token to OpenBao immediately; do not paste it anywhere else, not even briefly. Consistent with `HF-WP-0002` (bao.coulomb.social). ## T02 — Create the channels ```task id: FT-WP-0001-T02 status: todo priority: high ``` **Human step.** Create the **private test channel first**, then the public channel (Canon PUB-01). Add the bot as administrator with **Post Messages** only — the intent forbids it from using any wider right, so granting one would be a permission the system is not allowed to exercise. Every verification below runs against the private channel. Nothing reaches the public channel until the rendering has been seen by a person. ## T03 — Generate and store the redaction salt ```task id: FT-WP-0001-T03 status: todo priority: high ``` `openssl rand -hex 32`, stored in OpenBao beside the token, injected as `FLUID_REDACTION_SALT`. It must never change: see `docs/observation.md` for why rotating it silently invalidates every longitudinal comparison. ## T04 — Record the intent and publish R-1 ```task id: FT-WP-0001-T04 status: todo priority: high ``` ```bash export FLUID_INTERFACE=helix-forge-telegram-publishing fluid intent put --version IEI-1 --file InterfaceEvolutionIntent.md --activate # fill the digest in revisions/R-1.yaml, then fluid revision publish --file revisions/R-1.yaml --key-file "$FLUID_SIGNING_KEY" \ --adaptation-classes presentation --approved-by "$USER" --traffic-share 1.0 ``` Generate a real signing key pair for this; `--ephemeral-key` is development only, and a revision signed with one stops verifying after a restart. ## T05 — Build the adapter ```task id: FT-WP-0001-T05 status: todo priority: high ``` Implement the three operations in `contracts/r1.openapi.yaml` against the connector contract in `docs/adapter-contract.md`. TypeScript with grammY is the natural choice; the wire contract makes the language irrelevant to fluid-core. The two requirements that carry the most weight: publication is idempotent on `entry_id`, and an entry that cannot be converted faithfully is refused rather than approximated. `entry_content_loss` is a hard guardrail in both competing hypotheses and can only be honest if the adapter refuses. ## T06 — Publish one entry to the private channel ```task id: FT-WP-0001-T06 status: todo priority: high ``` The first real test. Publish a single hall entry to the private channel and confirm, by looking at it: - the rendering is faithful and readable; - re-publishing the same entry edits rather than duplicates; - the evidence store contains no Telegram user identity and no bot token; - `fluid audit trace R-1` reconstructs the publication. ## T07 — Implement both presentation forms as R-2 and R-3 ```task id: FT-WP-0001-T07 status: todo priority: medium ``` R-2 implements `H-tg-teaser`, R-3 implements `H-tg-serial`. Both are presentation adaptations over the same contract, so neither needs a contract change. Verify both against the private channel before either sees a subscriber. ## T08 — Open the public channel and publish the backlog ```task id: FT-WP-0001-T08 status: todo priority: medium ``` Point the production adapter at the public channel and publish the existing entries. 94 entries at once would be both a rate-limit problem and an unkind introduction for a new subscriber; publish them oldest-first at a human pace. Whichever of R-2 or R-3 is used here becomes the de facto control for the experiment, which is why `E-tg-length` names R-2 as control rather than R-1. ## T09 — Run the first experiment ```task id: FT-WP-0001-T09 status: todo priority: low ``` Start `E-tg-length` once the channel has roughly 100 subscribers. Before then the evaluator will report INCONCLUSIVE, and that is the correct answer rather than a reason to shorten the window. At one entry per week, a 90-day experiment yields about twelve entries. That is thin, and the honest expectation is that the first run is inconclusive and informs a better-powered second one. Record that expectation in the experiment's amendments rather than discovering it as a disappointment. ## T10 — Close the loop ```task id: FT-WP-0001-T10 status: todo priority: low ``` Record the hypothesis outcome, resolve the competition group, and promote the winner. Then confirm `fluid audit trace` reconstructs the whole chain from the length-limit pressure through to the promoted revision. That trace is the deliverable. It is what makes this the first FLUID interface rather than a bot that posts to a channel.