# FastAPI Conventions Process

This file documents the workflow used to build and refine this repo so the extraction can be repeated without guesswork.

## Goal

Turn repeated FastAPI-adjacent service patterns from mature upstream codebases into concise convention docs with verifiable citations.

## Scope split

Keep this repo at the **framework/service-boundary** level.

Good fits:
- route shape and handler thinness
- dependency injection and request-scoped wiring
- request/response schema boundaries
- persistence/session handling in web services
- app lifespan and startup/shutdown wiring
- service testing at the HTTP/ASGI boundary

Do **not** re-document generic Python guidance here unless FastAPI meaningfully bends it.

## Upstream selection rule

Use a mixed source set: framework internals plus at least one or two app-style repos.

Current first-wave set:
- `fastapi/fastapi`
- `encode/starlette`
- `pydantic/pydantic`
- `encode/httpx`

Current refinement/app-layer set:
- `fastapi-users/fastapi-users`
- `fastapi/full-stack-fastapi-template`

Selection criteria:
- respected and maintained
- reveals real service-boundary behavior, not just toy usage
- enough tests/examples to show lifecycle and caveats
- includes both intended abstractions and pragmatic app wiring

## Directory contract

- `sources/` = raw evidence notes, one file per upstream repo
- `patterns/` = synthesized conventions from repeated evidence
- `comparison/` = explicit notes on where FastAPI conventions differ from broader Python patterns

## Step-by-step workflow

### 1) Separate framework conventions from Python-wide rules
That split keeps guidance crisp and prevents vague “it depends” docs.

### 2) Make upstream code available locally
Local checkouts make `file:line` verification cheap and keep the process grounded.

### 3) Write source notes first
For each upstream repo, create `sources/<repo>.md` with:
- why the repo was chosen
- repeated patterns
- caveats/counterexamples
- exact `file:line` citations
- pattern candidates supported by the evidence

Good source notes are dense evidence, not polished guidance.

### 4) Synthesize conventions from the strongest repeated signals
Start with the topics where evidence is strongest.

Each convention doc should usually include:
- the convention
- why it exists
- where to apply it
- where not to cargo-cult it
- preferred shapes
- counterexamples
- source signals/citations

### 5) Add comparison notes where FastAPI bends general Python guidance
Examples:
- dependency injection via callables/signatures instead of constructor wiring
- request/response model boundaries as framework-facing objects
- lifespan hooks instead of generic entrypoint/context patterns

### 6) Refine before broadening
After the first useful convention set exists, do not rush to add more repos.

Instead:
- improve convention docs in fresh contexts
- strengthen citations
- rewrite `sources/*.md` so they are denser and more reusable
- reduce duplicated guidance across docs
- preserve subtle framework caveats that are easy to flatten away

## Handling mixed-concern source code

Upstream service code will often mix FastAPI behavior, Pydantic boundary behavior, and ordinary Python design in the same function or line.

When that happens:
- do not classify the whole snippet by file name or repo alone
- split the evidence into **framework-owned signal** and **generic Python signal**
- keep the request/response, dependency, lifecycle, and HTTP-boundary lesson here
- push reusable language-level guidance back to `python-patterns`

If the claim still makes full sense after removing FastAPI and HTTP, it is probably too generic to live here as a FastAPI convention.

## Review checklist

### For source notes
- Does the file distinguish repeated conventions from isolated examples?
- Does it preserve framework caveats and edge cases?
- Are citations exact and fast to verify?
- Does it avoid vague claims that are not source-backed?

### For convention docs
- Is the guidance really FastAPI/service-boundary specific?
- Is the framework-owned behavior described at the right seam?
- Are testing and dependency recommendations grounded in actual code/tests?
- Are exceptions and tradeoffs preserved instead of erased?

## Local git workflow used here

When the repo is ready for human review:
1. initialize a local git repo
2. stage the current documentation set
3. create a single initial commit so review has a stable baseline

This repo intentionally avoids pushing or creating remotes unless explicitly requested.

## What to avoid

- documenting FastAPI from memory or tutorial vibes
- mixing Python-wide guidance into this repo
- broadening source coverage before tightening evidence quality
- flattening dependency/lifespan/testing caveats into one-size-fits-all rules
- weak citations that are annoying to re-check