tegwick 5a785b9d9f 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

2026-09-04 19:21:08 +02:00

2.6 KiB

Raw Blame History

repo	updated
fluid-telegram	2026-09-04

INTENT

Why it exists

fluid-telegram is the FLUID interface helix-forge-telegram-publishing: the deterministic outbound surface through which HelixForge material reaches Telegram.

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

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

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.