</details>

### Configuração do Banco de Dados

O Kviklet precisa de seu próprio banco de dados postgres (ou pelo menos schema) para salvar metadados sobre consultas, conexões, aprovações, etc.
Você pode encontrar a imagem oficial aqui: https://hub.docker.com/_/postgres, ou usar uma versão hospedada na nuvem pelo provedor de nuvem de sua escolha.

Ao iniciar o contêiner kviklet, você precisará definir estas três variáveis de ambiente de acordo:```
SPRING_DATASOURCE_PASSWORD = password
SPRING_DATASOURCE_USERNAME = username
SPRING_DATASOURCE_URL = jdbc:postgresql://[host]:[port]/[database]?currentSchema=[schema]

Publicamos nossos containers no GitHub packages por enquanto, então com tudo isso configurado você pode executar `ghcr.io/kviklet/kviklet:main`, não se esqueça de mapear a porta `8080`, que é a porta padrão na qual o Kviklet é iniciado.

Um exemplo de docker run poderia ser assim:```
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

O client id e o secret do Google você pode obter facilmente seguindo as instruções do Google aqui:
https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid

Para URIs de redirecionamento válidas, você deve configurar: https://[kviklet_host]/api/login/oauth2/code/google
Para Origens Permitidas, simplesmente a URL do seu kviklet hospedado.

Depois de definir essas variáveis de ambiente, todos na sua organização podem fazer login com o botão sign in with google. Mas eles não terão nenhuma permissão por padrão, você terá que atribuir um papel a eles depois que fizerem login uma vez.

#### Keycloak

Se você quiser configurar SSO com Keycloak em vez disso, você precisa definir estas 4 variáveis de ambiente:```
KVIKLET_IDENTITYPROVIDER_CLIENTID
KVIKLET_IDENTITYPROVIDER_CLIENTSECRET
KVIKLET_IDENTITYPROVIDER_TYPE=keycloak
KVIKLET_IDENTITYPROVIDER_ISSUERURI=http://[host]:[port]/realms/[realm]

Crie um GitHub OAuth App em https://github.com/settings/developers e configure:

- Authorization callback URL: `https://[kviklet_host]/api/login/oauth2/code/github`
- Homepage URL: o URL do seu Kviklet alojado

`KVIKLET_IDENTITYPROVIDER_GITHUB_ALLOWEDORGS` é **obrigatório** (o Kviklet recusa-se a iniciar sem ele). As GitHub OAuth Apps não conseguem restringir quem completa o fluxo OAuth, por isso o Kviklet chama `/user/orgs` após a autenticação e rejeita utilizadores que não sejam membros de pelo menos uma organização na lista de permitidas (sem distinção de maiúsculas/minúsculas, são verificadas as primeiras 100 organizações).

Para que a verificação de organização consiga ver a pertença de um utilizador, este tem de clicar em **Grant** (ou **Request**) ao lado de cada organização permitida no ecrã de consentimento OAuth. Se a organização tiver "Restrict third-party OAuth applications" ativado, um proprietário da organização também tem de aprovar a OAuth app uma vez antes de a pertença de qualquer membro se tornar visível.

O Kviklet solicita os scopes `read:user`, `user:email` e `read:org`. Os emails são sempre lidos a partir de `/user/emails` e apenas uma entrada `primary && verified` é aceite, pelo que utilizadores com endereços de email privados ainda conseguem iniciar sessão com sucesso.

#### Outros fornecedores OIDC

Outros fornecedores compatíveis com OIDC (GitLab, Auth0, Okta, etc.) devem funcionar de forma semelhante ao Keycloak. Note que o `redirect URI` irá mudar dependendo do tipo que escolher, por isso se escolher `gitlab` será `https://[kviklet_host]/api/login/oauth2/code/gitlab`.
Se encontrar problemas, sinta-se à vontade para criar uma issue, ainda não testámos todos os fornecedores OIDC existentes (ainda) e pode haver pequenas diferenças na implementação que possam exigir atualizações do lado do Kviklet.

### LDAP

O Kviklet suporta autenticação LDAP. Para ativar e configurar o LDAP, pode substituir as seguintes variáveis de ambiente:```
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

Detalhes de configuração:

- `SAML_ENABLED`: Defina como `true` para habilitar a autenticação SAML
- `SAML_ENTITYID`: O ID da entidade do seu provedor de identidade SAML
- `SAML_SSOSERVICELOCATION`: A URL do serviço SSO do seu provedor de identidade
- `SAML_VERIFICATIONCERTIFICATE`: O certificado X.509 usado para verificar as respostas SAML (inclua as linhas BEGIN/END CERTIFICATE)

Opcionalmente, você pode personalizar os mapeamentos de atributos SAML:```
SAML_USERATTRIBUTES_EMAILATTRIBUTE=email
SAML_USERATTRIBUTES_NAMEATTRIBUTE=name
SAML_USERATTRIBUTES_IDATTRIBUTE=nameID

## Configuração

### Conexões

Depois de iniciar o Kviklet, você primeiro precisa configurar uma conexão de banco de dados. Vá para Configurações -> Bancos de Dados -> Adicionar Conexão.

![Adicionar Conexão](https://assets.kitploit.com/production/public/readmes/7140/3ded2a0b23e5d2f02feb21a854263c91dedea25a789fb75ab8342384c4e39b52.png)
![Adicionar Conexão](https://assets.kitploit.com/production/public/readmes/7140/585238c9eddad8ed4e2440096ce0616445a6696e1042f58676a1d0b038edde7f.png)

Aqui você pode configurar os requisitos de revisão e os limites de execução para cada conexão. Consulte [Portões de Revisão](#review-gates) para mais detalhes.

#### AWS IAM AUTH

O Kviklet suporta o uso de IAM Auth para conexões de banco de dados Postgres, MySQL e MariaDB; para isso, escolha IAM Auth ao criar uma nova conexão.

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

Isso removerá a opção de definir uma senha e, em vez disso, usará credenciais da AWS para se conectar ao banco de dados.

O Kviklet usa o `DefaultCredentialsProvider` da AWS para encontrar credenciais e gerar o token para a conexão. Isso significa que todos os locais típicos devem funcionar (variáveis de ambiente ou funções de instância associadas); a ordem exata está documentada aqui: https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/DefaultCredentialsProvider.html

Além disso, você pode fornecer um ARN de função da AWS que o Kviklet assumirá e usará essas credenciais para criar o token temporário do banco de dados. Isso é particularmente útil para se conectar a bancos de dados que não estão na mesma conta da AWS que o Kviklet. Para usar esse recurso, basta inserir o ARN da função no campo designado ao criar ou editar uma conexão IAM Auth. Deixar o campo vazio usará o provedor de credenciais padrão (sem assumir função).

A região da AWS a ser usada durante a geração do token é inferida a partir da URL da sua conexão, portanto não há opção para defini-la.

Para aprender como configurar o IAM Auth para o seu banco de dados, siga a documentação oficial da AWS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html
Os dois pontos principais são:

- Criar um usuário de banco de dados com a opção de autenticação IAM e as permissões corretas
- Criar uma política IAM que permita à entidade da AWS gerar tokens para esse usuário

### Portões de Revisão

Por padrão, o Kviklet permite uma configuração simples de contagem de revisões. Você pode configurar quantas aprovações as solicitações em uma conexão específica precisam antes de poderem ser executadas.

O status de aprovação de uma solicitação é calculado com base na última ação de cada revisor. Se um revisor aprovar e depois solicitar alterações, apenas a solicitação de alteração conta — sua aprovação anterior é removida. Editar uma solicitação sempre redefine todas as aprovações anteriores, garantindo que nenhuma alteração possa ser executada sem ser revisada primeiro. Da mesma forma, se uma execução falhar (por exemplo, devido a um erro de sintaxe SQL), as aprovações são redefinidas para que a solicitação possa ser corrigida e reaprovada sem precisar criar uma nova.

Você também pode configurar um limite de **máximo de execuções** por conexão para controlar com que frequência uma única solicitação aprovada pode ser executada. O padrão é 1. Definir como 0 permite execuções ilimitadas. Execuções com falha não contam para esse limite.

#### Requisitos de Revisão Baseados em Funções (Enterprise)

Com uma Licença Kviklet Enterprise, você pode configurar conexões individuais para exigir aprovações de usuários com funções específicas. Isso permite, por exemplo, exigir aprovação da equipe que mantém um determinado banco de dados ou proteger conexões sensíveis atrás de aprovações de DBA ou da gerência.

**Como funciona:**

Cada conexão tem uma contagem de **total de revisões necessárias** (`numTotalRequired`) que atua como um piso — o número mínimo de aprovações distintas necessárias, independentemente das funções. Além disso, você pode adicionar **requisitos de função** que especificam quantas aprovações devem vir de usuários com uma função específica (por exemplo, "1 de DBA, 1 de Segurança").

Uma solicitação só é aprovada quando **ambas** as condições são atendidas:

- O número total de aprovações distintas atende a `numTotalRequired`
- Cada requisito de função é individualmente satisfeito

Se um usuário pertence a várias funções, uma única aprovação desse usuário conta para todos os requisitos de função correspondentes. No entanto, ainda conta como apenas uma aprovação para a contagem total.

**Exemplo:** Uma conexão requer 3 aprovações totais, incluindo 1 de um DBA e 1 de Segurança. Um usuário que possui tanto a função de DBA quanto a de Segurança aprova — isso satisfaz ambos os requisitos de função, mas conta como apenas 1 das 3 aprovações totais necessárias. Ainda são necessárias mais duas aprovações de quaisquer usuários.

Se sua licença enterprise expirar, os requisitos de revisão baseados em funções existentes permanecem aplicados, mas não podem mais ser modificados. Você só pode removê-los para voltar à configuração simples de total de revisões.

### Funções

O Kviklet vem com 3 funções: Default, Admins e Developers.

- A função padrão fornece acesso de Leitura a todas as conexões e Solicitações. Essa função é atribuída a todos os usuários e não pode ser removida. No entanto, você pode alterar as permissões dessa função como quiser.
- Admins têm permissão para criar e editar conexões, bem como adicionar novos Usuários e definir suas permissões.
- Developers podem criar Solicitações, bem como aprová-las e comentá-las e, é claro, executar as instruções propriamente ditas.

Você pode personalizar Funções e, por exemplo, dar a uma função acesso apenas a uma conexão específica ou a um grupo de conexões de banco de dados.
Isso é útil, por exemplo, se você tem equipes diferentes com bancos de dados diferentes e deseja controlar o acesso a eles de forma mais granular.

#### Criando uma nova Função

Criar uma nova função funciona da seguinte forma. Vá para Configurações -> Funções -> Adicionar Função.

![Adicionar Função](https://assets.kitploit.com/production/public/readmes/7140/a91b79287c0b3130b83bdde1c059f49b89c5d43a1c0deae33b211ea427956f8e.png)
![Adicionar Função](https://assets.kitploit.com/production/public/readmes/7140/c535ac152759bb21bea04a0968ce43fa7bf946c7699feca23c71f9eaba41ceaf.png)

As configurações padrão não são tão relevantes para a maioria das funções e você pode simplesmente dar acesso de User Read e RoleView e deixar por isso mesmo.
Mais interessante é a adição de permissões individuais para Conexões. Aqui você primeiro adiciona um seletor para selecionar conexões específicas. Isso pode ser um id específico ou você pode usar curingas com `*` para corresponder a várias conexões. Por exemplo, se você quiser ter uma função que tenha acesso a todos os bancos de dados de desenvolvimento (caso você também gerencie o acesso a eles com o kviklet), você usaria um seletor como `dev-*` e garantiria que os ids das conexões estejam definidos corretamente.

Você também pode, é claro, criar um sistema que use para suas diferentes equipes dentro da sua organização.

### Sincronização de Funções (Enterprise)

Sincronize automaticamente as funções de usuário a partir dos grupos do seu provedor de identidade. Este recurso requer uma licença enterprise.

A **Configuração** é feita em Configurações > Sincronização de Funções:

- **Habilitar Sincronização de Funções**: Ativar/desativar a sincronização
- **Modo de Sincronização**:
  - **Sincronização Completa** - As funções do usuário correspondem exatamente aos mapeamentos de grupos do IdP (mais a função padrão)
  - **Aditivo** - Os grupos do IdP adicionam funções, mas não removem as existentes
  - **Apenas no Primeiro Login** - As funções são sincronizadas apenas no primeiro login; alterações manuais são preservadas depois
- **Atributo de Grupos**: O atributo do IdP que contém as associações de grupo (padrão: `groups`)
- **Mapeamentos de Funções**: Mapeie nomes de grupos do IdP (por exemplo, `engineering`) para funções do Kviklet

#### Configuração OIDC

Configure seu provedor OIDC para incluir uma claim `groups` no token de ID:

- **Keycloak**:

  O Keycloak não inclui grupos nos tokens por padrão, então você precisará adicionar um mapper ao cliente.
  1. Navegue até **Clients** no menu à esquerda
  2. Selecione seu cliente Kviklet
  3. Vá para a aba **Client scopes**
  4. Clique no escopo dedicado (por exemplo, `kviklet-dedicated`)
  5. Vá para a aba **Mappers**
  6. Clique em **Add mapper** → **By configuration**
  7. Selecione **Group Membership**
  8. Configure o mapper:

  | Configuração        | Valor    |
  | ------------------- | -------- |
  | 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. Clique em **Save**

  > **Importante:** O "Token Claim Name" deve corresponder ao "Groups Attribute" configurado nas configurações de Sincronização de Funções do Kviklet (padrão: `groups`).

- **Outros provedores OIDC**: Adicione um mapper/claim de grupos que inclua as associações de grupo do usuário no token de ID. Isso normalmente é feito na interface de administração do provedor.

  Se você encontrar problemas, sinta-se à vontade para criar uma issue; ainda não testamos todos os provedores OIDC existentes (ainda) e pode haver pequenas diferenças na implementação que podem exigir atualizações do lado do Kviklet.

#### Configuração LDAP

A sincronização de funções via LDAP usa o atributo `memberOf`:

1. Certifique-se de que seu servidor LDAP tenha o overlay `memberOf` habilitado
2. Defina **Groups Attribute** como `memberOf` no Kviklet
3. Os nomes dos grupos são então extraídos do atributo `memberOf` nos atributos dos usuários.

#### Configuração SAML

Configure seu IdP SAML para incluir grupos na asserção:

1. Adicione uma declaração de atributo que mapeie as associações de grupo do usuário
2. Defina o **Groups Attribute** no Kviklet para corresponder ao nome do atributo SAML
3. Os nomes dos grupos são então extraídos do atributo SAML nos atributos dos usuários.

### Notificações

Você pode configurar o Kviklet para enviar notificações para um canal no Slack ou Teams. Isso é útil para notificar sua equipe sobre novas solicitações que precisam ser revisadas. Você pode configurar isso em Configurações -> Geral -> Configurações de Notificação.

#### Slack

Para configurar notificações do Slack, você precisa criar um Slack App e habilitar webhooks para ele. Você pode seguir as instruções aqui: https://api.slack.com/messaging/webhooks

#### Teams

As notificações do Teams usam um webhook de **Workflow** do Power Automate. O Kviklet envia um Adaptive Card, que o template do webhook publica no seu canal.

**Recomendado: use o template de workflow**

1. No Teams, abra o canal onde você deseja receber notificações, clique em **...** ao lado do nome do canal e escolha **Workflows** (ou adicione o aplicativo **Workflows**).
2. Pesquise e crie o template **"Send webhook alerts to a channel"**.
3. Faça login quando solicitado, depois selecione o Team e o Canal de destino e crie o workflow.
4. Abra a etapa de gatilho e copie a **HTTP POST URL** gerada.
5. Cole a URL no Kviklet em Configurações -> Geral -> Configurações de Notificação e clique em salvar.

**Alternativa: construir o workflow manualmente**

Se você preferir construir o fluxo você mesmo (ou o template não estiver disponível):

1. Canal **...** -> **Workflows** -> crie um fluxo com o gatilho **"When a Teams webhook request is received"**.
2. Adicione a ação **Microsoft Teams -> "Post card in a chat or channel"**.
3. Defina o campo **Adaptive Card** da ação como a expressão `string(triggerBody())` para que ele publique o card que o Kviklet envia.
4. Selecione o Team e o Canal de destino, **Save**, depois copie a **HTTP POST URL** da etapa de gatilho.

Atualmente existem notificações para:

- Novas Solicitações que precisam de aprovações
- Novas aprovações em solicitações

#### Configuração de URL Base

Ao executar o Kviklet atrás de um proxy reverso ou Kubernetes Ingress, os links de notificação podem usar o endereço IP interno em vez do seu domínio público. O Kviklet tenta rastrear a URL correta observando as solicitações recebidas, mas alguns proxies reversos não definem os cabeçalhos Forwarded corretamente. Para corrigir isso, defina a URL base explicitamente:```
KVIKLET_BASE_URL=https://kviklet.example.com

O Kviklet registra uma linha na inicialização informando se a telemetria está ativada.

**O que é enviado.** Cada evento carrega um id de instância aleatório (gerado uma vez e armazenado no banco de dados do Kviklet), a URL base pela qual o Kviklet é acessado (veja acima; frequentemente um hostname interno) e a versão do Kviklet. Os usuários são identificados apenas por um id opaco com escopo na instância, de modo que usuários únicos podem ser contados, mas nenhum endereço de e-mail ou nome é jamais enviado. Os eventos exatos e suas propriedades são definidos em `backend/src/main/kotlin/dev/kviklet/kviklet/telemetry/TelemetryEvent.kt`.

**O que nunca é enviado.** Consultas, instruções, resultados, saída de comandos, mensagens de erro, nomes de conexão, hostnames, credenciais, títulos ou descrições de requisições, comentários e nomes de usuários ou funções.

### Logging

Por padrão, o Kviklet grava logs legíveis por humanos (pretty) no stdout, o que é conveniente ao lê-los diretamente ou via `docker logs`.

Se você envia logs para um sistema central (Elasticsearch, Loki, Datadog, CloudWatch, …), pode alternar para **logs JSON** estruturados, que são mais fáceis de indexar e consultar. Defina o formato por meio de uma variável de ambiente:```
# One of: ecs (Elastic Common Schema), logstash, gelf (Graylog)
LOGGING_STRUCTURED_FORMAT_CONSOLE=ecs

O Kviklet criptografará todas as suas credenciais existentes na inicialização e usará o segredo para futuras conexões que você criar.

### Rotação de Chave

Se você quiser rotacionar a chave, basta adicionar outra variável para a chave anterior e alterar a atual:```
ENCRYPTION_KEY_PREVIOUS=some-secret
ENCRYPTION_KEY_CURRENT=another-secret

As chaves de API herdam as permissões do usuário que as cria. Atualmente, apenas administradores podem gerenciar chaves de API e todas as ações realizadas com uma chave de API são atribuídas ao usuário que criou a chave.

Alguma documentação rudimentar da API pode ser encontrada em `[kviklet_host]/api/swagger-ui/index.html`. Mas tenha em mente que isto é um trabalho em andamento e a API pode mudar em versões futuras.

No final, a verdade está no código, então você pode sempre olhar para o controller para ver como a API está definida. Se você tiver alguma dúvida, sinta-se à vontade para abrir uma issue.

## Funcionalidades Experimentais

Atualmente existem duas funcionalidades experimentais. Elas foram construídas principalmente com base no feedback da comunidade. Sinta-se à vontade para experimentá-las e deixar qualquer contribuição que você possa ter. Esperamos desenvolvê-las mais no futuro e fazê-las funcionar bem com o fluxo de aprovação principal.

### Kubernetes Exec

Se você quiser usar a funcionalidade Kubernetes Exec, você precisa criar uma conexão kubernetes separada. O Kviklet usará o usuário do pod implantado para executar o comando. Portanto, certifique-se de que o usuário tenha as permissões necessárias para executar comandos nos pods que você deseja acessar.

O Kviklet também usa /bin/sh para executar o comando, então você precisará garantir que seus pods tenham um shell ou pelo menos um symlink em /bin/sh. Se isso te incomodar, sinta-se à vontade para abrir uma issue, podemos potencialmente tornar isso configurável ou encontrar outra solução.

Os comandos do Kubernetes aguardam apenas 5 segundos pela saída; se o comando demorar mais do que isso, o Kviklet aguardará até uma hora antes de expirar o comando. Esta é uma solução provisória, estamos investigando websockets para tornar isso mais responsivo e potencialmente habilitar sessões de terminal.

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

Se você criar solicitações para acesso temporário, você pode - em vez de usar a interface web - executar suas consultas através de um proxy gerenciado pelo kviklet e usar o cliente de banco de dados de sua escolha.
O proxy é uma funcionalidade enterprise: ele requer uma licença válida, e um administrador adicionalmente precisa ativá-lo em Configurações -> Geral -> Proxy de Banco de Dados.
Para isso, o contêiner escuta em portas estáveis (5432 e 3306 por padrão, configuráveis via `kviklet.proxy.postgres.port` e `kviklet.proxy.mysql.port`), então você precisa expor essas portas.
Os usuários podem então criar uma solicitação de acesso temporário e clicar em "Iniciar Proxy" assim que ela for aprovada. Cada solicitação recebe um nome de usuário e senha temporários; o Kviklet roteia cada conexão para sua solicitação pelo nome de usuário. Com estes, eles podem se conectar ao banco de dados. O Kviklet valida o usuário e senha temporários e faz proxy de todas as solicitações para o usuário subjacente no banco de dados. Quaisquer instruções executadas são registradas no log de auditoria como se tivessem sido executadas via interface web.

Nota: O proxy atualmente não suporta rastreamento de resultados. Portanto, as instruções executadas são registradas, mas não os resultados ou se uma instrução teve sucesso ou falhou.

![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

O Kviklet termina a conexão TLS com o banco de dados. Isso significa que, por padrão, qualquer tráfego de e para o proxy em si não é criptografado.  
Se você quiser que o kviklet recriptografe o tráfego, você pode fornecer ao Kviklet um certificado TLS e chave para o proxy definindo as seguintes variáveis de ambiente:```
PROXY_TLS_CERTIFICATE_SOURCE=env
PROXY_TLS_CERTIFICATE_CERT=your-certificate
PROXY_TLS_CERTIFICATE_KEY=your-key

De qualquer forma, o certificado e a chave devem ser armazenados em [formato pem](https://en.wikipedia.org/wiki/Privacy-Enhanced_Mail).

## Dúvidas? Contribuições?

Se você tiver alguma dúvida, quiser fornecer feedback ou precisar de ajuda com a configuração, junte-se à nossa [comunidade no Discord](https://discord.gg/7SmPJfeP6e). Você também pode criar uma [issue no GitHub](https://github.com/kviklet/kviklet/issues) para relatar bugs e solicitar recursos.

Se você quiser contribuir, sinta-se à vontade para fazer um fork e criar PRs para coisas pequenas. Se você planeja recursos maiores, eu agradeceria uma discussão prévia em uma issue no GitHub ou no Discord.

Você também pode entrar em contato comigo em [email protected].