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

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

View file

@ -7,18 +7,53 @@ updated: "2026-09-04"
## Why it exists
Fluid interface for telegram messaging and interaction platform.
`fluid-telegram` is the FLUID interface `helix-forge-telegram-publishing`: the
deterministic outbound surface through which HelixForge material reaches
Telegram.
Fluid interface for telegram messaging and interaction platform.
It exists because publishing under an organisation's name to an audience of
strangers is a governed act, not a side effect of having a bot token. The
interface makes that act legible: every publication carries a named reviewer, a
recorded consent basis, and a citation to the work it describes, and every one
of them is reconstructible afterwards from the evidence store.
## What it is not
**It is not a content system.** The channel does not republish hall entries. A
hall entry is a considered first-person account written for a colleague reading
a repository; a channel post is short, personal and written to travel. The post
is composed *from* the entry and is a different piece of writing.
Composition therefore happens **before** this interface is called, and belongs
to the campaign repository `pr-hall-of-helix`. The boundary is architectural —
`ArchitectureBlueprint.md` §48.1 forbids an LLM in the mandatory request path —
and editorial, because a post speaks about a named person's work in HelixForge's
voice and deserves a human read before it goes out.
This repository renders and delivers what it is given. It never writes, selects,
shortens or embellishes. A post that will not fit is refused, not truncated.
## Governing principle
This repository should stay focused on the purpose above. Work that changes its
authority, ownership boundaries, or operational promises should be captured in a
workplan before implementation.
`InterfaceEvolutionIntent.md` (IEI-1) is the constitutional constraint on this
interface and takes precedence over this file where they touch. It is
subordinate in turn to `helix-forge/INTENT.md`.
Operational authority is **FLUID-2 (Advisory)** by deliberate choice: the Daimon
may observe, classify pressure and propose adaptations, but may not generate
implementations, run experiments unattended, or promote anything. Raising that
mode is a governance change under IEI-1 §20, not an operational decision.
Work that changes this repository's authority, ownership boundaries, or
operational promises is captured in a workplan before implementation.
## What it enables
- A coding agent can understand why the repository exists before changing it.
- State Hub can register and coordinate work for this repository.
- Future workplans can stay connected to the repository's intended role.
- HelixForge can publish to Telegram under a stated intent, with a contract, a
revision history, and an audit trail that reconstructs any publication.
- A campaign (`pr-hall-of-helix`) can publish through a delivery surface it does
not have to own, and receive per-variant engagement back.
- Delivery questions — attach a portrait or not, which form travels further —
can be settled by experiment rather than by preference.
- The interface is reusable by any HelixForge campaign, not only the Hall of
Helix.