---
id: ACTIVITY-WP-0015
type: workplan
title: "Adopt State Hub Beachhead Endpoint"
domain: infotech
repo: activity-core
status: blocked
owner: claude
topic_slug: activity-core
created: "2026-06-24"
updated: "2026-06-24"
state_hub_workstream_id: ""
---

# Adopt State Hub Beachhead Endpoint

Carries the **blocked remainder** of [[ACTIVITY-WP-0014]] T05. The in-repo half
(idempotency-keyed State Hub writes) shipped in WP-0014; this workplan is the
client-side adoption that depends on the state-hub-owned **beachhead** capability
(per-machine read cache + write outbox) existing first.

**Blocked on:** the state-hub beachhead (proposal sent to the `state-hub` agent,
2026-06-23). Do not build queue/cache logic in activity-core — see
[[statehub-beachhead-principle]].

## Point STATE_HUB_URL at the beachhead

```task
id: ACTIVITY-WP-0015-T01
status: wait
priority: medium
state_hub_task_id: ""
```

Once the state-hub beachhead exposes a local endpoint, point activity-core's
`STATE_HUB_URL` (and the railiance runtime config) at it and verify reads are
served from cache and writes are queued/flushed correctly when central State Hub
is unreachable. Confirm idempotency-keyed writes dedup on flush (no duplicate
`daily_triage`/progress events).

## Retire the bespoke actcore-state-hub-bridge proxy

```task
id: ACTIVITY-WP-0015-T02
status: wait
priority: medium
state_hub_task_id: ""
```

Remove the inline `hostNetwork` HTTP proxy `actcore-state-hub-bridge` from
`k8s/railiance/20-runtime.yaml` — it is a primitive precursor of the beachhead
and should be replaced by the state-hub-owned component, not extended. Re-verify
the daily triage end-to-end after cutover, including an overnight scheduled run
while the workstation is asleep (the original failure condition).