Gateway Route Inventory (generated)

Generated mechanically by `docs/scripts/route_inventory.py`. Do not hand-edit — rerun the script. Regenerate: python3 docs/scripts/route_inventory.py --write · Check drift: python3 docs/scripts/route_inventory.py --check

What this proves / does not prove

• Proves: these route declarations (Actix routing attribute macros) exist in the gateway source at the snapshot commit.
• Does NOT prove: route correctness, authentication/authorization, test coverage, runtime health, production readiness, or public-claim safety. OpenAPI documented = yes does not mean the contract is complete or correct.
• Proof level (per `proof-level-taxonomy-capability-matrix.md`): every tabulated route row — gateway macros, governance-app registration candidates, and OpenAPI-unmatched operations — is recorded at L1 (a declaration / contract / registration site exists in source). A static scan cannot assert L2+ (unit/integration tests), L5 (live daemon/gateway), or higher; those require evidence this pass does not collect. OpenAPI documented = yes is still only L1 (a schema/contract exists), not runtime proof. The Proof column is uniform L1 by construction — it marks the ceiling of this evidence, not a per-route assessment. The unparsed route-registration candidates below are flagged leads (not parsed into routes) and carry no proof level.
• Defer to canonical truth/precedence: `source-of-truth-map.md` and proof levels in `proof-level-taxonomy-capability-matrix.md`. This is an orientation artifact (Canonical: no).

Snapshot

• Source commit: 6a1f00aed433a8c80862f6742f081129ceeb323e
• Gateway source scanned: icn/crates/icn-gateway/src/**
• OpenAPI spec: docs/api/openapi.generated.yaml

Coverage summary

• Discovered gateway route macros: 287 (DELETE 17 · GET 131 · POST 125 · PUT 14)
• OpenAPI documented paths: 5
• Matched as documented (best-effort method+path match): 2
• Not matched to OpenAPI (best-effort): 285 (~99% of discovered)
• Documented share of discovered routes: ~0.7%
• OpenAPI operations (method + path) not matched to a discovered gateway route: 3 (see section below)
• Governance app route-registration candidates (separate surface, not gateway macros): 86 (see section below)
• Proof level: every tabulated route row is recorded at L1 (287 gateway macros + 86 governance candidates + 3 OpenAPI-unmatched operations) — a declaration/contract/registration exists in source; the static scan asserts no level above L1. The 4 unparsed web::resource/.route candidates are flagged leads (not parsed into routes) and carry no proof level.

The gap is structural: only handlers hand-annotated for utoipa reach the OpenAPI spec. Of the OpenAPI paths, several belong to icn-governance-actor HTTP handlers that live outside the gateway crate and are not captured by this macro scan — so the documented/undocumented counts here are a best-effort comparison, while the two headline counts (discovered macros, OpenAPI paths) are the robust measured facts.

OpenAPI paths not matched to discovered gateway routes

These OpenAPI-documented paths did not mechanically match any discovered gateway route macro. That is expected when a handler is documented via #[utoipa::path] but registered outside the scanned icn/crates/icn-gateway/src/** tree — e.g. the governance app (icn-governance-actor = icn/apps/governance) documents its /gov/* handlers with utoipa and mounts them via web::resource("…").route(…) in apps/governance/src/http/configure.rs (no attribute macros). OpenAPI presence does not prove a runtime route exists or is mounted; these stay unknown / needs local verification.

Governance app route-registration candidates

The governance app (icn-governance-actor = icn/apps/governance) registers its HTTP routes via web::resource("…").route(web::<verb>().to(handlers::…)) in apps/governance/src/http/configure.rs, mounted under the gateway's web::scope("/gov") (the served path is /gov + the relative path below). It uses no route attribute macros, so the gateway macro scan above never sees these: they are a separate registration surface, listed here as candidates and not counted among the 287 gateway macros. This is why the unmatched /gov/* OpenAPI operations have no gateway-macro match — their handlers are registered here. The scan is mechanical (one configure.rs, one pattern); a registration site does not prove correctness, auth, mounting health, tests, or production readiness, so candidates stay unknown / needs local verification. OpenAPI documented = this candidate's (verb, /gov + path) matches a generated OpenAPI operation.

Limitations

• Full mounted-path resolution is best-effort. The Group column is /v1 + a web::scope("…") segment associated from server.rs .service(...)/.configure(...) registration sites (matched at identifier boundaries, keyed by the handler's top-level icn/crates/icn-gateway/src/api/<group> module) + the relative macro path. It is not a real Rust parser and may be wrong for deeply-nested or conditional scopes. The relative macro Path and the Source file are authoritative.
• The route table is attribute macros only. Macro-less web::resource("…")/.route(…) registrations in the gateway crate are flagged under Unparsed route-registration candidates; the governance app's out-of-crate registrations are listed under Governance app route-registration candidates. Neither is parsed into the gateway route table or counted as a gateway macro.
• This is generated-map work, not API documentation completion (issue #2112). It does not add or change any OpenAPI content or runtime behavior.

Routes

Status vocabulary is the existing set from source-of-truth-map.md; no new labels are introduced. A static macro scan proves only that a routing macro is declared in source — not that the handler is mounted and served (registration happens elsewhere via .service(...) / .configure(...), which this pass does not resolve). This scan therefore cannot assert gateway-backed: every discovered route's status defaults to unknown / needs local verification and claim-safety to needs review, pending human or runtime confirmation.

Unparsed route-registration candidates

Beyond attribute macros, Actix can also register routes via web::resource("…").route(web::<method>().to(handler)). This scan flags such sites mechanically but does not parse them into routes: a regex cannot reliably tell a production registration from a test fixture (e.g. inside #[cfg(test)] / test::init_service), and it does not resolve the mounted path without a real parser. They are not counted in the route total above and remain unknown / needs local verification — treat them as leads for human review.

• Candidates flagged: 4 (web::resource("…"): 2 · .route(…): 2)