Skip to content

I0916 — The smoke suite is derived from the route registry, never written twice

Generate the deployment smoke tests from the authoritative route registry, extending route metadata only where smoke testing genuinely needs it, and cover the surfaces that a plain status code cannot verify.

BLOCKED wave 5 · p0 · deep-work profile · parallel safe

Part of fly-deployment — A deployment is a projection of the repository model, and a reachable URL is its evidence.

Blocked. This issue cannot start until I0905, I0914 are done. The status is derived from that, not declared.

Objective

Generate the deployment smoke tests from the authoritative route registry, extending route metadata only where smoke testing genuinely needs it, and cover the surfaces that a plain status code cannot verify.

Why

A hand-written list of endpoints to check is the same defect as a hand-written OpenAPI file: it is complete on the day it is written and wrong afterwards. The registry already knows every route, and web surface discovery under ADR 0013 knows which of them are served.

Current state

The registry holds the capability routes and the router serves them. Nothing derives verification from either, and the served topology is being reshaped on other branches.

Desired state

The smoke suite enumerates what the registry and the resolved surface topology say is served, verifies each according to its kind, and gains a new route automatically when one is registered.

Scope

  • apps/majordomus-cli/src/deploy/smoke.rs
  • test/cases

Out of scope

  • A second list of endpoints in a script, a workflow or a test fixture
  • Route aliases created to make a test pass
  • Requiring a paid external provider for a deployment smoke run

Dependencies

What waits on this

Acceptance criteria

  • Every checked route comes from the registry or from the resolved surface topology, and adding a route adds its check with no second edit
  • Route metadata gains only the fields smoke testing actually needs, and no field that exists to make one test convenient
  • A websocket route is verified by a real upgrade, a message exchange and a clean close, not by a status code
  • The MCP transport is verified by a protocol-valid handshake, not by a 200 on its path
  • An OpenAI-compatible surface, where one is served, is verified for route presence, schema correctness, intentional authentication behaviour and correct rejection of malformed input, without requiring a paid completion
  • The OpenAPI document is retrieved and parsed, and its consistency with the registry is asserted
  • Deployment availability and external provider availability remain separate verdicts

Validation

  • bash test/run.sh
  • cargo test --workspace --all-features

Evidence required

  • smoke_derived
  • ws_upgrade
  • mcp_handshake
  • openapi_parsed

Evidence

None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.

Risk

The served topology is in flight on other branches. Pinning the suite to today's paths would make it stale on arrival; it has to ask the topology rather than name arms.

Timeline

started
—
verified
—
completed
—

Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.

Canonical record: .ai/repo/project/issues/I0916.yaml. Read it back with majordomus plan show I0916.