fluid-telegram/workplans/FT-WP-0001-telegram-identity-and-hall-channel.md

---
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.