41f144d7bd
- request_id generated or sanitized-propagated on every request (x-request-id)
- structured JSON logging (pino), one correlated line per request, injectable logger
- error envelope v2 { error: { statusCode, code, message, details? }, requestId }
- 5xx messages always generic; stack traces stay in server logs only
- explicit parseJson (zod) input validation hook at the API layer
- README HTTP contract section; deps justified in spec/tech.md
- all gates approved; verify.sh green
19 lines
1013 B
Markdown
19 lines
1013 B
Markdown
# Documenter — F-003 HTTP foundation and request context
|
|
|
|
done -> work/artifacts/F-003/documenter.md
|
|
|
|
## Why documentation applies
|
|
F-003 defines the API-wide HTTP contract (request id, error envelope, validation hook) that every future module consumes.
|
|
|
|
## Documents reviewed/produced
|
|
- `project/README.md`: new "HTTP contract" section — x-request-id policy, envelope shape + codes, no-stack-leak guarantee, parseJson validation pattern, LOG_LEVEL. (Applied via a build-stage bounce because `project/` writes require build/implementer/running.)
|
|
- `spec/tech.md`: pino + zod justification rows added at build stage.
|
|
- `specs/F-003-http-foundation/` SPEC/DESIGN/TASKS/TESTS consistent with implementation.
|
|
|
|
## Verification
|
|
- README HTTP contract section matches tested behavior (cross-checked against qa.json live probes and test suite).
|
|
- Envelope documented as v2 (additive over F-001), codes enumerated.
|
|
|
|
## Pending docs (not this ticket)
|
|
- Per-module validation schemas documented as modules land (F-005+).
|