docs/specs/¶
Post-implementation specifications — the authoritative "what this subsystem is and what it guarantees" reference for shipped features.
A spec captures the final intent and contract of an implementation
after a brief's work has fully shipped. It supersedes the brief
(which moves out of docs/briefs/ when its phases all merge) and
complements the operator reference in docs/<feature>.md.
See CLAUDE.md for the
full lifecycle and the rule on when to author a spec.
What a spec is (and is not)¶
A spec is the durable contract a future re-implementation would need to satisfy. It answers:
- What does this subsystem do?
- What invariants does it maintain?
- What is its public surface (interfaces, env vars, config fields, error semantics, exit codes, on-disk layout, network protocols)?
- What guarantees does it make to callers / operators?
A spec is not:
- A changelog —
CHANGELOG.mdowns that. - A how-to guide —
docs/<feature>.mdowns that for operators. - An API reference for individual functions — Go doc comments own that.
- A history of how the design evolved — git history + retired briefs own that.
When a fact could live in more than one place, this is the split:
| Question | Spec | Operator doc (docs/<feature>.md) |
Go doc |
|---|---|---|---|
| What does it do / guarantee? | yes (one paragraph + invariants) | yes (expanded, with examples) | — |
| How do I set it up? | — | yes | — |
| What config fields / env vars? | mention + link to the operator doc | yes (full table) | the struct field |
| What's the on-disk / wire format? | yes (if a re-implementer needs it) | only if operators debug/migrate it | — |
| How does function X work? | — | — | yes |
Terminology¶
Used consistently across specs:
- Source — origin of image bytes (filesystem / HTTP / S3); never called a "backend".
- Backend — a pluggable storage or strategy choice (cache: heap / filesystem / s3 / redis; auth access-service: builtin / header / external / oidc).
- Handler — an HTTP route handler. Service — an IIIF service (e.g.
AuthProbeService2). Interface — a Go interface (Source,Authorizer,Hook,RenderCache).
Naming¶
One file per subsystem. Current specs:
scaffold.md— initial project scaffold + cache contracthttp-interface.md— routes, middleware, status codes, cache/CORS semanticsauth.md— IIIF Authorization Flow 2.0 contractpresentation.md— IIIF Presentation API 3.0/2.1 serve/derive/viewer contracthtj2k.md— HTJ2K decode + distroless image contractcache-filesystem.md— filesystem cache backend contractimage-decode.md— resolution-aware decode + source I/O contractbench-harness.md— comparative benchmark harness contractwindows-build.md— Windows build/runner contractreleases.md— release process contracttelemetry.md— Sentry error tracking + OpenTelemetry tracing contract