engineering notes
Documentation
The docs section is split by responsibility so transport, parser, route behavior, and verification can be read independently without flattening everything into one long page.
architecture
Server architecture
The TCP server keeps state per connection, accumulates bytes conservatively, and only routes a request after a complete HTTP frame is present.
parser
Parser behavior
The parser is strict on purpose: it waits for CRLF CRLF, validates the request line, normalizes headers, and refuses to guess when the body is incomplete.
routes
Application routes
The route layer stays deliberately small so the project can prove its transport and parsing behavior without hiding behind application complexity.
verification
Verification workflow
This project is small enough that verification should be routine. Tests, typecheck, and live smoke requests together give a clear signal about transport, parser, and route health.
How to read this project
Start with architecture if you want the request lifecycle. Move to parser if you are changing request handling. Read routes if you are modifying endpoint behavior. Finish with verification before you trust the change.
This split is deliberate. The project is compact, but transport code becomes confusing quickly when socket ownership, parser rules, and route semantics are mixed into one page.
Why the docs are structured this way
Each page mirrors a real subsystem in the repository. That avoids the usual documentation problem where pages are organized around marketing headings instead of actual code boundaries.
The intent is that someone opening the docs can jump directly from a concept to the source file that implements it, without decoding vague language first.