Versão não está atualizada, conforme exercício.

Tendo em vista que:

• aprendizado é um processo que demanda dedicação e esforço consideráveis, além de constantes;
• falhas fazem parte do processo, de fato, no meu entendimento, são inevitáveis;
• falhas e dificuldades, embora inevitáveis, não podem impedir o progresso, o aprendizado, o contínuo aprimoramento; e que
• a turma dedica-se às atividades e há progresso claro (parabéns pelo esforço),

esclareço que:

• Em vez de duas atividades para serem concluídas até o dia primeiro de julho, teremos apenas uma única atividade, ao contrário do que foi apresentado no dia de ontem (11/06/2019).
• A data limite permanece primeiro de julho. Ou seja, a atividade a ser realizada conta com um período de três semanas inteiras para a sua realização, além de 7 horas em atividades supervisionadas.
• Nossa aula do dia 27 de junho será não presencial. Ou seja, você terá tempo adicional para concluir suas atividades sem o ônus de se deslocar até o laboratório. Em consequência, dia 25 de junho é o último dia para você esclarecer dúvidas com o professor. Ou seja, você tem duas semanas inteiras para esclarecer suas dúvidas sobre o que deve ser feito, sobre o critério de avaliação, sobre as suas issues, sobre os pull requests, sobre a qualidade do que você está produzindo, sobre os tópicos pertinentes à construção de software, enfim, sobre as suas dúvidas que só você pode apresentar.
• As datas acima são limites, tudo pode ser concluído antes.
• Os critérios de avaliação permanecem, assim como a forma de definição da nota. Se você está em dúvida, então entre em contato com o professor. De forma resumida, deve-se concluir o que foi pedido (não parcialmente), atender issues e pull requests, e com a qualidade definida por várias ferramentas para que a sua nota seja pelo menos 6,0. Há risco significativo aqui se não houver interação com o professor. Mais uma vez, esclareça suas dúvidas especificamente para o seu repositório (elemento de avaliação contínua da disciplina).
• A atividade a ser realizada, dado que antes eram duas, e agora apenas uma, predefinida pelo docente, é aquela da "Ordem de Serviço" (programa para identificar o dia da semana de uma data). Esta atividade foi identificada como pertencente ao tópico aula-10 (veja portal da disciplina).
• Você pode optar pela outra atividade, aquela atribuída ao tópico aula-09, o que cabe a você escolher, em vez do tópico aula-10, predefinido pelo docente. Caso queira optar pela atividade da aula-09, então deverá fazer o registro correspondente no arquivo README.md do seu repositório até as 19h59min do dia 13/06/2019, conforme ilustrado abaixo.

Minha preferência

Atividade documentada no tópico aula-10 (veja portal da disciplina).

Estas mudanças visam assegurar que nosso foco na “formação de profissionais aptos a contribuir efetivamente com a produção de softwares de qualidade seguindo princípios éticos e postura profissional” (objetivo do curso de Engenharia de Software), não seja prejudicado.

Se são relevantes, faça o merge, caso contrário, simplesmente remova os branches. Não é natural ter tantos branches para um volume reduzido de código. Imagine o esforço de gerenciamento para mantê-los imaginando um sistema com 1000 vezes mais linhas de código, por exemplo. Noutras palavras, ou há uma problema de gerenciamento aqui ou os branches (manutenção deles) é desnecessária.

Duplicata de #6

O seguinte trecho foi extraído do código:

const dayValidate = day => (day >= 1 && day <= 31);
const monthValidate = month => (month >= 1 && month <= 12);
const yearValidate = year => (year >= 12 && year <= 1753);

A implementação é da rotina diaDaSemana. Não seria melhor...

function diaValido(dia) {
  return dia >= 1 && dia <= 31;
}
....

São semanticamente equivalentes, mas não na perspectiva da manutenção. A alternativa apresentada é mais simples para se detectar eventual falha.

Em .eslintrc.json acrescente a regra "keyword-spacing" : "error". Ela detecta um item de leiaute (estilo) não observado pelo seu código. Naturalmente, faça os ajustes necessários, na sequência.

• Use o recurso do seu editor ou IDE para reformatar o código. Se ele não possui tal recurso, então minha orientação é mudar de ferramenta, pois manualmente ajustar o leiaute vai reduzir sua produtividade.

Boa parte do código já está escrito em seu próprio arquivo, sem "mistura" com aspectos de interação com o usuário, o que é relevante para a reutilização. Mas ainda restam alguns casos que não foram refatorados como potenciaSoma, dentre outros.

Há violações a serem corrigidas.

• Há múltiplas classes Number (remova-as).
• Há muitas classes fora do package com.github.josexcsta.ufg.cs.aula01, ou seja, precisam de package adequado, e não pode ser quadradoPerfeito ou numeroPrimo, por exemplo. Observe como o primeiro está montado, é necessário algo similar, por exemplo, com.github.josexcsta.ufg.cs.aula01.algoritmos.aplicacoes.
• Ainda temos um package "algoritmos" com vários arquivos, ou seja, há múltiplas estratégias de organização do código aqui. Você deve fazer uso exclusivamente de uma, a melhor é aquela baseada em uma classe (Algoritmos) para manter todos os métodos (minha opção para este cenário).

Temos que atingir 100% e descobrir os desafios de se fazer assim.

• Está incompleta. Por exemplo, encontrei esta linha de documentação que, naturalmente, diz pouco sobre o que é retornado. Precisamos saber, por exemplo, "verdadeiro quando o CPF satisfaz as regras de formação de um CPF". Linha: @returns {boolean} a. Curiosamente esta linha está no Crivo de Eratóstenes.
• Nesta implementação lê-se "Calcula o Crivo de Eratostenes dado uma coleção de numeros e um limite.", onde melhor seria algo como "Aplica o método conhecido por Crivo de Er...".
• Também encontrei "Calcula o valor PI de um numero." onde o mais preciso, suponho, seria: "Produz uma aproximação do valor de PI baseado no número de iterações fornecido, onde quanto maior o número de iterações, maior a precisão de PI".
• Não se esqueça de fornecer o nome da variável do parâmetro na documentação. Por exemplo @param {number} numerador o numerador da divisão

Seu repositório possui vários branches, o que, neste contexto, não é bom, pois as mudanças em um provavelmente afetam os demais. Dito de outra forma, em uma empresa, quando há uma base de código extensa, alguém trabalha em uma parte, outro trabalha em outra, aqui só há uma parte pequena com múltiplos esforços sobre ela, o que naturalmente resulta em MUITOS conflitos. Você deveria, aqui, estar concluindo tarefa por tarefa e removendo o branch de cada uma delas antes de iniciar a próxima.

Linhas em branco são empregadas para separar "seções" do código. Talvez fique mais bonito como você está fazendo, mas "dispersa" a atenção do leitor. As divisões introduzidas pelas linhas em branco indicam que há "mudanças" e funcionam como parágrafos em um texto.