[Garakis]

O que este PR faz

Implementa a S2-11 (card no Trello), que corresponde ao PBI-03.1.3 Sugerir cenários de aceitação. O harness da S2-09 já tinha a operação cenarios, mas nada a usava. Este PR fortalece essa operação e a liga no painel do copiloto da S2-10.

Critério do PBI	Como é atendido
1. Sugerir a partir da história	Cenários com nome, tipo, DADO, QUANDO e ENTÃO, exibidos no painel com o botão Usar no editor
2. Caminho principal e acesso não autorizado	O backend recusa resposta sem caminho_principal e, quando a história ou as regras citam um termo de rules.permission_terms, também sem acesso_nao_autorizado
3. Exigir história completa	A tela bloqueia e diz quais blocos faltam; o backend responde 400 HISTORIA_INCOMPLETA com details.campos sem chamar o modelo

Decisões

• Usar no editor só preenche o formulário de cenário. O PO revisa e salva pelo fluxo normal (justificativa em item concluído e auditoria continuam valendo). Um cenário que o PO já esteja digitando nunca é sobrescrito.
• Salvar um cenário sugerido não apaga as outras sugestões.
• O modo só aparece na edição de PBI existente e para quem pode editar cenários.
• permission_terms é uma lista nova em rules, versionada com o resto da configuração do harness. Revisões salvas antes deste PR recebem o padrão do código, sem migration.
• schema_version continua 1: o schema de saída é gerado pelo backend a cada chamada e nenhum cliente usava cenarios antes.

Validação local

• Backend: build ok; npm test com 352 testes passando, 0 falhas.
• Frontend: build ok; vitest com 292 testes passando (novos em CopilotScenarios.test.tsx e api_copilot.test.ts).
• ai-service: 17 testes do harness passando.
• test:integration:harness ganhou os passos da S2-11, mas não rodei localmente (sem Docker). O CI deste PR cobre esse script.

Pendências

• Capturas de tela com o modelo local (docs/evidence/S2-11-*.png).
• Revisão por outra pessoa.

Detalhes em docs/S2-11-CENARIOS.md.

🤖 Generated with Claude Code

[LoadCG]

Revisão QA complementar: os checks de CI estão verdes, mas encontrei duas lacunas que os testes atuais não cobrem. Minha recomendação é ajustar estes pontos e revalidar antes da aprovação.

[LoadCG]

[P2] perfil sozinho é ambíguo e pode forçar um cenário de acesso não autorizado sem requisito de permissão. Por exemplo, “consultar o perfil público do desenvolvedor” ativa requiresPermissionScenario; o backend então pode rejeitar a resposta ou a IA pode propor uma regra de acesso que não está na história. Sugiro usar expressões mais específicas de autorização ou uma condição configurável, e adicionar um teste para “perfil” usado como dado do domínio.

[Garakis]

Boa, procede. Reproduzi: "consultar o perfil público do desenvolvedor" ativava requiresPermissionScenario.

Corrigido em f9511ae: a lista padrão de permission_terms passou a usar expressões de autorização ("sem permissão", "perfil de acesso", "perfil de administrador", "somente o proprietário", "acesso restrito"...). "Perfil" e "administrador" soltos saíram, porque também aparecem como dado do domínio. A lista continua configurável no harness para quem precisar de outra expressão.

Testes novos: "consultar o perfil público do desenvolvedor", "editar meu perfil" e "cadastrar um administrador do condomínio" não exigem o cenário; "Somente o proprietário pode excluir o pedido", "Usuário sem permissão não visualiza o valor" e "Acesso restrito ao time financeiro" exigem.

[LoadCG]

[P2] A validação confere apenas o campo tipo, então uma saída pode marcar como acesso_nao_autorizado um cenário cujo DADO/QUANDO/ENTÃO descreve sucesso. O teste em harness.service.test.ts atualmente passa exatamente esse caso: o helper mantém “o sistema exibe o pedido” no ENTÃO mesmo no cenário de recusa. Assim, o backend pode aceitar uma resposta que não atende ao critério de acesso negado. Sugiro corrigir o fixture e cobrir explicitamente uma saída contraditória; a validação ou o contrato também devem deixar claro o limite do que conseguem garantir.

[Garakis]

Procede também, e o teste estava mesmo validando o caso errado.

Corrigido em f9511ae:

• O helper do teste agora gera um ENTÃO de recusa para acesso_nao_autorizado.
• O backend rejeita um cenário acesso_nao_autorizado cujo ENTÃO não descreve recusa (recusa, negado, bloqueado, não é permitido, permanece inalterado, mensagem de erro ou de permissão...). Há teste explícito com a saída contraditória ("o sistema exibe o pedido").
• O prompt do ai-service pede que o ENTÃO desse cenário diga explicitamente que a ação é recusada.

Sobre o limite: a verificação é lexical. Ela garante que a recusa está escrita, não que a regra de permissão proposta esteja correta, e a revisão do PO antes de salvar continua necessária. Isso ficou registrado em docs/S2-11-CENARIOS.md (seção "Limites das verificações") e na descrição da operação no OpenAPI.

[LoadCG]

Revisão QA complementar

Revisei o head atual (b720ca5) e os achados anteriores desta PR aparecem corrigidos: a detecção de permissão agora usa expressões mais específicas, e o backend exige texto explícito de recusa no ENTÃO para cenários de acesso não autorizado. Não encontrei outro problema bloqueador no diff revisado.

CI, typecheck/build dos três serviços e E2E com PostgreSQL e Chrome estão verdes para este head. O teste integrado do harness indicado na descrição não foi executado localmente por falta de Docker; o job E2E do CI executou a validação dos modos do copiloto com serviços isolados.

[LoadCG]

QA adicional — contrato impede perguntas sem cenário

Em ai-service/harness.py, a operação cenarios sempre força scenarios.minItems = 1. Isso conflita com o contrato do backend: validateScenarios aceita scenarios: [] quando a resposta inclui perguntas, e há teste cobrindo esse caminho. O prompt também orienta usar perguntas quando uma lacuna impedir um cenário verificável. Com a restrição do schema, essa resposta válida não pode ser gerada e a chamada pode falhar em vez de pedir esclarecimento ao PO.

Sugiro permitir lista vazia quando houver perguntas, ou ajustar contrato e testes para rejeitar explicitamente esse estado se a decisão de produto for sempre sugerir pelo menos um cenário. O CI usa Ollama simulado; os logs validam o contrato integrado, mas não demonstram a qualidade de cenários produzidos pelo modelo local. A descrição também registra que a captura com modelo local ainda está pendente.