O que estamos construindo: uma aplicação web de apoio à decisão, entregue em HTML, CSS e JavaScript. Ela automatiza a determinação da próxima providência a partir de condições declaradas sobre uma página-alvo.

Quem utiliza: autor ou curador. Esta página também serve ao autor-pesquisador, modelador, desenvolvedor, testador e responsável pela aceitação, para compreender a solução e suas evidências.

Problema, resultado esperado e fronteira

Problema: ao preparar uma versão de página, o autor precisa saber qual pendência tratar primeiro, evitando interpretar um encaminhamento como aprovação final.

Resultado esperado: obter uma única próxima providência, acompanhada da regra e da justificativa, ou receber uma indicação de informação insuficiente. A saída não certifica qualidade nem autoriza publicação.

Dentro da fronteira: receber declarações, avaliar regras, tratar informação parcial, apresentar resultado e rastro, limpar a consulta e executar testes do modelo. Fora da fronteira: inspecionar arquivos reais, validar evidências, executar revisão ou verificações técnicas da página-alvo, guardar histórico e publicar.

Unidade avaliada: uma mesma versão de uma página. As três declarações e a identificação da consulta devem referir-se à mesma versão. O protótipo recebe título, caminho opcional e versão/data de referência declarados. Não acessa o arquivo nem calcula hash; a correspondência com o arquivo real continua sob responsabilidade do usuário. Se a versão mudar, as declarações precisam ser reexaminadas.

Percurso de leitura: experimentar a solução → compreender o resultado e o término esperado → contexto e mapa → cenário → responsabilidades e jornada → caso de uso → requisitos → decisão → funcionalidades → aceitação → verificação → entrega e evolução.

Consultar o mapa integrado na vista Visão integrada.

Um autor prepara uma página do LAC. Antes de considerá-la candidata à publicação, precisa verificar se as fontes estão identificadas, se o conteúdo recebeu revisão humana e se as verificações técnicas previstas passaram.

Para este exemplo, propõe-se a seguinte prioridade: primeiro documentar as fontes; depois revisar o conteúdo; em seguida resolver as verificações técnicas. Quando os três critérios estão confirmados, encaminhar para a decisão humana de publicação.

Proposta didática: esses três critérios e sua prioridade não constituem uma regra canônica já aprovada do LAC. A indicação “Sim” representa uma declaração no simulador; a interface não verifica documentos nem executa testes reais.

Os papéis abaixo são responsabilidades do exemplo, não contas ou permissões implementadas. Uma pessoa pode acumular papéis; a designação dos responsáveis deve ser registrada antes do uso operacional.

Jornada: examinar evidências → informar C1–C3 → solicitar avaliação → compreender providência, justificativa e regra. R1–R3 levam a tratar a pendência, atualizar condições e consultar novamente. R4 encaminha diretamente à decisão humana; se aprovada, a página é publicada e conferida. Informação insuficiente leva a obter evidências adicionais.

Pontos de contato: documentos e pareceres; formulário e botão Avaliar; painel de resultado; encaminhamento entre autor, revisor e técnico; decisão editorial e ambiente de publicação.

A aceitação da aplicação e a aprovação da página-alvo são decisões distintas. A aplicação apoia o processo sociotécnico, mas não executa revisão, correções ou publicação.

Ator principal

Autor ou curador que prepara a revisão.

Objetivo

Identificar a próxima providência e sua justificativa.

Pré-condições

Uma versão da página existe; fontes, revisão e verificações técnicas previstas podem ser examinadas. Se o estado for desconhecido, manter “Ainda não sei” (Não informado). Só é necessário obter seu valor para esta decisão quando ele puder alterar a regra selecionada.

Fluxo principal

O ator examina as evidências, informa os valores conhecidos das três condições e solicita a avaliação. O sistema seleciona uma regra, exibe a providência, os valores informados e a justificativa.

Fluxos alternativos

Uma condição não foi informada e pode alterar a regra: solicitar preenchimento. Se todas as combinações possíveis dos valores ausentes selecionarem a mesma regra, apresentar essa regra. Uma ou mais condições são Não: indicar a primeira providência conforme a prioridade definida. Os demais problemas podem continuar existindo.

Pós-condição

Encaminhamento apresentado com rastro. Nenhuma página é alterada ou publicada.

Definem o comportamento esperado deste simulador. Os requisitos abaixo descrevem o escopo da implementação atual; as condições declaradas pelo usuário não são evidências verificadas automaticamente.

Requisitos acrescentados no redesenho

• RF-09: identificar página-alvo por título e versão/data antes de emitir uma providência; caminho ou URL é opcional e não é acessado pela aplicação.
• RF-10: manter campos e resultado ao alternar entre vistas; permitir links diretos e Voltar/Avançar do navegador.
• RF-11: incluir a identificação da página no resultado e invalidá-lo quando essa identificação mudar.

Definem qualidades e restrições da solução. A coluna de verificação distingue o que pode ser observado no código do que ainda exige validação de uso.

C1: fontes identificadas? C2: revisão humana aprovada? C3: verificações técnicas previstas passaram? Entradas booleanas; — aceita ambos os valores. As oito combinações são admissíveis.

Política Unique: exatamente uma regra corresponde a cada combinação neste modelo completo. As regras são mutuamente exclusivas; a prioridade foi expressa nas condições das regras, sem depender da ordem das linhas.

Consultar a tabela de decisão e experimentar suas regras.

7.1. Dicionário e critérios de preenchimento

As definições seguintes constituem o contrato didático desta versão. Em uso real, responsável e equipe devem aprovar as listas de fontes, critérios editoriais e verificações técnicas antes da avaliação. A ausência dessas listas não pode ser convertida automaticamente em Sim.

Lista técnica de referência deste exercício: abertura da página sem erro impeditivo de JavaScript; carregamento dos recursos previstos; funcionamento dos controles do cenário; inspeção dos destinos de navegação; legibilidade e operação na tela de referência. Essa lista serve para preencher C3 no cenário didático; não afirma que essas verificações foram feitas numa página real.

Para evitar a ambiguidade entre “revisão feita” e “revisão aprovada”, C2 passa a ser rotulada “Revisão humana aprovada?”. A saída R2 permanece “Concluir revisão humana”, incluindo resolver impedimentos encontrados.

7.2. Contrato de dados e resolução

Entrada parcial: [1, 0, null]
Completações: [1, 0, 0] e [1, 0, 1]
Ambas selecionam R2
Resultado: Concluir revisão humana

7.3. Estados e transições da interface

Os nomes abaixo são estados conceituais para implementação e teste, não códigos já expostos pela aplicação.

7.4. Exceções e mensagens

A tabela atual evita lacunas e sobreposições. Os caminhos de erro precisam continuar protegidos caso as regras sejam alteradas. Erros genéricos de infraestrutura do navegador ficam fora desse contrato de decisão.

7.5. Critérios verificáveis de qualidade

Decomposição dos requisitos em capacidades observáveis da interface. Como o protótipo já existe, o estado registra o que foi implementado nesta versão.

Providência não é funcionalidade executada: “Concluir revisão humana” é uma saída da avaliação. O simulador não realiza a revisão, não identifica fontes por conta própria, não executa verificações técnicas sobre uma página e não publica arquivos. Essas ações exigiriam outro escopo e novos requisitos.

A interface foi apresentada no início para tornar visível a solução proposta. Há uma única instância do formulário, compartilhada pelos botões das tabelas e pelos casos de teste.

Voltar à solução em funcionamento

Ao verificar a interação, observe preenchimento, avaliação parcial, resultado e destaque, invalidação após alteração e limpeza. Registre resultados para os requisitos e casos de aceitação correspondentes; experimentar a interface não equivale à aceitação formal.

C1: fontes identificadas? C2: revisão humana aprovada? C3: verificações técnicas previstas passaram? Entradas booleanas; — aceita ambos os valores. As oito combinações são admissíveis.

Política Unique: exatamente uma regra corresponde a cada combinação neste modelo completo. As regras são mutuamente exclusivas; a prioridade foi expressa nas condições, sem depender da ordem das linhas.

Escolha “Usar Rn” para preencher a interface de avaliação e depois clique em “Ver próxima providência”. A linha selecionada será destacada nas duas tabelas quando a avaliação for realizada.

9.1. Objeto e critério de conclusão da aceitação

Objeto: a funcionalidade que determina a próxima providência, não a aprovação editorial da página-alvo. Responsável: autor/curador designado para aceitar a aplicação; nome e decisão ainda não registrados. Estado: planejamento, sem aceitação realizada.

A tabela acima apoia a escolha das entradas e dos resultados esperados. Os casos funcionais e os requisitos não funcionais aplicáveis devem ser executados e registrados. Para concluir: nenhum impedimento aberto, pendências restantes avaliadas e decisão explícita do responsável com justificativa.

9.2. Casos de aceitação de referência

Registro de cada execução: caso, versão, executor, data, ambiente, resultado observado, evidência, situação (não executado/aprovado/reprovado/bloqueado) e pendências. Todos os casos de aceitação desta seção permanecem sem execução registrada. Testes automatizados da lógica são evidências de verificação, não substituem a decisão humana de aceitação.

A interface executa as oito combinações e compara a saída com resultados esperados definidos explicitamente para cada caso. A entrada 1, 0, 0 retorna “Concluir revisão humana”; os testes técnicos continuam pendentes e serão tratados na próxima avaliação.

A aprovação destes testes verifica a implementação deste modelo. Não valida a suficiência dos critérios de publicação nem a qualidade da página real.

11.1. Matriz de rastreabilidade e evidência

Registro de teste: identificar teste, versão da página, data, executor, navegador/sistema, entradas e estado anterior, passos realizados, resultado esperado, resultado observado e evidência. “Implementado” não equivale a “verificado” nem a “validado pelo usuário”.

Entrega da versão: aplicação web aceita e disponibilizada no LAC, com especificação, tabela de decisão, código, registros de teste e aceitação.

Condição de término: requisitos acordados atendidos; testes previstos executados e registrados; impedimentos resolvidos; aceitação humana registrada; versão disponibilizada e conferida. Alterações posteriores iniciam um novo ciclo de revisão.

Estado de referência: aplicação implementada e lógica verificada na elaboração. Verificações manuais de interface, acessibilidade, compatibilidade, aceitação e publicação ainda exigem evidências. Nesta revisão documental, a lógica foi preservada; não se registrou uma nova execução de aceitação.

Fim de uma consulta: apresentar providência determinada ou solicitar informação adicional. R4 não encerra o desenvolvimento nem autoriza publicação automática.

Retornar à visão integrada do exemplo