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
4.4 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated | planning_priority | planning_order | depends_on | related_repos | state_hub_workstream_id | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FLUID-WP-0009 | workplan | Establish the pr- campaign repository pattern and reduce hall-of-helix to an example | infotech | fluid-core | active | worsch | fluid-core | 2026-09-04 | 2026-09-04 | medium | 9 |
|
|
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
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
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
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
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
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.