</details>

### Configuración de la base de datos

Kviklet necesita su propia base de datos postgres (o al menos un esquema) para guardar metadatos sobre consultas, conexiones, aprobaciones, etc.
Puedes encontrar su imagen oficial aquí: https://hub.docker.com/_/postgres, o usar una versión alojada en la nube por el proveedor de nube que prefieras.

Al iniciar el contenedor de kviklet, deberás configurar estas tres variables de entorno en consecuencia:```
SPRING_DATASOURCE_PASSWORD = password
SPRING_DATASOURCE_USERNAME = username
SPRING_DATASOURCE_URL = jdbc:postgresql://[host]:[port]/[database]?currentSchema=[schema]

Publicamos nuestros contenedores en GitHub packages por ahora, así que con todo esto configurado puedes ejecutar `ghcr.io/kviklet/kviklet:main`, no olvides mapear el puerto `8080`, que es el puerto predeterminado en el que Kviklet se inicia.

Un ejemplo de docker run podría verse así:```
docker run \
-e SPRING_DATASOURCE_PASSWORD=postgres \
-e SPRING_DATASOURCE_USERNAME=postgres \
-e SPRING_DATASOURCE_URL=jdbc:postgresql://localhost:5432/Kviklet \
-e [email protected] \
-e INITIAL_USER_PASSWORD=someverysecurepassword \
--network host \
ghcr.io/kviklet/kviklet:main

El client id y secret de Google los puedes obtener fácilmente siguiendo las instrucciones de Google aquí:
https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid

Para los URI de redirección válidos, debes configurar: https://[kviklet_host]/api/login/oauth2/code/google
Para los Orígenes Permitidos, simplemente la URL de tu kviklet alojado.

Después de configurar esas variables de entorno, todos en tu organización podrán iniciar sesión con el botón de iniciar sesión con Google. Pero no tendrán ningún permiso por defecto, tendrás que asignarles un rol después de que inicien sesión una vez.

#### Keycloak

Si quieres configurar SSO con Keycloak en su lugar, necesitas configurar estas 4 variables de entorno:```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=keycloak
KVIKLET_IDENTITYPROVIDER_ISSUERURI=http://[host]:[port]/realms/[realm]

Crea una GitHub OAuth App en https://github.com/settings/developers y configura:

- Authorization callback URL: `https://[kviklet_host]/api/login/oauth2/code/github`
- Homepage URL: tu URL de Kviklet alojada

`KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS` es **obligatorio** (Kviklet se niega a iniciarse sin él). Las GitHub OAuth Apps no pueden restringir quién completa el flujo OAuth, por lo que Kviklet llama a `/user/orgs` después de la autenticación y rechaza a los usuarios que no son miembros de al menos una organización en la lista de permitidas (sin distinguir mayúsculas y minúsculas, se comprueban las primeras 100 organizaciones).

Para que la comprobación de organización vea la pertenencia de un usuario, este debe hacer clic en **Grant** (o **Request**) junto a cada organización permitida en la pantalla de consentimiento de OAuth. Si la organización tiene habilitado "Restrict third-party OAuth applications", un propietario de la organización también debe aprobar la aplicación OAuth una vez antes de que la pertenencia de cualquier miembro sea visible.

Kviklet solicita los scopes `read:user`, `user:email` y `read:org`. Los correos electrónicos siempre se leen desde `/user/emails` y solo se acepta una entrada `primary && verified`, por lo que los usuarios con direcciones de correo privadas aún pueden iniciar sesión correctamente.

#### Otros proveedores OIDC

Otros proveedores compatibles con OIDC (GitLab, Auth0, Okta, etc.) deberían funcionar de forma similar a Keycloak. Ten en cuenta que el `redirect URI` cambiará según el tipo que elijas, así que si eliges `gitlab` será `https://[kviklet_host]/api/login/oauth2/code/gitlab`.
Si encuentras problemas, no dudes en crear un issue; no hemos probado todos los proveedores OIDC que existen (todavía) y puede haber ligeras diferencias en la implementación que requieran actualizaciones por parte de Kviklet.

### LDAP

Kviklet admite autenticación LDAP. Para habilitar y configurar LDAP, puedes sobrescribir las siguientes variables de entorno:```
LDAP_ENABLED=true
LDAP_URL=ldap://your-ldap-server:389
LDAP_BASE=dc=your,dc=domain,dc=com
LDAP_PRINCIPAL=cn=admin,dc=your,dc=domain,dc=com
LDAP_PASSWORD=your-admin-password
LDAP_UNIQUE_IDENTIFIER_ATTRIBUTE=uid
LDAP_EMAIL_ATTRIBUTE=mail
LDAP_FULL_NAME_ATTRIBUTE=cn
LDAP_USER_OU=people
LDAP_SEARCH_BASE=ou=people

Detalles de configuración:

- `SAML_ENABLED`: Establecer en `true` para habilitar la autenticación SAML
- `SAML_ENTITYID`: El ID de entidad de tu proveedor de identidad SAML
- `SAML_SSOSERVICELOCATION`: La URL del servicio SSO de tu proveedor de identidad
- `SAML_VERIFICATIONCERTIFICATE`: El certificado X.509 utilizado para verificar las respuestas SAML (incluye las líneas BEGIN/END CERTIFICATE)

Opcionalmente, puedes personalizar las asignaciones de atributos SAML:```
SAML_USERATTRIBUTES_EMAILATTRIBUTE=email
SAML_USERATTRIBUTES_NAMEATTRIBUTE=name
SAML_USERATTRIBUTES_IDATTRIBUTE=nameID

## Configuración

### Conexiones

Después de iniciar Kviklet, primero debes configurar una conexión a base de datos. Ve a Settings -> Databases -> Add Connection.

![Add Connection](https://assets.kitploit.com/production/public/readmes/7140/3ded2a0b23e5d2f02feb21a854263c91dedea25a789fb75ab8342384c4e39b52.png)
![Add Connection](https://assets.kitploit.com/production/public/readmes/7140/585238c9eddad8ed4e2440096ce0616445a6696e1042f58676a1d0b038edde7f.png)

Aquí puedes configurar los requisitos de revisión y los límites de ejecución para cada conexión. Consulta [Review Gates](#review-gates) para más detalles.

#### AWS IAM AUTH

Kviklet admite el uso de IAM Auth para conexiones a bases de datos Postgres, MySQL y MariaDB; para ello, elige IAM Auth al crear una nueva conexión.

![IAM Auth](https://assets.kitploit.com/production/public/readmes/7140/14ed42bd639eb9b0ba81b22850e277703f2da9495dd101f68066f95fc51f291c.png)
![IAM Auth](https://assets.kitploit.com/production/public/readmes/7140/5a60a3a9ae527e11679f3c33c787caba4c80b379ddc463db1f871288408517e1.png)

Esto eliminará la opción de establecer una contraseña y, en su lugar, usará credenciales de AWS para conectarse a la base de datos.

Kviklet usa el `DefaultCredentialsProvider` de AWS para encontrar credenciales y generar el token para la conexión. Esto significa que todos los lugares típicos deberían funcionar (variables de entorno o roles de instancia asociados); el orden exacto está documentado aquí: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html

Además, puedes proporcionar un ARN de rol de AWS que Kviklet asumirá y usará esas credenciales para crear el token temporal de la base de datos. Esto es particularmente útil para conectarse a bases de datos que no están en la misma cuenta de AWS que Kviklet. Para usar esta función, simplemente introduce el ARN del rol en el campo designado al crear o editar una conexión IAM Auth. Dejar el campo vacío usará el proveedor de credenciales predeterminado (sin asunción de rol).

La región de AWS a usar durante la generación del token se infiere de la URL de tu conexión, por lo que no hay opción para configurarla.

Para aprender cómo configurar IAM Auth para tu base de datos, sigue la documentación oficial de AWS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
Los dos puntos principales son:

- Crear un usuario de base de datos con la opción de autenticación IAM y los permisos correctos
- Crear una política de IAM que permita a la entidad de AWS generar tokens para este usuario

### Review Gates

Por defecto, Kviklet permite una configuración simple del número de revisiones. Puedes configurar cuántas aprobaciones necesitan las solicitudes en una conexión específica antes de poder ejecutarse.

El estado de aprobación de una solicitud se calcula en función de la última acción de cada revisor. Si un revisor aprueba y luego solicita cambios, solo cuenta la solicitud de cambios: su aprobación anterior se elimina. Editar una solicitud siempre restablece todas las aprobaciones previas, lo que garantiza que ningún cambio pueda ejecutarse sin ser revisado primero. De forma similar, si una ejecución falla (por ejemplo, debido a un error de sintaxis SQL), las aprobaciones se restablecen para que la solicitud pueda corregirse y volver a aprobarse sin tener que crear una nueva.

También puedes configurar un límite de **ejecuciones máximas** por conexión para controlar con qué frecuencia se puede ejecutar una única solicitud aprobada. El valor predeterminado es 1. Establecerlo en 0 permite ejecuciones ilimitadas. Las ejecuciones fallidas no cuentan para este límite.

#### Requisitos de revisión basados en roles (Enterprise)

Con una licencia de Kviklet Enterprise puedes configurar conexiones individuales para que requieran aprobaciones de usuarios con roles específicos. Esto te permite, por ejemplo, exigir la aprobación del equipo que mantiene una base de datos determinada o restringir conexiones sensibles tras aprobaciones de DBA o de la dirección.

**Cómo funciona:**

Cada conexión tiene un recuento de **revisiones totales requeridas** (`numTotalRequired`) que actúa como mínimo: el número mínimo de aprobaciones distintas necesarias independientemente de los roles. Además de eso, puedes añadir **requisitos de rol** que especifiquen cuántas aprobaciones deben provenir de usuarios con un rol concreto (por ejemplo, "1 de DBA, 1 de Security").

Una solicitud solo se aprueba cuando se cumplen **ambas** condiciones:

- El número total de aprobaciones distintas alcanza `numTotalRequired`
- Cada requisito de rol se satisface individualmente

Si un usuario pertenece a varios roles, una sola aprobación de ese usuario cuenta para todos los requisitos de rol coincidentes. Sin embargo, sigue contando solo como una aprobación para el recuento total.

**Ejemplo:** Una conexión requiere 3 aprobaciones totales, incluyendo 1 de un DBA y 1 de Security. Un usuario que tiene tanto el rol DBA como el de Security aprueba: esto satisface ambos requisitos de rol, pero solo cuenta como 1 de las 3 aprobaciones totales necesarias. Todavía se requieren dos aprobaciones más de cualquier usuario.

Si tu licencia enterprise caduca, los requisitos de revisión basados en roles existentes siguen aplicándose, pero ya no se pueden modificar. Solo puedes eliminarlos para volver a la configuración simple de revisiones totales.

### Roles

Kviklet incluye 3 roles: Default, Admins y Developers.

- El rol default proporciona acceso de lectura a todas las conexiones y a las Requests. Este rol se asigna a todos los usuarios y no se puede eliminar. Sin embargo, puedes modificar los permisos de este rol como quieras.
- Los Admins tienen permiso para crear y editar conexiones, así como para añadir nuevos usuarios y establecer sus permisos.
- Los Developers pueden crear Requests, así como aprobarlas y comentarlas y, por supuesto, ejecutar las sentencias reales.

Puedes personalizar los Roles y, por ejemplo, dar a un rol acceso solo a una conexión específica o a un grupo de conexiones de base de datos.
Esto es útil, por ejemplo, si tienes distintos equipos con distintas bases de datos y quieres controlar el acceso a ellas de forma más granular.

#### Crear un nuevo rol

Crear un nuevo rol funciona de la siguiente manera. Ve a Settings -> Roles -> Add Role.

![Add Role](https://assets.kitploit.com/production/public/readmes/7140/a91b79287c0b3130b83bdde1c059f49b89c5d43a1c0deae33b211ea427956f8e.png)
![Add Role](https://assets.kitploit.com/production/public/readmes/7140/c535ac152759bb21bea04a0968ce43fa7bf946c7699feca23c71f9eaba41ceaf.png)

La configuración predeterminada no es muy relevante para la mayoría de los roles y puedes simplemente dar acceso User Read y RoleView y dejarlo así.
Más interesante es añadir permisos individuales para Connections. Aquí primero añades un selector para seleccionar conexiones específicas. Puede ser un id específico o puedes usar comodines con `*` para coincidir con varias conexiones. Por ejemplo, si quieres tener un rol que tenga acceso a todas las bases de datos de desarrollo (en caso de que también gestiones el acceso a ellas con kviklet), usarías un selector como `dev-*` y te asegurarías de que los ids de las conexiones estén configurados correctamente.

Por supuesto, también puedes crear un sistema propio que uses para tus distintos equipos dentro de tu organización.

### Sincronización de roles (Enterprise)

Sincroniza automáticamente los roles de usuario desde los grupos de tu proveedor de identidad. Esta función requiere una licencia enterprise.

La **configuración** se realiza en Settings > Role Sync:

- **Enable Role Sync**: Activa/desactiva la sincronización
- **Sync Mode**:
  - **Full Sync** - Los roles de usuario coinciden exactamente con sus asignaciones de grupos del IdP (más el rol predeterminado)
  - **Additive** - Los grupos del IdP añaden roles pero no eliminan los existentes
  - **First Login Only** - Los roles se sincronizan solo en el primer inicio de sesión; los cambios manuales se conservan después
- **Groups Attribute**: El atributo del IdP que contiene las pertenencias a grupos (predeterminado: `groups`)
- **Role Mappings**: Asigna nombres de grupos del IdP (por ejemplo, `engineering`) a roles de Kviklet

#### Configuración de OIDC

Configura tu proveedor de OIDC para incluir un claim `groups` en el token de ID:

- **Keycloak**:

  Keycloak no incluye grupos en los tokens de forma predeterminada, por lo que necesitarás añadir un mapper al cliente.
  1. Navega a **Clients** en el menú izquierdo
  2. Selecciona tu cliente de Kviklet
  3. Ve a la pestaña **Client scopes**
  4. Haz clic en el scope dedicado (por ejemplo, `kviklet-dedicated`)
  5. Ve a la pestaña **Mappers**
  6. Haz clic en **Add mapper** → **By configuration**
  7. Selecciona **Group Membership**
  8. Configura el mapper:

  | Setting             | Value    |
  | ------------------- | -------- |
  | Name                | `groups` |
  | Token Claim Name    | `groups` |
  | Full group path     | **OFF**  |
  | Add to ID token     | **ON**   |
  | Add to access token | **ON**   |
  | Add to userinfo     | **ON**   |
  9. Haz clic en **Save**

  > **Importante:** El "Token Claim Name" debe coincidir con el "Groups Attribute" configurado en los ajustes de Role Sync de Kviklet (predeterminado: `groups`).

- **Otros proveedores de OIDC**: Añade un mapper/claim de grupos que incluya las pertenencias a grupos del usuario en el token de ID. Esto normalmente se hace en la interfaz de administración del proveedor.

  Si tienes problemas, no dudes en crear una issue; no hemos probado todos los proveedores de OIDC que existen (todavía) y puede haber ligeras diferencias en la implementación que requieran actualizaciones por parte de Kviklet.

#### Configuración de LDAP

La sincronización de roles por LDAP usa el atributo `memberOf`:

1. Asegúrate de que tu servidor LDAP tenga habilitado el overlay `memberOf`
2. Establece **Groups Attribute** en `memberOf` en Kviklet
3. Los nombres de los grupos se extraen entonces del atributo `memberOf` en los atributos del usuario.

#### Configuración de SAML

Configura tu IdP SAML para incluir grupos en la aserción:

1. Añade una declaración de atributo que asigne las pertenencias a grupos del usuario
2. Establece el **Groups Attribute** en Kviklet para que coincida con el nombre de tu atributo SAML
3. Los nombres de los grupos se extraen entonces del atributo SAML en los atributos del usuario.

### Notificaciones

Puedes configurar Kviklet para enviar notificaciones a un canal de Slack o Teams. Esto es útil para notificar a tu equipo sobre nuevas solicitudes que necesitan revisión. Puedes configurarlo en Settings -> General -> Notification Settings.

#### Slack

Para configurar las notificaciones de Slack necesitas crear una Slack App y habilitar webhooks para ella. Puedes seguir las instrucciones aquí: https://api.slack.com/messaging/webhooks

#### Teams

Las notificaciones de Teams usan un webhook de **Workflow** de Power Automate. Kviklet envía una Adaptive Card, que la plantilla del webhook publica en tu canal.

**Recomendado: usar la plantilla de workflow**

1. En Teams, abre el canal en el que quieres recibir notificaciones, haz clic en **...** junto al nombre del canal y elige **Workflows** (o añade la aplicación **Workflows**).
2. Busca y crea la plantilla **"Send webhook alerts to a channel"**.
3. Inicia sesión cuando se te solicite, luego selecciona el Team y el Channel de destino y crea el workflow.
4. Abre el paso del trigger y copia la **HTTP POST URL** generada.
5. Pega la URL en Kviklet en Settings -> General -> Notification Settings y haz clic en guardar.

**Alternativa: crear el workflow manualmente**

Si prefieres crear el flujo tú mismo (o la plantilla no está disponible):

1. Canal **...** -> **Workflows** -> crea un flujo con el trigger **"When a Teams webhook request is received"**.
2. Añade la acción **Microsoft Teams -> "Post card in a chat or channel"**.
3. Establece el campo **Adaptive Card** de la acción en la expresión `string(triggerBody())` para que publique la tarjeta que envía Kviklet.
4. Selecciona el Team y el Channel de destino, **Save**, y luego copia la **HTTP POST URL** del paso del trigger.

Actualmente hay notificaciones para:

- Nuevas Requests que necesitan aprobaciones
- Nuevas aprobaciones en solicitudes

#### Configuración de la URL base

Cuando Kviklet se ejecuta detrás de un proxy inverso o un Ingress de Kubernetes, los enlaces de notificación pueden usar la dirección IP interna en lugar de tu dominio público. Kviklet intenta rastrear la URL correcta observando las solicitudes entrantes, pero algunos proxies inversos no establecen correctamente las cabeceras Forwarded. Para solucionarlo, establece la URL base explícitamente:```
KVIKLET_BASE_URL=https://kviklet.example.com

Kviklet registra una línea al iniciar indicando si la telemetría está activada.

**Qué se envía.** Cada evento lleva un id de instancia aleatorio (generado una vez y almacenado en la base de datos de Kviklet), la URL base desde la que se accede a Kviklet (ver arriba; a menudo un nombre de host interno) y la versión de Kviklet. Los usuarios se identifican únicamente mediante un id opaco con alcance a la instancia, por lo que se pueden contar usuarios únicos, pero nunca se envían direcciones de correo electrónico ni nombres. Los eventos exactos y sus propiedades se definen en `backend/src/main/kotlin/dev/kviklet/kviklet/telemetry/TelemetryEvent.kt`.

**Qué nunca se envía.** Consultas, sentencias, resultados, salida de comandos, mensajes de error, nombres de conexión, nombres de host, credenciales, títulos o descripciones de solicitudes, comentarios y nombres de usuario o de rol.

### Registro

Por defecto, Kviklet escribe logs legibles por humanos (pretty) en stdout, lo cual resulta cómodo al leerlos directamente o mediante `docker logs`.

Si envías los logs a un sistema central (Elasticsearch, Loki, Datadog, CloudWatch, …) puedes cambiar a **logs JSON** estructurados, que son más fáciles de indexar y consultar. Configura el formato mediante una variable de entorno:```
# One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)
LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs

Kviklet cifrará todas tus credenciales existentes al iniciar, y usará el secreto para futuras conexiones que crees.

### Rotación de claves

Si deseas rotar la clave, simplemente puedes agregar otra variable para la clave anterior y cambiar la actual:```
ENCRYPTION_KEY_PREVIOUS=some-secret
ENCRYPTION_KEY_CURRENT=another-secret

Las claves de API heredan los permisos del usuario que las crea. Actualmente solo los administradores pueden gestionar claves de API y todas las acciones realizadas con una clave de API se atribuyen al usuario que creó la clave.

Puedes encontrar documentación rudimentaria de la API en `[kviklet_host]/api/swagger-ui/index.html`. Pero ten en cuenta que esto es un trabajo en progreso y la API podría cambiar en futuras versiones.

Al final la verdad está en el código, así que siempre puedes consultar el controlador para ver cómo está definida la API. Si tienes alguna pregunta, no dudes en abrir un issue.

## Funcionalidades experimentales

Actualmente hay dos funcionalidades experimentales. Fueron construidas principalmente a partir de los comentarios de la comunidad. No dudes en probarlas y dejar cualquier comentario que puedas tener. Esperamos seguir desarrollándolas en el futuro y hacer que funcionen bien con el flujo de aprobación principal.

### Kubernetes Exec

Si quieres usar la funcionalidad Kubernetes Exec tienes que crear una conexión de kubernetes separada. Kviklet usará el usuario del pod desplegado para ejecutar el comando. Así que asegúrate de que el usuario tenga los permisos necesarios para ejecutar comandos en los pods a los que quieres acceder.

Kviklet también usa /bin/sh para ejecutar el comando, por lo que tendrás que asegurarte de que tus pods tengan un shell o al menos un enlace simbólico en /bin/sh. Si esto te molesta, no dudes en abrir un issue, potencialmente podemos hacer esto configurable o encontrar otra solución.

Los comandos de Kubernetes solo esperan 5 segundos por la salida; si el comando tarda más que eso, Kviklet esperará hasta una hora antes de agotar el tiempo de espera del comando. Esta es una solución provisional, estamos investigando websockets para hacer esto más receptivo y potencialmente habilitar sesiones de terminal.

### Proxy - Postgres, MariaDB, MySQL (Enterprise)

Si creas solicitudes para acceso temporal, puedes - en lugar de usar la interfaz web - ejecutar tus consultas a través de un proxy gestionado por kviklet y usar el cliente de base de datos de tu elección.
El proxy es una funcionalidad enterprise: requiere una licencia válida, y además un administrador tiene que activarlo en Settings -> General -> Database Proxy.
Para esto el contenedor escucha en puertos estables (5432 y 3306 por defecto, configurables mediante `kviklet.proxy.postgres.port` y `kviklet.proxy.mysql.port`), por lo que necesitas exponer esos puertos.
Los usuarios pueden entonces crear una solicitud de acceso temporal, y hacer clic en "Start Proxy" una vez que haya sido aprobada. Cada solicitud obtiene un nombre de usuario y contraseña temporales; Kviklet enruta cada conexión a su solicitud mediante el nombre de usuario. Con estos pueden conectarse a la base de datos. Kviklet valida el usuario y la contraseña temporales y hace proxy de todas las solicitudes al usuario subyacente en la base de datos. Cualquier sentencia ejecutada se registra en el registro de auditoría como si se hubiera ejecutado a través de la interfaz web.

Nota: El proxy actualmente no soporta el seguimiento de resultados. Así que las sentencias ejecutadas se registran pero no los resultados ni si una sentencia tiene éxito o falla.

![Postgres Proxy](https://assets.kitploit.com/production/public/readmes/7140/153b5b3e85c492079f01f1ffda490a53df2be01cfd808553abc511eb90fc1731.png)
![Postgres Proxy](https://assets.kitploit.com/production/public/readmes/7140/2c886b3cb184b13bbee9120ca5f1cdd9f45dd7743c5cf7a01fe8d5f7474d507a.png)

#### Proxy - TLS

Kviklet termina la conexión TLS hacia la base de datos. Eso significa que por defecto cualquier tráfico desde y hacia el propio proxy no está cifrado.  
Si quieres que kviklet recifre el tráfico puedes darle a Kviklet un certificado TLS y una clave para el proxy estableciendo las siguientes variables de entorno:```
PROXY_TLS_CERTIFICATE_SOURCE=env
PROXY_TLS_CERTIFICATE_CERT=your-certificate
PROXY_TLS_CERTIFICATE_KEY=your-key

De cualquier manera, el certificado y la clave deben almacenarse en [formato pem](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail).

## ¿Preguntas? ¿Contribuciones?

Si tienes alguna pregunta, quieres dar tu opinión o necesitas ayuda con la configuración, únete a nuestra [comunidad de Discord](https://discord.gg/7SmPJfeP6e). También puedes crear un [issue en GitHub](https://github.com/kviklet/kviklet/issues) para informar de errores y solicitar nuevas funcionalidades.

Si quieres contribuir, no dudes en hacer un fork y crear PRs para cosas pequeñas. Si planeas funcionalidades más grandes, agradecería algo de discusión previa en un issue de GitHub o en Discord.

También puedes contactarme en [email protected].