Close FLUID-WP-0009 T03 and mark blocked workplans as such

Audited fluid-core for accidental coupling to the Hall of Helix campaign
(redaction defaults, classifier thresholds, fitness metric names,
examples/echo-interface): none found beyond the deliberate conformance
handover test. Generalized one stray "hall-of-helix" example in a
connector.go comment.

FLUID-WP-0008 and FLUID-WP-0009 have no remaining tasks this repo can
act on — the rest are blocked on human steps (BotFather, Telegram
channel creation) or on other repos (fluid-telegram FT-WP-0001 T12,
a second fluid-x/fluid-substack interface) — so both move to status:
blocked.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: sonnet
Assistant-Process: 251457@bnt-lap001
Assistant-Session: fbcdbf1e-8619-4c11-a73f-2fd270008c35

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
 	}

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:

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