Reframe the interface around composed posts, not republished entries

The channel publishes a post written from a hall entry -- condensed,
personal, reach-optimized -- not the entry itself. That changes what
this interface is for and where its boundary sits.

Composition is deliberately outside the interface. Composing is a
probabilistic editorial task, and Blueprint 48.1 forbids an LLM in the
mandatory request path, so an interface that composed on demand would be
non-deterministic exactly where determinism is the whole claim. It is
also editorial: a post speaks about a named person's work in
HelixForge's voice, and a review step inside the request path is a
review step nobody performs.

The contract now takes a composed post with a required reviewer, a cited
source entry and a consent basis. A post carrying none of those is
refused. Absence of objection is not consent, and in an audit trail an
unfaithful post looks exactly like a faithful one -- the defence is that
a human read it, the source is named, and both are recorded.

The first experiment is rebuilt accordingly. The old competition asked
how to fit a whole entry into Telegram; that question no longer exists.
The new one asks whether the portrait earns the 3072 characters of
caption limit it costs, which is a delivery question this interface
actually owns. Competition over editorial voice belongs to the campaign
and runs on the per-variant engagement this interface reports.

Adds T05b (composition and review), T05c (consent basis for the 94
existing participants, blocking public publication) and T11 (extracting
the campaign into pr-hall-of-helix).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014KmVxhJ35tCo7rE7UnLwWu

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1116572@bnt-lap001
Assistant-Session: 8ba9bb93-a72a-4883-b189-2499cce5c400

InterfaceEvolutionIntent.md

@@ -59,21 +59,37 @@ Raising the mode is a governance change under §20, not an operational decision.
 
 ### Mission statement
 
-> Make hall-of-helix entries reliably and faithfully available to a Telegram
-> audience, without the people writing them having to think about Telegram.
+> Deliver composed channel posts to a Telegram audience reliably, verifiably,
+> and without an unreviewed word ever reaching a subscriber.
 
-An entry is written once, as Markdown, in `hall-of-helix/entries/`. Everything
-about how it becomes a Telegram post — length, formatting, media, threading —
-is this interface's problem and nobody else's.
+The unit of publication is a **post**, not a hall entry. A post is short,
+personal and written to travel; a hall entry is a considered first-person
+account written for someone reading a repository. They are different pieces of
+writing for different readers, and the second is the source of the first rather
+than its content.
+
+**Composition is not this interface's job.** Turning an entry into a post that
+is condensed, entertaining and reach-optimized is a probabilistic, editorial
+task. It happens upstream, before this interface is called. Two reasons, and
+the first is architectural rather than stylistic:
+
+1. `ArchitectureBlueprint.md` §48.1 names an LLM in the mandatory request path
+   as an anti-pattern. An interface that composed on demand would be
+   non-deterministic at exactly the point where determinism is the whole claim.
+2. A composed post speaks about a named person's work in HelixForge's voice.
+   That deserves a human read before it goes out, and a review step in the
+   request path is a review step nobody performs.
 
 ### Success looks like
 
-- A finished hall entry reaches the channel without a human reformatting it.
-- The published form is faithful: no entry is silently truncated, and no
-  attribution is lost.
+- A composed post reaches the channel without a human formatting it for
+  Telegram.
+- No post reaches a subscriber unreviewed.
+- Every post is traceable to the entry it was written from, so a claim can be
+  checked against what the person actually said.
 - Publishing twice does not post twice.
-- When Telegram's constraints and the entry's shape conflict, the conflict
-  surfaces as recorded pressure rather than as a mangled post.
+- Engagement is attributable to the composition strategy that produced it, so
+  the campaign can learn which writing travels.
 
 ---
 
@@ -105,10 +121,13 @@ is this interface's problem and nobody else's.
 
 ### In scope
 
-- Publishing hall-of-helix entries to a Telegram channel (Canon PUB-01).
-- Rendering an entry into Telegram's message forms (Canon PUB-02, MED-02).
+- Publishing composed posts to a Telegram channel (Canon PUB-01).
+- Rendering a post into Telegram's message forms (Canon PUB-02, MED-02).
+- Attaching a visual to a post (Canon MED-01).
 - Publication state: what was published, when, as which message.
-- Idempotency and correction of previously published entries.
+- Idempotency and correction of previously published posts.
+- Recording the composition variant a post came from, and reporting engagement
+  against it.
 - Bot identity presentation (Canon BOT-01).
 
 ### Conditionally in scope
@@ -116,12 +135,14 @@ is this interface's problem and nobody else's.
 Capabilities that may be introduced if evidence justifies them:
 
 - Scheduling a publication for a later time.
-- Publishing other HelixForge artifacts, such as release notes.
-- Attaching entry visuals as media (Canon MED-01).
+- Publishing other HelixForge material, such as release notes.
 - A linked discussion group for comments.
+- Publishing to more than one channel from one call.
 
 ### Out of scope
 
+- **Composing post text from a source entry.** This belongs to the campaign
+  that owns the editorial voice, not to the interface that delivers it. See §7.
 - Inbound bot commands and conversation (Canon BOT-02, AGT-01). A second
   revision family may add this later; it is not this interface today.
 - Payments and paid content (Canon PAY-*).
@@ -135,20 +156,28 @@ Capabilities that may be introduced if evidence justifies them:
 
 ### Responsibilities owned by this interface
 
-- Representation: how an entry becomes one or more Telegram messages.
-- Composition: assembling an entry, its metadata and its visual.
-- Validation: refusing an entry that cannot be published faithfully.
+- Representation: how a composed post becomes a Telegram message.
+- Delivery: attaching the visual, the source link, the formatting.
+- Validation: refusing a post that arrives unreviewed, unattributed, or in a
+  form Telegram cannot carry.
 - Routing: which revision serves a publication request.
-- Idempotency: recognising an entry it has already published.
+- Idempotency: recognising a post it has already published.
+- Attribution of engagement to composition variants.
 
 ### Responsibilities owned by backend systems
 
 | Backend | Responsibility | Boundary |
 |---|---|---|
 | Telegram Bot API | Message delivery, channel state, subscriber identity | FLUID may request delivery. It may not assume a limit will move, and must treat platform constraints as fixed. |
-| `hall-of-helix` | Entry content, its correctness, and whether it is finished | FLUID may read entries. It must never edit one to make it publishable. |
+| `pr-hall-of-helix` (planned) | Composing posts, the editorial voice, choosing what is worth publishing, obtaining subject consent | FLUID publishes what it is given and reports how it performed. It does not write, edit or select. |
+| `hall-of-helix` | Entry content, its correctness, and whether it is finished | FLUID never reads or edits an entry. Its only knowledge of one is the id and URL a post cites. |
 | OpenBao | Custody of the bot token | FLUID receives a credential. It never stores, logs or forwards one. |
 
+Until `pr-hall-of-helix` exists, composition is done by hand as part of
+`FT-WP-0001`. That is a temporary arrangement, and the boundary above is
+written for the state it is heading toward rather than the state it is in — so
+that the campaign, when it is extracted, finds the seam already cut.
+
 ### Explicit non-authority
 
 The Daimon must not autonomously:
@@ -156,14 +185,20 @@ The Daimon must not autonomously:
 - create, rename or delete Telegram channels, groups or bots;
 - change channel membership, administrators or permissions;
 - read, rotate or re-scope the bot token;
-- edit or truncate a hall-of-helix entry to fit a platform constraint;
+- compose, rewrite, shorten or embellish post text;
+- publish a post that carries no reviewer;
 - publish to any chat other than those declared in the routing configuration;
-- post on behalf of a person who has not asked for it.
+- publish a post about a person who has not consented, on either basis in §15.
 
-The last of these matters most. A hall entry is a first-person account someone
-wrote about their own work. Publishing it is an act taken on their behalf, and
-that authority comes from their having written it — not from the interface
-finding it convenient.
+The last two matter most, and they are the reason composition sits outside this
+interface. A post is a condensation written in HelixForge's voice about a named
+person's work. It can flatter, it can misstate, and it can put a claim in
+someone's mouth that their own entry never made — and in the 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, the post names the entry it came from, and both are recorded before
+anything reaches a subscriber.
 
 ---
 
@@ -171,23 +206,29 @@ finding it convenient.
 
 ### Concepts consumers should naturally understand
 
-- An **entry** is the unit of publication, identified by its hall entry id.
-- Publishing is **idempotent** on that id.
+- A **post** is the unit of publication, identified by its own post id.
+- A post **cites** the hall entry it was written from; it is not that entry.
+- Publishing is **idempotent** on the post id. A recomposition is a new post,
+  because it is a different piece of writing about the same work.
 - A **publication** has state: pending, published, failed, superseded.
 
 ### Interaction patterns considered natural
 
-- Publish one finished entry, then check its state.
-- Re-publish the same entry after a correction and get the same message updated.
-- List what has been published to reconcile against the hall.
+- Compose a post, have it reviewed, publish it, check its state.
+- Re-publish the same post id after a correction and get the same message
+  updated.
+- List publications by composition variant to compare how they performed.
 
 ### Expectations that should be discouraged
 
-- That Telegram formatting is Markdown. It is not, and entries that assume so
+- That Telegram formatting is Markdown. It is not, and posts that assume so
   will render wrongly.
-- That an entry appears instantly. Rate limits are real.
-- That a long entry arrives as one message. It cannot, and the interface's job
-  is to make that invisible rather than to pretend otherwise.
+- That a post appears instantly. Rate limits are real.
+- That this interface will shorten an over-length post. It will refuse it. A
+  composition that does not fit was not condensed, and deciding what to cut is
+  the composer's judgement, not the deliverer's.
+- That publishing a hall entry is possible. It is not: entries are sources, and
+  posts are what this interface carries.
 
 ---
 
@@ -203,10 +244,10 @@ volume.
 
 | Dimension | Priority | Target / Constraint | Notes |
 |---|---:|---|---|
-| Correctness | High | No entry published in a form that loses content | Hard guardrail |
-| Client utility | High | One call publishes one entry | The reason the interface exists |
+| Correctness | High | No post published unreviewed or unattributed | Hard guardrail |
+| Client utility | High | One call publishes one post | The reason the interface exists |
 | Reliability | High | Publication succeeds or reports why | |
-| Discoverability | High | A reader can reach the full entry | Drives the first experiment |
+| Discoverability | High | A reader can reach the source entry | Drives the first experiment |
 | Security | High | Token never leaves its custody | Hard guardrail |
 | Compatibility | Medium | Versioned evolution | Few consumers, all internal |
 | Simplicity | Medium | Prefer one publication concept | |
@@ -226,7 +267,7 @@ volume.
 | Dimension | Current | Preferred | Maximum | Scoring method |
 |---|---:|---:|---:|---|
 | Surface area (operations) | 3 | 4 | 8 | Count of declared operations |
-| Concept count | 2 | 3 | 5 | entry, publication |
+| Concept count | 2 | 3 | 5 | post, publication |
 | Parameter dimensionality | 4 | 6 | 12 | Declared parameters across operations |
 | Semantic overlap | 0 | 0 | 1 | Operations meaning the same thing |
 | Alternative-path count | 1 | 1 | 3 | Ways to achieve one outcome |
@@ -242,7 +283,9 @@ volume.
   another endpoint.
 - A candidate exceeding a hard maximum must not be promoted.
 - Presentation adaptations do not consume surface-area budget: they change how
-  an entry is rendered, not what the interface offers.
+  a post is delivered, not what the interface offers.
+- Any candidate that would move composition inside this interface is rejected
+  regardless of its complexity score. That boundary is not a budget question.
 
 ---
 
@@ -258,8 +301,9 @@ volume.
 - Breaking changes require a successor revision.
 - Every consumer is internal and known, so a breaking change is a coordination
   problem rather than a public one — but it is still a successor revision.
-- A change to how an entry is *rendered* is a presentation adaptation and does
-  not break the contract, even though readers will notice it.
+- A change to how a post is *delivered* — visual placement, link style,
+  formatting — is a presentation adaptation and does not break the contract,
+  even though readers will notice it.
 
 ### Coexistence expectations
 
@@ -325,6 +369,12 @@ success criteria, guardrails, complexity impact, risk, expected learning value.
 defensible answers, and choosing between them by argument rather than evidence
 is exactly the habit FLUID exists to break.
 
+Note the division of labour. Competitions about **delivery** — does a visual
+help, does a link preview help — belong to this interface and are run here.
+Competitions about **composition** — which editorial voice travels — belong to
+the campaign, and are run on the per-variant engagement this interface reports.
+Both are legitimate FLUID experiments; only the first is this interface's.
+
 ### Reach preference
 
 Prefer the smallest sufficient adaptation. This interface is small enough that a
@@ -378,6 +428,23 @@ population, not a caller.
 
 Single tenant. The interface serves HelixForge and no one else.
 
+### Subject consent
+
+A post speaks publicly about a named person's work. Two bases are recognised:
+
+- **standing** — the contributor agreed, when they took a seat in the hall,
+  that HelixForge may write about that work publicly. This is the ordinary case
+  and requires the agreement to actually exist, in `hall-of-helix/ENTRY.md`, and
+  to be revocable.
+- **explicit** — per-post approval from the subject. Required where the post
+  makes a claim the entry does not, quotes the subject, or concerns work they
+  have since asked not to be publicised.
+
+`not-required` covers posts about the project itself with no personal subject.
+
+A post carrying no basis is refused with 403. Absence of objection is not
+consent, and the interface must not treat it as such.
+
 ### Data handling
 
 Telegram user identity (Canon ID-01) must not enter the evidence store in any
@@ -388,9 +455,13 @@ consumers must not quietly learn about audiences.
 
 ### Logging and provenance
 
-Every publication records which entry, which revision, which message, and which
-consumer asked. The bot token appears in no log, error, telemetry event or
-evidence record.
+Every publication records which post, which source entry, which reviewer, which
+revision, which message, and which consumer asked. The bot token appears in no
+log, error, telemetry event or evidence record.
+
+Post *text* is retained in the publication record. It is what was said in
+HelixForge's name, and an audit that could not reproduce it would be unable to
+answer the only question that matters when a post is disputed.
 
 ### AI boundary
 
@@ -404,14 +475,15 @@ reaches this interface at all.
 
 | Quality attribute | Requirement | Hard guardrail? |
 |---|---|---:|
-| Correctness | No published entry loses content or attribution | yes |
-| Idempotency | Publishing an entry twice yields one publication | yes |
+| Correctness | No post published without a reviewer and a cited source entry | yes |
+| Consent | No post about a subject without a recorded basis | yes |
+| Idempotency | Publishing a post twice yields one publication | yes |
 | Availability | Best effort; publication may be retried | no |
 | Reliability | A failed publication reports why and may be retried safely | yes |
 | p95 latency | Under 10s excluding Telegram rate limiting | no |
 | Error rate | Under 1% of publication attempts | yes |
 | Security | Token never leaves custody | yes |
-| Auditability | Every publication traceable to entry, revision and caller | yes |
+| Auditability | Every publication traceable to post text, source entry, reviewer, revision and caller | yes |
 | Rollback | Any revision can be replaced by its predecessor within one policy generation | yes |
 
 ---
@@ -503,5 +575,9 @@ of scope, the first 100 subscribers, or annually.
 The Daimon should optimize aggressively inside this document and remain
 conservative at its boundaries.
 
-This interface may evolve in how it presents an entry. It may not evolve in
-whose voice it speaks.
+This interface may evolve in how it delivers a post. It may not evolve into
+writing one.
+
+The voice belongs to the campaign, the work belongs to the person who did it,
+and this interface's job is to carry the first without misrepresenting the
+second.