diff --git a/docs/recipes/async-lifespan.md b/docs/recipes/async-lifespan.md
index 9b49a13a..9faf3767 100644
--- a/docs/recipes/async-lifespan.md
+++ b/docs/recipes/async-lifespan.md
@@ -1,40 +1,34 @@
 # Async resources via lifespan
 
-Some resources need an `await` (or a running event loop) to construct, such as `aiohttp.ClientSession`, an `asyncpg` connection pool, an authenticated client whose construction does a token exchange. `modern-di` resolves synchronously, so the construction has to happen outside the resolve path.
+Some resources need an `await` or a running event loop to construct: `aiohttp.ClientSession`, an `asyncpg` connection pool, or a client that exchanges a token at startup. `modern-di` resolves synchronously, so a creator cannot `await`. Build these resources in the framework's lifespan and hand the live object to the container.
 
 ## Solution
 
-Do the async construction in the framework's lifespan. Use `container.set_context(SomeType, instance)` to register the live object on the APP container, then declare a `ContextProvider(SomeType, scope=Scope.APP)` so downstream factories can depend on the type.
-
-<!-- invisible-code-block: python
-import aiohttp
-
-
-class WeatherApi:
-    def __init__(self, client: aiohttp.ClientSession) -> None:
-        self.client = client
--->
+In the lifespan, build the resource and register it on the APP container with `container.set_context(SomeType, instance)`. Declare a `ContextProvider(SomeType, scope=Scope.APP)` so other factories can depend on the type. With FastAPI:
 
 ```python
 import contextlib
+import dataclasses
 from collections.abc import AsyncIterator
 
 import aiohttp
 import fastapi
+import modern_di_fastapi
 from modern_di import Container, Group, Scope, providers
 
 
-class Dependencies(Group):
-    http_client = providers.ContextProvider(
-        aiohttp.ClientSession,
-        scope=Scope.APP,
-    )
+@dataclasses.dataclass
+class WeatherApi:
+    client: aiohttp.ClientSession
 
-    # Downstream factories declare `client: aiohttp.ClientSession` and get the live instance
-    weather_api = providers.Factory(
-        WeatherApi,                    # signature: (client: aiohttp.ClientSession)
-        scope=Scope.REQUEST,
-    )
+    async def forecast(self, city: str) -> dict[str, str]:
+        async with self.client.get(f"https://weather.example.com/{city}") as response:
+            return await response.json()
+
+
+class Dependencies(Group):
+    http_client = providers.ContextProvider(aiohttp.ClientSession, scope=Scope.APP)
+    weather_api = providers.Factory(WeatherApi, scope=Scope.REQUEST)
 
 
 container = Container(groups=[Dependencies])
@@ -42,44 +36,79 @@ container = Container(groups=[Dependencies])
 
 @contextlib.asynccontextmanager
 async def lifespan(app: fastapi.FastAPI) -> AsyncIterator[None]:
-    async with container:                                          # ensures close_async on exit
-        async with aiohttp.ClientSession() as session:             # must be inside running loop
-            container.set_context(aiohttp.ClientSession, session)
-            yield
-        # ClientSession is closed by `async with` here
+    async with aiohttp.ClientSession() as session:
+        container.set_context(aiohttp.ClientSession, session)
+        yield
 
 
 app = fastapi.FastAPI(lifespan=lifespan)
+modern_di_fastapi.setup_di(app, container)
+container.validate()
+
+
+@app.get("/forecast/{city}")
+async def forecast(
+    city: str,
+    weather_api: WeatherApi = modern_di_fastapi.FromDI(WeatherApi),
+) -> dict[str, str]:
+    return await weather_api.forecast(city)
 ```
 
 <!-- invisible-code-block: python
-import aiohttp
+from fastapi.testclient import TestClient
 
-async with lifespan(app):
-    request_container = container.build_child_container(scope=Scope.REQUEST)
-    assert isinstance(request_container.resolve(WeatherApi).client, aiohttp.ClientSession)
+
+@app.get("/client-open")
+async def client_open(weather_api: WeatherApi = modern_di_fastapi.FromDI(WeatherApi)) -> bool:
+    return not weather_api.client.closed
+
+
+with TestClient(app) as client:
+    assert client.get("/client-open").json() is True
 -->
 
-`aiohttp.ClientSession` captures the running event loop at construction time, so it has to be built inside an async context, which the lifespan provides.
+`WeatherApi` receives the session through its `client: aiohttp.ClientSession` annotation. `aiohttp.ClientSession` needs a running event loop when it is constructed, and the lifespan runs inside the application's loop.
 
-The same pattern works for `asyncpg.create_pool(...)` (truly async), authenticated API clients that do a token exchange at startup, or anything else that needs `await` to be ready.
+`setup_di` wraps your lifespan: yours stays the outer context, and the integration opens the container inside it and closes it at shutdown, before your `async with` block exits. APP-scoped finalizers therefore run while the session is still open, and the session closes after them.
+
+Without an integration, enter the container yourself, after the resource, so it closes first:
+
+```python
+import contextlib
+from collections.abc import AsyncIterator
+
+import aiohttp
+import fastapi
+
+
+@contextlib.asynccontextmanager
+async def lifespan(app: fastapi.FastAPI) -> AsyncIterator[None]:
+    async with aiohttp.ClientSession() as session, container:
+        container.set_context(aiohttp.ClientSession, session)
+        yield
+```
+
+<!-- invisible-code-block: python
+import fastapi
+from modern_di import Scope
+
+async with lifespan(fastapi.FastAPI()):
+    request_container = container.build_child_container(scope=Scope.REQUEST)
+    assert not request_container.resolve(WeatherApi).client.closed
+assert container.closed
+-->
 
-`asyncpg.create_pool(...)` returns an awaitable `Pool` that only opens its
-connections when `await`ed (or entered with `async with`); modern-di has async
-*finalizers* but no async *initializer*, so the `await` has to happen in the
-lifespan.
+The same pattern fits `asyncpg.create_pool(...)`, which returns a pool that opens its connections only when awaited, and any client that needs an `await` before it is ready. `modern-di` has async finalizers but no async initializer, so that `await` belongs in the lifespan.
 
 ## Pitfalls
 
-- Set context *before* yielding. The lifespan hands control to the app inside the `yield`. If you `set_context` after yielding, requests that arrive in between won't see the value.
-- `set_context` never propagates between containers; see [context propagation](../providers/context.md#context-propagation). In the lifespan pattern above that is fine, because the resource is APP-scoped, so the APP-scoped `ContextProvider` reads the value set on the APP container. Per-request context is passed to each REQUEST child via `build_child_container(context={...})`.
-- Take care when combining a hand-written lifespan with an integration's `setup_di`. The integration (e.g. [`modern-di-fastapi`](../integrations/fastapi.md)'s `setup_di(app, container)`) already appends a lifespan that closes the container, and it merges with any `lifespan=` you pass. Keep the resource setup in your lifespan but drop the `async with container` wrapper: the integration owns the container close, and wrapping both closes it twice.
-- Choose APP scope unless the resource is per-connection. Redis and Kafka clients are process-singletons. For per-websocket-session resources, use `Scope.SESSION`.
-- `async with container:` handles APP-scope finalizers. If you also registered a `CacheSettings(finalizer=...)` somewhere, this runs it on exit. The lifespan-managed object isn't wrapped by a Factory, so its cleanup (`async with aiohttp.ClientSession()` in the example) is on you.
+- `set_context` never propagates between containers; see [Context propagation](../providers/context.md#context-propagation). Here that is fine: the `ContextProvider` is APP-scoped and the value is set on the APP container, so every REQUEST child reaches it.
+- Don't also wrap the lifespan in `async with container:` when you use `setup_di`. It is redundant: the integration already closes the container, and the second close runs no finalizers.
+- The container does not own the lifespan's resource. It was never created by a `Factory`, so no finalizer closes it; the `async with aiohttp.ClientSession()` block does.
 
 ## When a sync creator works instead
 
-Many "async" resources actually construct synchronously: `redis.asyncio.Redis.from_url(...)`, `sqlalchemy.ext.asyncio.create_async_engine(...)`, and `httpx.AsyncClient(...)` all return without awaiting. For those, prefer a normal `Factory` with `cache=CacheSettings(finalizer=async_close_fn)` and skip the lifespan + `set_context` dance entirely. Use this recipe only when construction needs `await` or a running event loop.
+Many async clients construct synchronously: `redis.asyncio.Redis.from_url(...)`, `sqlalchemy.ext.asyncio.create_async_engine(...)` and `httpx.AsyncClient(...)` all return without awaiting. For those, use a plain `Factory` with `cache=CacheSettings(finalizer=...)` and an async finalizer, and skip the lifespan and `set_context`. Use this recipe only when construction needs `await` or a running event loop.
 
 ## See also
 
diff --git a/docs/recipes/good-and-bad-practices.md b/docs/recipes/good-and-bad-practices.md
index 3a8674f9..013d9232 100644
--- a/docs/recipes/good-and-bad-practices.md
+++ b/docs/recipes/good-and-bad-practices.md
@@ -5,8 +5,8 @@ mistakes the framework lets you make, each paired with the mechanism that catche
 
 ## 1. Captive dependency: a wide-scoped provider holding a narrow-scoped one
 
-A *captive dependency* is a wide-scoped provider holding a narrow-scoped one it cannot actually
-outlive. See [the scope dependency rule](../providers/scopes.md#the-scope-dependency-rule) for why.
+A *captive dependency* is a wide-scoped provider holding a narrow-scoped one it cannot outlive. See
+[the scope dependency rule](../providers/scopes.md#the-scope-dependency-rule) for why.
 
 <!-- invisible-code-block: python
 from modern_di import Container, Group, Scope, providers
@@ -31,20 +31,16 @@ class Dependencies(Group):
     user_cache = providers.Factory(UserCache, scope=Scope.REQUEST)
 ```
 
-An explicit `container.validate()` call catches this: it raises `ValidationFailedError`
-carrying an `InvalidScopeDependencyError` for this exact graph before anything is ever resolved.
-See [Scope chain violation](../troubleshooting/scope-chain.md). Nothing validates automatically, so if
-the graph is never validated, the runtime failure is a `ScopeNotInitializedError`/`ScopeSkippedError`
-where the runtime error names both the provider that captured the dependency and the one that
-failed, and it fires on the first request that hits it rather
-than at startup. Prefer catching it statically with an explicit `validate()` call.
+`container.validate()` reports the broken version before anything resolves: it raises
+`ValidationFailedError` carrying an `InvalidScopeDependencyError`; see
+[Scope chain violation](../troubleshooting/scope-chain.md). Without `validate()`, the first resolve of
+`UserCache` raises `ScopeNotInitializedError`, whose message names both `UserCache` and `Session`, on
+the first request that reaches it instead of at startup.
 
 ## 2. Shipping a never-validated graph
 
-`validate()` is the only thing that checks the *whole* graph (cycles, inverted scopes, and missing
-dependencies). Nothing calls it for you: not construction, not `open()`, not `add_providers`, not
-`resolve()`. Skipping it leaves the bugs in place until whichever resolve happens to hit one
-first.
+`validate()` is the only check of the whole graph: cycles, scope violations, and dependencies
+nothing provides. Nothing calls it for you; see [Validation](../providers/lifecycle.md#validation).
 
 ```python
 # Broken: never validated, so wiring bugs surface one at a time, in production, on whatever request trips them
@@ -55,15 +51,15 @@ container = Container(groups=[Dependencies])
 container.validate()  # raises ValidationFailedError here if the graph is broken
 ```
 
-An explicit `container.validate()` call catches this. It is the only thing that finds every issue
-in the graph up front; without it, each wiring bug surfaces individually, at whichever resolve first
-reaches it. An unvalidated cyclic graph still isn't a silent hang; see
+`validate()` skips a provider declared with `bound_type=None` unless a provider registered by type
+depends on it, so such a provider can still fail on its first resolve. An unvalidated cyclic graph
+does not hang; see
 [the runtime cycle guard](../troubleshooting/circular-dependency.md#the-runtime-cycle-guard-without-validate).
 
 ## 3. A cached factory resolved before `set_context`
 
-Context values are read live on every resolve of a non-cached factory. A cached factory is
-built once, and a later `set_context` does not rebuild it.
+A cached factory is built once, and a later `set_context` does not rebuild it. An uncached factory
+reads the context again on every resolve.
 
 <!-- invisible-code-block: python
 class TenantConfig:
@@ -86,21 +82,18 @@ class Dependencies(Group):
     tenant_config = providers.Factory(create_tenant_config, scope=Scope.REQUEST)
 ```
 
-If a request container resolves `tenant_config` before the real tenant ID is known (e.g. during
-setup), the cached version keeps serving that first value for the rest of the request even after
-`request.set_context(str, real_tenant_id)` runs. Either drop `cache=True` for anything whose
-correctness depends on context set later, or make sure `set_context` runs before the first resolve.
-Nothing catches this automatically. It is a timing bug, not a wiring bug, so `validate()` cannot
-see it. See [Context propagation](../providers/context.md#context-propagation) for how `set_context`
-timing interacts with a provider's scope, and [Lifecycle](../providers/lifecycle.md) for caching.
+If a request container resolves `tenant_config` before the real tenant ID is set, the cached instance
+keeps the earlier value for the rest of the request. Drop `cache=True` for anything that depends on
+context set later, or set the context before the first resolve. `validate()` cannot catch this,
+because the graph is correct and only the timing is wrong. See
+[Context propagation](../providers/context.md#context-propagation).
 
-## 4. Service location via `container_provider` overuse
+## 4. Service location through an injected `Container`
 
-`container_provider` lets a creator accept the resolving `Container` itself and pull dependencies
-out of it manually. Used for its intended purpose (a provider that genuinely needs the container,
-such as building a child container), it's fine. Used as a shortcut to avoid declaring real
-parameters, it turns type-driven DI into a service locator: the dependency is hidden from
-`validate()`, from readers, and from anyone trying to see the graph.
+A creator can take the resolving `Container` as a parameter; see
+[Injecting the container itself](../providers/container.md#injecting-the-container-itself). Using it
+to pull the creator's real dependencies out of the container turns DI into a service locator: the
+dependency disappears from the signature and from `validate()`.
 
 <!-- invisible-code-block: python
 class Settings:
@@ -112,56 +105,70 @@ class Settings:
 def create_api_key(container: Container) -> str:
     return container.resolve(Settings).api_key
 
-# Works: declared as an ordinary parameter, so it is visible, validated, and testable via override
+# Works: declared as an ordinary parameter, so validate() checks it
 def create_api_key(settings: Settings) -> str:
     return settings.api_key
 ```
 
-Nothing enforces this; it is a matter of style discipline. Reserve
-`container_provider` for cases that are actually about the container (building a child container,
-introspecting the current scope), and declare everything else as a typed parameter so
-`validate()` and [Resolving dependencies](../introduction/resolving.md) can see it.
+When nothing provides `Settings`, the broken version passes `validate()` and raises
+`ProviderNotRegisteredError` on its first resolve, while `validate()` reports the declared parameter
+up front. Keep `Container` parameters for code that is about the container, such as building a child
+container.
 
 ## 5. Override leaks across tests
 
-`container.override(provider, replacement)` replacements are shared across the *whole* container
-tree. See [Testing with overrides](testing-overrides.md) for the mechanics. Forgetting to reset it
-affects more than the test that set it: every later test that shares the container inherits the
-replacement.
+Overrides are shared by the whole container tree (see [Testing with overrides](testing-overrides.md)),
+so one that is never reset reaches every later test that shares the container. Nothing reports the
+leak.
 
 <!-- invisible-code-block: python
+import typing
 from unittest.mock import Mock
 
 import pytest
-
-
-class Clock: ...
 -->
 
 ```python
-# Broken: no reset, so the next test that resolves Clock silently gets the fake
+class Clock:
+    def now(self) -> float:
+        return 0.0
+
+
+class Dependencies(Group):
+    clock = providers.Factory(Clock)
+
+
+container = Container(groups=[Dependencies])
+
+
+# Broken: nothing resets the override, so every later test that resolves Clock gets the fake
 def test_one() -> None:
-    container.override(Dependencies.clock, fake_clock)
-    ...
+    container.override(Dependencies.clock, Mock(spec=Clock))
 
-# Works: always reset, even if the test fails; a fixture teardown is the reliable place for this
+
+# Works: the with block resets the override after each test, even when the test fails
 @pytest.fixture
-def frozen_clock() -> Mock:
-    fake = Mock(spec=Clock)
-    container.override(Dependencies.clock, fake)
-    yield fake
-    container.reset_override(Dependencies.clock)
+def fake_clock() -> typing.Iterator[Mock]:
+    with container.override(Dependencies.clock, Mock(spec=Clock)) as fake:
+        yield fake
 ```
 
-Nothing catches this automatically mid-suite. `reset_override(provider)` (or `reset_override()` with no
-arguments, to clear everything) is the fix. Closing the root container does not clear overrides. See
-[Testing with overrides](testing-overrides.md#pitfalls).
+<!-- invisible-code-block: python
+test_one()
+assert isinstance(container.resolve(Clock), Mock)
+container.reset_override()
+assert isinstance(container.resolve(Clock), Clock)
+-->
+
+`reset_override(provider)`, or `reset_override()` with no argument, clears an imperative override.
+Closing the container does not. See [Testing with overrides](testing-overrides.md#pitfalls).
 
 ## 6. `skip_creator_parsing=True` with no `bound_type`
 
-`skip_creator_parsing=True` turns off signature introspection, which helps with callables that can't
-be reflected (C extensions, `functools.partial`). But skipping introspection also means modern-di has
-no idea what type the provider produces, so type-based resolution silently can't find it.
+`skip_creator_parsing=True` turns off signature introspection, for creators modern-di cannot
+introspect. It also skips the return annotation, so the provider has no bound type unless you pass
+one: `Factory(...)` warns at declaration, and resolving the type raises `ProviderNotRegisteredError`.
+See [`skip_creator_parsing`](../providers/factories.md#skip_creator_parsing).
 
 <!-- invisible-code-block: python
 class MyClass: ...
@@ -186,8 +193,39 @@ providers.Factory(
 )
 ```
 
-A `UserWarning` at declaration time catches this. It's easy to miss in test output, so treat it
-as a signal to add `bound_type=`.
+The warning is easy to miss in test output. Treat it as a signal to add `bound_type=`.
+
+## 7. Async finalizer on a container closed with `close_sync()`
+
+`close_sync()` cannot await, and a sync `with container:` block closes with it. An async finalizer
+there fails with `AsyncFinalizerInSyncCloseError` inside a `FinalizerError`, and the instance stays
+cached until `close_async()` runs. The Celery integration closes the APP container with
+`close_sync()`. See [Async finalizers and `close_sync()`](../providers/lifecycle.md#async-finalizers-and-close_sync).
+
+```python
+class HttpClient: ...
+
+
+async def close_client(client: HttpClient) -> None: ...
+
+
+class ClientDependencies(Group):
+    client = providers.Factory(HttpClient, cache=providers.CacheSettings(finalizer=close_client))
+```
+
+<!-- raises: FinalizerError -->
+
+```python
+# Broken: `with` closes the container with close_sync(), which cannot await close_client
+with Container(groups=[ClientDependencies]) as client_container:
+    client_container.resolve(HttpClient)
+```
+
+```python
+# Works: `async with` closes the container with close_async()
+async with Container(groups=[ClientDependencies]) as client_container:
+    client_container.resolve(HttpClient)
+```
 
 ## See also
 
diff --git a/docs/recipes/multi-group.md b/docs/recipes/multi-group.md
index a790a769..47f465bc 100644
--- a/docs/recipes/multi-group.md
+++ b/docs/recipes/multi-group.md
@@ -4,79 +4,60 @@ Your application has 30+ providers, and one `Group` holding all of them is unrea
 
 ## Solution
 
-Split providers into multiple `Group` subclasses by domain (database, cache, messaging, use cases) and pass them all to `Container(groups=[...])`. Cross-group dependencies wire by type, with no explicit references between groups.
-
-<!-- invisible-code-block: python
-import redis.asyncio as aioredis
-import sqlalchemy.ext.asyncio as sa_async
-
-
-class UserRepository:
-    def __init__(self, session: sa_async.AsyncSession) -> None:
-        self.session = session
-
-
-class OrderRepository:
-    def __init__(self, session: sa_async.AsyncSession) -> None:
-        self.session = session
-
-
-class PlaceOrder:
-    def __init__(self, users: UserRepository, orders: OrderRepository, cache: aioredis.Redis) -> None:
-        self.users = users
-        self.orders = orders
-        self.cache = cache
-
-
-class CancelOrder:
-    def __init__(self, orders: OrderRepository) -> None:
-        self.orders = orders
--->
+Split providers into several `Group` subclasses by domain (database, cache, repositories, use cases) and pass them all to `Container(groups=[...])`. Dependencies between groups wire by type, so no group refers to another.
 
 ```python
+import dataclasses
+
 import redis.asyncio as aioredis
 import sqlalchemy.ext.asyncio as sa_async
 from modern_di import Container, Group, Scope, providers
 
 
-# --- factory functions (defined once, shared across groups) ---
-
 def create_engine() -> sa_async.AsyncEngine:
     return sa_async.create_async_engine("postgresql+asyncpg://localhost/app")
 
 
-async def close_engine(engine: sa_async.AsyncEngine) -> None:
-    await engine.dispose()
-
-
 def create_session(engine: sa_async.AsyncEngine) -> sa_async.AsyncSession:
     return sa_async.AsyncSession(engine, expire_on_commit=False)
 
 
-async def close_session(session: sa_async.AsyncSession) -> None:
-    await session.close()
-
-
 def create_redis() -> aioredis.Redis:
     return aioredis.Redis.from_url("redis://localhost")
 
 
-async def close_redis(client: aioredis.Redis) -> None:
-    await client.aclose()
+@dataclasses.dataclass
+class UserRepository:
+    session: sa_async.AsyncSession
+
+
+@dataclasses.dataclass
+class OrderRepository:
+    session: sa_async.AsyncSession
+
+
+@dataclasses.dataclass
+class PlaceOrder:
+    users: UserRepository
+    orders: OrderRepository
+    cache: aioredis.Redis
+
 
+@dataclasses.dataclass
+class CancelOrder:
+    orders: OrderRepository
 
-# --- groups ---
 
 class Database(Group):
     engine = providers.Factory(
         create_engine,
         scope=Scope.APP,
-        cache=providers.CacheSettings(finalizer=close_engine),
+        cache=providers.CacheSettings(finalizer=sa_async.AsyncEngine.dispose),
     )
     session = providers.Factory(
         create_session,
         scope=Scope.REQUEST,
-        cache=providers.CacheSettings(finalizer=close_session),
+        cache=providers.CacheSettings(finalizer=sa_async.AsyncSession.close),
     )
 
 
@@ -84,50 +65,59 @@ class Cache(Group):
     redis_client = providers.Factory(
         create_redis,
         scope=Scope.APP,
-        cache=providers.CacheSettings(finalizer=close_redis),
+        cache=providers.CacheSettings(finalizer=aioredis.Redis.aclose),
     )
 
 
-class Repositories(Group):
-    # UserRepository signature: (session: AsyncSession)
-    users = providers.Factory(UserRepository, scope=Scope.REQUEST)
-    orders = providers.Factory(OrderRepository, scope=Scope.REQUEST)
+class Repositories(Group, scope=Scope.REQUEST):
+    users = providers.Factory(UserRepository)
+    orders = providers.Factory(OrderRepository)
 
 
-class UseCases(Group):
-    # PlaceOrder signature: (users: UserRepository, orders: OrderRepository, cache: aioredis.Redis)
-    place_order = providers.Factory(PlaceOrder, scope=Scope.REQUEST)
-    cancel_order = providers.Factory(CancelOrder, scope=Scope.REQUEST)
+class UseCases(Group, scope=Scope.REQUEST):
+    place_order = providers.Factory(PlaceOrder)
+    cancel_order = providers.Factory(CancelOrder)
 
 
 ALL_GROUPS = [Database, Cache, Repositories, UseCases]
 
 container = Container(groups=ALL_GROUPS)
+container.validate()
+```
+
+`Repositories` and `UseCases` set `scope=Scope.REQUEST` once on the class instead of on every provider; see [Group-level default scope](../providers/scopes.md#group-level-default-scope).
+
+`PlaceOrder` depends on providers from three other groups: the repositories, the Redis client from `Cache`, and through the repositories the session from `Database`. Inside one request both repositories get the same cached session:
+
+```python
+import sqlalchemy.ext.asyncio as sa_async
+
+async with container.build_child_container(scope=Scope.REQUEST) as request_container:
+    place_order = request_container.resolve(PlaceOrder)
+    session = request_container.resolve(sa_async.AsyncSession)
+    assert place_order.users.session is session
+    assert place_order.orders.session is session
 ```
 
 <!-- invisible-code-block: python
-import redis.asyncio as aioredis
+import sqlalchemy
 
-container.validate()
+await container.close_async()
 -->
 
-`PlaceOrder` depends on providers from three different groups: `Repositories`, `Cache`, and `Database` (transitively via the repositories). Nothing in `UseCases` references the other groups directly; type-based wiring sorts it out.
-
 ## Pitfalls
 
-- Duplicate `bound_type` raises at container creation. If two groups register providers for the same type (e.g. both bind to `AsyncSession`), `Container(groups=[...])` raises `DuplicateProviderTypeError` immediately. Fix by assigning distinct types, for instance by declaring thin subclasses (`class WriteSession(AsyncSession): ...`), or set `bound_type=None` on one provider and wire it explicitly via `kwargs`. See [Duplicate provider type](../troubleshooting/duplicate-type-error.md).
-- Attribute-name collisions do not affect `Container`. `Container` keys providers on their `bound_type`, not on the attribute name. Two groups can both have an attribute named `session` as long as their `bound_type`s differ, and `Container` sees no conflict. The duplicate-name `ValueError` belongs to `modern-di-pytest`'s `expose(*groups)` helper (a separate package), which generates one pytest fixture per attribute name and does raise `ValueError` on duplicates. If you use `expose()`, ensure attribute names are unique across the groups you pass to it.
-- Order in `groups=[...]` does not matter for resolution. Validate at startup by calling `container.validate()` explicitly, since nothing runs the check for you.
+- Two providers for the same type make `Container(groups=[...])` raise `DuplicateProviderTypeError`, whichever groups they are in. Give one of them `bound_type=None` and pass it to its consumers through [`kwargs`](../providers/factories.md#kwargs); see [DuplicateProviderTypeError](../troubleshooting/duplicate-type-error.md).
+- A provider object belongs to one group. Assigning it to a second group (`engine = Database.engine`) registers it twice and raises the same `DuplicateProviderTypeError`. To use another group's provider, depend on its type, or reference it in `kwargs={"engine": Database.engine}`.
+- `Container` ignores attribute names, so two groups can both have a `session` attribute. Litestar's `autowired_groups` and `modern-di-pytest`'s `expose()` do use them: the first warns and keeps the provider from the last group, and the second raises `ValueError`.
+- The order of `groups=[...]` does not matter. Nothing checks the combined graph for you, so call `container.validate()` at startup.
 
 ## Auto-wiring with Litestar
 
-If you're on Litestar, pass `autowired_groups=ALL_GROUPS` to `ModernDIPlugin` and every provider in those groups is automatically registered as a Litestar dependency by attribute name. A handler then receives one by naming a parameter after it, `place_order: NamedDependency[PlaceOrder]`, with no per-route `FromDI`.
-
-<!-- invisible-code-block: python
-from litestar import Litestar
--->
+On Litestar, pass `autowired_groups=ALL_GROUPS` to `ModernDIPlugin` and every provider in those groups becomes a Litestar dependency named after its attribute. A handler receives one by naming a parameter after it, `place_order: NamedDependency[PlaceOrder]`, with no per-route `FromDI`:
 
 ```python
+from litestar import Litestar
 from modern_di_litestar import ModernDIPlugin
 
 app = Litestar(
@@ -135,7 +125,7 @@ app = Litestar(
 )
 ```
 
-See the [Litestar integration](../integrations/litestar.md) for the full pattern.
+See [Auto-wiring with `autowired_groups`](../integrations/litestar.md#auto-wiring-with-autowired_groups) for a handler and the name-collision rules.
 
 ## See also
 
diff --git a/docs/recipes/pydantic-ai.md b/docs/recipes/pydantic-ai.md
index 293bdb08..425a24a4 100644
--- a/docs/recipes/pydantic-ai.md
+++ b/docs/recipes/pydantic-ai.md
@@ -66,9 +66,11 @@ async with container:
         assert "Hello, user-" in await answer("greet a user")
 -->
 
-Open the root container once at startup with `async with container:`, as in any other application.
-`agent.run_sync(...)` works the same way inside a `with` block, and so do `agent.run_stream(...)` and
-`agent.iter(...)`, as long as the child stays open until the run finishes.
+The `openai:` model string needs the `pydantic-ai-slim[openai]` extra; the recipe does not depend on
+the model. A constructed container is already open. Close it at shutdown, with
+`async with container:` around the application's lifetime or `await container.close_async()`, so
+APP-scoped finalizers run. `agent.run_sync(...)` works the same way inside a `with` block, and so do
+`agent.run_stream(...)` and `agent.iter(...)`, as long as the child stays open until the run finishes.
 
 If the agent also needs your own deps object, register it with the container instead: declare a
 provider for it and resolve it in the tool.
@@ -82,14 +84,35 @@ that must not be used concurrently, such as an `AsyncSession`. Give each tool ca
 
 ```python
 import contextvars
+import dataclasses
 import typing
 
-from modern_di import Container, Scope
+from modern_di import Container, Group, Scope, providers
 from pydantic_ai import Agent, RunContext
 from pydantic_ai.capabilities import AbstractCapability
 from pydantic_ai.messages import ToolCallPart
 from pydantic_ai.tools import ToolDefinition
 
+
+@dataclasses.dataclass
+class Session:
+    notes: list[str] = dataclasses.field(default_factory=list)
+
+    def add(self, note: str) -> None:
+        self.notes.append(note)
+
+    async def close(self) -> None: ...
+
+
+class NoteDependencies(Group):
+    session = providers.Factory(
+        Session,
+        scope=Scope.ACTION,
+        cache=providers.CacheSettings(finalizer=Session.close),
+    )
+
+
+container = Container(groups=[Dependencies, NoteDependencies])
 action_container: contextvars.ContextVar[Container] = contextvars.ContextVar("action_container")
 
 
@@ -119,31 +142,24 @@ agent = Agent("openai:gpt-5", deps_type=Container, capabilities=[ActionScope()])
 @agent.tool_plain
 async def save_note(note: str) -> str:
     session = action_container.get().resolve(Session)
-    ...
+    session.add(note)
+    return f"saved {note!r}"
 ```
 
 <!-- invisible-code-block: python
-from modern_di import Group, providers
 from pydantic_ai.models.test import TestModel
 
-
-class Session: ...
-
-
-class NoteDependencies(Group):
-    session = providers.Factory(Session, scope=Scope.ACTION)
-
-
 with agent.override(model=TestModel()):
-    async with Container(groups=[NoteDependencies]).build_child_container(scope=Scope.REQUEST) as run_container:
-        await agent.run("save a note", deps=run_container)
+    async with container.build_child_container(scope=Scope.REQUEST) as run_container:
+        result = await agent.run("save a note", deps=run_container)
+assert "saved" in result.output
+await container.close_async()
 -->
 
-Declare per-call providers at `Scope.ACTION`, for example
-`providers.Factory(Session, scope=Scope.ACTION, cache=providers.CacheSettings(finalizer=...))`. Each
-tool call gets its own instance, and its finalizer runs when that call returns. The container lives in
-a `ContextVar` rather than on the capability, because one capability instance serves all the
-concurrent calls; each call sees only the child it opened.
+`session` is declared at `Scope.ACTION`, so each tool call gets its own `Session`, and its finalizer
+runs when that call returns. The container lives in a `ContextVar` rather than on the capability,
+because one capability instance serves all the concurrent calls; each call sees only the child it
+opened.
 
 ## See also
 
diff --git a/docs/recipes/request-scoped-engine.md b/docs/recipes/request-scoped-engine.md
index fa743d33..4754a953 100644
--- a/docs/recipes/request-scoped-engine.md
+++ b/docs/recipes/request-scoped-engine.md
@@ -6,24 +6,13 @@ This recipe routes read-only requests (`GET`, `HEAD`) to a read-replica engine a
 
 ## Solution
 
-Two APP-scoped engine factories (primary and replica) and one REQUEST-scoped factory that inspects the request and returns the engine to use for it. Sessions and repositories depend on the *request-scoped* engine, not the named factories.
-
-<!-- invisible-code-block: python
-import sqlalchemy.ext.asyncio as sa_async
-
-
-def create_session(engine: sa_async.AsyncEngine) -> sa_async.AsyncSession:
-    return sa_async.AsyncSession(engine)
-
-
-async def close_session(session: sa_async.AsyncSession) -> None:
-    await session.close()
--->
+Declare two APP-scoped engine factories, primary and replica, and one REQUEST-scoped factory that looks at the request and returns the engine to use for it. The session depends on that request-scoped engine by type.
 
 ```python
-import sqlalchemy.ext.asyncio as sa_async
 import fastapi
-from modern_di import Group, Scope, providers
+import modern_di_fastapi
+import sqlalchemy.ext.asyncio as sa_async
+from modern_di import Container, Group, Scope, providers
 
 
 def create_primary_engine() -> sa_async.AsyncEngine:
@@ -34,13 +23,6 @@ def create_replica_engine() -> sa_async.AsyncEngine:
     return sa_async.create_async_engine("postgresql+asyncpg://replica/db")
 
 
-async def close_engine(engine: sa_async.AsyncEngine) -> None:
-    await engine.dispose()
-
-
-# Choose which engine this request uses.
-# `primary` and `replica` are injected by name from kwargs.
-# `request` is injected by type from the framework's request ContextProvider.
 def choose_engine(
     primary: sa_async.AsyncEngine,
     replica: sa_async.AsyncEngine,
@@ -51,48 +33,67 @@ def choose_engine(
     return primary
 
 
-class PrimaryEngine(sa_async.AsyncEngine): ...
-class ReplicaEngine(sa_async.AsyncEngine): ...
+def create_session(engine: sa_async.AsyncEngine) -> sa_async.AsyncSession:
+    return sa_async.AsyncSession(engine, expire_on_commit=False)
 
 
 class Dependencies(Group):
     primary = providers.Factory(
         create_primary_engine,
         scope=Scope.APP,
-        bound_type=PrimaryEngine,
-        cache=providers.CacheSettings(finalizer=close_engine),
+        bound_type=None,
+        cache=providers.CacheSettings(finalizer=sa_async.AsyncEngine.dispose),
     )
     replica = providers.Factory(
         create_replica_engine,
         scope=Scope.APP,
-        bound_type=ReplicaEngine,
-        cache=providers.CacheSettings(finalizer=close_engine),
+        bound_type=None,
+        cache=providers.CacheSettings(finalizer=sa_async.AsyncEngine.dispose),
     )
-
-    # REQUEST-scope: picks per-request, cached for the rest of that request
     engine = providers.Factory(
         choose_engine,
         scope=Scope.REQUEST,
         kwargs={"primary": primary, "replica": replica},
         cache=True,
     )
-
-    # Sessions and repositories use the REQUEST-scoped engine
     session = providers.Factory(
         create_session,
         scope=Scope.REQUEST,
-        cache=providers.CacheSettings(finalizer=close_session),
+        cache=providers.CacheSettings(finalizer=sa_async.AsyncSession.close),
     )
+
+
+container = Container(groups=[Dependencies])
+
+app = fastapi.FastAPI()
+modern_di_fastapi.setup_di(app, container)
+container.validate()
+
+
+@app.api_route("/engine", methods=["GET", "POST"])
+async def engine_url(
+    session: sa_async.AsyncSession = modern_di_fastapi.FromDI(sa_async.AsyncSession),
+) -> str:
+    return str(session.bind.url)
 ```
 
-Why the `PrimaryEngine` / `ReplicaEngine` subclasses: type-based resolution needs distinct types for the two factories. Without them, both would register under `AsyncEngine` and `Container(groups=[...])` would raise `DuplicateProviderTypeError` at startup. See [Duplicate provider type](../troubleshooting/duplicate-type-error.md).
+<!-- invisible-code-block: python
+from fastapi.testclient import TestClient
+
+with TestClient(app) as client:
+    assert client.get("/engine").json() == "postgresql+asyncpg://replica/db"
+    assert client.post("/engine").json() == "postgresql+asyncpg://primary/db"
+-->
+
+Only `engine` is registered under `AsyncEngine`, so `create_session` gets the engine chosen for the request. Two providers cannot both register under one type, so `primary` and `replica` have `bound_type=None` and reach `choose_engine` through `kwargs`; see [`bound_type`](../providers/factories.md#bound_type). `request` is wired by type to the `fastapi.Request` the integration puts in each request's container.
 
 ## Pitfalls
 
-- The choice factory must be REQUEST-scoped. It depends on the per-request `Request` object. An APP-scoped factory cannot consume request-scoped data and `container.validate()` will reject it.
-- The framework integration provides `fastapi.Request` (or `litestar.Request`) automatically. No need to declare a `ContextProvider` for it. For Litestar, use `litestar.Request`.
-- Don't apply this to per-connection pooling decisions. Engines (and their pools) are APP-scoped, so the choice you make per request selects which long-lived pool the session checks out from. Trying to make the engine itself REQUEST-scoped would create and dispose a pool every request.
-- Watch for write-after-read in a single request. If a `GET` handler ends up doing a write (e.g. updating a `last_seen_at` field), it'll go to the replica and fail. Either move the side-effect out of the read path, or pick a different routing predicate than HTTP method.
+- The choice factory must be REQUEST-scoped, because it consumes the per-request `Request`. `container.validate()` rejects an APP-scoped one with `InvalidScopeDependencyError`.
+- The integration registers the `ContextProvider` for `fastapi.Request` (on Litestar, `litestar.Request`), so you don't declare one. It does so in `setup_di`, so call `container.validate()` after `setup_di`, as above; see [Framework context objects](../providers/context.md#framework-context-objects).
+- `kwargs` resolves both engines every time `choose_engine` runs, so the first request creates both and they stay cached, even though it uses one of them. `create_async_engine` opens no connection, so this costs nothing until a session checks one out.
+- Keep the engines APP-scoped. Each engine owns a connection pool, and the per-request choice only selects which long-lived pool the session uses. A REQUEST-scoped engine would build and dispose a pool on every request.
+- Watch for writes in a read request. If a `GET` handler writes (updating a `last_seen_at` column, say), the write goes to the replica and fails. Move the side effect out of the read path, or route on something other than the HTTP method.
 
 ## See also
 
diff --git a/docs/recipes/sqlalchemy.md b/docs/recipes/sqlalchemy.md
index 395c2588..b7acec8c 100644
--- a/docs/recipes/sqlalchemy.md
+++ b/docs/recipes/sqlalchemy.md
@@ -1,16 +1,17 @@
 # Async SQLAlchemy: engine, session, repository
 
-This recipe wires `create_async_engine` + `AsyncSession` + repository classes through `modern-di` so the engine is shared process-wide, sessions are per-request, and cleanup happens automatically at shutdown and at the end of each request.
+This recipe wires `create_async_engine`, `AsyncSession` and repository classes through `modern-di`, so the process shares one engine, each request gets one session, and the containers close both.
 
 ## Solution
 
 The recipe uses three providers at two scopes:
 
-- The engine is at `Scope.APP`: one per process, cached, disposed at shutdown.
-- The session is at `Scope.REQUEST`: one per request, cached inside that request, closed at the end of the request.
-- Repositories are at `Scope.REQUEST` and depend on the session by type, one per request.
+- The engine is at `Scope.APP`: cached, so the whole process shares one engine and its connection pool, and disposed when the APP container closes.
+- The session is at `Scope.REQUEST`: cached in the request's container and closed when that container closes at the end of the request.
+- Repositories are at `Scope.REQUEST` and uncached. Every resolve builds a new repository, and all the repositories in one request share its session.
 
 ```python
+import sqlalchemy as sa
 import sqlalchemy.ext.asyncio as sa_async
 from modern_di import Group, Scope, providers
 
@@ -22,33 +23,28 @@ def create_engine() -> sa_async.AsyncEngine:
     )
 
 
-async def close_engine(engine: sa_async.AsyncEngine) -> None:
-    await engine.dispose()
-
-
 def create_session(engine: sa_async.AsyncEngine) -> sa_async.AsyncSession:
     return sa_async.AsyncSession(engine, expire_on_commit=False)
 
 
-async def close_session(session: sa_async.AsyncSession) -> None:
-    await session.close()
-
-
 class UserRepository:
     def __init__(self, session: sa_async.AsyncSession) -> None:
         self.session = session
 
+    async def count(self) -> int:
+        return await self.session.scalar(sa.text("SELECT count(*) FROM users"))
+
 
 class Dependencies(Group):
     engine = providers.Factory(
         create_engine,
         scope=Scope.APP,
-        cache=providers.CacheSettings(finalizer=close_engine),
+        cache=providers.CacheSettings(finalizer=sa_async.AsyncEngine.dispose),
     )
     session = providers.Factory(
         create_session,
         scope=Scope.REQUEST,
-        cache=providers.CacheSettings(finalizer=close_session),
+        cache=providers.CacheSettings(finalizer=sa_async.AsyncSession.close),
     )
     user_repository = providers.Factory(
         UserRepository,
@@ -56,9 +52,9 @@ class Dependencies(Group):
     )
 ```
 
-The session factory consumes `engine: sa_async.AsyncEngine` via type-based wiring, with no `kwargs={}` needed. `UserRepository` consumes `session: sa_async.AsyncSession` the same way.
+`create_session` receives the engine through its `sa_async.AsyncEngine` annotation, and `UserRepository` receives the session through its `sa_async.AsyncSession` annotation, so no `kwargs` are needed. Both finalizers are unbound async methods: Python passes the cached instance as `self`, as [Caching and finalizers](../providers/lifecycle.md#caching-and-finalizers) explains.
 
-Wire to your framework as usual:
+Wire the container to your framework and inject the repository where a handler needs it. With FastAPI:
 
 ```python
 import fastapi
@@ -70,21 +66,28 @@ container = Container(groups=[Dependencies])
 
 app = fastapi.FastAPI()
 modern_di_fastapi.setup_di(app, container)
+container.validate()
+
+
+@app.get("/users/count")
+async def count_users(
+    repository: UserRepository = modern_di_fastapi.FromDI(UserRepository),
+) -> int:
+    return await repository.count()
 ```
 
-The integration creates a REQUEST child container per request, so the session and repository are created on first resolve and cleaned up when the request ends.
+For a route that uses `FromDI`, `modern-di-fastapi` builds a REQUEST child container, resolves the session and the repository from it, and closes it after the response, which closes the session. The engine is disposed when the application shuts down. Call `container.validate()` after `setup_di`, because `setup_di` registers the integration's own providers; see [Validation](../providers/lifecycle.md#validation).
 
 ## Pitfalls
 
-- `CacheSettings.finalizer` accepts sync or async functions; it auto-detects. Don't wrap with `asyncio.run` or `asyncio.ensure_future`.
-- `expire_on_commit=False` on `AsyncSession` avoids expensive refreshes after commit. If you rely on `expire_on_commit=True`, leave it, though it's a common source of "session is closed" errors in async code.
-- Don't share the engine across REQUEST containers manually. The provider already does it: REQUEST containers walk up to the APP container to resolve the engine.
-- Repositories must be REQUEST-scoped, not APP-scoped: they hold a session which is REQUEST-scoped, and `container.validate()` will reject the inverse.
+- Keep `expire_on_commit=False`. With the default `True`, a commit expires every loaded object, and the next attribute read tries to reload it. In async code that read fails with a `StatementError` wrapping `sqlalchemy.exc.MissingGreenlet`.
+- The engine's finalizer is async, so the APP container has to be closed with `close_async()`. FastAPI and Litestar do that at shutdown. Flask, gRPC and Typer leave the APP container to you, and Celery closes it with `close_sync()`, which cannot await the finalizer. See [Per-scope finalization](../providers/lifecycle.md#per-scope-finalization) and [Async finalizers and `close_sync()`](../providers/lifecycle.md#async-finalizers-and-close_sync).
+- Repositories hold a REQUEST-scoped session, so they cannot be APP-scoped. `container.validate()` rejects an APP-scoped repository; see [the scope dependency rule](../providers/scopes.md#the-scope-dependency-rule).
 
 ## Variations
 
-- For multiple databases, declare two engine factories, two session factories, and give the second set distinct return types or `bound_type=` arguments so type-based resolution can tell them apart.
-- Tests typically override the engine with an `AsyncConnection` inside a transaction. See [Testing with overrides](testing-overrides.md).
+- For several databases, declare one engine and one session factory per database. Two providers cannot both register under `AsyncEngine`, so give the extra ones `bound_type=None` and pass them to their consumers through [`kwargs`](../providers/factories.md#kwargs). [Request-scoped engine selection](request-scoped-engine.md) shows the pattern with a primary and a replica.
+- In tests, override the engine with a connection inside a transaction that rolls back after each test. See [Transactional database tests](testing-overrides.md#transactional-database-tests).
 
 ## See also
 
diff --git a/docs/recipes/testing-overrides.md b/docs/recipes/testing-overrides.md
index ba67a4a1..0ead9ca0 100644
--- a/docs/recipes/testing-overrides.md
+++ b/docs/recipes/testing-overrides.md
@@ -1,10 +1,10 @@
 # Testing with overrides
 
-Tests often need to swap a real dependency (database, HTTP client, clock) for a fake one without touching production wiring.
+Tests often need to swap a real dependency (database, HTTP client, clock) for a fake one without touching production wiring. `container.override(provider, replacement)` makes every resolve of that provider return the replacement until the override is reset.
 
-## Solution
+## Override with a context manager
 
-`container.override(provider, replacement)` replaces what the provider resolves to, immediately, and returns an `OverrideHandle`. Used as a context manager, it auto-resets on exit, and that is the primary spelling for tests:
+`override()` returns an `OverrideHandle`. Used in a `with` block, it resets the override on exit, which makes it the primary spelling for tests:
 
 <!-- invisible-code-block: python
 from modern_di import Container, Group, providers
@@ -23,135 +23,207 @@ mock_client = ApiClient()
 
 ```python
 with container.override(MyGroup.api_client, mock_client) as client:
-    ...  # resolution returns mock_client; prior state restored on exit
+    assert container.resolve(ApiClient) is client
 ```
 
-The override applies at the `override()` call, not at `__enter__`. `__exit__` restores the snapshot taken at that call: a previously stacked override if there was one, otherwise no override. It does so even on exception, and even if `reset_override()` ran inside the block. Nested overrides of the same provider unwind in order: each handle restores whatever was active before it. Handles are expected to exit in reverse order of creation, which `with`-block nesting does naturally; manually exiting handles out of order can restore stale state.
+The override takes effect at the `override()` call, and `with` hands back the replacement. On exit, even after an exception or a `reset_override()` inside the block, the handle restores what was active at the call: an earlier override of the same provider, or none. Nested overrides of one provider unwind in reverse order, as nested `with` blocks do; exiting handles out of order can restore stale state.
 
-`container.override(provider, replacement)` also works as a plain imperative call: reset with `container.reset_override(provider)` (or `container.reset_override()` to clear all). This pair remains fully supported (see the patterns below). Closing the container does not clear overrides, so an imperative override stays until you reset it. Either way, the replacement is keyed by provider reference (not name) and is shared across the container tree, so an override on the root APP container applies to all child REQUEST containers too.
+Overrides are keyed by provider object and stored once for the whole container tree. An override set on any container, the root or a REQUEST child, applies to every container that shares its root.
 
-## Pattern 1: Simple mock override
+## Imperative override and reset
 
-For unit-style tests, override the provider with a fake before exercising the code under test:
+Without `with`, `override()` applies until you reset it:
+
+```python
+container.override(MyGroup.api_client, mock_client)
+assert container.resolve(ApiClient) is mock_client
+container.reset_override(MyGroup.api_client)
+```
+
+`container.reset_override()` with no argument clears every override. Closing a container does not clear them.
+
+## Container fixtures without the plugin
+
+You can test without [`modern-di-pytest`](../integrations/pytest.md): build the container in a session-scoped fixture, build a REQUEST child per test, and set overrides in function-scoped fixtures:
 
 <!-- invisible-code-block: python
+import dataclasses
 import sys
 import types
 
-from modern_di import Container, Group, Scope, providers
+from modern_di import Group, Scope, providers
 
 
-class UserRepository: ...
+class UserRepository:
+    def name(self, user_id: int) -> str:
+        return f"user-{user_id}"
 
 
-class PlaceOrder:
-    def __init__(self, users: UserRepository) -> None:
-        self.users = users
+@dataclasses.dataclass
+class Greeter:
+    users: UserRepository
 
+    def greet(self, user_id: int) -> str:
+        return f"Hello, {self.users.name(user_id)}"
 
-class Dependencies(Group):
-    user_repository = providers.Factory(UserRepository, scope=Scope.APP)
-    place_order = providers.Factory(PlaceOrder, scope=Scope.APP)
 
-
-app_ioc = types.ModuleType("app.ioc")
-app_ioc.Dependencies = Dependencies
-app_ioc.container = Container(groups=[Dependencies])
-app_package = types.ModuleType("app")
-app_package.ioc = app_ioc
-sys.modules.update({"app": app_package, "app.ioc": app_ioc})
+class Dependencies(Group):
+    user_repository = providers.Factory(UserRepository, scope=Scope.APP, cache=True)
+    greeter = providers.Factory(Greeter, scope=Scope.REQUEST)
+
+
+app_module = types.ModuleType("app")
+ioc_module = types.ModuleType("app.ioc")
+services_module = types.ModuleType("app.services")
+ioc_module.Dependencies = Dependencies
+ioc_module.ALL_GROUPS = [Dependencies]
+services_module.Greeter = Greeter
+services_module.UserRepository = UserRepository
+app_module.ioc = ioc_module
+app_module.services = services_module
+sys.modules.update({"app": app_module, "app.ioc": ioc_module, "app.services": services_module})
+del UserRepository, Greeter, Dependencies
 -->
 
 ```python
-from unittest.mock import AsyncMock
+import typing
+
+import modern_di
 import pytest
 
-from app.ioc import Dependencies, container
+from app import ioc
+from app.services import Greeter, UserRepository
+
+
+class FakeUserRepository(UserRepository):
+    def name(self, user_id: int) -> str:
+        return "fake"
+
+
+@pytest.fixture(scope="session")
+def di_container() -> typing.Iterator[modern_di.Container]:
+    with modern_di.Container(groups=ioc.ALL_GROUPS) as container:
+        container.validate()
+        yield container
 
 
 @pytest.fixture
-def fake_users() -> AsyncMock:
-    fake = AsyncMock(spec=UserRepository)
-    container.override(Dependencies.user_repository, fake)
-    yield fake
-    container.reset_override(Dependencies.user_repository)
+def request_container(di_container: modern_di.Container) -> typing.Iterator[modern_di.Container]:
+    with di_container.build_child_container(scope=modern_di.Scope.REQUEST) as container:
+        yield container
 
 
-async def test_place_order_calls_users(fake_users: AsyncMock) -> None:
-    use_case = container.resolve(PlaceOrder)
-    await use_case.run(...)
-    fake_users.find_by_id.assert_awaited()
+@pytest.fixture
+def fake_users(di_container: modern_di.Container) -> typing.Iterator[FakeUserRepository]:
+    with di_container.override(ioc.Dependencies.user_repository, FakeUserRepository()) as fake:
+        yield fake
+
+
+def test_greeting(request_container: modern_di.Container, fake_users: FakeUserRepository) -> None:
+    assert request_container.resolve(Greeter).greet(1) == "Hello, fake"
 ```
 
-## Pattern 2: Transactional session fixture (real database)
+<!-- invisible-code-block: python
+with modern_di.Container(groups=ioc.ALL_GROUPS) as root:
+    with root.override(ioc.Dependencies.user_repository, FakeUserRepository()) as fake:
+        with root.build_child_container(scope=modern_di.Scope.REQUEST) as child:
+            test_greeting(child, fake)
+    with root.build_child_container(scope=modern_di.Scope.REQUEST) as child:
+        assert child.resolve(Greeter).greet(1) == "Hello, user-1"
+
+for stand_in in ("app", "app.ioc", "app.services"):
+    sys.modules.pop(stand_in)
+-->
 
-For integration tests against a real database, run each test in a nested transaction that rolls back at the end. Override the engine provider with the test connection so every session created during the test reuses it.
+`Greeter` is REQUEST-scoped, so the test resolves it from `request_container`; resolving it from `di_container` raises `ScopeNotInitializedError`. The override sits on the session-scoped container, so `fake_users` has to undo it after each test, and the `with` block does that even when the test fails. To get dependencies as fixtures instead of resolving them in the test, see [Pytest integration](../integrations/pytest.md): [Pointing a fixture at a child container](../integrations/pytest.md#pointing-a-fixture-at-a-child-container) and [Overrides](../integrations/pytest.md#overrides).
 
-```python
-import pytest
-import sqlalchemy.ext.asyncio as sa_async
+## Transactional database tests
 
-from app.ioc import Dependencies, container
+For tests against a real database, run each test inside a transaction and roll it back at the end. Override the engine provider from the [Async SQLAlchemy recipe](sqlalchemy.md) with a connection that holds the open transaction, so every session built during the test uses that connection:
+
+<!-- invisible-code-block: python
+import sys
+import types
 
+import sqlalchemy.ext.asyncio as sa_async
+from modern_di import Group, Scope, providers
 
-@pytest.fixture(scope="session")
-async def engine() -> sa_async.AsyncEngine:
-    eng = sa_async.create_async_engine("postgresql+asyncpg://...test")
-    try:
-        yield eng
-    finally:
-        await eng.dispose()
 
+def create_engine() -> sa_async.AsyncEngine:
+    return sa_async.create_async_engine("postgresql+asyncpg://localhost/app")
 
-@pytest.fixture
-async def db_connection(engine: sa_async.AsyncEngine) -> sa_async.AsyncConnection:
-    async with engine.connect() as connection:
-        transaction = await connection.begin()
-        container.override(Dependencies.engine, connection)
-        try:
-            yield connection
-        finally:
-            container.reset_override(Dependencies.engine)
-            await transaction.rollback()
-```
 
-Tests that pull a session through DI (`container.resolve(sa_async.AsyncSession)`) get one bound to the test connection, and everything they write rolls back at the end.
+class Dependencies(Group):
+    engine = providers.Factory(create_engine, scope=Scope.APP, cache=True)
 
-## Pattern 3: `modern-di-pytest` fixtures
 
-For tests that consume DI dependencies as fixtures rather than resolving manually, the `modern-di-pytest` package generates fixtures from providers:
+app_module = types.ModuleType("app")
+ioc_module = types.ModuleType("app.ioc")
+ioc_module.Dependencies = Dependencies
+app_module.ioc = ioc_module
+sys.modules.update({"app": app_module, "app.ioc": ioc_module})
+del Dependencies
+-->
 
 ```python
-from modern_di_pytest import expose, modern_di_fixture
+import typing
 
-from app.ioc import Dependencies
+import modern_di
+import pytest
+import sqlalchemy.ext.asyncio as sa_async
 
+from app import ioc
 
-# Single fixture from a specific provider
-user_repository = modern_di_fixture(Dependencies.user_repository)
 
-# Or expose every provider in a Group as a fixture (one per attribute)
-expose(Dependencies)
+@pytest.fixture
+async def db_connection(
+    di_container: modern_di.Container,
+) -> typing.AsyncIterator[sa_async.AsyncConnection]:
+    engine = sa_async.create_async_engine("postgresql+asyncpg://user:pass@localhost/test")
+    async with engine.connect() as connection:
+        transaction = await connection.begin()
+        with di_container.override(ioc.Dependencies.engine, connection):
+            yield connection
+        await transaction.rollback()
+    await engine.dispose()
 
 
-async def test_user_repo(user_repository: UserRepository) -> None:
-    assert await user_repository.count() == 0
+@pytest.fixture
+async def session(
+    db_connection: sa_async.AsyncConnection,
+    di_container: modern_di.Container,
+) -> typing.AsyncIterator[sa_async.AsyncSession]:
+    async with di_container.build_child_container(scope=modern_di.Scope.REQUEST) as request_container:
+        yield request_container.resolve(sa_async.AsyncSession)
 ```
 
 <!-- invisible-code-block: python
-sys.modules.pop("app")
-sys.modules.pop("app.ioc")
+import sqlalchemy
+
+for stand_in in ("app", "app.ioc"):
+    sys.modules.pop(stand_in)
 -->
 
-Combine with `container.override(...)` in a setup fixture to swap underlying providers; `modern_di_fixture` resolves through the override.
+The session is REQUEST-scoped, so the `session` fixture resolves it from a REQUEST child, which also closes it after the test. Async fixtures need an async test plugin; with pytest-asyncio, set `asyncio_mode = "auto"` so plain `@pytest.fixture` works on them.
+
+Build the session with `join_transaction_mode="create_savepoint"`:
+
+```python
+import sqlalchemy.ext.asyncio as sa_async
+
+
+def create_session(engine: sa_async.AsyncEngine) -> sa_async.AsyncSession:
+    return sa_async.AsyncSession(engine, expire_on_commit=False, join_transaction_mode="create_savepoint")
+```
+
+Under the default mode, a `session.rollback()` in the code under test rolls back the test's transaction too, and the fixture's own rollback then emits `SAWarning: transaction already deassociated from connection`. With `create_savepoint`, the session commits and rolls back a savepoint inside the test's transaction, and the fixture's rollback discards everything. In production the session is bound to an engine, not to a connection already in a transaction, and the option has no effect.
 
 ## Pitfalls
 
-- Overrides are global. Override the root APP container and every child REQUEST container sees the replacement. Fine in tests; remember it if you also override in production code.
-- `override` is keyed by provider reference. Pass `Dependencies.user_repository` (the provider object), not the string `"user_repository"`.
-- Always `reset_override` in the fixture teardown. Leaking overrides between tests is a class of bug that doesn't fail loudly.
-- Wrap session-scoped containers in a function-scoped override fixture. If the `Container` fixture itself is session-scoped (built once for the whole test run), don't call `override`/`reset_override` directly in a test. Wrap the pair in their own function-scoped fixture so the override is guaranteed to reset after each test, even on failure.
-- Override the right level. If you override the engine but tests resolve the session, the session's creator still runs, so make sure the engine override produces something the creator can use. If the test relies on a specific session, override the session directly.
+- Overrides are global to the container tree. Override on any container and every container sharing its root sees the replacement. That is what tests want; keep it in mind if you ever override outside tests.
+- `override` is keyed by provider object. Pass `Dependencies.user_repository`, not the string `"user_repository"`, which raises `AttributeError`.
+- Always reset. A leaked override reaches every later test that shares the container, and nothing reports it. With a session-scoped container, set overrides in a function-scoped fixture with `with container.override(...)`, so they are reset after each test even when it fails.
+- Override the right level. If you override the engine but tests resolve the session, the session's creator still runs, so the replacement has to be something that creator accepts. If a test relies on a specific session, override the session itself.
 
 ## See also