askimo-ai/askimo

Summary We currently use slf4j-api (+ logback-classic as the backend) for logging across the Askimo codebase (see askimo/gradle/libs.versions.toml, the logging bundle). Since the project is Kotlin Multiplatform (Compose Multiplatform desktop/android), we should migrate to Kermit, a logging library designed for KMP, to get a consistent logging API across all targets (JVM/desktop, Android, iOS, etc.) instead of relying on a JVM-only facade like SLF4J. Motivation SLF4J is JVM-only and doesn't work out of the box across KMP targets (common/android/ios source sets), forcing expect/actual workarounds or JVM-only logging code. Kermit provides a common Logger API usable from commonMain, with platform-specific backends (Issue/LogWriter), and ships a dedicated kermit-jvm artifact that integrates cleanly with SLF4J/Logback on the JVM. Consolidating logging under one API simplifies maintenance and keeps log output consistent across desktop, Android, and any future targets. Scope of work Dependency

Current behavior In ChatInputField.kt, when AppConfig.voice.enabled is true, a mic button toggles VoiceRecordingState (IDLE → RECORDING → TRANSCRIBING → IDLE), backed by AudioRecorder (io.askimo.ui.voice.AudioRecorder). While RECORDING, a live waveform (voiceWaveform) plus an elapsed-seconds counter is shown next to the mic button, and recording auto-stops after MAX_VOICE_RECORDING_SECONDS. On stop, stopRecordingAndTranscribe sends captured audio to STT and inserts the transcript into the input field. AgentRunArea.kt's goal OutlinedTextField (around line 567) has no mic button, no VoiceRecordingState, and no AudioRecorder usage — voice dictation is only available in normal chat sessions, not in the agentic "Run" input. Proposed change Extract/reuse the voice-recording logic (VoiceRecordingState, AudioRecorder wiring, waveform UI, auto-stop timer, transcription callback) from ChatInputField.kt into a shared composable/helper, then integrate it into agenticRunArea's goal input

Replace the current JVM-only Exposed + HikariCP + sqlite-jdbc persistence stack in shared/ with SQLDelight 2, to enable sharing the local SQLite persistence layer across Kotlin Multiplatform targets (Android, iOS, Desktop) Motivation shared is currently a kotlin("jvm") module. org.jetbrains.exposed.v1.jdbc.* and sqlite-jdbc are JVM-only (JDBC + JNI), so this code cannot run on iOS or JS/WASM targets. SQLDelight 2 has first-class KMP drivers (sqlite-driver on JVM, AndroidSqliteDriver, NativeSqliteDriver for iOS/Native) backed by SQLite's native C API directly - no JDBC bridging required outside the JVM. Compile-time SQL validation against the schema (.sq files checked at build time) catches query/schema mismatches earlier than Exposed's runtime DSL. Removes reliance on HikariCP connection pooling, which provides little benefit for a single-writer SQLite file and can be replaced by a single SqlDriver instance. Current state Schema is defined as raw SQL DDL in DatabaseManager.kt - 17 ta

Summary With the growing list of predefined AI provider templates, the left-column list in the Add Provider dialog (TYPE_PICKER step) is becoming too long to scan visually. A search field should be added so users can quickly find a provider by name. Current Behaviour The providerTypePickerScreen renders a fixed scrollable list of all providers in the left column (~260dp wide). With 15+ entries, users must scroll to find a specific provider. Relevant file: ProviderSelectionDialog.kt Relevant function: providerTypePickerScreen Expected Behaviour A compact search field appears at the top of the left column, above the provider list Typing filters the list to entries whose displayName contains the query (case-insensitive) "Other (custom URL)" is always pinned at the bottom of the list - it is never filtered out If no providers match the query, show a subtle empty state message in the list area (e.g. "No providers found"), while "Other" remains visible If the currently selected entry no lo

Summary We currently have 5 predefined templates in OpenAiCompatibleTemplate.kt: Cloudflare AI, Groq, NVIDIA NIM, OpenRouter, Together AI This issue tracks adding more popular cloud AI providers as predefined templates so users can connect them in one click without needing to know the API URL. Background A template is a simple enum entry - no new factory, no new ModelProvider enum value needed. The minimum required fields are: PROVIDER_NAME( displayName = "Provider Name", initials = "PN", // 2-letter badge shown in the UI taglineKey = "provider.template.provider_name.tagline", // i18n key baseUrl = "https://api.provider.com/v1", apiKeyRequired = true, apiKeyUrl = "https://provider.com/get-api-key", helpTextKey = "provider.template.provider_name.help", // i18n key // optional overrides: // apiMode = OpenAiApiMode.RESPONSES, // httpVersion = HttpVersion.HTTP_1_1, // modelFetcher = { apiKey, baseUrl, httpVersion -> ... }, ) You