Resumo

  • A revisão 21 do JSCalendar 2.0 acrescenta uma condição de cobertura: sem progress geral explícito, a Task só pode assumir completed se pelo menos um participante tiver relatado progresso.
  • Silêncio não é falha nem trabalho em curso, mas também não é evidência de conclusão. O denominador, os valores recebidos, a versão da regra e a origem declarada ou derivada precisam permanecer auditáveis.

Um fluxo pode fechar sem que uma única pessoa tenha apertado o botão de concluir. Basta que a regra pergunte se todos os valores de progresso são completed e receba uma coleção vazia. Não há valor contrário; o painel exibe sucesso. O problema não é uma mentira explícita, mas uma conclusão produzida pela ausência de observações.

A revisão 21 de JSCalendar 2.0: A JSON Representation of Calendar Data, registrada em 2 de outubro de 2026, fecha essa passagem. A mudança vale quando a Task não contém progress geral explícito.

A revisão 20, acompanhando o RFC 8984, dizia que o padrão seria completed quando o progresso de todos os participantes fosse completed. A revisão 21 exige a existência de ao menos uma propriedade progress e que todos os participantes que fornecem essa propriedade indiquem completed.

É uma correção de fronteira, não prova de incidente. Em lógica formal, uma afirmação universal sobre conjunto vazio pode ser verdadeira. Algumas consultas poderiam, portanto, avaliar “todos concluíram” sem qualquer linha. As fontes não mostram produto real, perda ou falha. Elas mostram que o texto novo impede essa interpretação.

Também não obriga todos os participantes listados a responder. O progresso individual é opcional. Se dois de dez participantes reportarem e ambos estiverem completed, o padrão ainda pode ser completed. Os oito silenciosos não viram veto. A restrição é mais estreita: zero relatos jamais basta.

Por isso, cobertura é parte do resultado. “Dois de dois relatores concluíram” e “dois de dez participantes relataram, ambos concluíram” satisfazem o mesmo predicado, mas entregam informações de gestão diferentes. Mostrar apenas a palavra completed apaga o denominador.

A ordem restante resolve conflitos. Havendo pelo menos um relato, todos completed produz completed. Caso contrário, qualquer failed produz failed. Sem failed, qualquer in-process produz in-process. Quando nada se aplica, inclusive com zero relatos, o padrão é needs-action. Não é votação, e campos ausentes continuam ausentes.

A derivação só existe quando o progress da Task foi omitido. Um valor geral explícito é uma afirmação separada. Assim, dois estados completed podem ter proveniência diferente: asserted diretamente ou derived das observações. Um recibo que guarda só a palavra final perde a autoridade e o caminho do cálculo.

O progresso do Participant possui requisitos: só existe dentro de Task, requer calendarAddress e participationStatus accepted. Seus valores básicos são in-process, completed e failed, além de extensões permitidas. cancelled pertence ao vocabulário geral da Task, não ao conjunto básico individual.

percentComplete também é separado. É inteiro opcional entre zero e cem, não uma média normativa para definir a categoria. Converter cem em completed ou ausência em zero requer política local explícita, nunca suposição invisível.

RFC 5545 distingue STATUS de VTODO, instante de conclusão e estado de participação. RFC 5546 separa estado do objeto do organizador e PARTSTAT do participante. O JSON do JSCalendar facilita transporte, mas não funde contribuição pessoal e estado global.

JMAP Calendars e CalDAV adicionam transporte, sincronização e autoridade. Sucesso de API ou presença em registro IANA não prova execução da revisão 21. O documento pertence ao grupo CALENDAR EXTENSIONS, fluxo IETF, pretende Proposed Standard e está em AD Evaluation; ainda não é RFC.

Nem o melhor agregado é prova do mundo real. Uma contribuição marcada concluída pode não ter produzido entrega; uma Task pode sincronizar enquanto o trabalho externo falha. A cláusula nova evita concluir sem relatos, mas não certifica a verdade de relatos existentes.

Minimum Initial Specification de Lu Heng pede a menor regra comum capaz de preservar escolhas locais: ao menos uma observação antes do sucesso. Running-Code Primacy pergunta qual revisão e consulta rodaram. Reality Layers impede que estado de calendário seja tratado como execução ou cumprimento.

O controle é um recibo de agregação com UID, version, valor geral explícito, participantes totais, relatores, valores, extensões, precedência, resultado, versão do avaliador e ação posterior. Ele deve distinguir asserted de derived.

Uma pequena condição de existência protege uma regra maior: unanimidade probatória começa com alguma prova. Silêncio exige acompanhamento, não promoção automática a sucesso.

Fontes