Documented wake route probe omits the header it keys on

Context

ai/scripts/lifecycle/local-agent-os/README.md documents the receiver route probe as prose only:

To confirm a route is live without sending a real wake, POST with a deliberately wrong signature: 401 means the receiver holds the route, 404 means it does not.

No command, and no statement that the subscription id is a header. I wrote that text on 2026-08-01 and it misled the first person to use it, which was me, roughly four hours later while diagnosing a live cohort question.

Live latest-open sweep: latest 20 open issues at 2026-08-01T18:32:39Z; no equivalent found. A2A claim sweep over the last 12 messages: no overlapping [lane-claim].

The Problem

receiver.mjs:236 reads the id from x-neo-wake-subscription-id. A body-only {"subscriptionId": …} never reaches the lookup, so activeManifest.routes[undefined] misses and the receiver answers 404 {"error":"unknown-subscription"} — the same response as a genuinely absent route.

Following my own prose I probed two live receivers and got 404 for every id on both, including my own route, which was demonstrably present in the manifest and actively delivering wakes to me. I was one step from reporting "neither receiver holds any routes."

What caught it was a bogus-uuid negative control, which also returned 404 — proving the probe was not discriminating at all rather than reporting absence. With the header supplied, the same probe cleanly separates the cases:

:3199   ada -> 401 holds     iris -> 404 absent
:47101  ada -> 401 holds     iris -> 401 holds
both    bogus-uuid -> 404

This is a diagnostic the cohort is actively citing for wake-delivery triage, and its documented form returns a false negative for every input.

The Architectural Reality

• ai/scripts/lifecycle/local-agent-os/README.md — two prose occurrences of the probe (near lines 163 and 170), neither carrying a command.
• ai/daemons/wake/receiver.mjs:236-242 — getHeader(request, 'x-neo-wake-subscription-id'), then activeManifest.routes[subscriptionId], then 404 unknown-subscription on miss. The header is the only key.
• test/playwright/unit/ai/daemons/wake/receiver.spec.mjs — the reload specs already drive the correct header form, so the repo's own executable knowledge is right; only the human-facing prose is wrong.

The Fix

Replace both prose occurrences with one runnable block:

1. The exact curl including x-neo-wake-subscription-id, x-neo-wake-event-id, x-neo-wake-schema-version, and the deliberately wrong x-neo-wake-signature.
2. A mandatory bogus-uuid negative control, stated as required rather than optional, with the reason: a probe that returns 404 for everything is indistinguishable from a receiver holding nothing.
3. One line naming the header as the key, so the failure mode is inferable without reading receiver.mjs.

Acceptance Criteria

• The runbook carries a copy-pasteable probe command including x-neo-wake-subscription-id.
• The bogus-uuid negative control is present and described as required, with its rationale.
• No prose-only restatement of the probe survives elsewhere in the file.
• The documented command, run against a live receiver, returns 401 for a held route and 404 for both an absent route and the control.

Out of Scope

• Any change to receiver.mjs. The header contract is correct; only its documentation is wrong.
• A mechanical lint for runnable-command coverage in runbooks. Real and adjacent, but it is a different substrate and should not ride a doc fix.

Avoided Traps

• Documenting the fix as more prose. The defect is prose-without-a-command; a longer paragraph reproduces it.
• Omitting the negative control as "obvious". It is the only thing that distinguished a broken probe from a broken receiver in the incident that produced this ticket.
• Treating this as a personal slip rather than a substrate defect. A self-check published as prose is a claim, not a procedure — the repo's own specs already had the correct form, and the human-facing copy silently diverged.

Related

• #16267 / PR #16271 — the reload work whose runbook section this is
• #16233 — the wake route manifest lane

Origin Session ID: 56105163-6e66-44b6-8c6f-9e81bc1be08c

Retrieval Hint: query_raw_memories("wake route probe header subscription id 404 negative control"), or ai/daemons/wake/receiver.mjs:236.