tokio-rs/axum

Can another program use it through a documented, machine-readable surface?

• next: [service] L4 A second surface: another transport (HTTP and a protocol, two protocols), an MCP server, a CLI with JSON output, or an SDK. (only one programmatic surface)
• next: [cli] L3 Machine-readable output (--json/--format) and documented exit statuses. (no --json/--format option)

cli ladder · level 2

• ✓ L1 Invocable non-interactively: no prompts, or prompts guarded by a TTY check or a --yes/--no-input option. no interactive prompts
• ✓ L2 --help documents every option (at least 90% of options have help text). axum/benches/benches.rs 1 match
• ✗ L3 Machine-readable output (--json/--format) and documented exit statuses. no --json/--format option
• ✗ L4 The output format is specified by a JSON Schema. no JSON Schema for the output

library ladder · level 4

• ✓ L1 An importable, packaged API exists. axum-core/src/lib.rs Rust library crateaxum-extra/src/lib.rs Rust library crate
• ✓ L2 The public API is delimited (__all__, an exports map, exported identifiers). axum-core/src/lib.rs pub itemsaxum-extra/src/lib.rs pub items
• ✓ L3 The public API is statically typed (py.typed, type declarations, a typed language). axum-core/src/lib.rs statically typed languageaxum-extra/src/lib.rs statically typed language
• ✓ L4 An API reference is generated from the code (autodoc, mkdocstrings, typedoc, …). .github/workflows/CI.yml 2 matches

service ladder · level 3

• ✓ L1 A network surface exists: HTTP routes, an MCP server, or a standard protocol listener. axum/src/extract/path/mod.rs rust-axum/actix: 198 route declarations
• ✓ L2 A contract exists: a checked-in OpenAPI/GraphQL/protobuf/AsyncAPI spec, a framework-generated spec, MCP tool schemas, or a standard application protocol that off-the-shelf clients speak (RESP, MQTT, gRPC, PostgreSQL wire, …). examples/Cargo.toml graphql server
• ✓ L3 A contract covers its transport: an HTTP contract covers at least 80% of declared routes (generated contracts do), or the application layer over a standard protocol (commands, topics, payloads) is specified in a protocol document or AsyncAPI. examples/Cargo.toml generated from code: graphql server
• ✗ L4 A second surface: another transport (HTTP and a protocol, two protocols), an MCP server, a CLI with JSON output, or an SDK. only one programmatic surface

Can integrators rely on it not changing under them?

• next: L2 A changelog exists and marks breaking changes. (the changelog doesn't mark breaking changes)

all ladder · level 1

• ✓ L1 Releases are versioned (semver tags or versioned changelog sections). 18 semver tags, latest v0.4.0
• ✗ L2 A changelog exists and marks breaking changes. the changelog doesn't mark breaking changes
• ✓ L3 A deprecation mechanism is used in code (warnings, @deprecated, Deprecation/Sunset headers) or the API is versioned. axum-extra/src/extract/form.rs 2 matchesaxum-extra/src/extract/query.rs 2 matches
• ✓ L4 Across tagged releases, no OpenAPI operation, CLI option or __all__ symbol was removed without first being deprecated. 18 tagged releases compared

Can others react to state changes without polling?

• next: L3 Signed webhooks registrable through the API, or two mechanisms (webhooks, streams, a broker). (one delivery mechanism, or webhooks that are unsigned or not registrable through the API)

service ladder · level 2

• ✓ L1 Internal events exist (signals, queues, an outbox, emitters). axum/src/extract/ws.rs 73 matchesaxum/src/response/sse.rs 2 matches
• ✓ L2 Webhooks sent by this system, or a streaming endpoint (SSE, WebSocket). axum/src/extract/ws.rs 73 matchesaxum/src/response/sse.rs 2 matches
• ✗ L3 Signed webhooks registrable through the API, or two mechanisms (webhooks, streams, a broker). one delivery mechanism, or webhooks that are unsigned or not registrable through the API
• ✓ L4 Events are described by AsyncAPI or CloudEvents. axum-extra/src/extract/json_deserializer.rs 1 matchaxum/src/json.rs 1 match

Can a machine act with its own revocable, least-privilege identity?

• next: L2 Per-client, revocable credentials (managed API keys, service accounts) or OAuth2. (no managed keys or OAuth)

service ladder · level 1

• ✓ L1 Programmatic authentication (bearer tokens, API keys). examples/jwt/Cargo.toml 1 match
• ✗ L2 Per-client, revocable credentials (managed API keys, service accounts) or OAuth2. no managed keys or OAuth
• ✗ L3 Credentials carry scopes or permissions. no scopes or permissions
• ✗ L4 Standard provisioning or federation (OIDC client credentials, SCIM). no OIDC client credentials or SCIM

Can its data get in and out, in bulk, in open formats, with an explicit schema?

• next: L2 An export exists (endpoint or command, not only the UI). (no export)

all ladder · level 1

• ✓ L1 The data schema is explicit (migrations, DDL, schema files). examples/diesel-async-postgres/migrations/2023-03-14-180127_add_users/down.sqlexamples/diesel-async-postgres/migrations/2023-03-14-180127_add_users/up.sql
• ✗ L2 An export exists (endpoint or command, not only the UI). no export
• ✗ L3 A bulk export in an open format, and a bulk import. no open export format
• ✗ L4 The export format is documented and the round trip is tested. the export format isn't documented

Can an automated caller use it without guessing, and recover from failure?

• next: [service] L2 Field-level validation errors, and paginated lists. (no request validation)
• next: [cli] L2 Data on stdout, diagnostics on stderr, non-zero exit on failure. (no non-zero exit on failure)
• next: [library] L2 Inputs are validated with messages naming the bad argument. (no input validation errors)

cli ladder · level 1

• ✓ L1 Never blocks on a prompt when stdin is not a TTY. no interactive prompts
• ✗ L2 Data on stdout, diagnostics on stderr, non-zero exit on failure. no non-zero exit on failure
• ✗ L3 Documented exit statuses distinguish error classes, errors are JSON in JSON mode, and color is off when not a TTY. exit statuses aren't documented
• ✗ L4 --dry-run, limits for long or costly operations (timeouts, budgets), and agent docs. no --dry-run

library ladder · level 1

• ✓ L1 Errors are specific exception types, and library code never calls sys.exit. axum-core/src/extract/rejection.rs 2 matchesaxum-extra/src/extract/json_deserializer.rs 2 matches
• ✗ L2 Inputs are validated with messages naming the bad argument. no input validation errors
• ✓ L3 Timeouts and retries are configurable. axum/src/handler/mod.rs 1 matchaxum/src/routing/method_routing.rs 1 match
• ✗ L4 Agent docs, and examples that run as tests (doctests). no agent docs

service ladder · level 1

• ✓ L1 Errors are machine-readable: consistent JSON over HTTP, or a standard protocol's native error replies (RESP errors, MQTT reason codes, gRPC status, SQLSTATE). axum-core/src/response/mod.rs 3 matchesaxum/src/response/mod.rs 1 match
• ✗ L2 Field-level validation errors, and paginated lists. no request validation
• ✗ L3 Typed errors (RFC 9457 over HTTP, or a standard protocol's typed error codes), idempotent writes (Idempotency-Key), and rate-limit signals. no typed errors
• ✗ L4 Dry-run or validate-only, conditional requests, and agent docs. no dry-run

Can another system run and compose it without a human?

• next: [service] L2 Configured through environment variables, documented: a .env example, a config schema, or docs naming at least half of the variables the code reads. (the environment variables aren't documented)
• next: [cli] L3 Published to a public registry and run non-interactively in CI. (not published to a registry)
• next: [library] L3 Published to a public registry, with at most 10 runtime dependencies. (not published to a registry)

cli ladder · level 2

• ✓ L1 Runnable from source (a declared entry point). examples/websockets/Cargo.toml cargo binexamples/anyhow-error-response/src/main.rs cargo binary
• ✓ L2 Installable as a package that provides the command. examples/websockets/Cargo.toml cargo binexamples/anyhow-error-response/src/main.rs cargo binary
• ✗ L3 Published to a public registry and run non-interactively in CI. not published to a registry
• ✗ L4 Also shipped as a container image or a single binary. no container image or binary

library ladder · level 2

• ✓ L1 Importable from source. axum-core/src/lib.rs Rust library crateaxum-extra/src/lib.rs Rust library crate
• ✓ L2 Installable as a package (a package manifest). axum-core/src/lib.rs package manifestaxum-extra/src/lib.rs package manifest
• ✗ L3 Published to a public registry, with at most 10 runtime dependencies. not published to a registry
• ✓ L4 Optional features behind extras/features. axum-core/Cargo.toml 1 matchaxum-extra/Cargo.toml 1 match

service ladder · level 1

• ✓ L1 Runnable from source with documented steps (a README with commands). README.md
• ✗ L2 Configured through environment variables, documented: a .env example, a config schema, or docs naming at least half of the variables the code reads. the environment variables aren't documented
• ✗ L3 A container image. no Dockerfile
• ✗ L4 Composition artifacts (compose, Helm, IaC). no compose/Helm/IaC

Can behaviour be added without modifying the code?

• next: L1 Internal seams: a registry, registration function or plugin manager. (no registry or registration function)

all ladder · level 0

• ✗ L1 Internal seams: a registry, registration function or plugin manager. no registry or registration function
• ✗ L2 The docs show how to add behaviour through those seams (even in-tree). no registration functions to document
• ✗ L3 Out-of-tree extensions are discovered (entry points, a plugin directory, configuration) without editing the package. extensions must be added inside the package
• ✗ L4 The extension API is versioned, has lifecycle hooks, and has example extensions. the extension API isn't versioned

Can an operator, or an orchestrating agent, tell whether it works and why not?

• next: [service] L1 A health or readiness endpoint, or a container healthcheck. (no health endpoint or healthcheck)
• next: [cli] L1 Meaningful exit statuses, and errors on stderr. (no non-zero exit on failure)
• next: [library] L1 Logs through a standard logger namespace and never prints from library code. (no standard logger)

cli ladder · level 0

• ✗ L1 Meaningful exit statuses, and errors on stderr. no non-zero exit on failure
• ✗ L2 Verbosity control for diagnostics (--quiet, --log-level, --debug). no --quiet or log-level control
• ✗ L3 Structured logs (e.g. --log-format json) or a machine-readable run summary. no structured diagnostics
• ✗ L4 Tracing hooks (OpenTelemetry). no tracing hooks

library ladder · level 0

• ✗ L1 Logs through a standard logger namespace and never prints from library code. no standard logger
• ✗ L2 Log levels are used meaningfully (at least two levels). fewer than two log levels used
• ✗ L3 Optional metrics or tracing hooks. no metrics or tracing hooks
• ✗ L4 OpenTelemetry instrumentation available. no OpenTelemetry instrumentation

service ladder · level 0

• ✗ L1 A health or readiness endpoint, or a container healthcheck. no health endpoint or healthcheck
• ✗ L2 Structured logs. no structured logging
• ✓ L3 Metrics. examples/prometheus-metrics/Cargo.toml 2 matches
• ✗ L4 Distributed tracing (OpenTelemetry). no tracing

Can an agent change it safely with limited context?

• next: L3 At least 90% of modules fit 32k tokens and no file exceeds 12k; test/source token ratio at least 0.3; at least 70% of the code is typed. (96% of modules fit 32k tokens; 2 files over 12k; test/source token ratio 0.13 < 0.3)

all ladder · level 2

• ✓ L1 A README and some tests. README.mdaxum-macros/tests/debug_handler/fail/argument_not_extractor.rs 130 test files
• ✓ L2 CI runs the tests; applications pin dependencies (libraries and zero-dependency projects are exempt). .github/workflows/CI.yml.github/workflows/release-plz.yml
• ✗ L3 At least 90% of modules fit 32k tokens and no file exceeds 12k; test/source token ratio at least 0.3; at least 70% of the code is typed. 96% of modules fit 32k tokens; 2 files over 12k; test/source token ratio 0.13 < 0.3
• ✗ L4 No import cycles, and agent docs (AGENTS.md, CLAUDE.md, llms.txt). no agent docs (AGENTS.md, CLAUDE.md, llms.txt)