diff --git a/internal/runtime/connector.go b/internal/runtime/connector.go
index 33256eb..17f4aa1 100644
--- a/internal/runtime/connector.go
+++ b/internal/runtime/connector.go
@@ -81,7 +81,7 @@ func (c *Connector) Call(ctx context.Context, rev contract.Revision, r *http.Req
 	}
 
 	// Only idempotent methods are retried. Replaying a POST because an adapter
-	// was slow would publish the same hall-of-helix entry twice.
+	// was slow would create the same resource twice.
 	if !idempotent(r.Method) {
 		attempts = 1
 	}
diff --git a/workplans/FLUID-WP-0008-fluid-telegram-handover.md b/workplans/FLUID-WP-0008-fluid-telegram-handover.md
index f653ce6..45cc9d8 100644
--- a/workplans/FLUID-WP-0008-fluid-telegram-handover.md
+++ b/workplans/FLUID-WP-0008-fluid-telegram-handover.md
@@ -4,12 +4,12 @@ type: workplan
 title: "Handover: HelixForge Telegram identity and hall-of-helix channel"
 domain: infotech
 repo: fluid-core
-status: active
+status: blocked
 flavor: implementation
 owner: worsch
 topic_slug: fluid-core
 created: "2026-09-04"
-updated: "2026-09-04"
+updated: "2026-09-27"
 planning_priority: high
 planning_order: 7
 depends_on:
diff --git a/workplans/FLUID-WP-0009-campaign-repos-and-example-separation.md b/workplans/FLUID-WP-0009-campaign-repos-and-example-separation.md
index cc8b4a4..1a3549b 100644
--- a/workplans/FLUID-WP-0009-campaign-repos-and-example-separation.md
+++ b/workplans/FLUID-WP-0009-campaign-repos-and-example-separation.md
@@ -4,12 +4,12 @@ type: workplan
 title: "Establish the pr- campaign repository pattern and reduce hall-of-helix to an example"
 domain: infotech
 repo: fluid-core
-status: active
+status: blocked
 flavor: implementation
 owner: worsch
 topic_slug: fluid-core
 created: "2026-09-04"
-updated: "2026-09-04"
+updated: "2026-09-27"
 planning_priority: medium
 planning_order: 9
 depends_on:
@@ -110,7 +110,7 @@ interface reports.
 
 ```task
 id: FLUID-WP-0009-T03
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "d9c69244-19ef-5eaf-9f43-d0374d6278de"
 ```
@@ -124,6 +124,31 @@ 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