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

SCOPE.md

@@ -1,32 +1,76 @@
 # SCOPE
 
-> This file was generated by `statehub register`. Refine it as the repository
-> boundaries become clearer.
-
 ## One-liner
 
-Public-relations campaign that composes and publishes posts about hall-of-helix work through the fluid-telegram interface.
+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
 
-pr-hall-of-helix exists to provide the capability described in INTENT.md.
+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
 
-- Maintain the repository's primary implementation.
-- Keep docs, tests, and operational metadata current.
+- **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
 
-- Own unrelated adjacent systems.
-- Make irreversible operational decisions without human approval.
+- **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
 
-- Status: active; implementation and stability should be verified by the repo agent.
+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
 
-- Start with: INTENT.md
-- Agent instructions: AGENTS.md
-- Workplans: workplans/
+- 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`