Skip to content

[P0][GitHub] Publicar progresso canônico em Issues/tasks e PRs #442

Description

@wesleysimplicio

Objetivo

Formalizar no simplicio-loop que todo avanço observável do loop seja publicado de forma identificável e idempotente tanto na Issue/task de origem quanto na PR que implementa a etapa.

Esta issue nasce da execução da #423 e deve evitar que o Project 3, a Issue e a PR apresentem estados divergentes ou progresso sem autoria verificável.

Escopo

Implementar um contrato único de comentário para as transições do lifecycle:

claim → survey/plan → operate → review → recovery → PR → checks → merge → re-query → close.

Para cada transição, o comentário deve:

  • ser publicado na Issue/task de origem;
  • ser publicado na PR vinculada quando existir uma PR;
  • identificar o agente no formato Nome/Papel - #XXXX - Modelo, usando o nome do computador abreviado em quatro caracteres;
  • incluir run_id, task/issue, pr (quando houver), stage, status, attempt, fence, reason_code, receipt_id, evidências/comandos e próximo gate;
  • conter links cruzados entre Issue/task, PR, commit e evidências;
  • usar uma chave de idempotência estável por run_id + item + stage + attempt + transition, sem duplicar comentários em retry;
  • registrar explicitamente PASS, REGRESSED, BLOCKED ou NEEDS-HUMAN;
  • nunca publicar progresso em outro repositório ou em um Project diferente do Project do próprio repo.

Requisitos funcionais

  1. Criar um envelope/schema versionado para o comentário de progresso.
  2. Implementar publisher para Issue/task e PR com o mesmo envelope e chave idempotente.
  3. Reconciliar comentários existentes antes de criar outro, preservando histórico sem duplicação.
  4. Atualizar o item do Project do repo de acordo com o estado observado; comentário sozinho não pode marcar Done.
  5. Em erro de autenticação/permissão/API, produzir receipt fail-closed com reason_code estável e manter a Issue/PR em estado não concluído.
  6. Manter a identificação dos agentes, inclusive quando o mesmo modelo aparece em máquinas diferentes.
  7. Não criar, usar ou sugerir qualquer estado de quarentena.

Testes obrigatórios

  • unitários para envelope, identidade, chave idempotente e reason codes;
  • testes de retry que comprovem exatamente um comentário por transição em Issue e PR;
  • testes com PR ausente, PR fechada, PR trocada e item sem Project;
  • integração usando API fake/fixture para verificar links cruzados, paginação e erro de permissão;
  • replay: comentário adulterado ou receipt divergente não pode ser tratado como progresso válido;
  • paridade entre código fonte e pacote/wheel;
  • python scripts/check.py, suíte completa e git diff --check verdes.

Critérios de aceite

  • Cada etapa do loop publica comentário assinado na Issue/task e, quando aplicável, na PR.
  • Os comentários mostram agente, modelo, computador abreviado, run/attempt/fence, status e evidências.
  • Retries são idempotentes e não geram spam/duplicatas.
  • Issue/task, PR e Project apontam para o mesmo estado observado e para os mesmos receipts.
  • Falhas de API/auth ficam explícitas e bloqueiam o fechamento/merge.
  • Uma fixture completa prova a sequência inteira, inclusive recovery e re-query pós-merge.
  • Nenhum caminho usa quarentena.
  • Documentação e exemplos permitem que Codex, Claude e outros LLMs sigam o mesmo formato.

Definition of Done

Código, schemas, testes, documentação e pacote publicados em uma PR; review adversarial independente verde; checks verdes; PR mesclada somente após todas as evidências; Issue e Project do repo atualizados com links para a PR/commit e verificação em origin/main.

Metadata

Metadata

Assignees

No one assigned

    Labels

    architectureorchestratorOrchestration: DAG, pipeline, worker pool, isolationqualityQuality gates / verification

    Projects

    Status
    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions