fix(qa-gate): add mandatory story status update after gate verdict#543
fix(qa-gate): add mandatory story status update after gate verdict#543vxavierr wants to merge 1 commit intoSynkraAI:mainfrom
Conversation
Problem identified: @qa creates the gate file but leaves the story in InReview (or Ready for Review) — creating a stale Status field that any agent or human consulting the story will read as incorrect state. Dual root cause: - qa-gate.md had no explicit instruction to update the story Status field - story-lifecycle.md assigned the Done transition to @devops, which is incorrect — @devops handles git push, not the status field update Changes: - qa-gate.md: add MANDATORY FINAL STEP section with verdict→Status mapping table and required Change Log entry format. Gate file without status update is now defined as incomplete task execution. - story-lifecycle.md: replace single Done row (attributed to @devops) with two explicit rows owned by @qa: PASS/CONCERNS/WAIVED → Done (@qa MUST update) FAIL → InProgress (@qa MUST update) Add CRITICAL block mirroring the existing Draft→Ready critical note, making @qa's responsibility unambiguous.
|
@vxavierr is attempting to deploy a commit to the Pedro Valério Lopez's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... 📒 Files selected for processing (2)
✏️ Tip: You can disable in-progress messages and the fortune message in your review settings. Tip CodeRabbit can scan for known vulnerabilities in your dependencies using OSV Scanner.OSV Scanner will automatically detect and report security vulnerabilities in your project's dependencies. No additional configuration is required. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Fechando para revisão interna antes de resubmeter. |
nikolasdehor
left a comment
nikolasdehor
left a comment
There was a problem hiding this comment.
Review — PR #543: mandatory story status update after gate verdict
@vxavierr, fix bem fundamentado. O problema é real — um gate file sem atualização de status cria dado stale que propaga para qualquer consulta downstream (*list-stories, decisões de sprint, etc.).
Análise das mudanças
1. qa-gate.md — seção MANDATORY FINAL STEP
A tabela de mapeamento veredicto → status está correta:
| Veredicto | Status | Correto? |
|---|---|---|
| PASS | Done | Sim — story concluída |
| CONCERNS | Done | Sim — concerns são observações, não blockers |
| FAIL | InProgress | Sim — retorna para dev corrigir |
| WAIVED | Done | Sim — waiver aceita o risco, story avança |
O formato do Change Log entry é claro e auditável:
| {YYYY-MM-DD} | @qa (Quinn) | Gate: {verdict} — Status: {old} → {new} |
A definição "gate file sem atualização de status = execução incompleta" é a instrução certa — torna o comportamento mandatório, não opcional.
2. story-lifecycle.md — correção de responsabilidade
A correção de @devops para @qa na transição InReview → Done está factualmente correta. O @devops executa git push depois que a story já está Done — ele não é quem muda o status. O bloco CRITICAL adicionado espelha o padrão já existente para a transição Draft → Ready do @po, mantendo consistência.
A adição da linha InProgress (return) para FAIL é importante — sem ela, a transição reversa não estava documentada, e o LLM não teria instrução explícita para regredir o status.
Dois pontos menores
1. CONCERNS → Done merece uma nota
CONCERNS mapeando para Done é correto no contexto atual (concerns são informativos, não blockers). Mas vale considerar se no futuro haverá um status intermediário tipo Done (with concerns) para distinguir de um PASS limpo. Não é blocker para este PR — apenas mencionando para rastreabilidade.
2. Edge case: gate file já existe (re-execução)
Se o @qa executar *qa-gate duas vezes na mesma story (corrigindo um gate anterior), a instrução "append to Change Log" está correta (não substitui). Mas seria útil documentar explicitamente que o Status deve refletir o último veredicto, não o primeiro. Na prática o comportamento já é correto (a última escrita no campo Status ganha), mas uma nota explícita previne ambiguidade em cenários de re-execução.
Veredicto
Fix correto, bem delimitado, e resolve um problema real de consistência de dados. Ambas as mudanças estão alinhadas e se reforçam mutuamente. LGTM.
APPROVE
DevOps Review — @devops (Gage)Veredicto: APPROVED — Ready to merge quando reaberto
Bloqueador: Autor comentou "Fechando para revisão interna" — aguardando resubmissão. Merge imediato quando pronto. ⚡ Gage — Repository Guardian |
3 participants
Problema
O
@qacria o gate file mas não atualiza o campoStatusda story — que fica preso emInReview(ouReady for Review). Qualquer agente ou pessoa que consulte a story lê um estado incorreto: o gate file e o campo da story estão dessincronizados.Raiz dupla:
qa-gate.mdnão tinha nenhuma instrução explícita para atualizar oStatusda story após emitir o veredictostory-lifecycle.mdatribuía a transição paraDoneao@devops, o que está incorreto — o@devopsexecuta ogit push, não atualiza o campo de statusMudanças
qa-gate.mdAdiciona a seção
## MANDATORY FINAL STEP — Update Story Statuscom:story-lifecycle.mdDone(incorretamente atribuída ao@devops) por duas linhas explícitas de responsabilidade do@qa:PASS/CONCERNS/WAIVED → Done— @qa MUST updateFAIL → InProgress— @qa MUST updateCRITICAL(espelhando o que já existe para a transiçãoDraft → Ready) tornando a responsabilidade do@qainequívoca@devopssó executa ogit pushdepois que a story já estáDonePor que isso importa
Sem esse fix, qualquer consulta de status — incluindo
@aios-master *list-stories— lê dado stale. Uma story pode ter um gate PASS e continuar aparecendo comoInReview, fazendo agentes tratarem trabalho concluído como pendente.