🛜 scrumia-ktor

What it is responsible for

Nine refusal rules covering the eight rule families Ktor owns — routing, content negotiation, HTTP client, authentication, test client, server configuration, WebSockets and SSE, and observability — plus a ninth that names the dissociation between HTTP status and the application's typed-error discipline. Ships a ktor-audit skill that audits an existing codebase against the nine, and a find-spec mapping for the keys the module answers to. The rules are about a library, not a stack: a pure-JVM service, a Ktor-on-Android client, a Kotlin/JS browser app activates scrumia-ktor alone.

What it refuses

A route registered outside the application's routing {} tree. A Json.decodeFromString on call.receiveText() in an application that installs ContentNegotiation. An HttpClient constructed per call. A check inside the handler. A test that opens a real port. A literal port or secret in Kotlin. A websocket that never reads a frame, or an SSE loop that never reconnects. A println inside a handler. A Result.failure whose body is r.status — the channel is the application's, not the network's.

The assumption it makes

Assumes the library's documentation is the citation for every rule — no blog posts, no tutorials, no community patterns. Costs discipline at every plugin install, at every HttpClient construction, and at every route, and pays back in a surface that one reader can see end to end. The dissociation between HTTP status and effect semantics is the line the module exists to hold: scrumia-ktor owns the library, the typed-error paradigm belongs to the next module.

Its skills

• ktor-audit

Tags

• scrumia
• ktor
• http
• server
• client
• kotlin

What it plugs into

Install it

Read the source on GitHub