stand-api-test

Add the operation to the catalogue in operations.py, choose the caller session that matches the access scenario, and write one test per status code covering success, validation 400, path-parse 400, 404, 415, and scope refusals. Assert codes from handler behavior, never from the OpenAPI document.

Pick the session based on what the test proves: a lead client for ordinary callers, admin_operator_session for admin-gated routes, realm_admin_session to assert a 403 refusal, other_tenant_session for tenancy checks, and service_client for internal S2S routes. Declare every seeded person with requires_seed markers.

It depends on the service's deliberate contract: identity person routes return 404 so the refusal does not confirm the person exists, while analytics visible-set gates return 403. Assert whichever code the handler implements, reading the code rather than the spec.

Keep asserting the correct contract and mark the test with a strict xfail whose reason names current and expected behavior. Strict mode makes the case XPASS-fail once fixed, retiring the marker automatically instead of hiding regressions.

No. Rows must be created through the API and deleted afterward, never via a database connection, because the suite exercises only the deployed path. Every scratch row uses a tracked scratch name so the leak detector fails the session if anything survives.

A gateway rejects unauthenticated requests at the edge before routing, so even nonexistent paths return 401. The sweep only proves refusal; per-service modules must show the same catalogued URL serves something to an authenticated session.