diff --git a/README.md b/README.md
index 6912af30..96a233fe 100644
--- a/README.md
+++ b/README.md
@@ -364,6 +364,7 @@ Then get the local variables:
 
 ## 📖 Documentation
 
+- 🗺️ [Roadmap](./ROADMAP.md) – Path to 1.0: stability criteria, near-term themes, non-goals
 - 📘 [Tool Reference](./docs/tool-reference.md) – Complete API documentation
 - 🚦 [Getting Started Guide](./docs/getting-started.md) – First-time setup
 - 🏗️ [Architecture Overview](./docs/architecture/README.md) – Multi-language design
@@ -457,7 +458,7 @@ See [tests/README.md](./tests/README.md) for detailed testing instructions.
 - 🦀 **Rust**: Full support on Linux/macOS/Windows (Windows requires the GNU toolchain; MSVC is not supported by CodeLLDB)
 - ⚙️ **C/C++**: Full step-through debugging via CodeLLDB (launch + attach-by-PID; on Windows prefer MinGW/DWARF — MSVC PDB fidelity is partial)
 - 🟢 **Runtime**: Node.js 22+
-- 📈 **Active Development**: Regular updates and improvements
+- 📈 **Active Development**: Regular updates and improvements — see the [Roadmap](./ROADMAP.md) for the path to 1.0
 
 ## 🏛️ Who Maintains This
 
diff --git a/ROADMAP.md b/ROADMAP.md
new file mode 100644
index 00000000..e4d4cc7e
--- /dev/null
+++ b/ROADMAP.md
@@ -0,0 +1,32 @@
+# Roadmap
+
+_Last updated: 2026-08-22 (v0.24.2). This file is refreshed at each release._
+
+mcp-debugger gives AI agents step-through debugging over the Model Context Protocol: 28 tools across eight language adapters (Python, JavaScript/TypeScript, Ruby, Rust, Go, Java, .NET, C/C++), plus a mock adapter for testing. This roadmap answers two questions we hear from people evaluating the project: **is the tool surface stable enough to build on?** and **what's left before 1.0?**
+
+## Path to 1.0
+
+1.0 is defined by criteria, not dates. We cut 1.0 when all of the following hold:
+
+- **Tool-schema freeze.** The 28-tool surface and its response shapes are declared stable under SemVer: breaking changes to tool names, parameters, or response shapes require a major version. Prerequisite work: complete full parameter/response documentation in the [tool reference](docs/tool-reference.md) for the four tools currently summarized without schemas (`list_supported_languages`, `attach_to_process`, `detach_from_process`, `list_threads`).
+- **Per-platform CodeLLDB packages published and verified.** The five `@debugmcp/codelldb-*` platform packages (which let npm installs pull only the native debug engine for the current platform) are live on npm and verified across install channels (npx, global npm, Docker).
+- **A full release cycle with no breaking behavioral changes.** One complete minor release soaks with no regressions that change documented tool behavior.
+- **Supply-chain milestones.** OpenSSF Best Practices Silver, and build-provenance attestations covering every distributed artifact — npm tarballs (done), the Docker image, and the PyPI launcher ([#422](https://github.com/debugmcp/mcp-debugger/issues/422)).
+
+## Near-term themes
+
+- **Environment self-check** — a `mcp-debugger doctor` command that checks every adapter's runtime prerequisites in one pass, plus a consolidated diagnostics guide ([#423](https://github.com/debugmcp/mcp-debugger/issues/423)).
+- **Turnkey Kubernetes debugging** — a copy-paste recipe (docs + example manifests + attach presets) for debugging pods via ephemeral sidecar containers and port-forwarded attach ([#424](https://github.com/debugmcp/mcp-debugger/issues/424)).
+- **Published-artifact canary** — a scheduled install-and-debug matrix that exercises what users actually install (npx, global npm, Docker) across platforms, catching packaging regressions before users do ([#425](https://github.com/debugmcp/mcp-debugger/issues/425)).
+
+## Non-goals
+
+To set expectations, mcp-debugger is deliberately **not** heading toward:
+
+- **An IDE-replacement UI.** This is infrastructure for agents (and the humans supervising them), not a visual debugger. The `expose_session` DAP mirror exists so your IDE can watch a live session; that's the extent of the UI ambition.
+- **Languages without a maintained DAP backend.** Adapters wrap existing, actively maintained Debug Adapter Protocol implementations (debugpy, js-debug, CodeLLDB, Delve, …). We don't write or maintain debug engines.
+- **Editing or refactoring tools.** This is a debugger. Code modification belongs to other tools in the agent's kit.
+
+## Feedback
+
+If a 1.0 criterion above seems wrong or missing, [open an issue](https://github.com/debugmcp/mcp-debugger/issues) — the criteria are meant to be argued with.