diff --git a/INTENT.md b/INTENT.md index 509c54f..723d914 100644 --- a/INTENT.md +++ b/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. diff --git a/SCOPE.md b/SCOPE.md index 245c23e..4499054 100644 --- a/SCOPE.md +++ b/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`