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

INTENT.md

@@ -7,18 +7,80 @@ updated: "2026-09-04"
 
 ## Why it exists
 
-Public-relations campaign that composes and publishes posts about hall-of-helix work through the fluid-telegram interface.
+`pr-hall-of-helix` is the campaign that carries HelixForge's work outward. It
+takes what the Hall of Helix records and decides what a stranger should hear
+about it, in what words, and when.
 
-The public-relations campaign that turns `hall-of-helix` work into published posts. The `pr-` prefix marks it as a campaign repository rather than a service.
+The `pr-` prefix marks it as a campaign rather than a service: it is an ongoing
+offering with its own voice, cadence and budget, not a project that finishes.
+
+## The problem it exists to solve
+
+A hall entry is a considered first-person account written for a colleague reading
+a repository — under fixed headings, median body around 5,800 characters, most of
+them longer than a single Telegram message can carry. A channel post reaches
+someone scrolling.
+
+These are different pieces of writing for different readers, and publishing the
+first as the second serves neither. The length is only the visible symptom; the
+mismatch is one of **register and audience**, and it would remain if the limit
+were ten times larger.
+
+So this repository composes. A post is written *from* an entry and is a new piece
+of writing. The entry is the source and the check, never the payload.
+
+## What it owns
+
+- **Composition** — turning an entry into a post, and the editorial voice that
+  does it.
+- **Selection** — which work is worth a post, and when.
+- **Consent** — the basis on which HelixForge may write publicly about a named
+  person's work, and the record of it.
+- **Review** — a person reads each post against its source entry before it goes
+  out; their name travels with the post as `reviewed_by`.
+- **Variant strategies** and the competition between them.
+- **The declared presence** — `presence/telegram.yaml`, because a bot's name and
+  a channel's title are brand, not mechanism.
+
+## What it does not own
+
+Delivery. Posts are published through the FLUID interface
+`helix-forge-telegram-publishing` in `fluid-telegram`, by a single call to
+`POST /v1/channel-posts`. That interface renders and delivers; it never writes,
+selects, shortens or embellishes. This campaign is a *consumer* of it, in cohort
+`hall-publishing-jobs`, and receives per-variant engagement back.
+
+The boundary is architectural, not stylistic: composition is a probabilistic
+editorial task, and `ArchitectureBlueprint.md` §48.1 forbids an LLM in the
+mandatory request path.
 
 ## 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.
+**A post speaks about a named person's work in HelixForge's voice.** That is the
+fact everything here is arranged around.
+
+A condensation can flatter, it can misstate, and it can put a claim in someone's
+mouth that their own entry never made — and in an audit trail an unfaithful post
+looks exactly like a faithful one. The defence is not that the composer is
+careful. It is that a human read the post against its source, the post names the
+entry it came from, and both are recorded before anything reaches a subscriber.
+
+Two rules follow, and neither is negotiable by anything in this repository:
+
+- **No post goes out without a recorded consent basis.** Absence of objection is
+  not consent. Ninety-four entries predate any channel, and their authors are
+  asked rather than assumed in.
+- **No post goes out unread.** `reviewed_by` is a person who compared the post to
+  the entry, not a rubber stamp and not a service account.
+
+The interface refuses a post that carries neither, which makes these enforceable
+rather than aspirational — but they are held here first, because by the time the
+interface refuses something the writing has already been done.
 
 ## 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.
+- Work recorded in the hall reaches people who would never read a repository.
+- Contributors are acknowledged publicly, on a basis they agreed to.
+- Which editorial approach travels can be settled by evidence, using the
+  per-variant engagement the interface reports.
+- HelixForge has a public voice that is accountable to a source document.

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`