Prepare the FLUID interface for HelixForge Telegram publishing
Adds the governing intent, the R-1 contract and descriptor, the adapter's connector contract, the observation and redaction configuration, a runbook, and the seed evidence for the first experiment: a measured pressure record and two competing hypotheses about how a long hall entry should reach a reader. The interface is declared at FLUID-2 deliberately. It publishes under HelixForge's name to an audience that did not consent to being experimented on carelessly, and the cost of a bad post is reputational rather than recoverable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014KmVxhJ35tCo7rE7UnLwWu Assistant: claude-code Assistant-Model: opus Assistant-Process: 1116572@bnt-lap001 Assistant-Session: 8ba9bb93-a72a-4883-b189-2499cce5c400
This commit is contained in:
parent
87795446e2
commit
49b7458dfe
13 changed files with 3010 additions and 1 deletions
190
workplans/FT-WP-0001-telegram-identity-and-hall-channel.md
Normal file
190
workplans/FT-WP-0001-telegram-identity-and-hall-channel.md
Normal file
|
|
@ -0,0 +1,190 @@
|
|||
---
|
||||
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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue