fluid-core/workplans/FLUID-WP-0009-campaign-repos-and-example-separation.md

---
id: FLUID-WP-0009
type: workplan
title: "Establish the pr- campaign repository pattern and reduce hall-of-helix to an example"
domain: infotech
repo: fluid-core
status: blocked
flavor: implementation
owner: worsch
topic_slug: fluid-core
created: "2026-09-04"
updated: "2026-09-27"
planning_priority: medium
planning_order: 9
depends_on:
  - FLUID-WP-0008
related_repos:
  - fluid-telegram
  - fluid-x
  - fluid-substack
  - hall-of-helix
  - helix-forge
state_hub_workstream_id: "b6459dd0-fc4f-54a4-a2e9-d7b83cff6c6e"
---

# FLUID-WP-0009 — Campaign repositories and example separation

Two things this framework needs before it is genuinely reusable, and neither is
urgent enough to block the first Telegram publication.

**A place for campaigns to live.** Publishing the Hall of Helix is an ongoing
public-relations offering with its own editorial voice, cadence, consent
records and budget. Today it lives inside `FT-WP-0001`, a workplan that is
supposed to finish. It needs a repository.

**A framework that is not about one campaign.** While the only worked example is
the Hall of Helix, it is hard to tell which parts of fluid-core and
fluid-telegram are general and which quietly assume that particular use. The
test of a framework is a second consumer, and the honest way to find the
accidental couplings is to look for them deliberately.

This workplan should start after `FT-WP-0001` T12 — the loop closing once on
real traffic. Extracting a seam before using it is how you learn you cut it in
the wrong place.

## T01 — Define the pr- repository convention

```task
id: FLUID-WP-0009-T01
status: done
priority: medium
state_hub_task_id: "2a3aab85-e464-5b17-980f-1896ecd3794f"
```

Write down what a `pr-` repository is, so the second one does not have to be
reverse-engineered from the first.

The prefix covers public relations, promotion and propaganda — deliberately
including the uncomfortable third word, because a campaign repository that
cannot name what it is doing will not govern it well.

A `pr-` repo should carry: its own `INTENT.md`; a campaign intent describing
audience, voice and what it will not say; consent records for anyone it writes
about; composition strategies as named variants; and a publishing cadence. It
consumes one or more `fluid-*` interfaces and owns none of them.

**Written: `docs/campaign-repositories.md` (2026-09-04.)** It adds a review step
to the list above, the boundary table against `fluid-*`, the registration rules
(domain and topic follow the *subject*, since the domains are market sectors and
none of them is "marketing"), and the point that a campaign may run its own FLUID
loop over its own artifacts without merging it into the interface's.

It states its own test: whether a second campaign can be created from the
document without reading `pr-hall-of-helix`. Until that happens it describes one
case rather than a general rule — the same caution T05 applies to the framework.

## T02 — Establish pr-hall-of-helix

```task
id: FLUID-WP-0009-T02
status: wait
depends_on: [FT-WP-0001-T12]
priority: medium
blocking_reason: "Campaign move waits until the FLUID loop has closed once (FT-WP-0001 T12); the repository itself already exists."
state_hub_task_id: "7d40da89-9a4d-5358-ae2b-7a1a1339efff"
```

Create the repository and move the campaign into it, per `FT-WP-0001` T13. The
split is already written there; this task is the execution and the registration
with the State Hub under the `infotech` domain.

**Partly done, ahead of the sequencing above (2026-09-04).** The repository
exists, is registered (domain `infotech`, topic `helix-forge`, prefix
`PRHOH-WP-`), and carries a grounded `INTENT.md` and `SCOPE.md` plus the declared
Telegram presence at `presence/telegram.yaml`.

It was created early because provisioning needed somewhere to put the presence
spec — a bot's name and a channel's title are editorial, and putting them in the
delivery interface would have cut the seam in the wrong place immediately.

What remains is the part the sequencing was actually protecting: **the campaign
itself has not moved.** Composition and the review queue still live in
`fluid-telegram` under `FT-WP-0001` T06/T07, and should stay there until the loop
has closed once (T12), as `FT-WP-0001` T13 says.

The campaign becomes a consumer of `fluid-telegram` in cohort
`hall-publishing-jobs`, and runs its own FLUID loop over its own artifacts —
which composition variant travels — using the per-variant engagement the
interface reports.

## T03 — Find what fluid-core assumes about the Hall of Helix

```task
id: FLUID-WP-0009-T03
status: done
priority: medium
state_hub_task_id: "d9c69244-19ef-5eaf-9f43-d0374d6278de"
```

Audit fluid-core for anything that assumes this particular campaign. The
conformance handover test already couples the two repositories deliberately;
check whether anything else does so by accident.

Known candidates to check rather than assume clean: default redaction patterns,
the classifier's thresholds, the fitness metric names, and whether
`examples/echo-interface` is doing enough work to be the general example it
claims to be.

**Audited (2026-09-27).** No accidental coupling found:

- `internal/observation/redact.go` `DefaultRedactionPolicy` — patterns target
  bearer tokens, emails and connection strings; nothing Telegram- or
  hall-of-helix-specific.
- `internal/observation/classify.go` `DefaultClassifierOptions` — thresholds
  (`RepeatThreshold`, `MinConsumers`, `ErrorRateThreshold`) are generic
  interaction-shape numbers, not tuned to one interface's traffic.
- `internal/fitness/fitness.go` — metric names are caller-supplied strings
  (`MetricSpec.Name`); the package carries none of its own.
- `examples/echo-interface` — already the general §33 worked example
  (`GET /v1/entries` / `GET /v1/entries/latest`); it has no dependency on the
  Telegram case and is deliberately kept separate from it.
- One accidental reference: a comment in `internal/runtime/connector.go`
  naming "hall-of-helix" as the illustrative example for why non-idempotent
  methods aren't retried. Generalized to "the same resource" — no functional
  coupling, just a stray name in prose.
- The only deliberate coupling is the conformance handover test
  (`conformance/loop/loop_test.go`, `internal/control/api_test.go`) using
  `hall-publishing` as its interface ID, exactly as this task already expected.

Conclusion: fluid-core does not quietly assume the Hall of Helix campaign.
T05's second-interface test remains the real proof, but nothing found here
would block it.

## T04 — Reduce the Telegram case to a documented example

```task
id: FLUID-WP-0009-T04
status: wait
priority: low
depends_on: [FLUID-WP-0009-T02]
blocking_reason: "Campaign must live elsewhere first (T02)."
state_hub_task_id: "ec77e62c-1251-5331-a1a8-42985fb97b94"
```

Once the campaign lives elsewhere, `docs/handover/fluid-telegram.md` becomes a
worked example rather than a live handover: here is a real interface, here is
the pressure it faced, here is how the loop closed on it.

That is more valuable as documentation than it is as history, and it is the
form `fluid-x` and `fluid-substack` will want to read.

## T05 — Prove reuse with a second interface

```task
id: FLUID-WP-0009-T05
status: todo
priority: low
state_hub_task_id: "227d0d53-f325-5d95-8a18-d56603c820fd"
```

The real test of T03. Take `fluid-x` or `fluid-substack` from empty capability
canon to a published R-1, and record honestly how much of the fluid-telegram
handover transferred unchanged.

Whatever did not transfer is the accidental coupling, and finding it this way is
cheaper than arguing about it in advance.