Fire the coordinated launch (promotion strategy, Phase 4)

[lesnik512]

Migrated from planning/deferred.md, retired in the move to the PR-body-as-spec convention (#50).
The full ready-to-post copy is inlined below so this issue stands alone.

What

Fire the staggered launch — modern-di (Show HN + r/Python) → the org-story announcement →
faststream-outbox → httpware, roughly one per week.

Why it was deferred

Phase 4 fires only once Phases 0–2 (foundation hygiene, positioning backbone, conversion polish) are
complete. Much of that has since shipped — community-health defaults, the brand kit, the profile
tables, the docs sites — so this is close to ready.

Revisit trigger

When the maintainer judges the positioning surfaces done and picks a launch window. Launching is
one-shot per project (greenfield: no prior HN/Reddit/Lobsters threads exist for these projects), so
it is worth not wasting.

Opening the chat rooms is timed to this window — see #58.

---

Launch playbook (Phase 4)

Ready-to-post copy for the coordinated launch, plus timing and etiquette.

Facts checked 2026-09-06. Every number and claim below was verified against
PyPI, the GitHub API, and each project's own docs and source on that date. Re-check
before posting — HN and r/Python punish stale specifics, and these threads are
one-shot. Release counts below are PyPI version counts, not GitHub releases:
modern-di's GitHub tag list carries 127 entries, but 69 of those are pre-releases
and monorepo-era core-*/fastapi-* tags that were never modern-di on PyPI.
Current: modern-di 3.4.0 / 98 releases on PyPI / 66★ / zero runtime deps /
13 integrations (12 frameworks + the pytest plugin); that-depends 4.1.0 / 253★;
httpware 0.16.0 (wraps httpx2, not httpx); faststream-outbox 0.13.1;
lite-bootstrap 1.4.0.

Design principles

• Single-focus posts on link aggregators (HN/Reddit/Lobsters) outperform one
  sprawling "look at my org" post. Stagger one project per week.
• Greenfield: research found no prior HN/Reddit/Lobsters threads for these
  projects, so each post gets a clean first thread.
• Honest, calibrated voice: "new but sharp," first-person (maintainer). The
  "when not to use this" framing is the credibility play — keep it.
• One equal-billing announcement carries the whole-stack story.

Suggested order: modern-di (HN+Reddit) → stack announcement →
faststream-outbox → httpware, ~one per week.

---

1. Show HN — modern-di (lead)

Title: Show HN: modern-di – Typed dependency injection for Python, with scopes

Body:

Hi HN. I'm the author of modern-di, a dependency-injection framework for Python.

I kept building a FastAPI API, a FastStream worker, and a Typer CLI that all shared the same business logic — and rewiring the same dependencies three times, once per entrypoint. modern-di is my attempt at one typed wiring shared across all of them.

What it does:

• Type-based autowiring — your constructor type hints are the graph, and providers are plain class attributes on a Group. There is no @provide decorator and no string keys. In the FastAPI, Litestar, FastStream and taskiq integrations your handlers need no DI decorator either — just the framework's own route decorator.
• Explicit scopes — five built-in, APP → SESSION → REQUEST → ACTION → STEP, and you can extend the chain with any IntEnum. Wiring errors (cycles, scope violations, unresolvable dependencies) are caught by one container.validate() call at startup, before the first request — not lazily at resolve time.
• Async apps are first-class; the resolve path is synchronous. container.resolve(X) never awaits — but the container is an async context manager, async finalizers are supported, and genuinely async resources (an aiohttp session, an asyncpg pool) are constructed in the framework lifespan and injected by type. Most of the integrations are async frameworks. Keeping await out of resolution is deliberate and permanent, not a missing feature.
• 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, 98 releases on PyPI.

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 — considerably more established (~1.3k stars to my ~66), with arbitrary named scopes and await inside resolution. modern-di deliberately takes the other road: an async resource (an aiohttp session, an asyncpg pool) is constructed in the framework lifespan and injected by type via a ContextProvider, so the resolve path stays synchronous. There's a recipe for exactly this: https://modern-di.modern-python.org/recipes/async-lifespan/
• Built-in integration coverage between the two is now roughly comparable — 12 official frameworks to Dishka's 13 — though Dishka also has ~10 community-maintained integrations on top. modern-di's bets are a lighter declaration model, a smaller core, the first-party pytest plugin, and being one consistent small stack.

On the declaration model, precisely — because I'd rather state the limits than have them found: providers are plain class attributes, so there's no @provide anywhere, and in the FastAPI/Litestar/FastStream/taskiq integrations handlers need no DI decorator. But eight of the other integrations (Starlette, Flask, aiohttp, gRPC, Celery, arq, aiogram, Typer) do need an @inject, and at the FastAPI boundary you still mark the parameter (Annotated[UserService, FromDI(UserService)]), because that's how FastAPI's own DI hooks in. So: lighter than Dishka on declarations, not "decorator-free."

• 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, with a "do you even need a DI container?" section up front: https://modern-di.modern-python.org/introduction/comparison/
Repo: https://github.com/modern-python/modern-di

Happy to dig into the design — especially the decision to keep await out of the resolve path.

Etiquette: post Tue–Thu ~8–10am ET; never ask for upvotes; reply to every
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, 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 (five built-in: APP → SESSION → REQUEST → ACTION → STEP) and one validate() call at startup that catches cycles and scope violations. The same container wires your FastAPI app, your FastStream workers, your Celery/arq/taskiq tasks, your Typer CLI, and your tests — via 12 official framework integrations plus a first-party pytest plugin that turns any dependency into a fixture, 13 in all. Async apps are first-class — most of the integrations are async frameworks; what's synchronous is the resolve path itself, with async construction and teardown handled 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 considerably more established (~1.3k stars), has arbitrary named scopes, and awaits inside resolution. modern-di takes the other road — async resources are built in the lifespan and injected by type through a ContextProvider (recipe), so resolution stays sync. Built-in integration coverage is now roughly comparable — 12 official frameworks to Dishka's 13, though Dishka also has ~10 community-maintained integrations. modern-di bets on a lighter declaration model (providers are plain class attributes — no @provide; and no @inject in the FastAPI/Litestar/FastStream/taskiq integrations, though eight others do need one), a smaller core, and a first-party pytest plugin.
• vs that-depends (my earlier framework): modern-di adds explicit scopes and drops global state; that-depends remains the async-first sibling and stays maintained.

Docs + comparison: https://modern-di.modern-python.org

---

3. Lobsters

Submit the link https://modern-di.modern-python.org (the docs, not the bare
repo), tag python. Authored comment:

Typed DI for Python with explicit scopes, built so one container wires a FastAPI app, FastStream workers, and a Typer CLI together. Async apps are first-class; the resolve path itself never awaits, by design. The docs include an honest comparison vs dependency-injector/Dishka and a "do you even need DI?" section. Author here — happy to discuss the no-await-in-resolve call.

Only post if you have a Lobsters account with karma; it's allergic to drive-by
self-promo.

---

4. Org-story announcement (equal billing)

For a blog / dev.to / GitHub Discussion "Announcements" post — the one place the
whole stack shares billing. Full ~580-word draft:

---

The modern-python stack: production Python services without the boilerplate

Every production Python service I build needs roughly the same scaffolding. A
sensible project structure. A way to wire dependencies that doesn't turn into a
tangle. Resilient calls to other services. Reliable event publishing when a
database write and a message have to happen together. And observability, so I can
actually see what's happening in production.

None of that is the interesting part of the product — but all of it has to be
there, and getting it right repeatedly is tedious. Over the last couple of years
I've been factoring these concerns into a small family of MIT-licensed libraries,
each independently usable, built with the same tooling
(uv, ruff,
ty). Collectively they're the modern-python
stack. Here's how the pieces fit.

Start from a template.
fastapi-sqlalchemy-template
and litestar-sqlalchemy-template
are dockerized, batteries-included starting points: FastAPI or Litestar,
SQLAlchemy 2, PostgreSQL, dependency injection already wired, with linting,
typing, and tests configured. Clone, rename, and you have a service that runs —
instead of spending the first day assembling boilerplate.

Wire your dependencies with modern-di.
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, 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 (FastStream), gRPC, the CLI (Typer), Telegram
bots (aiogram), and pytest. It uses type-based autowiring (your constructor hints
are the graph), explicit scopes validated in one call at startup, and a
first-party pytest plugin that turns any dependency into a fixture. Async
applications are first-class — most of those integrations are async frameworks.
What is deliberately synchronous is the resolve path: a resource that genuinely
needs to await (an aiohttp session, an asyncpg pool) is constructed in the
framework lifespan and injected by type through a ContextProvider, so resolution
itself never awaits. 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
honest comparison with dependency-injector and Dishka, opening with a "do you even
need a DI container?" section.)

Call other services with httpware.
As soon as a service talks to other services, you need more than a bare HTTP
client. httpware is an HTTP client framework, with sync and async clients, built
on 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
faststream-outbox.
If your service writes to a database and publishes an event, you have a dual-write
problem: a crash between the two leaves them inconsistent. faststream-outbox
solves it with the transactional outbox pattern for FastStream and Postgres —
write your domain row and an outbox row in the same transaction, and a relay
forwards each row to your broker (Kafka, RabbitMQ, NATS, Redis) with a single
decorator. At-least-once delivery, with a dead-letter option.

Instrument everything with
lite-bootstrap.
Finally, observability. lite-bootstrap wires OpenTelemetry, Prometheus, Sentry,
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.

Use one, or all of them. The point isn't to adopt everything. Each library
stands alone — use httpware without modern-di, or lite-bootstrap with a framework
of your own. But together they cover the unglamorous 20% of a service that you'd
otherwise rebuild every time. modern-python.org ties
it together, and everything is open to issues, ideas, and contributions. These are
young, actively-developed projects — I'd genuinely like your feedback on what's
missing.

---

5. Staggered follow-up posts (own thread each, later weeks)

• 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 young (first commit 2026-05-06,
  now 0.13.1 across 34 PyPI 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.)

6. awesome-list submissions (one-liners)

• awesome-python (DI section): modern-di — typed dependency injection with scopes and framework integrations.
• awesome-fastapi: modern-di-fastapi — dependency injection for FastAPI via modern-di.
• awesome-asyncio / FastStream lists: faststream-outbox — transactional outbox for FastStream + Postgres.

7. Social one-liners (X / Mastodon / Bluesky)

• "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."
• "An HTTP client framework where your 404s are typed exceptions and retry/bulkhead/circuit-breaker are composable middleware. Sync and async. httpware."

---

Posting playbook (timing & etiquette)

• Stagger one launch item per week (modern-di → announcement →
  faststream-outbox → httpware). Greenfield, so each gets a clean first thread.
• Don't simultaneously cross-post the same project to HN + Reddit; space by a
  day or more.
• Engage every comment — that feedback is your Phase 5 roadmap input; route it
  to the modern-di Ideas Discussion.
• HN/Reddit: never solicit votes; lead with the honest "when not to use
  this." That candor is the credibility play.
• Reddit r/Python: follow the Showcase rules (the three required sections);
  post and engage, don't drop-and-run.

[lesnik512]

This was generated by AI during triage.

Human Brief

Category: enhancement
Summary: Fire the staggered launch (modern-di → org-story announcement → faststream-outbox → httpware), after refreshing the inlined copy against current releases.

Why this cannot be delegated to an agent:

• Every posting surface (Show HN, r/Python, Lobsters, dev.to) requires the maintainer's own identity and standing. Lobsters is called out in the body as needing an account with karma.
• Each post is one-shot per project. Greenfield means exactly one clean first thread per project, with no recovery from a bad one.
• Picking the launch window is explicitly the maintainer's judgment ("when the maintainer judges the positioning surfaces done").
• The body commits to engaging every comment, which is sustained human conversation and is the input to Phase 5.

Blocking pre-step: the inlined copy is stale. Now split out as #78 (ready-for-agent), which this issue is formally blocked on.

Facts were checked 2026-07-13. Re-verified against PyPI and the GitHub API on 2026-09-06:

Claim in the copy	Current
modern-di 2.28.0	3.4.0
modern-di 116 releases	127 GitHub releases (PyPI lists 98 versions)
modern-di 58 stars	66 stars
that-depends 4.0.2 / 251 stars	4.1.0 / 253 stars
httpware 0.15.1	0.16.0
faststream-outbox 0.10.5	0.13.1
lite-bootstrap 1.2.3	1.4.0

modern-di crossed a major version (2.x to 3.x) since the copy was written. The HN and r/Python drafts make specific design claims that were true of 2.x and need re-verification against 3.4.0 rather than renumbering:

• "13 integrations", and the exact integration list
• "no @provide decorator", providers as plain class attributes
• the synchronous resolve path and the ContextProvider async-lifespan recipe
• the claim that exactly seven integrations (Starlette, Flask, aiohttp, Celery, arq, aiogram, Typer) still need an @inject
• the Dishka star comparison ("~1.2k stars to my ~60"), both sides of it

Pin which "releases" figure the copy means: GitHub releases and the PyPI version count disagree (127 vs 98).

Acceptance criteria:

• Every version number, star count and release count re-verified on the posting date, not before it
• The modern-di design claims above re-checked against 3.x docs and corrected wherever 3.x changed them
• The "releases" figure sourced consistently, with the source stated
• modern-di posted to Show HN and r/Python, spaced by at least a day, Tue-Thu ~8-10am ET
• Org-story announcement published with equal billing for the whole stack
• faststream-outbox and httpware posted in later weeks, roughly one per week
• Chat rooms opened as the window starts (Open the org chat rooms (Telegram + Discord) during launch week #58)

Out of scope:

• Opening the chat rooms themselves. Open the org chat rooms (Telegram + Discord) during launch week #58 tracks that work.
• Newsletter submissions, and syndicating the org-story piece to dev.to / Hashnode. Those moved wholly to Submit the launch to the newsletters and syndicate the org story #59.
  This issue owns first publication of the org-story piece and therefore its canonical URL; Submit the launch to the newsletters and syndicate the org story #59 owns syndication
  after that URL exists, and is now formally blocked on this issue.
• Podcast pitches (Pitch Talk Python to Me and Python Bytes once the docs link gate is green #72), which are gated on the docs link gate in Add the offline link gate to the 18 green repos, and unpublish the ADRs in the two that have them #66, not on the launch window.
• awesome-list submissions and social one-liners, which can trail the main posts.

---

Corrected after grilling #59: the newsletter and cross-post items were originally listed here as partly in scope. They belong entirely to #59. Nothing else in this brief changed.

[lesnik512]

Fact re-verification pass — 2026-09-06 (#78)

The body above has been edited in place and its header now reads Facts checked 2026-09-06. Everything below is what changed and where each figure came from. Nothing was posted anywhere; this issue still ends at corrected text.

Numeric claims

Claim	Was	Now	Source
modern-di version	2.28.0	3.4.0	PyPI /pypi/modern-di/json → info.version
modern-di releases	"116 releases"	98 releases on PyPI	PyPI releases keys (98). See the "which number" note below.
modern-di stars	58★	66★	GitHub API repos/modern-python/modern-di
that-depends	4.0.2 / 251★	4.1.0 / 253★	PyPI + GitHub API
httpware	0.15.1	0.16.0	PyPI
faststream-outbox	0.10.5 / 29 releases / first commit 2026-05-07	0.13.1 / 34 PyPI releases / first commit 2026-05-06	PyPI; GitHub commit 083fb15 "init", 2026-05-06T18:45:17Z
lite-bootstrap	1.2.3	1.4.0	PyPI
Dishka comparison	"~1.2k stars to my ~60"	"~1.3k stars to my ~66"	GitHub API: dishka 1276, modern-di 66

"Releases" now cites one source, and says which. The header states release counts are PyPI version counts. modern-di's GitHub tag list has 127 entries; 69 of those never existed as a modern-di PyPI version — they are 1.0.0-alpha* / 2.0.0-alpha* pre-releases and monorepo-era core-* / fastapi-* / etc. tags. PyPI's 98 is the count of published modern-di releases, and is what a reader can reproduce. faststream-outbox is the same choice: 34 on PyPI, 33 GitHub releases.

Claims re-derived and unchanged

• modern-di has zero runtime dependencies — PyPI requires_dist is null; pyproject.toml has no [project.dependencies].
• modern-di is MIT — license = "MIT" in pyproject.toml, MIT on the GitHub API.
• httpware builds on httpx2, not httpx — requires_dist: httpx2>=2.0.0,<3.0.
• 13 official integrations — the docs' own comparison table lists exactly 13, and it counts pytest: aiogram, aiohttp, arq, Celery, FastAPI, FastStream, Flask, gRPC, Litestar, Starlette, taskiq, Typer, pytest. There are 13 matching modern-di-* repos in the org.
• Providers are plain class attributes on a Group, no @provide, no string keys — docs/index.md, docs/introduction/resolving.md.
• No DI decorator in FastAPI, Litestar, FastStream, taskiq — zero @inject occurrences across those four integration pages.
• The resolve path is synchronous and the container is an async context manager with async finalizers — modern_di/container.py: def resolve(...) (not async def), plus __aenter__ / __aexit__ / close_async; docs/introduction/design-decisions.md §1 "Resolution is sync-only; finalizers may be sync or async".
• Async resources via ContextProvider in the lifespan — docs/recipes/async-lifespan.md is unchanged in substance: container.set_context(...) in the lifespan + providers.ContextProvider(T, scope=Scope.APP).
• "Greenfield" — re-checked. HN Algolia URL search for modern-python.org and each project repo path returns 0 stories; Lobsters search returns nothing for any of the four projects.
• Every URL in the copy returns 200, including the ones inside the org-story draft (14 distinct URLs, all 200 following redirects).

Design claims corrected against modern-di 3.x

1. Scopes. Was "(APP → REQUEST → …)". 3.x has five built-in scopes, APP → SESSION → REQUEST → ACTION → STEP (Scope is an IntEnum, APP=1…STEP=5), and SESSION sits between APP and REQUEST, so the old shorthand implied a wrong order. Corrected in all three places. Source: docs/providers/scopes.md.

2. "Build-time" validation. Was "build-time cycle- and scope-violation checks". Validation is an explicit container.validate() call, not automatic. From the docstring in modern_di/container.py: "This is the only thing that validates — construction, open, add_providers, and resolve never do." It checks cycles, transitive scope ordering, and missing/unresolvable dependencies. Reworded to "one container.validate() call at startup, before the first request — not lazily at resolve time." This is a case where the old phrasing was the flattering reading, so it went rather than getting softened.

3. The @inject count and membership was wrong — it is eight, not seven. The copy's list omitted gRPC. modern-di-grpc requires @inject on servicer methods (docs/integrations/grpc.md: DIInterceptor "resolves FromDI-annotated parameters of @inject-decorated servicer methods"). Verified by counting @inject in every integration page: 0 for fastapi/faststream/litestar/taskiq, non-zero for aiogram, aiohttp, arq, celery, flask, grpc, starlette, typer. Both halves of the sentence corrected.

4. The FastAPI boundary form. Was FromDI(Dependencies.user_service) — "you still name the provider". FromDI(dependency_or_type) still accepts a provider, but the docs now show and prefer resolution by type: typing.Annotated[Report, modern_di_fastapi.FromDI(Report)] (docs/integrations/fastapi.md), and docs/introduction/resolving.md says "prefer resolution by type… reach for resolve_provider only when type-based resolution would be ambiguous." Changed to "you still mark the parameter (Annotated[UserService, FromDI(UserService)])". The paragraph's actual point — lighter than Dishka, not decorator-free — is unaffected.

5. "Do you even need a DI container?" is a section, not a page. It is the opening section of introduction/comparison.md, at https://modern-di.modern-python.org/introduction/comparison/#do-you-even-need-a-di-container. Corrected in the Show HN body and the org story; the Lobsters comment already said "section". The Show HN link now points at the comparison page directly. The "design decisions" page does exist as its own page, and its non-goals are still auto-binding, in-package integrations and graph rendering (plus a fourth, static wiring verification) — that claim stands.

6. Dishka "custom scopes" is no longer a clean differentiator. modern-di 3.x supports custom scopes: docs/providers/scopes.md#custom-scopes — "pass any IntEnum value where Scope is accepted". The real difference is that Dishka's are arbitrary named scopes, which is how the project's own comparison page puts it. Changed to "arbitrary named scopes" in both places rather than leaving a claim the docs contradict.

7. The integration count and the list now agree. The r/Python copy said "13 official integrations and a first-party pytest plugin", which double-counted pytest into 14. Now: "12 official framework integrations plus a first-party pytest plugin…, 13 in all". The Show HN bullet already named 12 frameworks + pytest and needed no change. The org story said "Thirteen official integrations" but its parenthetical list covered only 11 and silently dropped aiogram and pytest; the list is now complete.

8. "Integration coverage is roughly comparable" was left standing but made precise, because unqualified it is not supportable. Counting built-in integrations from Dishka's own docs/integrations/index.rst toctree: 14 in-library (aiogram, aiogram_dialog, aiohttp, arq, celery, click, fastapi, flask, grpcio, litestar, sanic, starlette, taskiq, telebot) against modern-di's 12 frameworks — comparable. Dishka additionally links ~10 community-maintained integrations, and its FastStream integration is community-supported where modern-di's is first-party. The copy now says "Built-in integration coverage… 12 frameworks to Dishka's 14 — though Dishka also has a large community-maintained set on top", which is both true and keeps the original point.

Nothing was left unverified

Every claim the brief enumerated was checked against PyPI, the GitHub API, or modern-di 3.4.0's own docs and source. Two notes for the posting-day re-check rather than open questions:

• Star counts move. 66 / 253 / 1276 are as of 2026-09-06. ~1.3k for Dishka has headroom; ~66 does not.
• modern-di local checkout was at 3.4.0-8-g02e9cf7 — eight commits past the published 3.4.0 tag, all docs/CI. Design claims were read from files whose content matches the published docs site, and the four docs URLs referenced were confirmed live at 200.

Out of scope, but noticed

docs/introduction/comparison.md in modern-di still tells readers to choose Dishka if they need "an integration modern-di doesn't have yet (aiogram, Taskiq, gRPC, …)" — modern-di ships all three. That is a stale line in the project docs, not in this copy, so it was left alone; worth a separate issue on modern-python/modern-di.