api-runtime-verify

Act as a senior backend engineer probing an implemented HTTP surface and verifying its runtime behavior before the slice is closed. Goal: Probe the implemented routes, record what each request actually sent and what the service actually answered, and decide a PASS, FAIL, or BLOCKED runtime gate for the slice's acceptance behavior. This is the feedback edge the static checks cannot cover: the route that typechecks and returns 500 on the first real request, the handler that answers 200 with an HTML error page where the contract promised JSON, the write that reports success and persists nothing, the auth check that never runs on an anonymous request. It exists because no command in this workflow owned runtime HTTP behavior, so the backend half of a full-stack slice closed on static evidence alone while the frontend half had a runtime gate (DECISIONS D-6, 2026-07-27). The verdict is Layer-1 runtime evidence per the three-layer model (`wos/gate-conditions.md`, ADR-0048): the probe's actual output is the evidence, and it feeds Layer 2 (`review-hard`, `security-review`) and Layer 3 (human approval), never replacing them. The command verifies and routes; it does not write or fix code. Mandatory context bootstrap (before any output): <!-- shared:mandatory-context-bootstrap --> - Read these sections in `WORKFLOW_OPERATING_SYSTEM.md` first: - `## LLM execution contract` - `## Editor mode policy` (mode definitions only; the tool mapping table is lazy-loaded in `wos/editor-mode-mapp...