align render worker agenda direction

discussion/workflow/agendas/AGD-0043-real-render-worker-establishment.md

@@ -167,9 +167,9 @@ O host desktop pode ser a primeira integracao concreta, mas nao deve ser o unico
 
 **Pergunta:** Quem chama present: worker, host event loop, ou display cadence service?
 
-**Sugestao:** no primeiro corte, o worker deve produzir/publish uma superficie pronta e notificar host invalidation; o host event loop continua sendo autoridade de apresentacao da janela nativa. O "repeat ultimo frame valido" deve ser modelado no controller/telemetry como comportamento de consumo/cadence, mas o swap/window present concreto deve respeitar o host.
+**Sugestao:** no primeiro corte, o worker deve produzir/publish uma superficie pronta como buffer RGBA8888 owned, por exemplo `OwnedRgba8888Frame`. O host event loop continua sendo autoridade de apresentacao da janela nativa. O "repeat ultimo frame valido" deve repetir o ultimo buffer publicado, nao recompor nem exigir que o worker conheca a API nativa de janela/swap.
 
-**Motivo:** winit/pixels e plataformas graficas frequentemente tem afinidade com thread/event loop. Colocar o swap real dentro do worker pode funcionar em alguns hosts e quebrar portabilidade. O contrato importante e que a VM nao bloqueie e que o host tenha uma superficie publicada coerente.
+**Motivo:** RGBA8888 ja e o formato logico canonico nas specs. Um frame owned com `FrameId`, ownership/epoch, largura, altura, stride e pixels RGBA8888 deixa o contrato testavel sem janela e evita acoplamento a winit/pixels, SDL, swapchain ou textura nativa. Colocar o swap real dentro do worker pode funcionar em alguns hosts e quebrar portabilidade. O contrato importante e que a VM nao bloqueie e que o host tenha uma superficie publicada coerente.
 
 ### 5. Como o worker recebe recursos read-only?
 
@@ -219,5 +219,19 @@ Esta agenda pode virar decision quando tivermos:
 ## Discussion
 
 - 2026-06-06: Agenda criada dentro da `DSC-0042` para separar worker real da preparacao de fronteira discutida em `AGD-0042`.
+- 2026-06-15: Apos a conclusao dos planos `PLN-0098` a `PLN-0109`, a direcao da agenda foi alinhada em torno da Opcao C: controller em `prometeu-system`, handoff single-slot thread-safe, backend fake/local primeiro, e publicacao de frame owned RGBA8888 antes da integracao desktop concreta.
 
 ## Resolution
+
+Direcao proposta para decisao:
+
+- `RenderManager` continua como autoridade de policy, ownership/epoch, latest-wins e telemetry;
+- o worker controller contratual deve viver em `prometeu-system`;
+- traits compartilhadas minimas podem viver em `prometeu-hal`;
+- o handoff real deve ser single-slot latest-wins com sincronizacao explicita, inicialmente `Mutex<Option<RenderSubmission>> + Condvar`;
+- o worker separa `pending` de `in_flight` e checa stop/ownership/epoch antes de publicar;
+- o worker publica um `OwnedRgba8888Frame` ou equivalente, contendo frame id, owner/epoch, dimensoes, stride e pixels RGBA8888 owned;
+- o host event loop faz o upload/present nativo a partir do ultimo frame publicado;
+- o primeiro backend deve ser fake/local para provar contrato e concorrencia sem janela;
+- a integracao desktop concreta vem depois, usando a mesma trait/backend contract;
+- testes devem usar barreiras/condvars para provar ausencia de bloqueio da VM, latest-wins, stale discard, shutdown bounded e telemetry.