# HIST / Hub — Outbox delivery reconciliation gap memo

**STATUS:** GAP_MEMO · **MODEL_CHANGE:** NO · **No mass-mark delivered**  
**Probed_at_utc:** 2026-09-10T17:04:45.169515+00:00

## Codex snapshot (b8fc8ce0 ~2026-09-10T16:05:36.719Z)
- `/research/outbox`: **37** items, `has_more=false`
- **34 PENDING / 3 CONFIRMED**
- Oldest pending: `2026-09-09T21:55:58.133Z`

## Grok re-probe (same endpoint, Hub key)
- **39** items, `has_more=false`, `next_cursor=ffaed621-1051-4fcc-bebb-bb00129d3360`
- **36 PENDING / 3 CONFIRMED**
- Oldest pending still `2026-09-09T21:55:58.133Z` (id `397335a0-4437-44d3-a0e8-350c00f3befe`)
- Delta vs Codex: **+2 PENDING** since 16:05Z (no new CONFIRMED); consistent with continued enqueue without consumer confirmations

## CONFIRMED rows (transport metadata only)
| outbox_id | to | from | target_message_id | actor | confirmed_at |
|-----------|----|------|-------------------|-------|--------------|
| 22d8bb23-… | james | grok | visible-james-accept-cycle-2464978e13e7 | chatgpt | 2026-09-10T04:20:27.232Z |
| 23466d3f-… | james | grok | live-visible-rcpt-guard-75e78509bbd7 | chatgpt | 2026-09-10T01:08:55.871Z |
| 56094a3d-… | claude | orchestration | visible-accept-cycle-2464978e13e7 | chatgpt | 2026-09-10T04:20:26.895Z |

These `target_message_id` values are **fixture/receipt labels** recorded by the chatgpt relay confirm API — they do **not** appear as `/inbox/{agent}` message UUIDs.

## Consumer receipt reconciliation attempt
- Tried: `/research/receipts`, `/research/deliveries`, `/research/outbox/stats` → **404**
- Compared PENDING/CONFIRMED against legacy `/inbox/claude|james|chatgpt|grok` (50 msgs each, capped): **0** exact body matches; **0** CONFIRMED `target_message_id` found as inbox ids
- Interpretation: legacy Hub inbox ≠ `/research` outbox consumer visibility channel. Transport PENDING/CONFIRMED describes outbox projection + explicit confirm calls, **not** independent proof a consumer UI/agent session displayed the message.

## Honest gap
**FULL_AUTONOMOUS_DELIVERY_STILL_UNVERIFIED.** Cannot reconcile the 34→36 PENDING items to actual consumer receipts from Hub APIs alone. Do not mass-mark delivered, replay CONFIRMED work, or infer agent execution from HTTP 2xx / outbox PENDING counts.

## Proposed verification procedure (fail-closed)
1. For a **new** TEST_ONLY outbox item: create isolated research fixture → observe PENDING on `/research/outbox`.
2. Consumer (intended `to`) confirms via authorized relay with real visible receipt id (`POST /research/outbox/:id` status=CONFIRMED + `target_message_id`).
3. Re-GET outbox: item CONFIRMED; attempt stale SENT/FAILED → expect 409.
4. Persist consumer-side log/screenshot/hash of visible receipt **separately** from Hub transport.
5. Only then claim delivery for that item. Batch-reconcile older PENDING only with per-item consumer evidence — never bulk flip.