Real Render Worker Establishment

discussion/index.ndjson

@@ -1,8 +1,8 @@
-{"type":"meta","next_id":{"DSC":43,"AGD":43,"DEC":32,"PLN":98,"LSN":49,"CLSN":1}}
+{"type":"meta","next_id":{"DSC":43,"AGD":44,"DEC":33,"PLN":110,"LSN":49,"CLSN":1}}
 {"type":"discussion","id":"DSC-0039","status":"abandoned","ticket":"render-pipeline-family-and-future-3d","title":"Render Pipeline Family and Future 3D","created_at":"2026-06-04","updated_at":"2026-06-04","tags":["gfx","renderer","runtime","architecture","pipeline"],"agendas":[{"id":"AGD-0039","file":"AGD-0039-render-pipeline-family-and-future-3d.md","status":"abandoned","created_at":"2026-06-04","updated_at":"2026-06-04","_override_reason":"User explicitly chose to close this agenda without a new decision because DSC-0038 already established enough architecture for future extension, and 3D is intentionally deferred."}],"decisions":[],"plans":[],"lessons":[],"_override_reason":"User explicitly chose to close this agenda without a new decision because DSC-0038 already established enough architecture for future extension, and 3D is intentionally deferred."}
 {"type":"discussion","id":"DSC-0040","status":"done","ticket":"vm-render-parallel-execution-boundary","title":"VM and Render Parallel Execution Boundary","created_at":"2026-06-04","updated_at":"2026-06-06","tags":["runtime","renderer","vm","concurrency","architecture","perf"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0048","file":"discussion/lessons/DSC-0040-vm-render-parallel-execution-boundary/LSN-0048-render-workers-need-a-closed-packet-contract.md","status":"done","created_at":"2026-06-06","updated_at":"2026-06-06"}]}
 {"type":"discussion","id":"DSC-0041","status":"open","ticket":"foreground-stack-game-pause-shell-vm-backed","title":"Foreground Stack, Game Pause, and VM-Backed Shell Coexistence","created_at":"2026-06-05","updated_at":"2026-06-05","tags":["runtime","os","lifecycle","shell","game","vm","foreground","architecture"],"agendas":[{"id":"AGD-0041","file":"AGD-0041-foreground-stack-game-pause-shell-vm-backed.md","status":"open","created_at":"2026-06-05","updated_at":"2026-06-05"}],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0042","status":"open","ticket":"real-render-worker-establishment","title":"Real Render Worker Establishment","created_at":"2026-06-06","updated_at":"2026-06-06","tags":["runtime","renderer","worker","concurrency","host","hal","architecture"],"agendas":[{"id":"AGD-0042","file":"AGD-0042-real-render-worker-establishment.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0042","status":"open","ticket":"real-render-worker-establishment","title":"Real Render Worker Establishment","created_at":"2026-06-06","updated_at":"2026-06-06","tags":["runtime","renderer","worker","concurrency","host","hal","architecture"],"agendas":[{"id":"AGD-0042","file":"AGD-0042-host-hardware-render-boundary-preparation.md","status":"accepted","created_at":"2026-06-06","updated_at":"2026-06-06"},{"id":"AGD-0043","file":"AGD-0043-real-render-worker-establishment.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06"}],"decisions":[{"id":"DEC-0032","file":"DEC-0032-platform-layer-and-hardwarebridge-elimination.md","status":"accepted","created_at":"2026-06-06","updated_at":"2026-06-06","ref_agenda":"AGD-0042"}],"plans":[{"id":"PLN-0098","file":"PLN-0098-define-platform-facade-contracts.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0099","file":"PLN-0099-introduce-owned-render-submission-sink.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0100","file":"PLN-0100-migrate-local-render-publication-to-sink.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0101","file":"PLN-0101-remove-immediate-gfx-syscall-rendering.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0102","file":"PLN-0102-introduce-game2d-frame-composer-service.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0103","file":"PLN-0103-introduce-runtime-platform-and-testplatform.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0104","file":"PLN-0104-migrate-vm-runtime-hostcontext-to-platform.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0105","file":"PLN-0105-migrate-firmware-and-hub-to-platform-services.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0106","file":"PLN-0106-migrate-desktop-host-to-platform-services.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0107","file":"PLN-0107-migrate-remaining-platform-domains.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0108","file":"PLN-0108-migrate-tests-to-testplatform.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]},{"id":"PLN-0109","file":"PLN-0109-remove-hardwarebridge-and-update-specs.md","status":"open","created_at":"2026-06-06","updated_at":"2026-06-06","ref_decisions":["DEC-0032"]}],"lessons":[]}
 {"type":"discussion","id":"DSC-0038","status":"done","ticket":"render-frame-packet-boundary","title":"Logical Render Pipelines and Command Packets","created_at":"2026-05-25","updated_at":"2026-06-04","tags":["gfx","renderer","runtime","frame-composer","architecture","ui","pipeline"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0047","file":"discussion/lessons/DSC-0038-render-frame-packet-boundary/LSN-0047-typed-render-submissions-preserve-domain-boundaries.md","status":"done","created_at":"2026-06-04","updated_at":"2026-06-04"}]}
 {"type":"discussion","id":"DSC-0035","status":"done","ticket":"task-owned-shell-windows","title":"Agenda - Task-Owned Shell Windows","created_at":"2026-05-15","updated_at":"2026-05-15","tags":["runtime","os","task","window-manager","shell","lifecycle"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0044","file":"discussion/lessons/DSC-0035-task-owned-shell-windows/LSN-0044-task-window-liveness-belongs-to-the-task.md","status":"done","created_at":"2026-05-15","updated_at":"2026-05-15"}]}
 {"type":"discussion","id":"DSC-0034","status":"done","ticket":"system-os-domain-facades","title":"Agenda - SystemOS Domain Facades","created_at":"2026-05-15","updated_at":"2026-05-15","tags":["runtime","os","services","api-surface","lifecycle","fs"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0043","file":"discussion/lessons/DSC-0034-system-os-domain-facades/LSN-0043-systemos-domain-facades.md","status":"done","created_at":"2026-05-15","updated_at":"2026-05-15"}]}

discussion/workflow/agendas/AGD-0042-host-hardware-render-boundary-preparation.md

@@ -0,0 +1,191 @@
+---
+id: AGD-0042
+ticket: real-render-worker-establishment
+title: Host Hardware and Render Boundary Preparation
+status: accepted
+created: 2026-06-06
+resolved:
+decision: DEC-0032
+tags: [runtime, renderer, hardware, host, hal, boundary, architecture]
+---
+
+## Contexto
+
+`DSC-0040` fechou a arquitetura base para separar VM/logical execution de render consumption. A implementacao atual ainda usa `HardwareBridge` como uma trait agregadora grande: render, composer, `Gfx`, audio, input, touch e assets ficam expostos juntos para runtime, firmware e syscalls.
+
+Para estabelecer um worker real, precisamos antes preparar essa fronteira. A direcao agora nao e mais transformar `HardwareBridge` em uma interface host-implemented permanente. A direcao e reformular o runtime em uma platform layer com servicos explicitos e eliminar completamente o `HardwareBridge` monolitico como contrato final.
+
+O worker real deve depender apenas de uma sub-abstracao minima de render, nunca de `&mut Hardware` inteiro.
+
+Esta agenda (`AGD-0042`) discute a preparacao/refatoracao de fronteiras. A agenda seguinte (`AGD-0043`) dentro da mesma `DSC-0042` discutira o estabelecimento do worker real propriamente dito.
+
+## Problema
+
+Hoje o sistema ja tem uma trait (`HardwareBridge`), mas ela ainda permite acoplamentos que impedem um worker real limpo:
+
+- `HostContext` entrega `&mut dyn HardwareBridge` para syscalls;
+- syscalls `gfx2d.*` e `gfxui.*` ainda fazem buffering de comandos e tambem desenham imediatamente via `hw.gfx_mut()`;
+- composer state (`bind_scene`, `set_camera`, `emit_sprite`, `close_game2d_packet`) vive dentro da mesma abstracao que render/present;
+- firmware e Hub publicam diretamente via `hw.publish_render_submission`;
+- host desktop instancia `prometeu_drivers::Hardware` diretamente e usa constantes concretas como `Hardware::W/H`;
+- testes dependem fortemente do `Hardware` concreto.
+
+Se introduzirmos o worker real agora, a implementacao provavelmente acabara passando `&mut Hardware`, `&mut Gfx` ou `FrameComposer` vivo para a fronteira do worker por conveniencia. Isso quebraria o contrato definido em `DEC-0031`.
+
+## Pontos Criticos
+
+### 0. Escopo da migracao completa
+
+Podemos migrar render primeiro para reduzir risco e desbloquear o worker real, mas a mudanca nao deve parar no render. Audio, input, touch, assets/storage, clock/pacing e telemetry tambem devem sair do `HardwareBridge` monolitico para servicos/facades explicitos.
+
+`HardwareBridge` deve morrer ao final desta mudanca. Qualquer uso intermediario e scaffold de migracao, nao contrato final.
+
+### 1. Eliminacao do `HardwareBridge`
+
+`HardwareBridge` pode existir apenas como detalhe transitorio durante a migracao, se isso reduzir risco de implementacao. Ele nao deve sobreviver como compat layer permanente nem como contrato publico do runtime.
+
+O estado final deve remover `HardwareBridge` e substituir o acesso monolitico por servicos explicitos de plataforma.
+
+### 2. Render submission sink
+
+O primeiro corte provavelmente deve extrair algo como `RenderSubmissionSink`, separando `submit/publish` de `HardwareBridge`.
+
+### 3. Remocao de render imediato das syscalls
+
+As syscalls de `gfx2d`/`gfxui` devem apenas gravar comandos nos buffers que fecham o packet. O desenho imediato via `hw.gfx_mut()` deve sair antes do worker real.
+
+### 4. Composer como dominio logico
+
+`bind_scene`, `set_camera`, `emit_sprite` e `close_game2d_packet` pertencem ao fechamento logico do frame. Precisamos separar essa capacidade do backend que rasteriza/presenta.
+
+### 5. Host-owned concrete hardware
+
+`prometeu_drivers::Hardware` deve continuar existindo como implementacao local/default, mas nao como a arquitetura. O host desktop pode owns essa implementacao ou uma composicao de facades.
+
+### 6. Test migration
+
+Muitos testes instanciam `Hardware::new()`. A migracao deve preservar fixtures simples, talvez com um `TestHardware` ou `LocalHardware` que implemente as novas facades.
+
+## Opcoes
+
+### Opcao A - Quebrar `HardwareBridge` em uma unica grande refatoracao
+
+**Abordagem:** substituir `HardwareBridge` por facades menores em runtime, firmware, host e testes de uma vez.
+
+**Pros:**
+- resultado final mais limpo imediatamente;
+- remove rapidamente o risco de acoplamento.
+
+**Contras:**
+- alto blast radius;
+- muitos testes mudam ao mesmo tempo;
+- dificil isolar regressao funcional de regressao arquitetural.
+
+**Manutenibilidade:** boa no destino, arriscada durante a transicao.
+
+### Opcao B - Extrair facades incrementalmente e eliminar `HardwareBridge` no final
+
+**Abordagem:** criar facades menores (`RenderSubmissionSink`, composer/logical frame facade, audio/input/assets), usar `HardwareBridge` apenas como scaffold temporario se necessario, migrar callers por etapas e remover `HardwareBridge` ao final.
+
+**Pros:**
+- menor risco;
+- permite commits pequenos;
+- preserva testes e host desktop enquanto a fronteira e endurecida;
+- facilita medir quando o worker real ja pode nascer.
+
+**Contras:**
+- periodo intermediario com duas camadas;
+- exige disciplina para nao continuar usando `gfx_mut()` no caminho errado.
+- requer criterio explicito de remocao para evitar que o scaffold vire legado.
+
+**Manutenibilidade:** melhor equilibrio para o estado atual do repo.
+
+### Opcao C - Criar apenas `RenderSubmissionSink` agora e adiar o resto
+
+**Abordagem:** extrair somente a publicacao de submissions e manter composer/gfx/audio/input/assets no `HardwareBridge` por enquanto.
+
+**Pros:**
+- menor mudanca inicial;
+- desbloqueia parte do worker path.
+
+**Contras:**
+- ainda deixa syscalls e composer acoplados ao hardware grande;
+- worker real ainda pode esbarrar no viewport cache/composer vivo;
+- risco de adiar o problema central.
+
+**Manutenibilidade:** aceitavel como primeiro PR, insuficiente como preparacao completa.
+
+## Sugestao / Recomendacao
+
+Recomendo a **Opcao B**, em fases, com uma restricao forte: **`HardwareBridge` deve ser eliminado no estado final**.
+
+1. Criar `RenderSubmissionSink` com erro tipado minimo, mantendo implementacao local em `prometeu_drivers::Hardware`.
+2. Trocar publication local para depender de `RenderSubmissionSink`, nao do `HardwareBridge` inteiro.
+3. Remover writes imediatos de `gfx_mut()` nas syscalls `gfx2d`/`gfxui`; syscalls devem apenas bufferizar comandos.
+4. Extrair uma facade de composer/logical frame closure para `bind_scene`, `set_camera`, `emit_sprite`, `close_game2d_packet`.
+5. Migrar firmware, Hub, runtime, host desktop e testes para as facades novas.
+6. Remover `HardwareBridge` e qualquer dependencia nova dele.
+7. Atualizar fixtures/testes para dependerem das facades certas.
+
+O criterio tecnico: antes da agenda do worker real virar plano, nenhum caminho de render worker deve precisar de `&mut Hardware`, `&mut Gfx`, `FrameComposer` vivo ou estado mutavel da VM.
+
+O criterio arquitetural: antes desta agenda fechar, `HardwareBridge` deve estar definido como artefato a ser removido, nao como compatibilidade preservada.
+
+## Perguntas em Aberto
+
+- [x] `HardwareBridge` deve sobreviver como compatibilidade final?
+  - Resposta: nao. Ele deve ser completamente eliminado no destino.
+- [x] Se houver transicao incremental, `HardwareBridge` deve herdar facades menores ou apenas expor accessors temporarios?
+  - Resposta: se existir durante a migracao, deve usar accessors/adapters temporarios explicitos. Nao deve herdar facades menores, para nao parecer o novo contrato arquitetural.
+- [x] `RenderSubmissionSink` deve receber `&RenderSubmission` ou owned `RenderSubmission`?
+  - Resposta: owned `RenderSubmission`. O contrato deve nascer pronto para handoff/worker; o caminho local pode adaptar internamente quando necessario.
+- [x] O erro tipado minimo entra ja nesta preparacao ou fica para a agenda do worker real?
+  - Resposta: entra ja nesta preparacao, em forma minima. A API nao deve nascer infalivel para ser quebrada logo na agenda do worker real.
+- [x] Qual e a primeira syscall/teste que prova que `gfx2d` nao desenha mais imediatamente?
+  - Resposta: comecar por `gfx2d.clear` e `gfx2d.draw_text`. Os testes devem provar que a syscall apenas bufferiza comando e que pixels mudam somente apos fechamento/publicacao da submission.
+- [x] Composer deve ficar no runtime/logical side ou continuar em `prometeu_drivers::Hardware` enquanto nao houver worker?
+  - Resposta: deve ficar no logical side/runtime service. A migracao pode ser faseada, mas `bind_scene`, `set_camera`, `emit_sprite` e `close_game2d_packet` sao preparacao de frame logico, nao backend fisico.
+- [x] Como preservar testes simples que hoje usam `Hardware::new()`?
+  - Resposta: criar `TestPlatform` como fixture explicita para testes. Nao preservar `HardwareBridge` como compatibilidade.
+- [x] Que nomes vamos usar: `Hardware`, `HostHardware`, `LocalHardware`, `RuntimeHardware`, `RenderDevice`, `RenderSubmissionSink`?
+  - Resposta: usar `Platform`/`RuntimePlatform` para o agregado de servicos, `TestPlatform` para fixtures de teste, `RenderSubmissionSink` para submissao, `RenderBackend` para raster/present, e `Game2DFrameComposer` para o composer logico de Game2D. Evitar `Hardware` como nome arquitetural central.
+- [x] Onde os contratos da platform layer devem viver?
+  - Resposta: contratos/facades em `prometeu-hal`; implementacoes locais/test em `prometeu-drivers`; integracao e ownership operacional no `prometeu-system` e nos hosts.
+- [x] `Game2DFrameComposer` pertence ao runtime/logical side ou ao backend de render?
+  - Resposta: pertence ao logical side. O contrato deve ficar separado do backend renderizavel. A implementacao inicial pode migrar em fases, mas nao deve continuar sendo tratada como parte do hardware fisico.
+- [x] Qual e o criterio para remover `HardwareBridge`?
+  - Resposta: remover quando runtime, firmware, Hub, host desktop e testes tiverem migrado para facades explicitas. A remocao deve ser plano proprio ou criterio final de um plano de migracao, nao compatibilidade opcional.
+- [x] Aceitamos a quebra intencional de render imediato em `gfx2d`/`gfxui`?
+  - Resposta: sim. Syscalls devem bufferizar comandos; pixels devem mudar somente no fechamento/publicacao da submission. Testes que dependem de desenho imediato devem ser atualizados para o novo contrato.
+
+## Criterio para Encerrar
+
+Esta agenda pode virar decision quando tivermos:
+
+- sequencia clara de refatoracao para preparar a fronteira;
+- definicao das facades minimas;
+- estrategia para remover render imediato das syscalls;
+- decisao de remocao do `HardwareBridge` e estrategia de transicao, se houver;
+- estrategia de testes/fixtures;
+- criterio objetivo de pronto para iniciar `AGD-0043`.
+
+## Discussion
+
+- 2026-06-06: Agenda reescopada. A `DSC-0042` passa a ter duas agendas: esta para preparacao da fronteira host/hardware/render, e `AGD-0043` para o worker real.
+- 2026-06-06: Direcao levantada: `Hardware` deve ser uma abstracao/contrato implementado pelo host, nao um objeto concreto owned pelo runtime que cruza a fronteira do worker.
+- 2026-06-06: Avaliacao inicial de impacto: mudanca media/alta, mas fatiavel. O acoplamento principal esta em `HardwareBridge`, `HostContext`, syscalls de `dispatch`, firmware, Hub, host desktop e testes.
+- 2026-06-06: Reformulacao de objetivo: a intencao inicial era expor `Hardware` como interface consumida pelo runtime e implementada pelo host. Com a evolucao do sistema, isso pode estar limitado demais. O novo objetivo e reformular o runtime para um padrao mais proximo de uma plataforma handheld: runtime/OS como dono de lifecycle, scheduling, recursos e contratos; host/board support package como implementacao de dispositivos; render/audio/input/assets expostos por facades separadas e testaveis, nao por uma unica abstracao monolitica de hardware.
+- 2026-06-06: Direcao cravada: `HardwareBridge` nao deve ser preservado como compatibilidade. No estado final da reformulacao ele deve ser completamente eliminado, substituido por servicos/facades explicitos de platform layer.
+- 2026-06-06: Perguntas abertas respondidas: transicao por adapters/accessors temporarios, `RenderSubmissionSink` owned, erro tipado minimo ja na preparacao, primeiros testes em `gfx2d.clear`/`gfx2d.draw_text`, composer no logical side, fixtures via `TestPlatform`, e nomes preferidos `Platform`/`RuntimePlatform`, `RenderSubmissionSink`, `RenderBackend`, `Game2DFrameComposer`.
+- 2026-06-06: Escopo confirmado: render pode migrar primeiro, mas a migracao deve cobrir todos os dominios atualmente presos ao `HardwareBridge`. O objetivo final inclui a remocao completa do `HardwareBridge`, nao apenas reduzir seu uso no render.
+- 2026-06-06: Pontos adicionais aceitos: facades em `prometeu-hal`, implementacoes local/test em `prometeu-drivers`, integracao em `prometeu-system`/hosts; `Game2DFrameComposer` no logical side; `HardwareBridge` removido apos migracao completa dos callers; e quebra intencional do desenho imediato das syscalls `gfx2d`/`gfxui`.
+
+## Resolution
+
+`AGD-0042` resolve que o destino arquitetural nao e uma interface monolitica `HardwareBridge` implementada pelo host. O destino e uma platform layer composta por servicos/facades explicitos, com contratos em `prometeu-hal`, implementacoes local/test em `prometeu-drivers`, e integracao operacional em `prometeu-system` e nos hosts.
+
+`HardwareBridge` pode existir apenas como scaffold temporario de migracao. Ele deve ser completamente eliminado ao final, sem compatibilidade permanente. A migracao pode comecar por render, mas deve cobrir todos os dominios atualmente presos ao bridge: render, composer/frame, audio, input/touch, assets/storage, clock/pacing e telemetry quando aplicavel.
+
+O primeiro corte deve preparar o caminho do render worker sem implementa-lo ainda: introduzir `RenderSubmissionSink` owned com erro tipado minimo, remover desenho imediato das syscalls `gfx2d`/`gfxui`, mover `Game2DFrameComposer` para o logical side/runtime service, e substituir fixtures baseadas em `Hardware::new()` por `TestPlatform`.
+
+Esta agenda estara pronta para decision quando a decision puder definir a sequencia de migracao e os criterios de remocao final do `HardwareBridge` sem reabrir o contrato de render worker da `DSC-0040`.

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

@@ -1,172 +0,0 @@
----
-id: AGD-0042
-ticket: real-render-worker-establishment
-title: Real Render Worker Establishment
-status: open
-created: 2026-06-06
-resolved:
-decision:
-tags: [runtime, renderer, worker, concurrency, host, hal, architecture]
----
-
-## Contexto
-
-`DEC-0031` fechou a arquitetura base da fronteira VM/render: submissions fechadas, handoff single-slot latest-wins, pacing por `FrameScheduler`, politica explicita por `AppMode`, ownership/epoch e telemetria.
-
-A implementacao atual ja tem a base local/sincrona e um `LocalRenderWorker` cooperativo por capability flag. Isso valida o roteamento e a politica, mas ainda nao estabelece um worker real em outra thread/core. O proximo passo arquitetural e transformar esse prototipo em uma unidade de execucao real sem reabrir a decisao base.
-
-Esta agenda existe para discutir somente o estabelecimento do worker real. Ela nao deve redecidir `gfx2d` como overlay, o packet boundary, AppMode policy, ou latest-wins; esses pontos pertencem a `DEC-0031`.
-
-## Problema
-
-Um worker real precisa cruzar fronteiras que o prototipo local ainda evita:
-
-- ownership e lifetime de recursos compartilhados entre VM/logical core e render worker;
-- como o worker recebe, consome, rasteriza e apresenta submissions sem `&mut Hardware`, `&mut Gfx`, `FrameComposer` vivo ou estado mutavel da VM;
-- como o viewport cache/read model fica seguro e barato;
-- como shutdown, stop token, current work e stale owner funcionam quando ha trabalho realmente em voo;
-- onde fica o present loop e se ele roda a 60Hz independentemente da VM;
-- como erros de render/present deixam de ser apenas panic containment e viram resultado tipado;
-- como host desktop, hardware proprio, outro core, DMA ou coprocessador mapeiam para o mesmo contrato.
-
-## Pontos Criticos
-
-### 1. Ownership do worker
-
-Precisamos decidir se o worker real pertence ao runtime, ao host, a HAL, ou a uma camada hibrida. `DEC-0031` diz que host/HAL fornece capability concreta, mas `RenderManager` coordena contrato. Falta definir o boundary operacional.
-
-### 2. Surface e backend renderizavel
-
-O worker nao pode receber `&mut Hardware` ou `&mut Gfx` da VM thread. Precisamos de um objeto/capability renderizavel que seja owned pelo worker ou mediado por host.
-
-### 3. Recursos read-only e viewport cache
-
-Glyph/scene banks ja tem boundary read-only inicial. O viewport cache ainda precisa de um modelo concreto: snapshot, `Arc` read-only, double-buffer cache, cache materializado por frame, ou service proprietario.
-
-### 4. Current work e cancelamento
-
-O `RenderManager` ja descarta pending e rejeita stale epoch antes de present. Com worker real, uma submission pode estar em rasterizacao. Precisamos definir stop token, epoch check antes de present, bounded join e descarte de current work.
-
-### 5. Present loop e frame repeat
-
-Hoje repeated present e telemetria/hook. Um worker real provavelmente precisa de loop de present/display cadence. Falta decidir se o worker apresenta a 60Hz, se o host faz scanout/repeat, e como isso conversa com `FrameScheduler`.
-
-### 6. Erros tipados
-
-`RenderSurface` hoje e infalivel e panic containment vira `PresentFailed`. Para worker real, render/present deveria retornar erro tipado, distinguindo falha recuperavel, backend lost, surface lost, panic, shutdown e stale discard.
-
-### 7. Testabilidade
-
-Precisamos de testes que provem thread boundary, latest-wins sob atraso real, shutdown com current work em voo, stale epoch durante rasterizacao, repeat do ultimo frame e ausencia de bloqueio da VM.
-
-## Opcoes
-
-### Opcao A - Worker real dentro do runtime
-
-**Abordagem:** `RenderManager` ou um novo `RenderWorkerRuntime` cria e gerencia uma thread de render, canais/slots, stop token e lifecycle.
-
-**Pros:**
-- contrato fica perto de `RenderManager`;
-- facil testar com runtime puro;
-- menos dependencia de host desktop.
-
-**Contras:**
-- risco de runtime assumir detalhes de surface/window que pertencem ao host;
-- pode ficar ruim para hardware proprio, DMA ou coprocessador;
-- exige abstrair muito bem o backend renderizavel.
-
-**Manutenibilidade:** boa se o backend for uma trait pequena e owned pelo worker; ruim se vazar `Hardware`/`Gfx` vivo.
-
-### Opcao B - Worker real como responsabilidade do host
-
-**Abordagem:** runtime fecha submissions e handoff; host implementa thread/core/present loop usando uma capability HAL/host.
-
-**Pros:**
-- encaixa melhor desktop windowing, swapchain, surface lost e display cadence;
-- facilita mapeamento para plataformas diferentes;
-- runtime continua sem detalhe de thread/window.
-
-**Contras:**
-- testes de contrato podem ficar mais integrados e menos unitarios;
-- risco de cada host reinterpretar o contrato;
-- `RenderManager` precisa expor hooks suficientes sem virar passivo demais.
-
-**Manutenibilidade:** boa para plataformas diversas, desde que exista uma suite de contrato obrigatoria.
-
-### Opcao C - Worker como HAL/backend owned, coordenado pelo runtime
-
-**Abordagem:** runtime possui `RenderManager` e policy; HAL/host fornece um `RenderBackend`/`RenderWorkerBackend` owned e thread-safe. Um `RenderWorkerController` conecta handoff, stop token, epoch e telemetry.
-
-**Pros:**
-- separa contrato runtime de implementacao de host;
-- permite worker thread no desktop e outro core/DMA em hardware;
-- cria ponto unico para testes de contrato;
-- evita passar `&mut Hardware` ou `&mut Gfx` pela fronteira.
-
-**Contras:**
-- mais desenho inicial;
-- exige definir traits novas com cuidado;
-- pode ser excessivo se o primeiro worker real for apenas desktop.
-
-**Manutenibilidade:** melhor direcao se quisermos preservar portabilidade e nao acoplar runtime a winit/surface.
-
-### Opcao D - Adiar worker real e manter prototipo local
-
-**Abordagem:** nao implementar worker real agora; apenas fortalecer testes/spec e manter `LocalRenderWorker`.
-
-**Pros:**
-- menor risco imediato;
-- evita mexer em host/surface antes da necessidade real.
-
-**Contras:**
-- nao valida thread/core real;
-- deixa lacunas de Send/Sync, shutdown current work e present cadence;
-- pode mascarar problemas de ownership ate tarde.
-
-**Manutenibilidade:** aceitavel por curto prazo, fraca se a demanda agora e paralelismo real.
-
-## Sugestao / Recomendacao
-
-Recomendo seguir pela **Opcao C - Worker como HAL/backend owned, coordenado pelo runtime**.
-
-O desenho deve manter `RenderManager` como dono de policy, epoch, handoff e telemetry, mas introduzir uma camada operacional para worker real com:
-
-- backend/render surface owned pelo worker ou pelo host;
-- handoff single-slot sem bloquear VM;
-- stop token e bounded shutdown;
-- check de epoch/owner antes de present;
-- erro tipado para render/present;
-- present cadence explicita, com repeat do ultimo frame quando nao houver submission nova;
-- testes de contrato que rodem sem janela nativa sempre que possivel.
-
-Essa recomendacao preserva `DEC-0031` e evita transformar o runtime puro em dono de detalhes de window/swapchain.
-
-## Perguntas em Aberto
-
-- [ ] O primeiro worker real deve nascer no host desktop/winit ou em uma abstracao runtime/HAL testavel sem janela?
-- [ ] Qual trait substitui `RenderSurface::consume_submission(&RenderSubmission) -> ()` para erro tipado?
-- [ ] O worker owns `Gfx`/framebuffer, ou `Gfx` continua em `Hardware` e precisa ser dividido?
-- [ ] Como o viewport cache sera exposto ao worker: snapshot por frame, `Arc` read-only, double-buffer, ou service proprietario?
-- [ ] Quem roda o present loop de 60Hz: worker, host event loop, ou uma autoridade de display separada?
-- [ ] Como testar current work em voo sem depender de sleeps/flakiness?
-- [ ] Como mapear shutdown: stop accepting, discard pending, cancel current, join bounded, preserve last surface?
-- [ ] Quais tipos precisam de prova `Send + Sync` antes do primeiro worker real?
-- [ ] Shell continua fora do worker no primeiro passo, ou devemos provar explicitamente que capability Game nao afeta Shell?
-
-## Criterio para Encerrar
-
-Esta agenda pode virar decision quando tivermos uma resposta clara para:
-
-- ownership/layer responsavel pelo worker real;
-- trait/backend de render/present e modelo de erro;
-- modelo de recurso read-only, especialmente viewport cache;
-- protocolo de shutdown/current work;
-- present cadence/repeat;
-- plano de testes para thread/core real;
-- escopo do primeiro worker real, incluindo o que fica explicitamente fora.
-
-## Discussion
-
-- 2026-06-06: Agenda criada apos a execucao de `DSC-0040`, que fechou a arquitetura base mas deixou o worker real como etapa futura deliberada.
-
-## Resolution

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

@@ -0,0 +1,153 @@
+---
+id: AGD-0043
+ticket: real-render-worker-establishment
+title: Real Render Worker Establishment
+status: open
+created: 2026-06-06
+resolved:
+decision:
+tags: [runtime, renderer, worker, concurrency, host, hal, architecture]
+---
+
+## Contexto
+
+`DEC-0031` definiu o contrato arquitetural da fronteira VM/render. `AGD-0042` prepara a fronteira host/hardware/render para que `Hardware` deixe de ser um objeto concreto atravessando o worker e passe a ser contrato/facades implementadas pelo host.
+
+Esta agenda discute a implementacao do worker real propriamente dito, assumindo que a preparacao da fronteira foi ou sera resolvida antes da execucao.
+
+## Problema
+
+O `LocalRenderWorker` atual e cooperativo/local. Ele prova o roteamento de policy, mas nao prova:
+
+- thread/core real;
+- ownership do backend renderizavel;
+- present loop;
+- stop token para current work;
+- bounded shutdown/join;
+- stale epoch durante rasterizacao;
+- erro tipado de render/present;
+- repeat real do ultimo frame valido;
+- ausencia de bloqueio da VM sob atraso do render.
+
+## Pontos Criticos
+
+### 1. Ownership e lifecycle do worker
+
+Precisamos decidir quem cria, inicia, para e reinicia o worker: runtime controller, host/HAL, ou ambos em contrato dividido.
+
+### 2. Handoff real
+
+O single-slot latest-wins ja existe como abstracao local. O worker real precisa de uma implementacao thread-safe, sem fila crescente e sem bloquear a VM.
+
+### 3. Backend renderizavel
+
+O worker deve owns um backend minimo ou receber capability host-owned. Esse backend deve consumir `RenderSubmission`, resolver recursos read-only e produzir/presentar frame sem `&mut Hardware`.
+
+### 4. Present cadence
+
+Precisamos decidir se o worker roda a 60Hz, se o host event loop dirige present, ou se ha uma autoridade separada de display cadence. Repeated present deve virar comportamento real, nao apenas hook.
+
+### 5. Shutdown/current work
+
+Quando houver uma submission em rasterizacao, shutdown e owner transition precisam impedir present obsoleto e terminar em tempo bounded.
+
+### 6. Error model
+
+Precisamos trocar o modelo infalivel/panic containment por erro tipado para render/present/worker failure.
+
+### 7. Testes de concorrencia
+
+Precisamos provar o contrato sem depender de janela nativa nem sleeps frageis.
+
+## Opcoes
+
+### Opcao A - Worker thread no runtime com backend mockavel
+
+**Abordagem:** runtime cria um worker thread generico que recebe um backend implementando trait testavel.
+
+**Pros:**
+- testes de contrato mais diretos;
+- menor dependencia do host desktop.
+
+**Contras:**
+- runtime passa a owns detalhes de thread;
+- precisa cuidado para nao absorver politica de host/window.
+
+**Manutenibilidade:** boa se o backend for limpo; ruim se virar acoplamento de host dentro do runtime.
+
+### Opcao B - Worker thread no host desktop primeiro
+
+**Abordagem:** implementar o primeiro worker no host winit/pixels e adaptar o runtime a submit/policy.
+
+**Pros:**
+- valida o caso real visual;
+- encaixa com surface/present/winit.
+
+**Contras:**
+- mais dificil testar sem janela;
+- risco de contrato ficar host-specific;
+- portabilidade fica menos comprovada.
+
+**Manutenibilidade:** boa para desktop, menos boa para hardware proprio.
+
+### Opcao C - Worker controller runtime + backend host/HAL
+
+**Abordagem:** criar um controller de worker que implementa handoff, stop token, epoch check e telemetry; o backend concreto vem de host/HAL e pode ser mockado em testes.
+
+**Pros:**
+- separa contrato de backend;
+- testavel sem janela;
+- mapeia para thread desktop, outro core ou fallback;
+- preserva `RenderManager` como coordenador.
+
+**Contras:**
+- desenho inicial mais exigente;
+- depende da preparacao da `AGD-0042`.
+
+**Manutenibilidade:** melhor opcao se queremos worker real sem amarrar a winit.
+
+## Sugestao / Recomendacao
+
+Recomendo a **Opcao C - Worker controller runtime + backend host/HAL**.
+
+O primeiro worker real deveria:
+
+- consumir um handoff thread-safe single-slot;
+- ter stop token e shutdown bounded;
+- checar ownership/epoch antes de present;
+- expor erros tipados;
+- repetir o ultimo frame valido em cadence definida;
+- sincronizar telemetry sem alterar semantica da VM;
+- ter backend fake/mocked para testes de concorrencia.
+
+O host desktop pode ser a primeira integracao concreta, mas nao deve ser o unico lugar onde o contrato e testado.
+
+## Perguntas em Aberto
+
+- [ ] O worker controller vive em `prometeu-system`, `prometeu-hal`, `prometeu-drivers`, ou host?
+- [ ] O handoff thread-safe sera `Mutex<Option<...>>`, canal bounded, atomic slot, ou estrutura propria?
+- [ ] Como modelar current work para shutdown e stale owner?
+- [ ] Quem chama present: worker, host event loop, ou display cadence service?
+- [ ] Como o worker recebe recursos read-only preparados na `AGD-0042`?
+- [ ] Qual erro tipado minimo precisamos no primeiro worker?
+- [ ] Como provar que a VM nao bloqueia quando o worker atrasa?
+- [ ] Qual sera o primeiro backend real: desktop `Gfx`/pixels, framebuffer local, ou fake backend?
+
+## Criterio para Encerrar
+
+Esta agenda pode virar decision quando tivermos:
+
+- local/camada do worker controller;
+- estrutura thread-safe de handoff;
+- trait/backend de render/present;
+- present cadence/repeat;
+- shutdown/current work;
+- error model;
+- test matrix de concorrencia;
+- escopo do primeiro worker real.
+
+## Discussion
+
+- 2026-06-06: Agenda criada dentro da `DSC-0042` para separar worker real da preparacao de fronteira discutida em `AGD-0042`.
+
+## Resolution

discussion/workflow/decisions/DEC-0032-platform-layer-and-hardwarebridge-elimination.md

@@ -0,0 +1,198 @@
+---
+id: DEC-0032
+ticket: real-render-worker-establishment
+title: Platform Layer and HardwareBridge Elimination
+status: accepted
+created: 2026-06-06
+accepted:
+agenda: AGD-0042
+plans: [PLN-0098, PLN-0099, PLN-0100, PLN-0101, PLN-0102, PLN-0103, PLN-0104, PLN-0105, PLN-0106, PLN-0107, PLN-0108, PLN-0109]
+tags: [runtime, platform, hardware, host, hal, renderer, architecture]
+---
+
+## Status
+
+Decision draft emitted from accepted agenda `AGD-0042`.
+
+This decision is ready for review. Once accepted, it becomes the normative contract for plans that prepare Prometeu's platform layer before the real render worker work in `AGD-0043`.
+
+## Contexto
+
+`DEC-0031` established the VM/render boundary: closed render submissions, single-slot handoff, frame pacing, AppMode policy, ownership epoch, and render telemetry.
+
+The current implementation still depends on `HardwareBridge`, a monolithic trait that exposes render, composer, `Gfx`, audio, input, touch, assets, frame begin, and presentation through one runtime-facing object. That bridge was useful as an early abstraction, but it is no longer sufficient for a high-quality handheld-style runtime.
+
+The goal is no longer to make `HardwareBridge` the permanent host-implemented interface. The goal is to replace it with an explicit platform layer made of domain services/facades. Runtime code should depend on stable platform contracts; host/board code should provide concrete implementations.
+
+This decision prepares the platform boundary. It does not implement the real render worker. Worker establishment remains scoped to `AGD-0043`.
+
+## Decisao
+
+Prometeu SHALL replace the monolithic `HardwareBridge` model with a platform layer composed of explicit domain services/facades.
+
+`HardwareBridge` SHALL NOT survive as a final compatibility contract. It MAY exist only as temporary migration scaffold. The end state MUST remove `HardwareBridge` and all production/runtime dependencies on it.
+
+The migration MAY begin with render, because render blocks the real worker path, but it MUST NOT stop there. The migration MUST cover every domain currently coupled through `HardwareBridge`: render, Game2D frame composition, audio, input/touch, assets/storage, clock/pacing, and telemetry where applicable.
+
+The first implementation wave SHALL prepare render-worker-safe boundaries without introducing the real worker yet:
+
+- introduce an owned `RenderSubmissionSink`;
+- introduce minimal typed render submission errors;
+- remove immediate framebuffer writes from `gfx2d` and `gfxui` syscalls;
+- move Game2D frame composition into a logical-side `Game2DFrameComposer` service/facade;
+- replace test fixtures centered on `Hardware::new()` with `TestPlatform`.
+
+## Rationale
+
+A handheld-quality runtime needs clear separation between platform policy and board/host implementation.
+
+The runtime/OS owns:
+
+- lifecycle and AppMode policy;
+- VM execution;
+- frame pacing;
+- render ownership and handoff;
+- logical frame composition;
+- command buffers;
+- resource visibility policy;
+- telemetry semantics.
+
+The host/board implementation owns:
+
+- window/surface or physical framebuffer;
+- concrete present implementation;
+- physical input events;
+- audio backend;
+- IO/storage backend;
+- host threads, cores, DMA, or coprocessor mapping.
+
+A single `HardwareBridge` encourages accidental coupling. It lets VM syscalls, firmware, Hub, renderer, audio, input, assets, and present share the same mutable object. That model makes it too easy for future worker work to pass `&mut Hardware`, `&mut Gfx`, or live `FrameComposer` state across the render boundary.
+
+Explicit facades make dependencies visible and testable. They also let each domain evolve with the lifecycle, threading, and error semantics it actually needs.
+
+## Invariantes / Contrato
+
+### 1. No final `HardwareBridge`
+
+`HardwareBridge` MUST be removed from the final architecture of this migration.
+
+During migration, code MAY use adapters or temporary accessors to bridge old and new APIs. Those adapters MUST be treated as implementation scaffolding, not as new public/runtime architecture.
+
+`HardwareBridge` MUST NOT inherit the new facades as a way to preserve itself as a permanent aggregate contract.
+
+### 2. Facades live at the right layer
+
+Contracts/facades SHALL live in `prometeu-hal`.
+
+Local/default and test implementations SHALL live in `prometeu-drivers` unless a domain has a stronger existing home.
+
+Operational integration and ownership orchestration SHALL live in `prometeu-system` and host crates.
+
+### 3. Render submission is owned
+
+`RenderSubmissionSink` SHALL accept owned `RenderSubmission` values.
+
+The owned contract is required because asynchronous handoff transfers ownership to a consumer. Local/synchronous paths MAY adapt internally, but the facade MUST be compatible with future worker handoff.
+
+### 4. Render submission errors are typed
+
+The preparation work SHALL introduce a minimal typed error surface for submission/render publication.
+
+The API MUST NOT be born infallible if the next worker stage will immediately need typed failure. Panic containment may remain as a safety net, but normal backend failure should have an explicit result type.
+
+### 5. `gfx2d` and `gfxui` syscalls buffer commands only
+
+`gfx2d.*` and `gfxui.*` syscalls MUST NOT mutate the framebuffer immediately.
+
+Those syscalls SHALL record commands into the appropriate logical command buffer. Pixels change only when a closed render submission is consumed/published by the render path.
+
+The first regression tests MUST include `gfx2d.clear` and `gfx2d.draw_text` proving that syscalls buffer commands and presentation happens only after frame closure/publication.
+
+### 6. Game2D composition is logical-side state
+
+`bind_scene`, `set_camera`, `emit_sprite`, and `close_game2d_packet` are logical frame preparation, not physical backend behavior.
+
+The migration SHALL introduce `Game2DFrameComposer` as the logical-side service/facade for Game2D frame composition. Its implementation may move in phases, but it MUST NOT remain conceptually part of a physical render backend.
+
+### 7. Tests use `TestPlatform`
+
+Tests that need a full local platform fixture SHALL migrate toward `TestPlatform`.
+
+`TestPlatform` SHOULD keep tests ergonomic while making dependencies explicit through the new facades. It MUST NOT preserve `HardwareBridge` as hidden compatibility.
+
+### 8. Render may migrate first, but the migration is complete only when every domain is moved
+
+The render path MAY be migrated first.
+
+The architecture is not complete until audio, input/touch, assets/storage, clock/pacing, telemetry where applicable, firmware, Hub, runtime, host desktop, and tests no longer depend on `HardwareBridge`.
+
+## Impactos
+
+### Spec
+
+Specs need to describe the platform layer as explicit services/facades rather than a monolithic hardware bridge.
+
+Render specifications must state that `gfx2d`/`gfxui` syscalls buffer commands and that framebuffer mutation occurs through render submission consumption/publication.
+
+### Runtime
+
+Runtime code must stop depending on `&mut dyn HardwareBridge`.
+
+VM dispatch must stop using `hw.gfx_mut()` for immediate drawing. Runtime frame closure must depend on logical services such as `Game2DFrameComposer` and publication facades such as `RenderSubmissionSink`.
+
+### HAL
+
+`prometeu-hal` must define the stable contracts for the platform layer.
+
+At minimum, the first wave needs `RenderSubmissionSink` and its typed error. Later waves should define or refine composer, audio, input/touch, assets/storage, clock/pacing, and telemetry facades.
+
+### Drivers
+
+`prometeu-drivers` should provide local/default implementations and `TestPlatform`.
+
+The existing `prometeu_drivers::Hardware` may be used as a migration source, but it must not remain the final runtime-facing architecture.
+
+### Host
+
+Host crates must move from directly owning and exposing `Hardware` as the runtime's universal bridge toward implementing platform services.
+
+The desktop host may remain the first concrete integration, but the contracts must remain portable to handheld board support, emulator, web, or coprocessor/DMA implementations.
+
+### Firmware / Hub
+
+Firmware and Hub must migrate away from `publish_render_submission` on `HardwareBridge` and toward explicit render submission publication/platform services.
+
+### Tests
+
+Tests must migrate from direct `Hardware::new()` dependence to `TestPlatform` or narrower facade-specific fixtures.
+
+Tests must be updated where they assume immediate framebuffer mutation from `gfx2d`/`gfxui` syscalls.
+
+## Referencias
+
+- `AGD-0042`: Host Hardware and Render Boundary Preparation.
+- `AGD-0043`: Real Render Worker Establishment.
+- `DEC-0031`: VM and Render Parallel Execution Boundary.
+- `LSN-0048`: Render Workers Need a Closed Packet Contract.
+
+## Propagacao Necessaria
+
+Create implementation plans before editing specs or code.
+
+Recommended plan sequence:
+
+1. introduce `RenderSubmissionSink` and minimal typed submit error;
+2. migrate local render publication away from `HardwareBridge`;
+3. remove immediate framebuffer writes from `gfx2d`/`gfxui` syscalls and update tests;
+4. introduce `Game2DFrameComposer` as logical-side service/facade;
+5. introduce `RuntimePlatform`/`Platform` and `TestPlatform`;
+6. migrate firmware, Hub, runtime, host desktop, and tests to explicit facades;
+7. migrate remaining domains: audio, input/touch, assets/storage, clock/pacing, telemetry as needed;
+8. remove `HardwareBridge`;
+9. update specs and lessons after implementation publishes the new structure.
+
+`AGD-0043` SHOULD NOT move to implementation until this decision has produced enough platform boundary work that a render worker can be built without `&mut Hardware`, `&mut Gfx`, live `FrameComposer`, or mutable VM state crossing into the worker.
+
+## Revision Log
+
+- 2026-06-06: Initial decision draft generated from accepted `AGD-0042`.

discussion/workflow/plans/PLN-0098-define-platform-facade-contracts.md

@@ -0,0 +1,81 @@
+---
+id: PLN-0098
+ticket: real-render-worker-establishment
+title: Define Platform Facade Contracts
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [runtime, platform, hal, facades]
+---
+
+## Objective
+
+Define the first `prometeu-hal` platform facade contracts that will replace the monolithic `HardwareBridge` model.
+
+## Background
+
+`DEC-0032` requires Prometeu to move from one runtime-facing `HardwareBridge` to explicit platform services/facades. This first plan creates the stable contract surface without migrating callers yet.
+
+## Scope
+
+### Included
+
+- Add facade modules/types in `crates/console/prometeu-hal`.
+- Define names and module ownership for `RuntimePlatform`, `RenderSubmissionSink`, `RenderBackend`, `Game2DFrameComposer`, and `TestPlatform` integration points.
+- Add minimal documentation explaining that `HardwareBridge` is legacy migration scaffold.
+
+### Excluded
+
+- Do not remove `HardwareBridge`.
+- Do not migrate syscalls, firmware, Hub, host, or tests yet.
+- Do not implement the real render worker.
+
+## Execution Steps
+
+### Step 1 - Add platform facade module
+
+**What:** Create a `platform` module in `prometeu-hal`.
+**How:** Add facade trait declarations and re-exports without changing existing call sites.
+**File(s):** `crates/console/prometeu-hal/src/platform.rs`, `crates/console/prometeu-hal/src/lib.rs`.
+
+### Step 2 - Declare domain facade boundaries
+
+**What:** Define initial placeholder traits for render submission, render backend, Game2D composer, audio, input/touch, assets/storage, clock/pacing, and telemetry.
+**How:** Keep non-render traits minimal or marker-like when detailed APIs are not yet migrated.
+**File(s):** `crates/console/prometeu-hal/src/platform.rs`.
+
+### Step 3 - Document migration status
+
+**What:** Mark `HardwareBridge` as legacy scaffold.
+**How:** Add module-level comments stating it must be removed by later plans.
+**File(s):** `crates/console/prometeu-hal/src/hardware_bridge.rs`.
+
+## Test Requirements
+
+### Unit Tests
+
+- Compile-only tests or trait object assertions where useful.
+
+### Integration Tests
+
+- Existing HAL/system/driver tests must continue to pass.
+
+### Manual Verification
+
+- Confirm `HardwareBridge` has no new dependencies on the platform facades.
+
+## Acceptance Criteria
+
+- [ ] Platform facade module exists in `prometeu-hal`.
+- [ ] `HardwareBridge` is explicitly documented as migration scaffold.
+- [ ] No runtime behavior changes.
+- [ ] Existing tests pass.
+
+## Dependencies
+
+- `DEC-0032`.
+
+## Risks
+
+- Introducing too much API too early can freeze poor names. Keep this plan narrow.

discussion/workflow/plans/PLN-0099-introduce-owned-render-submission-sink.md

@@ -0,0 +1,82 @@
+---
+id: PLN-0099
+ticket: real-render-worker-establishment
+title: Introduce Owned RenderSubmissionSink
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [runtime, renderer, hal, errors]
+---
+
+## Objective
+
+Introduce an owned `RenderSubmissionSink` facade with minimal typed submission errors.
+
+## Background
+
+`DEC-0032` requires render publication to move away from `HardwareBridge` and to accept owned `RenderSubmission` values so the contract is compatible with async handoff.
+
+## Scope
+
+### Included
+
+- Define `RenderSubmissionSink`.
+- Define minimal `RenderSubmitError`.
+- Implement the facade for the current local driver path.
+
+### Excluded
+
+- Do not migrate all publication call sites yet.
+- Do not spawn a render worker.
+- Do not remove `HardwareBridge::publish_render_submission`.
+
+## Execution Steps
+
+### Step 1 - Define sink and error
+
+**What:** Add `RenderSubmissionSink` and `RenderSubmitError`.
+**How:** `submit_render_submission(&mut self, submission: RenderSubmission) -> Result<(), RenderSubmitError>`.
+**File(s):** `crates/console/prometeu-hal/src/platform.rs` or a render-specific HAL module.
+
+### Step 2 - Implement local sink
+
+**What:** Implement the sink for the current local driver implementation.
+**How:** Adapt owned submission to the existing local `Hardware` publication path.
+**File(s):** `crates/console/prometeu-drivers/src/hardware.rs`.
+
+### Step 3 - Add tests
+
+**What:** Prove owned submission is consumed by the local sink.
+**How:** Add driver test using `RenderSubmission::game2d` and `RenderSubmission::shell_ui`.
+**File(s):** `crates/console/prometeu-drivers/src/hardware.rs` or platform test module.
+
+## Test Requirements
+
+### Unit Tests
+
+- Local sink accepts owned Game2D and ShellUi submissions.
+- Error type is constructible and debuggable.
+
+### Integration Tests
+
+- `cargo test -p prometeu-hal -p prometeu-drivers`.
+
+### Manual Verification
+
+- Confirm the sink does not take `&RenderSubmission`.
+
+## Acceptance Criteria
+
+- [ ] `RenderSubmissionSink` takes owned `RenderSubmission`.
+- [ ] Minimal typed error exists.
+- [ ] Local driver implements the sink.
+- [ ] Existing publication behavior remains intact.
+
+## Dependencies
+
+- `PLN-0098`.
+
+## Risks
+
+- Local paths may still need temporary borrow adaptation. Keep it internal to the implementation.

discussion/workflow/plans/PLN-0100-migrate-local-render-publication-to-sink.md

@@ -0,0 +1,80 @@
+---
+id: PLN-0100
+ticket: real-render-worker-establishment
+title: Migrate Local Render Publication to RenderSubmissionSink
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [runtime, renderer, platform]
+---
+
+## Objective
+
+Move local render publication call sites from `HardwareBridge::publish_render_submission` to `RenderSubmissionSink`.
+
+## Background
+
+The sink must become the publication boundary before a real worker can replace the local path. Runtime, firmware, and Hub currently publish through the monolithic bridge.
+
+## Scope
+
+### Included
+
+- Runtime local render surface uses `RenderSubmissionSink`.
+- Firmware splash/crash publication uses the sink.
+- Hub Shell UI publication uses the sink or a temporary adapter.
+
+### Excluded
+
+- Do not remove `HardwareBridge`.
+- Do not migrate non-render domains.
+- Do not change command buffering semantics yet.
+
+## Execution Steps
+
+### Step 1 - Adapt runtime tick publication
+
+**What:** Replace `HardwareRenderSurface` dependency on `HardwareBridge::publish_render_submission`.
+**How:** Route submission through `RenderSubmissionSink`.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/tick.rs`.
+
+### Step 2 - Adapt firmware and Hub publication
+
+**What:** Stop direct calls to `hw.publish_render_submission`.
+**How:** Use the sink through explicit platform/render facade access or temporary adapter.
+**File(s):** `crates/console/prometeu-firmware/src/firmware_step_splash_screen.rs`, `crates/console/prometeu-firmware/src/firmware_step_crash_screen.rs`, `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs`.
+
+### Step 3 - Update tests
+
+**What:** Adjust tests that call `HardwareBridge::publish_render_submission`.
+**How:** Use `RenderSubmissionSink` where render publication is the target.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/tests.rs`, driver tests.
+
+## Test Requirements
+
+### Unit Tests
+
+- Existing render manager tests pass.
+
+### Integration Tests
+
+- `cargo test -p prometeu-system -p prometeu-firmware -p prometeu-drivers`.
+
+### Manual Verification
+
+- `rg "publish_render_submission" crates/console` shows only legacy implementation or intentionally unmigrated scaffold.
+
+## Acceptance Criteria
+
+- [ ] Runtime publication uses `RenderSubmissionSink`.
+- [ ] Firmware/Hub publication no longer depend directly on the monolithic bridge.
+- [ ] Tests pass.
+
+## Dependencies
+
+- `PLN-0099`.
+
+## Risks
+
+- Firmware code may need a small context shape change. Keep compatibility adapters temporary and explicit.

discussion/workflow/plans/PLN-0101-remove-immediate-gfx-syscall-rendering.md

@@ -0,0 +1,82 @@
+---
+id: PLN-0101
+ticket: real-render-worker-establishment
+title: Remove Immediate Gfx2D and GfxUI Syscall Rendering
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [runtime, gfx, syscalls, renderer]
+---
+
+## Objective
+
+Make `gfx2d.*` and `gfxui.*` syscalls buffer commands only, without mutating the framebuffer immediately.
+
+## Background
+
+`DEC-0032` requires framebuffer mutation to occur through render submission consumption/publication, not inside VM syscall dispatch. This is required before render can run independently.
+
+## Scope
+
+### Included
+
+- Remove `hw.gfx_mut().*` immediate draw calls from VM dispatch for `gfx2d` and `gfxui`.
+- Add regression tests for `gfx2d.clear` and `gfx2d.draw_text`.
+- Update tests that assumed immediate pixel mutation.
+
+### Excluded
+
+- Do not remove `GfxBridge`.
+- Do not migrate composer in this plan.
+- Do not implement worker.
+
+## Execution Steps
+
+### Step 1 - Remove immediate Game gfx writes
+
+**What:** Delete direct `hw.gfx_mut()` rendering in `Gfx*` syscall handlers.
+**How:** Keep command buffering into `gfx2d_commands`.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/dispatch.rs`.
+
+### Step 2 - Remove immediate Shell UI writes
+
+**What:** Delete direct `hw.gfx_mut()` rendering in `GfxUi*` syscall handlers.
+**How:** Keep command buffering into `gfxui_commands`.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/dispatch.rs`.
+
+### Step 3 - Add regression tests
+
+**What:** Prove syscalls do not affect pixels until publication.
+**How:** Tests for `gfx2d.clear` and `gfx2d.draw_text` should inspect command buffers and frame publication.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/tests.rs`.
+
+## Test Requirements
+
+### Unit Tests
+
+- `gfx2d.clear` buffers only.
+- `gfx2d.draw_text` buffers only.
+- Shell UI commands buffer only.
+
+### Integration Tests
+
+- Stress cartridge still renders after frame publication.
+
+### Manual Verification
+
+- `rg "gfx_mut\\(\\).*draw|gfx_mut\\(\\).*clear|gfx_mut\\(\\).*fill" dispatch.rs` returns no immediate render calls.
+
+## Acceptance Criteria
+
+- [ ] Gfx syscalls no longer mutate framebuffer immediately.
+- [ ] Pixels change only after render submission publication.
+- [ ] Tests updated to the new contract.
+
+## Dependencies
+
+- `PLN-0100`.
+
+## Risks
+
+- Debug workflows may have relied on immediate drawing. Tests must make the new frame boundary explicit.

discussion/workflow/plans/PLN-0102-introduce-game2d-frame-composer-service.md

@@ -0,0 +1,82 @@
+---
+id: PLN-0102
+ticket: real-render-worker-establishment
+title: Introduce Game2DFrameComposer Logical Service
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [runtime, composer, game2d, platform]
+---
+
+## Objective
+
+Introduce `Game2DFrameComposer` as the logical-side service/facade for Game2D frame preparation.
+
+## Background
+
+`DEC-0032` states that `bind_scene`, `set_camera`, `emit_sprite`, and `close_game2d_packet` are logical frame preparation, not physical backend behavior.
+
+## Scope
+
+### Included
+
+- Define a `Game2DFrameComposer` facade.
+- Move or wrap existing `FrameComposer` behavior under logical-side naming.
+- Migrate composer syscalls to use the facade rather than generic hardware.
+
+### Excluded
+
+- Do not rewrite scene cache internals.
+- Do not move viewport cache across threads.
+- Do not implement worker.
+
+## Execution Steps
+
+### Step 1 - Define composer facade
+
+**What:** Add `Game2DFrameComposer` trait or service contract.
+**How:** Include `begin_frame`, `bind_scene`, `unbind_scene`, `set_camera`, `emit_sprite`, `close_game2d_packet`, and required read checks.
+**File(s):** `crates/console/prometeu-hal/src/platform.rs` or composer-specific HAL module.
+
+### Step 2 - Implement using current composer
+
+**What:** Make current local driver composer satisfy the new logical service.
+**How:** Reuse `FrameComposer` implementation under adapter/implementation.
+**File(s):** `crates/console/prometeu-drivers/src/frame_composer.rs`, `crates/console/prometeu-drivers/src/hardware.rs`.
+
+### Step 3 - Migrate composer syscalls
+
+**What:** Dispatch composer syscalls through `Game2DFrameComposer`.
+**How:** Remove dependency on `HardwareBridge` methods for composer.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/dispatch.rs`.
+
+## Test Requirements
+
+### Unit Tests
+
+- Composer facade closes packets equivalent to previous `FrameComposer`.
+- Invalid scene/bank behavior remains unchanged.
+
+### Integration Tests
+
+- Existing scene/composer runtime tests pass.
+
+### Manual Verification
+
+- Composer syscalls no longer require `&mut dyn HardwareBridge`.
+
+## Acceptance Criteria
+
+- [ ] `Game2DFrameComposer` exists as logical service/facade.
+- [ ] Composer syscalls route through it.
+- [ ] Existing Game2D scene rendering remains correct.
+
+## Dependencies
+
+- `PLN-0098`.
+- `PLN-0101`.
+
+## Risks
+
+- Scene cache ownership can be accidentally moved too early. Keep cache behavior local while changing the boundary.

discussion/workflow/plans/PLN-0103-introduce-runtime-platform-and-testplatform.md

@@ -0,0 +1,82 @@
+---
+id: PLN-0103
+ticket: real-render-worker-establishment
+title: Introduce RuntimePlatform and TestPlatform
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [runtime, platform, tests]
+---
+
+## Objective
+
+Introduce `RuntimePlatform`/`Platform` as the aggregate of explicit platform services, and `TestPlatform` as the default test fixture.
+
+## Background
+
+`DEC-0032` requires tests and runtime integration to depend on explicit facades rather than `Hardware::new()` and `HardwareBridge`.
+
+## Scope
+
+### Included
+
+- Define aggregate platform access shape.
+- Add `TestPlatform` in `prometeu-drivers`.
+- Start migrating representative VM runtime tests.
+
+### Excluded
+
+- Do not migrate all tests in this plan.
+- Do not remove `HardwareBridge`.
+- Do not migrate all host code.
+
+## Execution Steps
+
+### Step 1 - Define platform aggregate
+
+**What:** Add `RuntimePlatform` or `Platform` aggregate facade.
+**How:** Expose accessors for render sink, Game2D composer, audio, input/touch, assets/storage, clock/pacing, and telemetry placeholders.
+**File(s):** `crates/console/prometeu-hal/src/platform.rs`.
+
+### Step 2 - Add TestPlatform
+
+**What:** Provide ergonomic test fixture implementing the initial platform facades.
+**How:** Reuse current local driver components internally without exposing `HardwareBridge`.
+**File(s):** `crates/console/prometeu-drivers/src/test_platform.rs`, `crates/console/prometeu-drivers/src/lib.rs`.
+
+### Step 3 - Migrate representative tests
+
+**What:** Move a small set of runtime tests from `Hardware::new()` to `TestPlatform`.
+**How:** Choose tests covering render, composer, and asset surfaces.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/tests.rs`, asset/memcard test modules as appropriate.
+
+## Test Requirements
+
+### Unit Tests
+
+- `TestPlatform` initializes all required facades.
+
+### Integration Tests
+
+- Migrated runtime tests pass with `TestPlatform`.
+
+### Manual Verification
+
+- New tests do not import `prometeu_drivers::Hardware` directly.
+
+## Acceptance Criteria
+
+- [ ] `RuntimePlatform`/`Platform` aggregate exists.
+- [ ] `TestPlatform` exists and is used by representative tests.
+- [ ] Test ergonomics remain acceptable.
+
+## Dependencies
+
+- `PLN-0098`.
+- `PLN-0099`.
+- `PLN-0102`.
+
+## Risks
+
+- Overly broad aggregate can recreate `HardwareBridge`. Keep domain access explicit and named.

discussion/workflow/plans/PLN-0104-migrate-vm-runtime-hostcontext-to-platform.md

@@ -0,0 +1,79 @@
+---
+id: PLN-0104
+ticket: real-render-worker-establishment
+title: Migrate VM Runtime HostContext to Platform Services
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [runtime, vm, platform, hostcontext]
+---
+
+## Objective
+
+Change VM runtime execution from receiving `&mut dyn HardwareBridge` to receiving explicit platform services.
+
+## Background
+
+`HostContext` currently carries `Option<&mut dyn HardwareBridge>`. That shape lets every syscall see the entire bridge. `DEC-0032` requires explicit services instead.
+
+## Scope
+
+### Included
+
+- Introduce a platform-aware `HostContext` shape.
+- Migrate VM runtime tick/dispatch to use platform services.
+- Preserve VM tests and fault behavior.
+
+### Excluded
+
+- Do not migrate firmware/Hub in this plan.
+- Do not remove `HardwareBridge` yet.
+
+## Execution Steps
+
+### Step 1 - Add platform host context
+
+**What:** Extend or replace `HostContext` with platform-service access.
+**How:** Add methods for required VM syscall domains instead of `require_hw()`.
+**File(s):** `crates/console/prometeu-hal/src/host_context.rs`.
+
+### Step 2 - Migrate runtime tick
+
+**What:** Tick uses platform services for begin-frame, composer frame closure, render sink, audio clear, and telemetry reads.
+**How:** Replace direct bridge access with explicit facade calls.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/tick.rs`.
+
+### Step 3 - Migrate dispatch
+
+**What:** VM syscall dispatch uses explicit facade methods.
+**How:** Remove `ctx.require_hw()` as the central dispatch dependency.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/dispatch.rs`.
+
+## Test Requirements
+
+### Unit Tests
+
+- VM dispatch tests pass with platform context.
+
+### Integration Tests
+
+- `cargo test -p prometeu-system`.
+
+### Manual Verification
+
+- `rg "require_hw|HardwareBridge" vm_runtime` shows no production VM runtime dependency except temporary compatibility adapters explicitly marked.
+
+## Acceptance Criteria
+
+- [ ] VM runtime dispatch no longer depends on the monolithic bridge.
+- [ ] Tick uses explicit platform services.
+- [ ] Existing VM fault behavior remains unchanged.
+
+## Dependencies
+
+- `PLN-0103`.
+
+## Risks
+
+- `HostContext` is used in VM unit tests. Migration must keep no-hardware test contexts ergonomic.

discussion/workflow/plans/PLN-0105-migrate-firmware-and-hub-to-platform-services.md

@@ -0,0 +1,81 @@
+---
+id: PLN-0105
+ticket: real-render-worker-establishment
+title: Migrate Firmware and Hub to Platform Services
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [firmware, hub, platform, render]
+---
+
+## Objective
+
+Move firmware screens and Hub UI away from `HardwareBridge` and onto explicit platform services.
+
+## Background
+
+Firmware splash/crash and Hub currently receive `&mut dyn HardwareBridge` and publish Shell UI directly through it. `DEC-0032` requires migration to platform facades.
+
+## Scope
+
+### Included
+
+- Firmware context uses platform services.
+- Splash/crash screens publish via render sink.
+- Hub input/render uses input/render facades.
+
+### Excluded
+
+- Do not implement worker.
+- Do not change Hub UX or firmware state machine semantics.
+
+## Execution Steps
+
+### Step 1 - Update firmware context
+
+**What:** Replace `PrometeuContext` hardware bridge field with platform services.
+**How:** Expose only the services firmware needs: input, assets, render sink.
+**File(s):** `crates/console/prometeu-firmware/src/firmware/prometeu_context.rs`, `firmware.rs`.
+
+### Step 2 - Migrate firmware screens
+
+**What:** Splash and crash screens publish through `RenderSubmissionSink`.
+**How:** Build Shell UI packet and submit owned submission.
+**File(s):** `crates/console/prometeu-firmware/src/firmware_step_splash_screen.rs`, `firmware_step_crash_screen.rs`.
+
+### Step 3 - Migrate Hub
+
+**What:** Hub uses platform input/render services instead of `HardwareBridge`.
+**How:** Replace activation input and render publication dependencies.
+**File(s):** `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs`.
+
+## Test Requirements
+
+### Unit Tests
+
+- Firmware state tests pass.
+- Hub UI tests pass.
+
+### Integration Tests
+
+- `cargo test -p prometeu-firmware -p prometeu-system`.
+
+### Manual Verification
+
+- Firmware/Hub no longer call `publish_render_submission` on `HardwareBridge`.
+
+## Acceptance Criteria
+
+- [ ] Firmware context no longer exposes the monolithic bridge.
+- [ ] Splash/crash/Hub render via render sink.
+- [ ] Hub input uses platform/input facade.
+
+## Dependencies
+
+- `PLN-0103`.
+- `PLN-0104`.
+
+## Risks
+
+- Firmware code is lifecycle-sensitive. Keep behavior changes out of scope.

discussion/workflow/plans/PLN-0106-migrate-desktop-host-to-platform-services.md

@@ -0,0 +1,79 @@
+---
+id: PLN-0106
+ticket: real-render-worker-establishment
+title: Migrate Desktop Host to Platform Services
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [host, desktop, platform]
+---
+
+## Objective
+
+Move the desktop host from directly exposing `prometeu_drivers::Hardware` as the runtime bridge to owning a platform implementation.
+
+## Background
+
+The host currently creates `Hardware::new()` and passes it into firmware/runtime paths. `DEC-0032` requires hosts to implement platform services, not to expose a monolithic bridge.
+
+## Scope
+
+### Included
+
+- Introduce desktop/local platform ownership in the host.
+- Replace host usage of `Hardware::W/H` with platform display constants or framebuffer descriptor.
+- Keep the same visual/audio/input behavior.
+
+### Excluded
+
+- Do not implement render worker thread.
+- Do not change windowing library or presentation policy.
+
+## Execution Steps
+
+### Step 1 - Add host platform field
+
+**What:** Host runner owns a platform implementation rather than raw `Hardware`.
+**How:** Wrap current local driver implementation behind platform facades.
+**File(s):** `crates/host/prometeu-host-desktop-winit/src/runner.rs`.
+
+### Step 2 - Replace direct hardware constants
+
+**What:** Stop reading `Hardware::W/H` directly in host rendering/input.
+**How:** Use a framebuffer/display descriptor exposed by platform/render service.
+**File(s):** `crates/host/prometeu-host-desktop-winit/src/runner.rs`, `input.rs`.
+
+### Step 3 - Update debugger host setup
+
+**What:** Debugger paths instantiate platform fixture/implementation.
+**How:** Replace `Hardware::new()` in debugger setup.
+**File(s):** `crates/host/prometeu-host-desktop-winit/src/debugger.rs`.
+
+## Test Requirements
+
+### Unit Tests
+
+- Host crate tests compile.
+
+### Integration Tests
+
+- `cargo test -p prometeu-host-desktop-winit`.
+
+### Manual Verification
+
+- Desktop host still runs stress cartridge.
+
+## Acceptance Criteria
+
+- [ ] Desktop host owns platform services.
+- [ ] Host no longer treats `Hardware` as runtime bridge.
+- [ ] Display dimensions come from platform/render descriptor.
+
+## Dependencies
+
+- `PLN-0105`.
+
+## Risks
+
+- Desktop host mixes runtime and window concerns. Keep worker threading out of this plan.

discussion/workflow/plans/PLN-0107-migrate-remaining-platform-domains.md

@@ -0,0 +1,89 @@
+---
+id: PLN-0107
+ticket: real-render-worker-establishment
+title: Migrate Remaining Platform Domains
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [platform, audio, input, assets, clock, telemetry]
+---
+
+## Objective
+
+Migrate non-render domains out of `HardwareBridge` into explicit platform services.
+
+## Background
+
+`DEC-0032` permits render to migrate first but requires the full migration to cover audio, input/touch, assets/storage, clock/pacing, and telemetry where applicable.
+
+## Scope
+
+### Included
+
+- Audio service/facade migration.
+- Input/touch service/facade migration.
+- Assets/storage service/facade migration.
+- Clock/pacing and telemetry surface migration where currently coupled.
+
+### Excluded
+
+- Do not change domain semantics.
+- Do not implement async IO unless already supported by existing services.
+
+## Execution Steps
+
+### Step 1 - Migrate audio
+
+**What:** Replace `hw.audio()`/`hw.audio_mut()` production dependencies.
+**How:** Route through explicit audio platform service.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/dispatch.rs`, firmware/host integration files.
+
+### Step 2 - Migrate input and touch
+
+**What:** Replace `hw.pad()`/`hw.touch()` dependencies.
+**How:** Expose input snapshots through platform input service.
+**File(s):** `crates/console/prometeu-system`, `crates/console/prometeu-firmware`, host input modules.
+
+### Step 3 - Migrate assets/storage
+
+**What:** Replace `hw.assets()`/`hw.assets_mut()` dependencies.
+**How:** Route through asset/storage services while preserving commit and bank visibility semantics.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime`, `crates/console/prometeu-firmware`.
+
+### Step 4 - Migrate clock/pacing/telemetry coupling
+
+**What:** Move any platform-facing clock or telemetry coupling out of `HardwareBridge`.
+**How:** Use explicit runtime/platform services.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime`, HAL telemetry modules.
+
+## Test Requirements
+
+### Unit Tests
+
+- Audio/input/asset syscall tests pass.
+
+### Integration Tests
+
+- `cargo test -p prometeu-system -p prometeu-firmware -p prometeu-drivers`.
+
+### Manual Verification
+
+- `rg "audio_mut|pad_mut|touch_mut|assets_mut" crates/console` does not show production bridge dependencies.
+
+## Acceptance Criteria
+
+- [ ] Audio migrated to platform service.
+- [ ] Input/touch migrated to platform service.
+- [ ] Assets/storage migrated to platform service.
+- [ ] Clock/pacing/telemetry bridge coupling removed where applicable.
+
+## Dependencies
+
+- `PLN-0104`.
+- `PLN-0105`.
+- `PLN-0106`.
+
+## Risks
+
+- Asset visibility semantics are high risk. Keep behavior-preserving tests broad.

discussion/workflow/plans/PLN-0108-migrate-tests-to-testplatform.md

@@ -0,0 +1,81 @@
+---
+id: PLN-0108
+ticket: real-render-worker-establishment
+title: Migrate Tests to TestPlatform
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [tests, platform, fixtures]
+---
+
+## Objective
+
+Replace remaining test dependence on `Hardware::new()` and `HardwareBridge` with `TestPlatform` or narrower facade fixtures.
+
+## Background
+
+`DEC-0032` requires tests that need a full local platform fixture to use `TestPlatform`, not hidden `HardwareBridge` compatibility.
+
+## Scope
+
+### Included
+
+- VM runtime tests.
+- Firmware tests.
+- Driver integration tests that still use monolithic hardware only as fixture.
+- Host debugger tests where applicable.
+
+### Excluded
+
+- Do not remove production bridge until tests are migrated.
+- Do not change behavior under test.
+
+## Execution Steps
+
+### Step 1 - Inventory test dependencies
+
+**What:** Find all direct `Hardware::new()` and `HardwareBridge` test uses.
+**How:** Use `rg` and classify by domain.
+**File(s):** test modules across `crates/console` and `crates/host`.
+
+### Step 2 - Migrate full-platform tests
+
+**What:** Replace `Hardware::new()` with `TestPlatform`.
+**How:** Use explicit facade accessors in assertions.
+**File(s):** `crates/console/prometeu-system/src/services/vm_runtime/tests*.rs`, firmware tests.
+
+### Step 3 - Migrate narrow tests
+
+**What:** Replace full platform with narrower fixtures where only one domain is under test.
+**How:** Use render/composer/audio/input/asset fixtures directly.
+**File(s):** driver and runtime test modules.
+
+## Test Requirements
+
+### Unit Tests
+
+- All migrated tests pass.
+
+### Integration Tests
+
+- `cargo test --workspace` or relevant workspace subset if full workspace is too broad.
+
+### Manual Verification
+
+- `rg "Hardware::new\\(|HardwareBridge" crates --glob '*test*'` shows no test dependency except tests explicitly covering legacy removal.
+
+## Acceptance Criteria
+
+- [ ] `TestPlatform` is the default full platform fixture.
+- [ ] Tests no longer preserve `HardwareBridge` by habit.
+- [ ] Narrow tests use narrower fixtures.
+
+## Dependencies
+
+- `PLN-0103`.
+- `PLN-0107`.
+
+## Risks
+
+- Large mechanical changes can hide behavior regressions. Keep commits grouped by test domain.

discussion/workflow/plans/PLN-0109-remove-hardwarebridge-and-update-specs.md

@@ -0,0 +1,91 @@
+---
+id: PLN-0109
+ticket: real-render-worker-establishment
+title: Remove HardwareBridge and Update Specs
+status: open
+created: 2026-06-06
+completed:
+ref_decisions: [DEC-0032]
+tags: [platform, cleanup, specs, hal]
+---
+
+## Objective
+
+Remove `HardwareBridge` from the codebase and publish the new platform layer contract in specs.
+
+## Background
+
+`DEC-0032` explicitly forbids preserving `HardwareBridge` as final compatibility. After all domains and tests migrate, the bridge must be deleted.
+
+## Scope
+
+### Included
+
+- Delete `HardwareBridge`.
+- Remove exports/imports and adapters that only preserve bridge compatibility.
+- Update canonical specs in English.
+- Run validation and broad tests.
+
+### Excluded
+
+- Do not implement the real render worker.
+- Do not change platform service semantics beyond cleanup.
+
+## Execution Steps
+
+### Step 1 - Delete bridge
+
+**What:** Remove `HardwareBridge` trait and module.
+**How:** Delete source file and remove exports/imports.
+**File(s):** `crates/console/prometeu-hal/src/hardware_bridge.rs`, `crates/console/prometeu-hal/src/lib.rs`, all remaining imports.
+
+### Step 2 - Remove compatibility adapters
+
+**What:** Delete migration-only adapters.
+**How:** Replace final references with direct platform services or remove dead code.
+**File(s):** HAL, drivers, system, firmware, host modules touched by previous plans.
+
+### Step 3 - Update specs
+
+**What:** Document platform layer and removal of monolithic hardware bridge.
+**How:** Update runtime/host/render specs in English.
+**File(s):** `docs/specs/runtime/*.md` and related canonical specs.
+
+### Step 4 - Validate and test
+
+**What:** Run discussion validation and broad test suite.
+**How:** Use `discussion validate` and cargo tests for affected crates.
+**File(s):** repository root.
+
+## Test Requirements
+
+### Unit Tests
+
+- HAL, drivers, firmware, system tests pass.
+
+### Integration Tests
+
+- Host desktop crate compiles/tests.
+- Stress cartridge still runs through local platform path.
+
+### Manual Verification
+
+- `rg "HardwareBridge"` returns no production references.
+- `rg "Hardware::new\\("` returns no runtime-facing dependency; any remaining use is local implementation detail or removed.
+
+## Acceptance Criteria
+
+- [ ] `HardwareBridge` is deleted.
+- [ ] No production/runtime dependencies remain.
+- [ ] Specs describe platform services/facades.
+- [ ] Tests pass.
+- [ ] `AGD-0043` can proceed without needing `&mut Hardware`, `&mut Gfx`, live `FrameComposer`, or mutable VM state in the worker.
+
+## Dependencies
+
+- `PLN-0107`.
+- `PLN-0108`.
+
+## Risks
+
+- Removing the bridge too early will cause broad breakage. Only execute after dependency searches show all call sites have migrated.