b40c0e01e1
Some checks failed
ci / build (push) Has been cancelled
source: repo-manager reason: deterministic projection registration Assistant: claude-code Assistant-Model: opus Assistant-Process: 1116572@bnt-lap001 Assistant-Session: 8ba9bb93-a72a-4883-b189-2499cce5c400
132 lines
4.4 KiB
Markdown
132 lines
4.4 KiB
Markdown
---
|
|
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: active
|
|
owner: worsch
|
|
topic_slug: fluid-core
|
|
created: "2026-09-04"
|
|
updated: "2026-09-04"
|
|
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: todo
|
|
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.
|
|
|
|
## T02 — Establish pr-hall-of-helix
|
|
|
|
```task
|
|
id: FLUID-WP-0009-T02
|
|
status: todo
|
|
priority: medium
|
|
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.
|
|
|
|
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: todo
|
|
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.
|
|
|
|
## T04 — Reduce the Telegram case to a documented example
|
|
|
|
```task
|
|
id: FLUID-WP-0009-T04
|
|
status: todo
|
|
priority: low
|
|
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.
|