# STATE-WP-0079 caller and receiver review — 2026-09-05

## Actions and scope

User authorized the proposed SBOM meter retirements, caller tracing/migration,
and refreshed cutover checklist. No application image, production writer,
network policy, runtime deployment, or compatibility handler was changed.

A fresh seven-day primary review re-confirmed both candidates before mutation.
Direct Nexus licence-report and snapshot reads returned HTTP 200 from the State
Hub pod. Both meter records were patched with STATE-WP-0079-T05 provenance.
The saved before/after receipt is
`STATE-WP-0079-sbom-retirement-20260905.json`: eight retired, seven legacy,
zero remaining candidates. Handler deletion is not claimed by meter retirement.

## Caller trace

Searched non-hidden source trees under `/home/worsch` for `workstream_id`,
`/workstreams`, and the two SBOM endpoints, covering Python, shell, JS/TS and
YAML while excluding tests, dependency trees, docs, archives and fixtures.
517 matching lines were triaged by receiver and operation. A second Markdown
instruction scan excluded workplans, generated indexes, docs, archives and
session evidence. Matching strings alone were not treated as runtime callers.

- Repo Manager's licence-report client uses explicit `SBOM_NEXUS_URL`; it is a
  direct Nexus client, not evidence of a State Hub caller.
- SBOM Nexus importer intentionally reads source and target snapshots/licences
  for migration comparison. Its matching paths do not establish ongoing use.
- The bundled State Hub skill advertised removed `create_workstream` and
  `POST /workstreams/`; README and dashboard goals documentation also described
  retired routes as supported. Corrected these to current workplan contracts,
  file-first sync and component attribution.
- No current hard-coded State Hub workstream route caller was found in the
  scanned runtime sources. This does not cover hidden installations, remote
  checkouts, dynamically built paths or past one-off commands.

Targeted local agent-session review extracted only tool-call timestamp, working
repository and legacy path. Full session contents were not copied into evidence.

| Time (UTC) | Caller context | Observed operation | Confidence / correction |
| --- | --- | --- | --- |
| 2026-09-04 17:21:25.339 | Claude agent, fluid-telegram | Task query with legacy `workstream_id`, targeting `f2373858-c932-5a4d-81b6-db9a3595135a` | Actual command in session history; within four seconds of meter last_seen 17:21:29.173850. Strong correlation, not request-ID proof. AGENTS.md now prescribes canonical query and `X-StateHub-Component: fluid-telegram` |
| 2026-08-29 12:57:27.083 | Claude agent, ops-warden | Task query with legacy `workstream_id`, targeting `ae3ff76f-883d-5e2f-b6aa-144d61e8fdef` | Actual command in session history. AGENTS.md now prescribes canonical query and `X-StateHub-Component: ops-warden` |

Caller guidance commits: fluid-telegram `f7af151`, ops-warden `96dbb22`.
Both changes are restricted to the repository-owned AGENTS.md extension.

Replayed only the **canonical** task queries with those component headers:
HTTP 200, 8 and 5 tasks respectively. No legacy query was replayed, so the
retirement clocks were not reset by verification. Agent instructions reduce
future misuse; they do not prove that future sessions will follow them.

Remaining attribution: the meter's 11 task-filter calls are not all individually
explained, seven workstream-detail calls remain unidentified, and the one SBOM
index call remains unidentified. These are STATE-WP-0079-T07 live work, not
claimed completed migrations.

## Log retention limit

Requested seven days of `deployment/state-hub` pod logs. Available logs start
2026-09-04T20:10:36Z, after the relevant last-seen timestamps. No matching legacy
requests appear in that retained interval. Kubernetes has no previous container
log for this pod. Hence these logs cannot retrospectively identify the calls;
absence in this interval is not evidence of seven quiet days.

## Receiving runtime probe

The live State Hub deployment image was `main-cdff3b7`; its configmap directs
both SBOM read and write compatibility paths to the cluster Nexus service.

`core-hub-api` and `core-hub-api-candidate` deployments both reported 1/1 ready.
From the State Hub pod, requests to both Core Hub service addresses on port 8010
were connection-refused. Cause was not established and no connectivity change
was made. From candidate pod loopback, `/openapi.json` returned a **Hub Core
Runtime** schema with 31 paths. It exposes `/api/v2/interaction-events`, but no
`/messages`, `/progress`, `/token-events` or `/interface-changes` family.

Shared Python routers exist for messages/progress, but importing them into
State Hub does not deploy them on the owner runtime or migrate their rows.
HUB-WP-0005's successful Core Hub `/api/v2` absorption must not be used as proof
of the State Hub family cutover. STATE-WP-0079-T08 owns the bounded follow-up:
identify/expose one deployed message-read contract, historical data projection,
transport and parity/rollback evidence before changing any reader/writer.

## Validation

- Live primary identity and fresh seven-day eligibility verified before PATCH.
- Direct receiving SBOM reads: 200; canonical caller task reads: 200.
- State Hub skill passes the skill-creator frontmatter validator; this also
  corrected an existing unquoted colon that made its description invalid YAML.
- Documentation and caller-instruction edits pass `git diff --check`.
- No executable application code changed; no database test suite was needed.