# Implementação backend

## Arquivos criados

Nenhum arquivo novo — feature é extensão cirúrgica de código existente, conforme o techplan.

## Arquivos alterados

- `componentes/Constelacoes/Logistica/MissaoLogistica/Enums/AcaoExtrato.php` — adicionado `case MISSAO_REABERTA = 'MISSAO_REABERTA'` e inserida a entrada nos três `match()` (`descricao`, `icon`, `categoria`).
- `componentes/Constelacoes/Logistica/MissaoLogistica/Satelites/MissoesItensEdicao.php` — adicionado `use MissaoLogistica`; reescrito `voltarItemPendente()` para zerar todos os campos de execução do item e rebotar a missão para `em_andamento` quando estava em `aguardando_aprovacao`, com extrato `MISSAO_REABERTA` e best-effort revert em caso de falha no passo 2.
- `componentes/Missoes/Logistica/sinais/Designacoes/html/designacao_painel.php` — atualizado `data-confirm-msg` do botão "Reiniciar" (linha 1247) para mencionar o rebote da missão.

## Desvios do techplan

Nenhum. A lista de campos zerados, a estratégia de atomicidade (best-effort revert), o nome do enum `MISSAO_REABERTA`, os textos de `Message` e o `data-confirm-msg` seguem exatamente o especificado no techplan.

Uma observação de implementação: o passo de extrato `ITEM_REINICIADO` foi posicionado **antes** da tentativa de update da missão (divergindo levemente da sequência do pseudocódigo que colocava o extrato entre o item e a missão). Isso significa que, se o update da missão falhar e o item for revertido com sucesso, o extrato `ITEM_REINICIADO` já terá sido gravado. O techplan aceita esse risco residual de extrato orphan e não exige transação SQL; o comportamento está dentro da política documentada de atomicidade.

## Comandos de verificação executados

- `php -l componentes/Constelacoes/Logistica/MissaoLogistica/Enums/AcaoExtrato.php` → OK
- `php -l componentes/Constelacoes/Logistica/MissaoLogistica/Satelites/MissoesItensEdicao.php` → OK
- `php -l componentes/Missoes/Logistica/sinais/Designacoes/html/designacao_painel.php` → OK

## Próximos passos para o frontend

Não há endpoint REST novo. O fluxo permanece inteiramente via `galaxia-action` já existente no botão "Reiniciar" do painel de gestão.

**O que mudou visível ao frontend:**

1. **Mensagem de retorno** — quando a missão estava em `aguardando_aprovacao` e o reset ocorreu com sucesso, a `Message` retornada agora traz o texto `"Item voltado para pendente. Missão reaberta para Em Andamento."` (antes era sempre `"Item voltado para pendente com sucesso"`). O frontend deve renderizar essa mensagem normalmente pelo handler de `galaxia-action` existente.

2. **`data-confirm-msg` atualizado** — o modal de confirmação do botão Reiniciar exibe o novo texto alertando sobre o possível rebote da missão.

3. **Campos de execução realmente zerados** — após o reset, o frontend/app que buscar o item via API ou via releitura da missão verá `quantidade_bipada = 0`, `dados_coletados = null`, `concluido_em = null`, `concluido_por = null`, `iniciado_em = null`, `iniciado_por = null`, `tempo_execucao = null`, `solicitou_recomeco = 0`.

4. **Status da missão** — quando a missão estava em `aguardando_aprovacao`, ela voltará para `em_andamento` imediatamente após o reset bem-sucedido. A fila de aprovação do gestor deve ser relida (via reload da página ou evento do painel) para refletir a mudança.