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

id	type	title	domain	repo	status	owner	topic_slug	created	updated	planning_priority	planning_order	depends_on	related_repos
FT-WP-0001	workplan	Establish HelixForge's Telegram identity and publish the Hall of Helix	infotech	fluid-telegram	active	worsch	fluid-telegram	2026-09-04	2026-09-04	high	1	FLUID-WP-0008	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

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

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

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

id: FT-WP-0001-T04
status: todo
priority: high

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

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

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

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

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

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

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.