coulomb/pr-hall-of-helix
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
pr-hall-of-helix/SCOPE.md
tegwick 6593dde485 Ground INTENT.md and SCOPE.md for the campaign 
Replaces the register-generated stubs. States the problem the campaign
exists to solve -- an entry and a post are different pieces of writing for
different readers, and the mismatch is register rather than length -- and
draws the boundary against fluid-telegram in both directions.

Two rules are written as non-negotiable: no post without a recorded consent
basis, and none unread. The interface enforces both, but they belong here
first, because by the time the interface refuses something the writing has
already been done.

Also carries the no-ranking constraint forward from the hall. A campaign is
where ranking would re-enter by the back door -- "most featured", or a
cadence that quietly favours the same names.

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 21:07:43 +02:00

3.5 KiB
Raw Blame History

SCOPE

One-liner

The campaign that composes posts from Hall of Helix entries and publishes them through the fluid-telegram interface — owning what is said, never how it is carried.

Core Idea

An entry goes in; a post comes out; a person reads the post against the entry before it travels. Everything in this repository is one of those three moves, or the record of one.

In Scope

  • The declared presence — presence/telegram.yaml, validated against fluid-telegram/presence/telegram.schema.yaml, plus brand assets in presence/assets/.
  • Composition — the step that turns an entry into a post: condensed, personal, carrying a link back to the source entry. Each composition records the variant label of the strategy that produced it.
  • Selection and cadence — which entries are worth a post, and at what pace.
  • The review queue — who reads what, and the reviewed_by that results.
  • Consent records — the basis per contributor, and its revocation.
  • Variant strategies and their competition, run on the per-variant engagement the interface reports.

Out of Scope

  • Delivery. Rendering, the Bot API, idempotency, retries, rate limits. Those belong to fluid-telegram, and the only contact with them is POST /v1/channel-posts.
  • Provisioning. The presence is declared here and applied there. This repository holds no token, no session and no credential of any kind.
  • Editing hall entries. The hall is a record. If a post cannot be written honestly from an entry, that is a reason not to write the post.
  • Publishing without a basis or a reviewer. Not a policy this repository may relax; the interface refuses such a post regardless.
  • Ranking contributors. The hall does not rank, and a campaign built on it must not introduce ranking by the back door — "most featured", "top contributor", or a cadence that quietly favours the same names.
  • Batch-publishing the backlog. Ninety-four posts in a burst is a rate-limit problem, an unkind introduction for a new subscriber, and ninety-four compositions nobody has had time to read properly. The backlog is a source to draw on, not a queue to drain.

Current State

Stub, freshly registered. The declared presence exists and validates. Composition, consent and the review queue do not yet exist here — they live temporarily in fluid-telegram under FT-WP-0001 T06/T07 and move here under T13, once the FLUID loop has closed at least once. Extracting a seam before it has been used is how you find out you cut it in the wrong place.

Registered with the Custodian State Hub: domain infotech, topic helix-forge, workplan prefix PRHOH-WP-.

Open and blocking:

  • The consent basis for the 94 existing entries. Nothing publishes until it is settled (FT-WP-0001 T07, with the record itself belonging in hall-of-helix/ENTRY.md).
  • presence/assets/helixforge-avatar.png is referenced by the spec but absent; provision apply fails on /setuserpic until it exists. Left for a person on purpose — it is the first thing a stranger sees of HelixForge on Telegram.

Getting Oriented

  • Why it exists: INTENT.md
  • What is published where: presence/telegram.yaml
  • The interface this campaign consumes: fluid-telegram/INTENT.md, and its governing document fluid-telegram/InterfaceEvolutionIntent.md
  • How the presence is provisioned: fluid-telegram/docs/provisioning.md
  • The source material: hall-of-helix/README.md
  • Agent instructions: AGENTS.md