Tighten FastAPI repo boundary guidance

README.md

@@ -21,14 +21,6 @@ Primary upstreams mined so far:
 - `fastapi-users/fastapi-users`
 - `fastapi/full-stack-fastapi-template`
 
-Why this mix works:
-- FastAPI: router composition, dependencies, semantic exceptions, override-based testing seams
-- Starlette: lifespan, middleware, exception-layer mechanics, application assembly
-- Pydantic: request/response model boundaries and validation/serialization caveats
-- HTTPX: ASGI and transport-based testing seams
-- FastAPI Users: dependency-driven auth and router factory patterns
-- Full-stack FastAPI Template: real service module structure, session/auth wiring, and schema transitions
-
 ## Current convention set
 
 - `patterns/routes.md`
@@ -39,34 +31,16 @@ Why this mix works:
 - `patterns/testing.md`
 - `comparison/fastapi-vs-python.md`
 
-## What belongs here
+## Boundary rubric: does this belong in `fastapi-conventions`?
 
-Examples:
-- thin route handlers vs embedded business logic
-- request/response schema boundaries
-- dependency injection shape and lifetime
-- error envelope and exception translation
-- app startup/shutdown and resource wiring
-- sync/async boundaries at the HTTP layer
+Use this repo when the rule is mainly about the HTTP or app boundary: routes, `Depends(...)`, request/response schemas, HTTP error meaning, lifespan, or ASGI-level testing.
 
-## What does **not** belong here
+Push it back to the sibling `python-patterns` repo when the rule would still make sense in a CLI, library, or batch job.
 
-Do not duplicate generic Python rules unless FastAPI deliberately bends them. Link back to `python-patterns` instead.
-
-## Reviewing this repo
-
-Recommended review order:
-1. `README.md`
-2. `PROCESS.md`
-3. `sources/*.md` for evidence quality
-4. `patterns/*.md` for synthesis quality
-5. `comparison/*.md` for split-of-concerns clarity
-
-Questions to ask during review:
-- Is the guidance actually FastAPI/service-boundary specific?
-- Are framework seams described where the framework really owns behavior?
-- Are testing and dependency claims grounded in real source and tests?
-- Are caveats preserved instead of over-generalized?
+Quick check:
+- if FastAPI or Starlette owns the behavior, this repo should lead
+- if deleting the HTTP boundary leaves most of the rule intact, it is probably too generic for this repo
+- if the split is awkward, prefer the higher-level doc and cross-link rather than duplicating guidance
 
 ## Core rule