hub-core/workplans/HUB-WP-0011-statehub-inbox-freshness-and-cutover.md
tegwick 4153ad7305
Some checks failed
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / pytest-smoke (push) Failing after 2s
feat: consume account authority and refresh blocked dependencies
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a0e747-8f27-7242-8df8-8bc44f88c929
2026-10-04 12:12:09 +02:00

5.9 KiB

id type title domain repo status flavor owner topic_slug created updated origin origin_ref related state_hub_workstream_id
HUB-WP-0011 workplan State Hub inbox freshness and reader cutover infotech hub-core blocked residual codex infotech 2026-09-05 2026-10-04 residual HUB-WP-0010
STATE-WP-0079
RAPPCOREHUB-WP-0004
3c8034fc-fd90-58f5-99bc-99b4f93e5ee1

Establish ongoing inbox freshness

id: HUB-WP-0011-T01
status: wait
flavor: residual
priority: high
state_hub_task_id: "588e4b58-4694-513c-8e7a-1fab38fb6ce3"
blocking_reason: "State Hub must define a consistent source revision/cursor, read/archive changes, explicit deletions/retention and recovery semantics for the derived inbox; packaging owner must admit refresh/staleness operation."

The deployed inbox reader is an explicitly labeled one-time snapshot pilot. Define and implement monotonic source revision/cursor semantics, atomic refresh, read/archive updates, deletes/retention treatment and stale-source signaling. The initial importer deliberately refuses different existing rows; do not turn it into an unconditional overwrite loop. Prove recovery and idempotency without creating a second message writer. Decide the source/destination ownership boundary before live client traffic moves.

Loose-ends review 2026-09-27: left todo, not implemented in this pass. This task's own scope calls for a source/destination ownership boundary decision — who is authoritative for a message once both State Hub and hub-core hold a copy, and what "deletes/retention treatment" means for messages State Hub no longer serves (archive locally, tombstone, or refuse) — before writing the monotonic-cursor and upsert logic that would encode that decision durably against live message data. That is the same kind of call this workplan's T02 requires external review for, and it should not be made unilaterally in a loose-ends pass. Recommend Bernd (or a follow-up session with that decision in hand) confirms the ownership/retention boundary, after which the cursor and upsert implementation is a bounded, mechanical follow-on to the existing import_snapshot in hub_core/runtime/inbox_projection.py.

Admit the actual reader identity and full scope semantics

id: HUB-WP-0011-T02
status: wait
flavor: residual
priority: high
state_hub_task_id: "35c5ae8b-f357-512f-af40-bc5915f3c02d"
depends_on: [HUB-WP-0012-T02, HUB-WP-0012-T03, HUB-WP-0012-T05]
blocking_reason: "Selected reader owner must specify principal, recipient/broadcast/alias scope; identity/platform owners must deliver a dedicated workload grant and credential under the shared access contract."

Replace pilot operator authentication with the reviewed caller-specific access contract and delivered workload credential. Preserve recipient authorization, broadcast behavior, repository canonical/alias resolution, source timestamps and thread/read/archive semantics for the selected reader. The existing pilot supports only one literal agent and exact sender filters. Never distribute the operator token as an application credential.

2026-09-28 integration dependency: HUB-WP-0012-T02 through T05 own the shared NetKingdom identity, policy and workload-caller contract. Reuse that contract here; this task retains inbox-specific recipient/alias semantics. The root-only human milestone does not authorize an automated reader as root or close the freshness and reader-switch tasks.

Execute one reviewed client switch

id: HUB-WP-0011-T03
status: wait
flavor: residual
priority: high
state_hub_task_id: "61c727a5-f4b1-54c0-b634-7d71a5416496"
depends_on: [HUB-WP-0011-T01, HUB-WP-0011-T02]
blocking_reason: "Needs fresh parity and caller-admission receipts plus a State Hub/client-owner authorized reversible reader switch."

After T01/T02 pass, produce live freshness and parity receipts for one State Hub inbox reader; verify rollback to the current State Hub endpoint. Then execute that bounded reader switch with the concrete deployment authorization. Retire its compatibility dependency only after metered acceptance. Message-writer cutover and all other route families remain separate STATE-WP-0079 work.

Dependency review — 2026-10-04

T01 is now wait, not runnable todo. STATE-WP-0079's T08/T09 record confirms State Hub remains the message writer; that ownership is no longer an unanswered question. The unprovided contract is how its mutable inbox is replicated:

Receiving task Required owner artifact Resume/acceptance condition
T01 state-hub: versioned consistent snapshot/change-feed format, monotonic revision or cursor, read/archive changes, deletion versus retention semantics, replay/compaction recovery and source timestamp Implement atomic derived refresh only against that contract; prove replay, out-of-order refusal, deletion treatment and freshness loss without writing source messages
T01 rapp-core-hub: deployment/refresh runner, admitted source-read identity, selected maximum lag and stale-source behavior Test restart/recovery and publish bounded freshness evidence; historical pilot hash is not freshness
T02 Selected reader owner + NetKingdom/access-engine/platform: exact workload identity/audience/actions, recipient and broadcast visibility, canonical/alias resolution and delivered credential reference Prove allowed scope and denied other recipients without the pilot operator token
T03 state-hub + selected client owner: named single reader, parity sample/window, rollback endpoint and switch authorization Rehearse rollback, execute only that switch, then retain metered acceptance

No source feed or revised retention contract was found in the reviewed source handoff. The existing one-shot importer correctly refuses changed rows; no unconditional overwrite or speculative tombstone policy was added. All three tasks now wait on explicit inputs, so the workplan remains blocked.