docs(planning): refresh the launch playbook against current reality (#47)

The copy was drafted in June and the projects have moved. Verified every
claim against PyPI, the GitHub API and each repo's README on 2026-07-13.

Corrections:
- httpware wraps httpx2 (2.5.0), not httpx, and now ships sync as well as
  async clients. The copy said "wraps httpx", which is simply false and is
  exactly what a Show HN thread would catch.
- modern-di has 13 official integrations, not the 4 the copy listed
  (adds Starlette, Flask, aiohttp, Celery, arq, taskiq, aiogram, gRPC).
- The Dishka comparison conceded "many more integrations". Dishka has ~15 to
  modern-di's 13, so that undersold the project. Reframed to what is still
  true and checkable: Dishka is considerably more established (~1.2k stars),
  supports async resolution and custom scopes, and integration coverage is
  now roughly comparable.
- 100+ releases -> 116. lite-bootstrap adds FastMCP and Pyroscope.
- faststream-outbox is no longer "~weeks old" (first commit 2026-05-07,
  now 0.10.5 across 29 releases); httpware is still 0.x, so keep the pin advice.

Adds a dated facts-checked banner, since these threads are one-shot and the
numbers go stale again.

Author: lesnik512

planning/launch-playbook.md

@@ -3,6 +3,13 @@
 Internal asset — **not published** (lives at the repo root, outside the MkDocs `docs/` tree).
 Ready-to-post copy for the coordinated launch, plus timing and etiquette.
 
+> **Facts checked 2026-07-13.** Every number and claim below was verified against
+> PyPI, the GitHub API, and each repo's README on that date. Re-check before
+> posting — HN and r/Python punish stale specifics, and these threads are
+> one-shot. Current: `modern-di` 2.28.0 / 116 releases / 58★ / zero runtime deps /
+> 13 integrations; `that-depends` 4.0.2 / 251★; `httpware` 0.15.1 (wraps
+> **httpx2**, not httpx); `faststream-outbox` 0.10.5; `lite-bootstrap` 1.2.3.
+
 **Design principles**
 - **Single-focus posts** on link aggregators (HN/Reddit/Lobsters) outperform one
   sprawling "look at my org" post. Stagger one project per week.
@@ -31,13 +38,13 @@ Suggested order: **modern-di (HN+Reddit)** → **stack announcement** →
 > - **Type-based autowiring** — your constructor type hints *are* the graph; no `Provide[...]` markers or string keys.
 > - **Explicit scopes** (APP → REQUEST → …) with **build-time** cycle- and scope-violation checks.
 > - **Sync resolution by design** — async setup/teardown lives in the framework lifespan, not in resolution. This is deliberate and permanent, not a missing feature.
-> - **Official integrations** for FastAPI, Litestar, FastStream, and Typer, plus a first-party pytest plugin that turns any dependency into a fixture.
-> - Zero-dependency core, MIT, 100+ releases.
+> - **Official integrations** for FastAPI, Litestar, Starlette, Flask, aiohttp, FastStream, Celery, arq, taskiq, aiogram, gRPC, and Typer — plus a first-party pytest plugin that turns any dependency into a fixture.
+> - Zero-dependency core, MIT, 116 releases.
 >
 > Where it honestly stands:
 > - If you're building a single FastAPI service and everything is request-scoped, FastAPI's `Depends` is enough — you don't need this.
-> - The closest library is **Dishka**, which is more established, has many more integrations, and supports async resolution + custom scopes. If you need those, use Dishka. modern-di's bets are a simpler sync-only model, the first-party pytest plugin, and being one consistent small stack.
-> - It's young but actively developed.
+> - The closest library is **Dishka**, which is considerably more established (~1.2k stars to my ~60) and supports async resolution and custom scopes. If you need either, use Dishka. Integration coverage is now roughly comparable between the two. modern-di's bets are a simpler sync-only model, the first-party pytest plugin, and being one consistent small stack.
+> - It's young but actively developed, and deliberately conservative — the docs have a "design decisions" page for what it leaves out on purpose (auto-binding, in-package integrations, graph rendering).
 >
 > Docs include a full comparison and a "do you even need a DI container?" page: https://modern-di.modern-python.org
 > Repo: https://github.com/modern-python/modern-di
@@ -51,20 +58,20 @@ comment; the honest "when not to use it" is what earns goodwill.
 
 ## 2. r/Python (Showcase format — three required sections)
 
-**Title:** `modern-di – typed dependency injection with scopes and one wiring across FastAPI, Litestar, FastStream, and Typer`
+**Title:** `modern-di – typed dependency injection with scopes and one wiring across FastAPI, Litestar, FastStream, Celery, and Typer`
 
 **Body:**
 
 > **What My Project Does**
-> modern-di is a dependency-injection framework. You declare providers once (type-based autowiring from constructor hints), and resolve them with explicit scopes (APP → REQUEST → …) and build-time cycle/scope checks. The same container wires your FastAPI app, your FastStream workers, your Typer CLI, and your tests — via official integrations and a first-party pytest plugin that turns any dependency into a fixture. Sync resolution by design; async lives in the framework lifespan.
+> modern-di is a dependency-injection framework. You declare providers once (type-based autowiring from constructor hints), and resolve them with explicit scopes (APP → REQUEST → …) and build-time cycle/scope checks. The same container wires your FastAPI app, your FastStream workers, your Celery/arq/taskiq tasks, your Typer CLI, and your tests — via 13 official integrations and a first-party pytest plugin that turns any dependency into a fixture. Sync resolution by design; async lives in the framework lifespan.
 >
 > **Target Audience**
 > Python teams whose business logic runs behind *more than one entrypoint* (an API plus workers/CLIs) and who want one wiring instead of three. It's production-intended but young — early adopters welcome. If you have a single web service where everything is request-scoped, framework-native `Depends`/`Provide` is enough and modern-di is overkill.
 >
 > **Comparison**
 > - **vs FastAPI `Depends` / Litestar `Provide`:** great inside one app, but don't span workers/CLIs or give typed app-scoped singletons; modern-di shares one wiring across all entrypoints.
 > - **vs `dependency-injector`:** type-based autowiring instead of `Provide[...]` markers; nested request scopes; first-party pytest plugin.
-> - **vs Dishka** (the closest library): Dishka is more established, has more integrations, and supports async resolution + custom scopes — pick it if you need those. modern-di bets on a simpler sync-only model and a first-party pytest plugin.
+> - **vs Dishka** (the closest library): Dishka is considerably more established (~1.2k stars) and supports async resolution + custom scopes — pick it if you need those. Integration coverage is now roughly comparable. modern-di bets on a simpler sync-only model and a first-party pytest plugin.
 > - **vs `that-depends`** (my earlier framework): modern-di adds explicit scopes and drops global state; that-depends stays maintained for async resolution.
 >
 > Docs + comparison: https://modern-di.modern-python.org
@@ -118,10 +125,13 @@ instead of spending the first day assembling boilerplate.
 The thing that tends to rot first in a growing service is dependency wiring.
 modern-di is a typed DI container built around one idea: *one wiring shared across
 every entrypoint.* The same container resolves dependencies in your FastAPI
-handlers, your FastStream workers, and your Typer CLI — instead of three parallel
-copies that drift apart. It uses type-based autowiring (your constructor hints are
-the graph), explicit scopes with build-time validation, and a first-party pytest
-plugin that turns any dependency into a fixture. It's deliberately sync-only:
+handlers, your FastStream workers, your Celery tasks, and your Typer CLI — instead
+of four parallel copies that drift apart. Thirteen official integrations cover the
+web frameworks (FastAPI, Litestar, Starlette, Flask, aiohttp), the task queues
+(Celery, arq, taskiq), messaging, gRPC, and the CLI. It uses type-based autowiring
+(your constructor hints are the graph), explicit scopes with build-time validation,
+and a first-party pytest plugin that turns any dependency into a fixture. It's
+deliberately sync-only:
 async setup and teardown belong in the framework lifespan, not in resolution. If
 you only have a single web service, your framework's own `Depends` is enough —
 modern-di earns its place when you have a second entrypoint. (The docs include an
@@ -130,10 +140,11 @@ DI?" page.)
 
 **Call other services with [`httpware`](https://httpware.modern-python.org).**
 As soon as a service talks to other services, you need more than a bare HTTP
-client. httpware wraps httpx with the things you'd otherwise assemble yourself:
-typed errors (4xx/5xx become a status-keyed exception tree, no more
-`raise_for_status`), typed response bodies (decode straight to your pydantic or
-msgspec model), and resilience as composable middleware — retry with budget,
+client. httpware is an HTTP client framework, with sync and async clients, built
+on [httpx2](https://pypi.org/project/httpx2/). It supplies what you'd otherwise
+assemble yourself: typed errors (4xx/5xx become a status-keyed exception tree, no
+more `raise_for_status`), typed response bodies (decode straight to your pydantic
+or msgspec model), and resilience as composable middleware — retry with budget,
 bulkhead, and circuit breaker, ordered explicitly.
 
 **Publish events reliably with
@@ -148,8 +159,9 @@ decorator. At-least-once delivery, with a dead-letter option.
 **Instrument everything with
 [`lite-bootstrap`](https://lite-bootstrap.modern-python.org).**
 Finally, observability. lite-bootstrap wires OpenTelemetry, Prometheus, Sentry,
-and structlog into a FastAPI, Litestar, or FastStream service in a few lines —
-each instrument opt-in, each skipped automatically if you don't configure it.
+Pyroscope, and structlog into a FastAPI, Litestar, FastStream, or FastMCP service
+in a few lines — each instrument opt-in, each skipped automatically if you don't
+configure it.
 Consistent instrumentation across a fleet of services, without copy-pasting 150
 lines of setup into every repo.
 
@@ -167,10 +179,12 @@ missing.
 
 - **Show HN: faststream-outbox** — "the transactional outbox pattern for
   FastStream + Postgres." Outbox is a respected, technical topic. Honest framing:
-  the pattern is battle-tested, the library is ~weeks old.
-- **Show HN / r/Python: httpware** — "httpx clients with typed errors + composable
-  resilience (retry/bulkhead/circuit-breaker)." Resilience patterns draw
-  discussion. Beta; pin versions.
+  the pattern is battle-tested, the library is young (first commit 2026-05-07,
+  now 0.10.5 across 29 releases).
+- **Show HN / r/Python: httpware** — "a Python HTTP client framework: sync + async
+  clients on httpx2, with typed errors and composable resilience
+  (retry/bulkhead/circuit-breaker)." Resilience patterns draw discussion. Still
+  0.x — say so, and tell people to pin.
 
 (Reuse the modern-di structures above: HN = honest "what/where-it-stands";
 r/Python = What-it-does / Target-audience / Comparison.)
@@ -183,9 +197,9 @@ r/Python = What-it-does / Target-audience / Comparison.)
 
 ## 7. Social one-liners (X / Mastodon / Bluesky)
 
-- "One typed DI wiring for your FastAPI app, FastStream workers, and Typer CLI — not three. modern-di, sync-by-design: https://modern-di.modern-python.org"
+- "One typed DI wiring for your FastAPI app, FastStream workers, Celery tasks, and Typer CLI — not four. modern-di, sync-by-design: https://modern-di.modern-python.org"
 - "Dual-write problem in your event-driven service? faststream-outbox does the transactional outbox for FastStream + Postgres in one decorator."
-- "httpx, but your 404s are typed exceptions and retry/bulkhead/circuit-breaker are composable middleware. httpware."
+- "An HTTP client framework where your 404s are typed exceptions and retry/bulkhead/circuit-breaker are composable middleware. Sync and async. httpware."
 
 ---