coulomb/fluid-telegram
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Ground the repo docs and move presence provisioning to a declared spec

Browse source 
Align AGENTS.md with the FT-WP- prefix the hub already registered, and
rewrite INTENT.md and SCOPE.md, which were still the generated stubs and
carried none of the composed-post framing the interface is built around.

Fix two artifact inconsistencies: R-1's retry comment still described
POST /v1/hall-entries idempotent on entry_id, from before the reframe to
composed posts; and the seed pressure record listed only one of the two
hypotheses that cite it. Rename it to match its id.

Replace the manual T01-T03 route with FT-WP-0002. The Bot API cannot
create a bot or a channel, so provisioning is an MTProto client acting as
a designated operator account (Canon INT-03), driven from a declared
presence spec owned by the campaign. One bounded human bootstrap remains
and docs/provisioning.md says why it cannot be removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0172sgCZEEDJcnQmr4SGDvKa

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1361245@bnt-lap001
Assistant-Session: b3b428ef-f3e6-4688-b091-01f71461d66a
This commit is contained in:
tegwick 2026-09-04 19:21:08 +02:00
parent 3dae4ae74c
commit 5a785b9d9f
11 changed files with 670 additions and 46 deletions
Download patch file Download diff file Expand all files Collapse all files

56
workplans/FT-WP-0001-telegram-identity-and-hall-channel.md
View file

@ -46,6 +46,14 @@ first experiment. See `docs/` and the handover package at
What remains needs either a person with a Telegram account or a running
adapter.
**T01–T03 have moved.** They were written as manual steps; they are now
provisioned from a declared specification by `FT-WP-0002`, and the three tasks
below are kept as the record of what must be true rather than as instructions to
follow. The Bot API cannot create a bot or a channel, so provisioning is an
MTProto client acting as a designated operator account (Canon INT-03); one
bounded human bootstrap remains, and `docs/provisioning.md` says exactly what it
is and why it cannot be removed.
## T01 — Register the bot
```task
@ -55,14 +63,18 @@ priority: high
state_hub_task_id: "a5449e86-3181-54b6-a0fe-e5c761b3e4ba"
```
**Human step.** Register the HelixForge bot through BotFather (Canon BOT-01).
Bots are first-class Telegram accounts and need no phone number.
**Superseded by `FT-WP-0002` T04.** The bot is registered by the provisioner
from the declared presence spec, not by hand: BotFather `/newbot` driven over
MTProto, name, about text, description and avatar set from the spec, and the
token written straight to OpenBao without passing through a terminal. Consistent
with `HF-WP-0002` (bao.coulomb.social).
Set the bot's name, description and profile image to something a reader
encountering it cold would recognise as HelixForge.
What survives from the original step is the requirement, not the method: a
reader encountering the bot cold should recognise it as HelixForge. That is now
`bot.name` / `bot.about` / `bot.description` in the spec, where it is reviewable
before it is applied.
Write the token to OpenBao immediately; do not paste it anywhere else, not even
briefly. Consistent with `HF-WP-0002` (bao.coulomb.social).
Close this task when `FT-WP-0002` T04 has run. See `docs/provisioning.md`.
## T02 — Create the channels
@ -73,13 +85,21 @@ priority: high
state_hub_task_id: "597ab1b7-5903-5a5d-a510-0a6946325404"
```
**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.
**Superseded by `FT-WP-0002` T04.** Both channels are created by the
provisioner via `channels.createChannel`, private test channel first (Canon
PUB-01), with the bot added as administrator through `channels.editAdmin`.
Every verification below runs against the private channel. Nothing reaches the
public channel until the rendering has been seen by a person.
The ordering and the rights are no longer conventions a person is trusted to
follow. `apply` will not touch the public channel until the test channel has
recorded a successful publication, and it grants **Post Messages** and refuses
anything wider *even if the spec asks for it* — the intent forbids the system
from holding a right it may not exercise, so the grant is the right place to
enforce that.
Every verification below still runs against the private channel, and nothing
reaches the public channel until a person has looked at a rendering.
Close this task when `FT-WP-0002` T04 has run.
## T03 — Generate and store the redaction salt
@ -90,9 +110,15 @@ priority: high
state_hub_task_id: "bbe5da73-e604-5dfe-b25f-fba802f67618"
```
`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.
**Superseded by `FT-WP-0002` T05.** The provisioner generates 32 bytes if and
only if the OpenBao path is empty, and has no path that overwrites one. Injected
as `FLUID_REDACTION_SALT`.
It must never change: see `docs/observation.md` for why rotating it silently
invalidates every longitudinal comparison. Making that a property of the tool
rather than a note in a workplan is the whole reason the step moved.
Close this task when `FT-WP-0002` T05 has run.
## T04 — Record the intent and publish R-1