docs(readme): point the validation callout at the single-declaration path

README.md

@@ -288,7 +288,7 @@ def http_trigger(req: func.HttpRequest) -> func.HttpResponse:
 
 > **Pydantic v2 is a required dependency** (`pydantic>=2.0,<3.0`) and is installed with this package. `requests=` / `responses=` accept Pydantic models (the recommended path) **or** raw JSON Schema dicts (see below) — so you can describe schemas without authoring Pydantic models, but Pydantic itself is always present.
 
-> **Want runtime validation too? (optional)** `@openapi` documents your Pydantic models — it does not parse or validate requests at runtime. If you also want automatic request parsing, consistent `400`/`422` error responses, and response-model enforcement, layer [`azure-functions-validation`](https://github.com/yeongseon/azure-functions-validation-python)'s `@validate_http` on the **same** Pydantic models. It is an optional companion, not a dependency — this package works fully on its own. See the [validation README](https://github.com/yeongseon/azure-functions-validation-python#readme) for details, or a full runnable example that pairs both on one resource: [Full Stack CRUD API](https://github.com/yeongseon/azure-functions-cookbook-python/tree/main/examples/apis-and-ingress/full_stack_crud_api).
+> **Want runtime validation too? (optional)** `@openapi` documents your Pydantic models — it does not parse or validate requests at runtime. If you also want automatic request parsing, consistent `400`/`422` error responses, and response-model enforcement, layer [`azure-functions-validation`](https://github.com/yeongseon/azure-functions-validation-python)'s `@validate_http` on the **same** Pydantic models. It is an optional companion, not a dependency — this package works fully on its own. See the [validation README](https://github.com/yeongseon/azure-functions-validation-python#readme) for details, or a full runnable example that pairs both on one resource: [Full Stack CRUD API](https://github.com/yeongseon/azure-functions-cookbook-python/tree/main/examples/apis-and-ingress/full_stack_crud_api). `@validate_http` alone is also enough for the generated spec: the request, parameter and response models you declare in it, plus its `422` response, are discovered from its metadata, so `@openapi` is then only needed for summary, tags, security and extra response codes (see [Automatic bridge](docs/usage.md#automatic-bridge-zero-duplication)).
 
 > **Want structured logging too? (optional)** Pair your documented endpoints with [`azure-functions-logging`](https://github.com/yeongseon/azure-functions-logging-python) for structured, correlation-aware logs and observability. It attaches request/response context to every log line without changing your `@openapi` contracts. Like validation, it is an optional companion, not a dependency — this package works fully on its own. See the [logging README](https://github.com/yeongseon/azure-functions-logging-python#readme) for details.
 

docs/usage.md

@@ -771,6 +771,12 @@ when the discovered description is blank. Different schemas for the same
 status, request body, or parameter remain configuration errors; the exception
 identifies the endpoint, conflicting item, and both metadata sources.
 
+`register_openapi_routes(app, ...)` and the `app=` argument of `generate_openapi_spec`,
+`get_openapi_json`, `get_openapi_yaml` and `generate_openapi_report` already scan the app, so a
+separate `scan_endpoint_metadata(app)` call is optional on that path. Call it yourself only when
+you want to seed a registry ahead of time, for example the process-wide one for a generator call
+that does not pass `app=`.
+
 !!! info "No extra dependencies required"
     `scan_endpoint_metadata()` reads the convention-based metadata attribute
     written by `@validate_http` — no extra install step needed beyond having both