muchq · aaylward · Sep 9, 2026 · Sep 9, 2026
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -14,6 +14,6 @@ labels: bug
 
 ## Environment
 
-- smithy-cpp version/commit:
+- opal-cpp version/commit:
 - Bazel version (`bazel version`):
 - OS and compiler:
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -6,7 +6,7 @@ labels: enhancement
 
 ## Problem
 
-<!-- What are you trying to do that smithy-cpp doesn't support today? -->
+<!-- What are you trying to do that opal-cpp doesn't support today? -->
 
 ## Proposal
 

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,13 +1,21 @@
 # Changelog
 
-All notable changes to smithy-cpp are documented here. The format follows
+All notable changes to opal-cpp are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versions follow the
 policy in [docs/versioning.md](docs/versioning.md).
 
 ## [Unreleased]
 
 ### Breaking
 
+- **The default client `User-Agent` is `opal-cpp/<version>`**, formerly
+  `smithy-cpp/<version>`, following the repository's rename to
+  [`muchq/opal-cpp`](https://github.com/muchq/opal-cpp) (ADR-0024 addendum).
+  Anything matching on the old product token — a WAF rule, a log query, a
+  server-side allowlist — needs the new one. `ClientConfig::user_agent` is
+  still yours to set. The banner on generated files reads `Code generated
+  by opal-cpp (cpp-codegen)` for the same reason; goldens regenerate. The
+  old repository URL redirects.
 - **The Bazel module is `opal_cpp`, not `smithy_cpp`** (#201, ADR-0024; the
   third and last surface, which closes the issue). `bazel_dep(name =
   "smithy_cpp")` is now `bazel_dep(name = "opal_cpp")`, the runtime labels
@@ -806,5 +814,5 @@ Central publishing remain deferred (see [docs/versioning.md](docs/versioning.md)
   per-module summary, and uploads the rendered HTML report as an artifact;
   `make coverage` runs the same locally. Measurement only — no gate yet.
 
-[0.2.0]: https://github.com/muchq/smithy-cpp/releases/tag/v0.2.0
-[0.1.0]: https://github.com/muchq/smithy-cpp/releases/tag/v0.1.0
+[0.2.0]: https://github.com/muchq/opal-cpp/releases/tag/v0.2.0
+[0.1.0]: https://github.com/muchq/opal-cpp/releases/tag/v0.1.0
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,4 +1,4 @@
-# Contributing to smithy-cpp
+# Contributing to opal-cpp
 
 Thanks for your interest! This project is in early development — see
 [`docs/PLAN.md`](docs/PLAN.md) for the roadmap and [`docs/adr/`](docs/adr/) for the decisions

diff --git a/README.md b/README.md
@@ -1,7 +1,7 @@
-# smithy-cpp
+# opal-cpp
 
 Smithy code generators for C++ — generate idiomatic C++ clients and servers from
-[Smithy](https://smithy.io) models, plus the shared C++ runtime they build on.
+[Smithy](https://smithy.io) models, plus `opal`, the shared C++ runtime they build on.
 
 **Start here → [docs/quickstart.md](docs/quickstart.md):** empty directory to a generated C++
 client integration-testing a generated C++ server, in one Bazel module — no prior Smithy
@@ -10,7 +10,7 @@ experience assumed. Day 2 (evolving the model) is
 
 - **Vendor-neutral:** implements Smithy and its protocol specs; nothing AWS-specific. The REST
   protocol is [`alloy#simpleRestJson`](https://disneystreaming.github.io/smithy4s/docs/protocols/simple-rest-json/overview/)
-  (the neutral protocol smithy4s uses — so smithy-cpp clients and smithy4s services interoperate).
+  (the neutral protocol smithy4s uses — so opal-cpp clients and smithy4s services interoperate).
 - **Three protocols:** `alloy#simpleRestJson` (REST/JSON), `smithy.protocols#rpcv2Cbor` (RPC/CBOR),
   and `smithy.cpp.protocols#jsonRpc2` (RPC/JSON over JSON-RPC 2.0) — all vendor-neutral.
 - **Bazel-native:** Bazel 9 is the sole supported build system for the repo and consumers.
@@ -68,7 +68,7 @@ Roadmap and per-phase status live in [`docs/PLAN.md`](docs/PLAN.md).
 | [generated-types.md](docs/generated-types.md) | The Smithy → C++ mapping contract |
 | [server-guide.md](docs/server-guide.md) | What the generated server does before/after your handler |
 | [production-guide.md](docs/production-guide.md) | Real transports, TLS, retries, auth, middleware |
-| [runtime.md](docs/runtime.md) | The `smithy-cpp-runtime` library, module by module |
+| [runtime.md](docs/runtime.md) | The `opal-cpp-runtime` library, module by module |
 | [development.md](docs/development.md) | Building, testing, and linting this repo |
 | [versioning.md](docs/versioning.md) | Compatibility policy; [CHANGELOG.md](CHANGELOG.md) has releases |
 | [PLAN.md](docs/PLAN.md) | The phased roadmap; [adr/](docs/adr) records architecture decisions |

diff --git a/codegen/smithy-cpp-codegen/src/main/java/io/smithycpp/codegen/BuildFileGenerator.java b/codegen/smithy-cpp-codegen/src/main/java/io/smithycpp/codegen/BuildFileGenerator.java
@@ -25,7 +25,7 @@ static void run(
     // --config=werror, so a new compiler's new warnings never break consumers.
     out.append(
         """
-        # Code generated by smithy-cpp (cpp-codegen). DO NOT EDIT.
+        # Code generated by opal-cpp (cpp-codegen). DO NOT EDIT.
 
         load("@rules_cc//cc:defs.bzl", "cc_library")
 

diff --git a/codegen/smithy-cpp-codegen/src/main/java/io/smithycpp/codegen/CppWriter.java b/codegen/smithy-cpp-codegen/src/main/java/io/smithycpp/codegen/CppWriter.java
@@ -88,7 +88,7 @@ public String toString() {
     }
     boolean isHeader = filename.endsWith(".h");
     StringBuilder out = new StringBuilder();
-    out.append("// Code generated by smithy-cpp (cpp-codegen). DO NOT EDIT.\n\n");
+    out.append("// Code generated by opal-cpp (cpp-codegen). DO NOT EDIT.\n\n");
     if (isHeader) {
       out.append("#ifndef ").append(includeGuard()).append('\n');
       out.append("#define ").append(includeGuard()).append("\n\n");

diff --git a/codegen/smithy-cpp-codegen/src/main/java/io/smithycpp/codegen/TestsBuildFileGenerator.java b/codegen/smithy-cpp-codegen/src/main/java/io/smithycpp/codegen/TestsBuildFileGenerator.java
@@ -15,7 +15,7 @@ static void run(
     StringBuilder out = new StringBuilder();
     out.append(
         """
-        # Code generated by smithy-cpp (cpp-codegen). DO NOT EDIT.
+        # Code generated by opal-cpp (cpp-codegen). DO NOT EDIT.
 
         load("@rules_cc//cc:defs.bzl", "cc_test")
 

diff --git a/codegen/smithy-cpp-codegen/src/test/java/io/smithycpp/codegen/BuildFileGeneratorTest.java b/codegen/smithy-cpp-codegen/src/test/java/io/smithycpp/codegen/BuildFileGeneratorTest.java
@@ -43,7 +43,7 @@ void bothModeEmitsTypesSerdeClientAndServerTargets() {
     assertTrue(build.contains("name = \"serde\""), build);
     assertTrue(build.contains("name = \"client\""), build);
     assertTrue(build.contains("name = \"server\""), build);
-    assertTrue(build.contains("# Code generated by smithy-cpp (cpp-codegen). DO NOT EDIT."));
+    assertTrue(build.contains("# Code generated by opal-cpp (cpp-codegen). DO NOT EDIT."));
     assertTrue(build.contains("load(\"@rules_cc//cc:defs.bzl\", \"cc_library\")"), build);
   }
 

diff --git a/docs/PLAN.md b/docs/PLAN.md
@@ -1,6 +1,6 @@
-# smithy-cpp — Phased Implementation Plan
+# opal-cpp — Phased Implementation Plan
 
-A plan for building **smithy-cpp**: a [Smithy](https://smithy.io) code generator that produces
+A plan for building **opal-cpp**: a [Smithy](https://smithy.io) code generator that produces
 idiomatic, well-tested C++ **clients** and **servers**, plus the shared C++ **runtime library**
 the generated code depends on. A core requirement threaded through every phase: **generated
 clients are used to integration-test generated servers**, so the two halves continuously verify
@@ -58,7 +58,7 @@ each other.
 - **Stand on smithy-rs's shoulders.** smithy-rs (§3.2a) already solved client+server generation
   for a systems language with the same codegen framework; we port its architecture and test
   strategy to C++ instead of rediscovering them.
-- **Vendor-neutral.** smithy-cpp implements the Smithy specification and its protocol specs —
+- **Vendor-neutral.** opal-cpp implements the Smithy specification and its protocol specs —
   nothing AWS-specific: no SigV4, no AWS traits, no endpoint/region logic, no AWS SDK behaviors.
   AWS-adjacent artifacts are limited to what protocol specs mandate (e.g. restJson1's
   error-discriminator header) and the reuse of official protocol-test suites and smithy-rs as
@@ -75,7 +75,7 @@ each other.
 ### 3.1 Components
 
 ```
-smithy-cpp/
+opal-cpp/
 ├── codegen/                  # The generator (JVM, Smithy DirectedCodegen) — §3.2
 │   ├── smithy-cpp-codegen/           # core: symbol provider, type/serde generation
 │   ├── smithy-cpp-codegen-client/    # client-specific generation
@@ -118,7 +118,7 @@ official Smithy generator that ships **both a client and a server generator plus
 which is exactly our shape. We will treat it as the reference implementation and consult it
 before designing each subsystem, mapping its structure onto ours:
 
-| smithy-rs (Kotlin/Rust) | smithy-cpp equivalent | Used in |
+| smithy-rs (Kotlin/Rust) | opal-cpp equivalent | Used in |
 |---|---|---|
 | `codegen-core` (SymbolProvider, `RustWriter`, protocol serde generators shared by client & server) | `smithy-cpp-codegen` core module, `CppWriter` | Phase 2 |
 | `codegen-client` + `ClientProtocolTestGenerator` | `smithy-cpp-codegen-client` + client protocol-test generation | Phase 3 |
@@ -149,7 +149,7 @@ Further protocols slot in behind the same interface later (§9).
 A note on vendor neutrality: `restJson1` lives in the `aws.protocols` trait namespace for
 historical reasons, but it is the de-facto standard protocol for generic (non-AWS) Smithy REST
 services — smithy-rs's generic server targets it — and carries no AWS coupling beyond
-protocol-mandated names (e.g. its error-discriminator header). smithy-cpp implements protocol
+protocol-mandated names (e.g. its error-discriminator header). opal-cpp implements protocol
 specs and nothing else: no AWS traits, endpoints, auth, or SDK behaviors (see §2).
 
 > **Superseded before 0.1.0 (Phase 7e).** We used `restJson1` through Phases 3–7 precisely
@@ -223,7 +223,7 @@ with documented commands; ADRs 1–4 merged.
 
 ---
 
-### Phase 1 — Runtime core: `smithy-cpp-runtime` (≈3–4 weeks)
+### Phase 1 — Runtime core: `opal-cpp-runtime` (≈3–4 weeks)
 
 **Goals:** the hand-written C++ library that generated code will call into. No codegen yet — the
 runtime is designed against *hand-written* mock "generated" code for the weather example, which
@@ -299,7 +299,7 @@ containing all **data types** — no operations yet.
   `std::unique_ptr` indirection, C++ reserved-word and keyword escaping, PascalCase/camelCase
   conventions documented and fixed here).
 - Generate: headers + sources for all shapes in closure, a `BUILD.bazel` for the generated
-  module (a `cc_library` depending on `smithy-cpp-runtime`), equality operators, and
+  module (a `cc_library` depending on `opal-cpp-runtime`), equality operators, and
   builder-style construction (designated initializers where possible).
 - Deterministic output (stable ordering) — a hard requirement for golden tests.
 - Stand up the **generate→compile→run test pipeline** modeled on smithy-rs's
@@ -483,11 +483,11 @@ without reading generator internals or touching Gradle.
     Bazel 9 module that depends on the released `opal_cpp` module, defines a model, builds
     client + server, and runs the Phase-5-style integration test — this is the quick-start
     acceptance test.
-- **CLI wrapper**: `smithy-cpp generate --model … --mode client|server|both --out …` (thin wrapper
+- **CLI wrapper**: `opal-cpp generate --model … --mode client|server|both --out …` (thin wrapper
   around `smithy build` with our plugin preconfigured) for generation outside Bazel — inspecting
   output, or vendoring generated sources into other environments (unsupported paths, but the
   escape hatch exists); distributed via the Smithy CLI's plugin mechanism.
-- **Project template**: `smithy-cpp init` / a template repo producing the canonical Bazel 9
+- **Project template**: `opal-cpp init` / a template repo producing the canonical Bazel 9
   module layout (model/, client/, server/, integration-test skeleton *pre-wired to test the
   server with the client*, mirroring our Phase 5 harness — users inherit the pattern for free).
 - **Packaging**: Bazel Central Registry module (rules + runtime); pinned generator distribution

diff --git a/docs/adr/0002-initial-protocols.md b/docs/adr/0002-initial-protocols.md
@@ -41,4 +41,4 @@ from.
 - Further protocols slot in behind the same `ProtocolGenerator` interface later, added on
   demand (JSON-RPC 2.0 landed in Phase 7e as `smithy.cpp.protocols#jsonRpc2`; restXml remains
   a candidate).
-- smithy-cpp stays vendor-neutral: no AWS traits, auth, endpoint logic, or SDK behaviors (PLAN §2).
+- opal-cpp stays vendor-neutral: no AWS traits, auth, endpoint logic, or SDK behaviors (PLAN §2).
diff --git a/docs/adr/0004-bazel-only.md b/docs/adr/0004-bazel-only.md
@@ -15,7 +15,7 @@ parity is a permanent maintenance tax, and the target audience builds with Bazel
 - Consumers use the `opal_cpp` bzlmod module (published to the Bazel Central Registry from
   Phase 6) and the `smithy_cpp_*_library` rules, which run the generator hermetically inside the
   build graph.
-- No CMake files are provided or accepted. The `smithy-cpp` CLI (Phase 6) can emit plain C++
+- No CMake files are provided or accepted. The `opal-cpp` CLI (Phase 6) can emit plain C++
   sources plus a file manifest for vendoring into other build systems, as an explicitly
   unsupported escape hatch.
 - The codegen JVM subproject builds with Gradle (standard for Smithy plugins) — that is an

diff --git a/docs/adr/0016-generated-event-streams.md b/docs/adr/0016-generated-event-streams.md
@@ -25,7 +25,7 @@ the ADR-0015 session underneath rather than re-implemented.
 ## The wire binding (authored, vendor-neutral)
 
 Neither alloy nor core Smithy defines how these protocols' event streams
-ride WebSocket, so smithy-cpp authors the convention the way it authored
+ride WebSocket, so opal-cpp authors the convention the way it authored
 jsonRpc2 (ADR-0002 precedent: the trait and the generator are the
 normative definition, with an in-repo suite):
 

diff --git a/docs/adr/0024-runtime-not-named-after-the-idl.md b/docs/adr/0024-runtime-not-named-after-the-idl.md
@@ -45,7 +45,8 @@ The distinction the audit applies: a name that refers to the **model**
 keeps `smithy`; a name that refers to a **runtime thing that would exist
 identically had the service been hand-written** does not. So these stay:
 
-- The repository, `smithy-cpp`. It is a Smithy tool.
+- The repository, `smithy-cpp`. It is a Smithy tool. (Superseded the same
+  day: see the addendum below.)
 - The codegen plugin, `codegen/`, `io.smithycpp.codegen`, and the
   `software.amazon.smithy` dependency.
 - The Bazel rules `smithy_cpp_{types,client,server}_library`. They take a
@@ -95,3 +96,17 @@ and the goldens regenerate from them.
   metrics fix in #199 was the only instance.
 - `docs/versioning.md`'s compatibility surface #3 read
   `runtime/include/smithy/**` until the include-root PR moved it.
+
+## Addendum (2026-09-09): the repository is `opal-cpp`
+
+Once the third surface landed, the repository was renamed from `smithy-cpp`
+to `opal-cpp`, outside #201's stated scope, so the project's name and the
+runtime's agree: the tool is named for what it produces, not for what it
+reads. Everything that named the repository follows — the README, the
+CHANGELOG's release links, the quickstart's `git_override` remote, the
+issue templates — and so does the client's default `User-Agent`,
+`opal-cpp/<version>`, which names the project that sent the request and
+was the one wire-visible string the original audit missed. GitHub
+redirects the old URL. The codegen plugin's directory,
+`codegen/smithy-cpp-codegen`, keeps its name: it is the Smithy plugin, the
+one thing here that really is named for the IDL.
diff --git a/docs/development.md b/docs/development.md
@@ -4,7 +4,7 @@ Two build trees live in this repository (see PLAN §3.1):
 
 | Tree | Language | Build | What it is |
 |---|---|---|---|
-| `runtime/` (+ future generated code, examples, integration tests) | C++20 | Bazel 9 | The `smithy-cpp-runtime` library that generated code links against |
+| `runtime/` (+ future generated code, examples, integration tests) | C++20 | Bazel 9 | The `opal-cpp-runtime` library that generated code links against |
 | `codegen/` | Java 17 | Gradle | The Smithy → C++ generator (smithy-build plugin) |
 
 ## Prerequisites

diff --git a/docs/generated-types.md b/docs/generated-types.md
@@ -82,7 +82,7 @@ compatibility contract: changes to it are breaking for consumers of generated co
 - **Docs**: `@documentation` becomes `///` comments.
 - **Files**: per module, `include/<namespace path>/types.h`, `serde.h` + `src/serde.cc`,
   `client.h` + `src/client.cc`, and a generated `BUILD.bazel` exposing `cc_library ":types"`
-  and `":client"` targets that depend on the smithy-cpp runtime (`runtimeTarget` /
+  and `":client"` targets that depend on the opal-cpp runtime (`runtimeTarget` /
   `runtimePackage` settings).
 
 ## Enums

diff --git a/docs/production-guide.md b/docs/production-guide.md
@@ -1,6 +1,6 @@
 # Production guide
 
-How to configure generated smithy-cpp clients and servers for production use:
+How to configure generated opal-cpp clients and servers for production use:
 timeouts, retries, and request compression. Every knob lives on
 `opal::ClientConfig` (`opal/client/config.h`), so the guidance below
 applies to every generated client the same way.