projektor

Use when adding/changing database schema (Flyway migrations under server/persistence/database-schema), writing or modifying a *Repository/*DatabaseRepository class, regenerating jOOQ code, or writing tests that touch the database. Covers the migration → jOOQ codegen workflow, the repository pattern (interface + *DatabaseRepository backed by jOOQ DSLContext/DAOs), Koin wiring, transaction handling, and how the real-Postgres test setup works (per-test HikariCP pool, no truncation between tests, random-ID isolation).

Use when adding/modifying HTTP routes, auth checks, config values, or cross-cutting Ktor plugins in server/server-app — the general application/HTTP layer (as opposed to the MCP-specific server, covered by mcp-server-dev, or the jOOQ/Postgres layer, covered by database-persistence). Covers the Route-extension-function file convention, the manual header-token auth pattern, the lack of a StatusPages plugin (error handling is per-route try/catch), config loading via ApplicationConfig + per-subsystem *Config.createXConfig factories, and how to write an HTTP-level test with ApplicationTestCase.

Use when adding tools to, modifying, or debugging Projektor's MCP server (server/server-app/src/main/kotlin/projektor/mcp/, served at /mcp via the Ktor mcpStatelessStreamableHttp helper). Covers the ContentNegotiation/Jackson footgun that silently breaks MCP JSON-RPC responses (wrong field casing, explicit nulls, wrong enum values) whenever a new SDK type is touched, how to verify a response is actually spec-compliant instead of just checking HTTP 200, the OAuth well-known discovery routes, and local/live testing commands.

Use when you need the big-picture map of this repo — what Projektor is, what each Gradle/npm module does, how a test run flows from CI publish to UI render, the server-api/server-client/server-app split, and how local dev and production deployment work. This is the "start here" orientation skill; it deliberately doesn't duplicate the deep internals already covered by mcp-server-dev, database-persistence, or ktor-server-dev — it points to those instead. Use this before a broad refactor, when you're lost about where something lives, or when onboarding to an unfamiliar part of the codebase.

Use when running, reproducing, or debugging Cypress e2e test failures in this repo (ui/cypress) — including CI-reported failures pasted from a build log, flaky/intermittent failures, click handlers that silently do nothing, tooltip/graph assertions after a UI-library upgrade, or cy.intercept not behaving as expected. Covers how to start the dev server and run specs here, how to pull data out of the browser into terminal output, hit-testing a stuck click, and the two cy.intercept footguns (StaticResponse property names, substring URL matching) that have caused real failures in this codebase.