Stop naming runtime surfaces after the IDL: audit `smithy` in generated code and runtime deps

[aaylward]

The distinction

Smithy is the IDL a service is described in. It is not a property of the service, of an HTTP request, of a JSON encoder, or of a TLS socket. Where a name refers to the model — a codegen rule that consumes .smithy files, the operation name stamped from the model — naming it after Smithy is correct. Where a name refers to a runtime thing that would exist identically had the service been hand-written, the IDL has leaked into an identity it has no claim on.

The receipt is #199: the built-in metric families shipped as smithy_http_requests_total, smithy_http_request_duration_seconds and smithy_http_requests_in_flight. Nothing about counting an HTTP request is Smithy. A dashboard reading request rate has no reason to know what IDL the service was described in, and a fleet running services from several toolchains gets one of them announcing its build system in every series name. Those are now http_requests_total, http_request_duration_seconds and http_requests_in_flight, and the registry's own counter is metrics_observations_dropped_total. This issue is the rest of that audit.

Where it stands today

Defensible — these genuinely name the IDL, and should stay:

• smithy_cpp_client_library / smithy_cpp_server_library Bazel rules. They take a .smithy model as input; naming them for it is accurate.
• codegen/, io.smithycpp.codegen, the software.amazon.smithy dependency. It is a Smithy codegen plugin.
• Prose and doc comments referring to "the Smithy operation", the model, traits. The operation metric label really is the Smithy operation name.
• The project being called smithy-cpp. It is a Smithy tool.

Misnamed — the IDL appearing in runtime surfaces that have nothing to do with it:

Surface	Shape today	Scale
Runtime namespace	smithy::Outcome, smithy::Document, smithy::Error, smithy::http::BeastServerTransport, smithy::json::Encode, smithy::server::Middleware, smithy::eventstream::Message	every runtime type
Include root	#include "smithy/http/beast_transport.h"	53 headers, 305 including files
Bazel module + labels	bazel_dep(name = "smithy_cpp"), @smithy_cpp//runtime:http	consumer-visible
Generated code	~2000 smithy:: references across 109 generated files, emitted as string literals from 26 codegen Java files	regenerated, not hand-edited
Metric family names	fixed in #199	—

A service that never opens a Smithy model still writes smithy:: for its JSON codec and its HTTP transport. smithy::json::Encode is a JSON encoder; smithy::http::BeastHttpClient is a Beast client. Neither is a Smithy concept.

What makes this hard

This is a breaking rename with a large blast radius, and the honest reason it hasn't happened is that the cost is real:

• Every downstream consumer's includes, using declarations, and BUILD deps change at once.
• The 109 checked-in generated files are goldens; they regenerate, but the diff is enormous and reviewing it is mostly noise.
• docs/versioning.md allows breaking changes on a minor bump pre-1.0, so the policy permits it — but the migration cost lands on users either way.

So this issue is a decision to make, not a task to pick up. Options, roughly in increasing order of cost:

1. Do nothing beyond the metric names. The namespace is internal-facing enough that the mismatch is a wart, not a problem. Close this and keep the naming honest only where it is externally visible (metric names, log fields, wire-visible strings).
2. Rename the namespace with a compatibility alias. namespace <new> with namespace smithy = <new>; retained for a deprecation window, and forwarding headers under smithy/ that include the new root. Consumers migrate on their own schedule; the alias comes out at 1.0.
3. Rename everything at once, including the Bazel module and include root, in a single release with a migration note.

Whichever way it goes, the sequencing constraint is the same: the codegen emitters are the source of truth for the generated references, so they change first and the goldens regenerate from them — nobody hand-edits generated/.

Not in scope

Renaming the repository or the codegen plugin. Those are Smithy tools and are named correctly.

Suggested first step

Pick between options 1–3 before any code moves. If it is 2 or 3, the follow-up is mechanical and can be scripted, but it should land in one PR per surface (namespace, include root, Bazel labels) rather than one PR for all of them — each is independently reviewable, and a mixed one is unreviewable.