ktor-backend-endpoint

Follow a six-step procedure: write the SQL migration, define the Exposed table, implement a suspend Repository returning domain models, create a framework-free Use Case, add a thin Ktor route that only parses and serializes, then register everything in Koin and Application.kt.

Enable RLS on every new table with ALTER TABLE ... ENABLE ROW LEVEL SECURITY and create a policy filtering by workspace_id using current_setting('app.current_workspace_id'). Never bypass RLS with superuser roles or run tenant queries without a WHERE filter.

Use SELECT ... FOR UPDATE on the parent Project row inside a transaction, increment its last_task_number counter, then insert the task with that locked number. Global database sequences and in-memory counters are not acceptable for this pattern.

No. Routes must only parse requests, extract the tenant from the JWT, call a Use Case, and serialize the response. Calling Repositories from routes breaks layer boundaries and makes business logic untestable without a running server.

Validate the provider's signature header (X-Hub-Signature-256 or X-Gitlab-Token) against the raw request body before processing any payload. Document explicitly why the endpoint omits the authenticate block, and ensure lookups by git_branch_name use a dedicated index.

Use Cases contain pure business logic and must be testable without a server or database framework. Importing io.ktor.* or org.jetbrains.exposed.* couples the domain layer to infrastructure, violating Clean Architecture boundaries and breaking unit testability.