pensar numa estratégia para a interface da aprendizagem do bot e os próximos passos

a partir de initializeBot alterar para class ES6

Como o comando /cancelar só está sendo utilizado quando o bot espera uma resposta (dada) do usuário, seria interessante usar uma mensagem de aviso de espera (em vez do alerta) e o inline-keyboards nessa mensagem.

Assim, além de editar a mensagem enviada para remover as (3) opções dadas (após a seleção da opção "ensinar"), editar o conteúdo de "Não sei te responder...\nmas você pode me ensinar, se quiser." para "😀 Opa! Estou esperando a sua resposta, tudo bem?" junto com a opção para cancelar tal espera.

Seria preciso remover o uso desse alerta para evitar redundância, em:

Uma forma de aumentar o acesso às perguntas do "conhecimento externo" seria, caso não encontre uma pergunta que case exatamente com a de alguma do conhecimento externo, procurar a que melhor se aproxima da intenção do usuário. Assim, a resposta que o bot dará seria algo como "você quis dizer ...".

centralizar as intenções no RS.
Retirar o uso desse evento:

Atualmente o sistema não evita votos repetidos de um usuário sobre a mesma pergunta [do conhecimento externo].

Deve-se pensar em uma estratégia que melhor se adeque ao sistema.
Uma ideia seria adicionar mais um atributo (uma lista) na Questao para inserir os ids dos usuários que já votaram nela

vide

Por enquanto o autor de uma resposta dada não pode removê-la -- o que seria interessante.
Uma ideia para adicionar tal opção seria na própria resposta que o bot retorna quando o autor de uma resposta dada (conhecimento externo) realiza sua pergunta, como um [Inline keyboards], por exemplo:
inline-keyboards

Para adicionar mais uma camada de abstração

• vide o prolog-controller como exemplo
• alterar o index.js main e do brain (atributos e uso inadequado de métodos do RS) visando a implementação

Em

Em vez de salvar o nick, caso não existe, salvar o first_name.

pensar em como o bot pode enviar uma mensgem mencionando um usuário sem username

As dependências desenvolvidas parecem estar desorganizadas e a estrutura atual não está visualmente/convecionalmente agradável. Seria interessante repensar na estrutura física e/ou arquitetura...

Em relação ao código, por fim, deve-se refatorar as funções (principalmente as utilitárias) visando o paradigma Funcional. Além de remover as funções que não estão sendo utilizadas pelo sistema.

criar testes unitários para verificar as intenções em queries.rives; i.e., checar se estão saindo com as consultas corretas

Seria bom adicionar screenshots/gifs (no README) de estados do bot em funcionamento; demonstrando todas as funcionalidades da versão corrente

No README principal, para expor a lógica do sistema, seria interessante:

• inserir diagramas de sequência (e/ou atividade)
• fazer/inserir benchmarks para verificar o tempo de resposta com e sem parser final (da resposta do RiveScript)
  ...

arquivo que contém apenas declarações de arrays que podem ser usados nos padrões para apresentar alternativas (sinônimos ou palavras sem acentos)

vide o teste:

A ideia é remover os emojis antes de salvar no banco, em

solução: resposta.replace(/([\uE000-\uF8FF]|\uD83C[\uDF00-\uDFFF]|\uD83D[\uDC00-\uDDFF])/g, '')

• usar o JSDoc
• inserir o Type Signature do Ramda em casos mais extremos (funcionais)

verificar nova arquitetura e definir as intents de acordo com as perguntas que o bot responde (prever inserção de novas)

verificar arquitetura definida

vide a branch 'using-rivescript'

Dado .rive com:

+ *
- [<star>]

A resposta para a intenção "ão" está sendo "[ãã]".
Isso causa erros ao citar nomes acentuados como "são"

Os erros observados nas linhas:

são causados por causa do uso da regra absolute_file_name/2 do Swi-Prolog, que gera o caminho incorreto para o arquivo fatos_dinamicos.pl.lock.
Notei que o caminho gerado é o da raiz (sige-telegram-bot/) pois é o diretório do index.js que inicia todo o sistema...