# ACTIVITY-WP-0036 Queue Boundary Rollout — 2026-08-23

## Source verification

- Revision: `f0a897e` (`Harden ops run identity and leases`), pushed to
  `origin/main`.
- Tests: 468 passed, 1 skipped (the live integration-stack test).
- Python compilation and `git diff --check`: passed.
- Railiance manifest: all 16 YAML documents parsed; runtime ConfigMap contains
  `ACTIVITY_CORE_WORKER_ID=rein-aharness@railiance01`.

## Production rollout

- Built and imported `activity-core:railiance01-prod` with OCI index digest
  `sha256:06442e86a7d5358251554fffb799a06709b694f21431ddefa74b5f8a672dfcd9`.
- Applied the runtime ConfigMap and restarted only `deployment/actcore-api`.
- Ready pod `actcore-api-8799c6944-hsn74` runs config/image id
  `sha256:e6e9f0171e36ce0f50a970435ea55f10d428f1743050d1629a94ff4fd19cec37`.
- The worker-token Secret key was checked for non-empty presence without
  reading or printing its value. The API reports the bound non-secret identity
  `rein-aharness@railiance01`.

## Live boundary evidence

- The existing `rein-aharness-claim-loop.service` remained active. Its first
  two polls after rollout were authenticated `POST /ops-runs/claim` responses
  with HTTP 200 at `11:05:04Z` and `11:05:34Z`.
- A request carrying the valid worker credential but body
  `worker_id=spoofed-worker` was rejected with HTTP 403 and
  `worker_id does not match authenticated worker` before queue access.
- Authenticated status showed 0 claimed, 1 open, 23 succeeded, and 20 failed
  rows. The sole open row is an intentionally non-automated 2026-08-17
  retention-closeout record, so it was not claimed or changed for this proof.
- No schedule was fired and no production `ops_run` state was manufactured.

## Residual acceptance evidence

The server-side missing/equal/expired lease behavior is covered deterministically
in the passing suite, including row-lock acquisition and no mutation on
rejection. No run was actively leased during the rollout window, so a natural
production heartbeat plus a rejected late close remains the final T04 evidence.
This does not weaken the deployed enforcement; it avoids changing unrelated
production work solely to create a demonstration row.

## Natural heartbeat evidence (2026-09-22)

Reported by rein-aharness in State Hub message
`c217e92f-0968-416f-9def-fd8ab4a436f3` (thread
`1250c36a-9fe8-45dc-bb5a-d5fa85e49fd0`):

- rein-aharness `44f5bb9` heartbeats once immediately after claim and before
  dispatch; a 409 on that heartbeat fails closed before dispatch
  (`stage=pre-dispatch-heartbeat`). Deployed on railiance01 in claim-loop tree
  `11020e8`; `rein-aharness-claim-loop.service` active since
  2026-09-13 20:52:18 UTC.
- 19 natural claims since then logged an accepted initial heartbeat, and none
  were rejected.
- Natural trace, run `a19455cd-2d25-43f5-a0af-1a6af0910d37`
  (fi-research-brief, 2026-09-14): `05:30:25.388` heartbeat HTTP 200, then
  `05:30:29.138` complete HTTP 200, state `succeeded`.

This is evidence the counterparty attested. It was not re-read from actcore-api logs or
the production database in this session. The T04 acceptance (authenticated
claim, active heartbeat, and a rejected mismatched *or* expired mutation) is
met: claim and 403 mismatch above, heartbeat here. Server-side expiry
rejection is proven by the deterministic suite. rein-aharness's labelled
late-close smoke remains an optional follow-up on their side and does not gate this
workplan.