2026-04-29 07:19:37 +00:00
8 changed files with 10 additions and 606 deletions
--- a/discussion/index.ndjson
+++ b/discussion/index.ndjson
@ -1,4 +1,4 @@
-{"type":"meta","next_id":{"DSC":31,"AGD":31,"DEC":23,"PLN":46,"LSN":39,"CLSN":1}}
+{"type":"meta","next_id":{"DSC":31,"AGD":31,"DEC":23,"PLN":46,"LSN":40,"CLSN":1}}
 {"type":"discussion","id":"DSC-0023","status":"done","ticket":"perf-full-migration-to-atomic-telemetry","title":"Agenda - [PERF] Full Migration to Atomic Telemetry","created_at":"2026-04-10","updated_at":"2026-04-10","tags":["perf","runtime","telemetry"],"agendas":[{"id":"AGD-0021","file":"workflow/agendas/AGD-0021-full-migration-to-atomic-telemetry.md","status":"done","created_at":"2026-04-10","updated_at":"2026-04-10"}],"decisions":[{"id":"DEC-0008","file":"workflow/decisions/DEC-0008-full-migration-to-atomic-telemetry.md","status":"accepted","created_at":"2026-04-10","updated_at":"2026-04-10"}],"plans":[{"id":"PLN-0007","file":"workflow/plans/PLN-0007-full-migration-to-atomic-telemetry.md","status":"done","created_at":"2026-04-10","updated_at":"2026-04-10"}],"lessons":[{"id":"LSN-0028","file":"lessons/DSC-0023-perf-full-migration-to-atomic-telemetry/LSN-0028-converging-to-single-atomic-telemetry-source.md","status":"done","created_at":"2026-04-10","updated_at":"2026-04-10"}]}
 {"type":"discussion","id":"DSC-0020","status":"done","ticket":"jenkins-gitea-integration","title":"Jenkins Gitea Integration and Relocation","created_at":"2026-04-07","updated_at":"2026-04-07","tags":["ci","jenkins","gitea"],"agendas":[{"id":"AGD-0018","file":"workflow/agendas/AGD-0018-jenkins-gitea-integration-and-relocation.md","status":"done","created_at":"2026-04-07","updated_at":"2026-04-07"}],"decisions":[{"id":"DEC-0003","file":"workflow/decisions/DEC-0003-jenkins-gitea-strategy.md","status":"accepted","created_at":"2026-04-07","updated_at":"2026-04-07"}],"plans":[{"id":"PLN-0003","file":"workflow/plans/PLN-0003-jenkins-gitea-execution.md","status":"done","created_at":"2026-04-07","updated_at":"2026-04-07"}],"lessons":[{"id":"LSN-0021","file":"lessons/DSC-0020-jenkins-gitea-integration/LSN-0021-jenkins-gitea-integration.md","status":"done","created_at":"2026-04-07","updated_at":"2026-04-07"}]}
 {"type":"discussion","id":"DSC-0021","status":"done","ticket":"asset-entry-codec-enum-with-metadata","title":"Asset Entry Codec Enum Contract","created_at":"2026-04-09","updated_at":"2026-04-09","tags":["asset","runtime","codec","metadata"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0024","file":"lessons/DSC-0021-asset-entry-codec-enum-contract/LSN-0024-string-on-the-wire-enum-in-runtime.md","status":"done","created_at":"2026-04-09","updated_at":"2026-04-09"}]}
@ -28,4 +28,4 @@
 {"type":"discussion","id":"DSC-0017","status":"done","ticket":"asset-entry-metadata-normalization-contract","title":"Asset Entry Metadata Normalization Contract","created_at":"2026-03-27","updated_at":"2026-04-09","tags":[],"agendas":[{"id":"AGD-0016","file":"workflow/agendas/AGD-0016-asset-entry-metadata-normalization-contract.md","status":"done","created_at":"2026-03-27","updated_at":"2026-04-09"}],"decisions":[{"id":"DEC-0004","file":"workflow/decisions/DEC-0004-asset-entry-metadata-normalization-contract.md","status":"accepted","created_at":"2026-04-09","updated_at":"2026-04-09"}],"plans":[],"lessons":[{"id":"LSN-0023","file":"lessons/DSC-0017-asset-metadata-normalization/LSN-0023-typed-asset-metadata-helpers.md","status":"done","created_at":"2026-04-09","updated_at":"2026-04-09"}]}
 {"type":"discussion","id":"DSC-0018","status":"done","ticket":"asset-load-asset-id-int-contract","title":"Asset Load Asset ID Int Contract","created_at":"2026-03-27","updated_at":"2026-03-27","tags":["asset","runtime","abi"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0019","file":"lessons/DSC-0018-asset-load-asset-id-int-contract/LSN-0019-asset-load-id-abi-convergence.md","status":"done","created_at":"2026-03-27","updated_at":"2026-03-27"}]}
 {"type":"discussion","id":"DSC-0019","status":"done","ticket":"jenkinsfile-correction","title":"Jenkinsfile Correction and Relocation","created_at":"2026-04-07","updated_at":"2026-04-07","tags":["ci","jenkins"],"agendas":[{"id":"AGD-0017","file":"workflow/agendas/AGD-0017-jenkinsfile-correction.md","status":"done","created_at":"2026-04-07","updated_at":"2026-04-07"}],"decisions":[{"id":"DEC-0002","file":"workflow/decisions/DEC-0002-jenkinsfile-strategy.md","status":"accepted","created_at":"2026-04-07","updated_at":"2026-04-07"}],"plans":[{"id":"PLN-0002","file":"workflow/plans/PLN-0002-jenkinsfile-execution.md","status":"done","created_at":"2026-04-07","updated_at":"2026-04-07"}],"lessons":[{"id":"LSN-0020","file":"lessons/DSC-0019-jenkins-ci-standardization/LSN-0020-jenkins-standard-relocation.md","status":"done","created_at":"2026-04-07","updated_at":"2026-04-07"}]}
-{"type":"discussion","id":"DSC-0030","status":"open","ticket":"internal-viewport-270p","title":"Agenda - Internal Viewport 270p (480x270)","created_at":"2026-04-27","updated_at":"2026-04-27","tags":["gfx","runtime","viewport","resolution","frame-composer","host"],"agendas":[{"id":"AGD-0030","file":"workflow/agendas/AGD-0030-internal-viewport-270p.md","status":"done","created_at":"2026-04-27","updated_at":"2026-04-27"}],"decisions":[{"id":"DEC-0022","file":"workflow/decisions/DEC-0022-internal-viewport-270p.md","status":"accepted","created_at":"2026-04-27","updated_at":"2026-04-27","ref_agenda":"AGD-0030"}],"plans":[{"id":"PLN-0043","file":"workflow/plans/PLN-0043-runtime-270p-core-migration.md","status":"done","created_at":"2026-04-27","updated_at":"2026-04-27","ref_decisions":["DEC-0022"]},{"id":"PLN-0044","file":"workflow/plans/PLN-0044-host-and-tests-270p-propagation.md","status":"done","created_at":"2026-04-27","updated_at":"2026-04-27","ref_decisions":["DEC-0022"]},{"id":"PLN-0045","file":"workflow/plans/PLN-0045-specs-and-docs-270p-publication.md","status":"review","created_at":"2026-04-27","updated_at":"2026-04-27","ref_decisions":["DEC-0022"]}],"lessons":[]}
+{"type":"discussion","id":"DSC-0030","status":"done","ticket":"internal-viewport-270p","title":"Agenda - Internal Viewport 270p (480x270)","created_at":"2026-04-27","updated_at":"2026-04-28","tags":["gfx","runtime","viewport","resolution","frame-composer","host"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0039","file":"lessons/DSC-0030-internal-viewport-270p/LSN-0039-resolution-baseline-changes-are-runtime-wide-contracts.md","status":"done","created_at":"2026-04-28","updated_at":"2026-04-28"}]}
--- a/discussion/workflow/agendas/AGD-0030-internal-viewport-270p.md
+++ b/discussion/workflow/agendas/AGD-0030-internal-viewport-270p.md
@ -1,133 +0,0 @@
---
-id: AGD-0030
-ticket: internal-viewport-270p
-title: Agenda - Internal Viewport 270p (480x270)
-status: done
-created: 2026-04-27
-resolved: 2026-04-27
-decision: DEC-0022
-tags: [gfx, runtime, viewport, resolution, frame-composer, host]
---
-
-# Agenda - Internal Viewport 270p (480x270)
-
-## Contexto
-
-O runtime hoje trata `320x180` como viewport interna canonica em pontos importantes do pipeline, inclusive documentacao de hardware, `FrameComposer`, `SceneViewportResolver` e testes do host/debug overlay.
-
-A proposta e subir a resolucao interna para `480x270`, preservando a mesma proporcao `16:9`, mas alterando custo de composicao, tamanho de caches, area visivel da camera e possivelmente algumas expectativas implicitas de contrato entre runtime, host, assets e tooling.
-
-Existe contexto arquitetural recente relevante:
-
- `DSC-0025` separou cena canonica, viewport cache e politica de resolver;
- `DSC-0026` consolidou `FrameComposer` como dono da composicao do frame;
- a mudanca agora nao e apenas trocar um par de constantes, porque a viewport interna participa de sizing, copy policy, camera framing e budget de memoria.
-
-## Problema
-
-Precisamos decidir se a viewport interna do Prometeu deve deixar de ser `320x180` e passar a ser `480x270` como novo baseline do runtime.
-
-A decisao precisa fechar:
-
- se `480x270` vira contrato fixo do sistema ou apenas default configuravel; - vira contrato fixo do sistema
- se a camera e o frame visible devem realmente expor mais mundo ou apenas densidade maior; - esse deve ser o frame visible default (zoom de camera sera discutido em outra agenda)
- como ficam caches, copy regions, sprite/world composition e apresentacao no host; - devem seguir o mesmo padrao que temos hj, mas com uma area maior.
- qual o impacto aceito em CPU, RAM e largura de banda para o target handheld. - o impacto foi aceito na integra. esssa mudanca eh definitiva e deve perfurar em specs e docs.
-
-## Pontos Criticos
-
- Compatibilidade de contrato:
-  qualquer lugar que hoje assume `320x180` pode deixar de ser detalhe interno e passar a ser break de comportamento observavel. - devemos corrigir onde for necessario.
- Custo de frame:
-  `480x270` aumenta pixels por frame em 2.25x versus `320x180`, o que pode afetar render software, fades, copy/convert no host e overlays. - o impacto foi aceito na integra.
- Viewport cache e resolver:
-  o `SceneViewportResolver` e o sizing do `FrameComposer` dependem diretamente da viewport para anchor, drift, hysteresis e regioes de refresh. -- mudancas necessarias para esse novo tamanho.
- Semantica de camera:
-  aumentar a viewport pode mudar gameplay, enquadramento, spawn visibility e design de HUD se o jogo passa a ver mais mundo. -- sem compat. nao ha jogos ainda usando essas features.
- Host e debug tooling:
-  overlay, apresentacao desktop e eventuais capturas/testes visuais hoje ainda carregam suposicoes de `320x180`. - precisamos atuar em mudancas ali tb
- Escopo de migracao:
-  precisamos decidir se a troca cobre apenas runtime/host ou tambem specs, exemplos, assets de referencia e testes de regressao. - devemos migrar tudo para o novo tamanho. os assets nao sao necessarios, podemos mante-los no mesmo tamanho, com excessao dos glyphos de texto.
-
-## Hotspots Atuais
-
- [hardware.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/console/prometeu-drivers/src/hardware.rs#L24)
- [frame_composer.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/console/prometeu-drivers/src/frame_composer.rs#L197)
- [scene_viewport_resolver.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/console/prometeu-hal/src/scene_viewport_resolver.rs#L56)
- [overlay.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/host/prometeu-host-desktop-winit/src/overlay.rs#L478)
-
-## Alvo da Discussao
-
-Definir o contrato correto para a viewport interna 270p no runtime e quais propagacoes sao obrigatorias antes de qualquer mudanca em spec ou codigo.
-
-## Opcoes
-
-### Opcao A - Manter `320x180` como contrato canonico
-
- **Abordagem:**
-  rejeitar a troca de baseline e, se necessario, melhorar apenas o upscale/apresentacao no host.
- **Pro:**
-  evita reabrir camera, caches, testes e budget de composicao.
- **Con:**
-  nao entrega mais area/pixel density interna e pode limitar qualidade visual ou framing pretendido.
- **Manutenibilidade:**
-  custo baixo agora, mas posterga a pergunta arquitetural se `320x180` ja nao representa mais o alvo real do produto.
-
-### Opcao B - Promover `480x270` a nova viewport canonica fixa
-
- **Abordagem:**
-  trocar o baseline interno do sistema inteiro para `480x270` e propagar a mudanca onde o contrato hoje assume `320x180`.
- **Pro:**
-  simplifica o modelo final: uma resolucao interna oficial, sem modo duplo.
- **Con:**
-  aumenta custo por frame, pode expor mais mundo do que jogos atuais esperam e exige migracao coordenada em runtime/host/tests/specs.
- **Manutenibilidade:**
-  boa se o produto realmente quer 270p como target oficial; ruim se depois precisarmos voltar a variabilidade.
-
-### Opcao C - Introduzir viewport interna configuravel com `320x180` e `480x270`
-
- **Abordagem:**
-  transformar a viewport interna em configuracao de sistema/composer, permitindo coexistencia de 180p e 270p.
- **Pro:**
-  reduz risco de migracao abrupta e facilita benchmark comparativo.
- **Con:**
-  amplia superficie de contrato, multiplica combinacoes de teste e pode contaminar caminhos que hoje assumem um unico baseline.
- **Manutenibilidade:**
-  pior no curto e medio prazo; so vale se variabilidade de resolucao for requisito real de produto, nao apenas etapa de transicao.
-
-## Sugestao / Recomendacao
-
-Seguir inicialmente com a **Opcao B** como hipotese de trabalho: `480x270` deve ser tratado como novo baseline canonico, nao como configuracao geral.
-
-A recomendacao, porem, fica condicionada a duas verificacoes antes do fechamento da agenda:
-
- confirmar que o efeito desejado e realmente aumentar a viewport observavel do jogo, e nao apenas melhorar a cadeia de apresentacao;
- confirmar que o custo extra de composicao e caches cabe no budget aceito para o handheld alvo.
-
-Se qualquer uma dessas premissas falhar, a Opcao A ou uma variante mais restrita da Opcao C volta a ser competitiva.
-
-## Perguntas em Aberto
-
- A mudanca pretende mostrar mais mundo por frame ou manter o mesmo framing com outra granularidade visual? - mostrar mais mundo
- `480x270` deve ser contrato global do runtime ou apenas default do host desktop? - contrato global do runtime, o prometeu passa a ser um console 270p
- Quais syscalls, specs ou expectativas de cartridge assumem implicitamente a area visivel atual? - todas se e quando necessario
- O budget de `SceneViewportCache` e das copias incrementais continua aceitavel com 2.25x mais pixels? - sim, aqui se tornarao ainda mais importantes
- Fade, overlay e conversao `RGB565 -> RGBA8` no host permanecem viaveis sem nova rodada de otimizacao? - por enquanto iremos com o que temos, otimizaremos depois
- Ha assets, HUDs ou testes snapshot que dependem do framing de `320x180`? - nao, nada que nao possa ser migrado para o novo tamanho, mas sem necessidade de vc atuar nisso.
-
-## Criterio para Encerrar
-
-Esta agenda pode ser encerrada quando houver alinhamento suficiente para escrever uma decisao que feche explicitamente:
-
- se `480x270` substitui `320x180` como contrato canonico; - sim
- se a viewport maior muda framing/gameplay observavel ou apenas rasterizacao interna; - maior framing
- quais modulos precisam de propagacao obrigatoria em runtime, host, specs e testes; - todos
- qual evidence minima de custo/memoria e necessaria para executar a migracao com seguranca. - o preco jah foi aceito, iremos migrar.
-
-## Resolucao
-
-A agenda foi encerrada com decisao favoravel a promover `480x270` como resolucao interna canonica do Prometeu.
-
-O novo tamanho passa a definir o frame visible default do console, com maior area observavel de mundo, sem compromisso de compatibilidade com o framing anterior de `320x180`.
-
-A migracao deve perfurar runtime, host, touch, specs, docs e testes. Otimizacoes de custo adicionais nao bloqueiam a mudanca: o aumento de CPU, RAM e bandwidth foi aceito como custo estrutural do novo baseline.
--- a/discussion/workflow/decisions/DEC-0022-internal-viewport-270p.md
+++ b/discussion/workflow/decisions/DEC-0022-internal-viewport-270p.md
@ -1,115 +0,0 @@
---
-id: DEC-0022
-ticket: internal-viewport-270p
-title: Internal Viewport 270p (480x270) as Canonical Runtime Contract
-status: accepted
-created: 2026-04-27
-accepted: 2026-04-27
-agenda: AGD-0030
-plans: [PLN-0043, PLN-0044, PLN-0045]
-tags: [gfx, runtime, viewport, resolution, frame-composer, host, touch]
---
-
-## Status
-
-Accepted on `2026-04-27`.
-
-This decision is normatively locked until explicitly revised by a later decision.
-
-## Contexto
-
-O runtime do Prometeu ainda trata `320x180` como resolucao interna canonica em pontos centrais do sistema, incluindo `Hardware`, `FrameComposer`, host desktop, touch mapping, documentacao de hardware e testes.
-
-O trabalho recente de `DSC-0025` e `DSC-0026` consolidou o modelo correto para esse tipo de mudanca: viewport cache, resolver e frame composition ja possuem ownership claro e aceitam propagacao consistente a partir de um baseline unico de viewport.
-
-O objetivo desta decisao nao e melhorar upscale do host. O objetivo e redefinir o contrato do console para `480x270` como resolucao interna oficial, com maior area visivel de mundo por frame.
-
-## Decisao
-
-O Prometeu SHALL adotar `480x270` como resolucao interna canonica do runtime.
-
-`320x180` MUST cease to be treated as o baseline operacional do console em runtime, host, specs, docs e testes.
-
-`480x270` MUST representar o frame visible default do sistema. A mudanca e observavel: o console passa a mostrar mais mundo por frame.
-
-O runtime MUST NOT introduzir, nesta migracao, um modo dual `180p/270p` nem uma configuracao geral de viewport interna.
-
-Qualquer discussao futura sobre zoom de camera, framing alternativo ou modos adicionais MUST acontecer em discussao separada e MUST NOT enfraquecer este contrato base por inferencia.
-
-## Rationale
-
-Um baseline unico e fixo reduz ambiguidade de contrato e evita contaminar `FrameComposer`, host e specs com variabilidade que nao foi pedida como requisito real de produto.
-
-Aumentar apenas a cadeia de apresentacao do host nao resolve o objetivo do trabalho, porque o requisito aceito e ampliar o frame visible do console, nao apenas ampliar a imagem final.
-
-O custo estrutural de `480x270` foi explicitamente aceito. Portanto, CPU, RAM e bandwidth adicionais nao sao criterio de veto nesta decisao; passam a ser apenas materia de otimizacao posterior.
-
-Como ainda nao existem jogos dependentes do framing anterior, nao ha motivo para carregar compatibilidade legada como restricao principal desta migracao.
-
-## Invariantes / Contrato
-
- `Hardware::W` e `Hardware::H` MUST convergir para `480` e `270`.
- O framebuffer canonico do runtime MUST operar em `480x270` RGB565.
- O host desktop MUST criar sua superficie base a partir da nova resolucao canonica e MUST mapear touch/pointer para o novo dominio absoluto.
- `FrameComposer` MUST usar `480x270` como viewport base para scene binding, camera framing, cache sizing e resolver ownership.
- `SceneViewportResolver` e `SceneViewportCache` MUST preservar o modelo atual de ownership e refresh policy; a mudanca e de baseline dimensional, nao de arquitetura.
- O efeito observavel da camera MUST ser maior framing por frame. Esta decisao MUST NOT ser reinterpretada como mero aumento de densidade com framing igual.
- A conversao `RGB565 -> RGBA8`, fades, overlay e copy paths MAY permanecer com a implementacao atual nesta etapa. Otimizacao posterior e permitida, mas nao e precondicao para adotar `480x270`.
- Assets existentes MUST continuar validos quando seu contrato nao depende da resolucao base. A migracao de assets em massa MUST NOT ser inventada como parte obrigatoria desta decisao.
- Glyphs e superficies textuais MAY exigir ajuste posterior quando o novo framing expuser necessidade de nova ocupacao visual, mas isso nao bloqueia o baseline 270p.
-
-## Impactos
-
-### Runtime
-
- `Hardware`, `Gfx`, `FrameComposer`, `SceneViewportResolver` e caminhos relacionados passam a operar sobre `480x270`.
- Buffers de frame e custos por pixel aumentam estruturalmente.
- O budget de viewport cache e copy path continua valido conceitualmente, mas com volume maior de trabalho e memoria.
-
-### Host
-
- O host desktop deve recriar sua superficie `Pixels` no novo tamanho base.
- O mapeamento de input absoluto deve seguir `480x270`.
- Overlay e qualquer teste de RGBA host-owned devem abandonar hardcodes de `320x180`.
-
-### Firmware / Guest / ABI
-
- O espaco visivel observado pelo software convidado muda porque a camera default passa a enquadrar uma area maior.
- Esta decisao nao cria nova syscall, nao muda formato de argumento e nao introduz seletor de resolucao.
-
-### Specs / Docs
-
- As specs canonicas do runtime MUST publicar `480x270` como resolucao oficial.
- Textos sobre touch e framebuffer MUST ser atualizados para refletir o novo dominio coordenado.
-
-### Tooling / Tests
-
- Testes com hardcodes de `320x180` MUST migrar.
- Snapshots, asserts de tamanho e fixtures de host/debug MUST convergir para `480x270`.
-
-## Referencias
-
- `AGD-0030` - Internal Viewport 270p (480x270)
- `DSC-0025` - Scene Bank and Viewport Cache Refactor
- `DSC-0026` - Integrate render_all with Scene Cache and Camera
- [hardware.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/console/prometeu-drivers/src/hardware.rs:116)
- [runner.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/host/prometeu-host-desktop-winit/src/runner.rs:229)
- [input.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/host/prometeu-host-desktop-winit/src/input.rs:73)
- [04-gfx-peripheral.md](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/docs/specs/runtime/04-gfx-peripheral.md:22)
- [07-touch-peripheral.md](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/docs/specs/runtime/07-touch-peripheral.md:20)
-
-## Propagacao Necessaria
-
- Atualizar constantes canonicas de resolucao em runtime.
- Atualizar criacao de framebuffer e apresentacao no host desktop.
- Atualizar mapping absoluto de touch/pointer.
- Atualizar testes de `FrameComposer`, `SceneViewportResolver`, host overlay e demais asserts fixos de tamanho.
- Atualizar specs e docs que ainda publicam `320x180`.
- Escrever um plano de execucao que separe:
-  runtime/host/tests;
-  specs/docs;
-  qualquer ajuste textual ou visual adicional nao bloqueante.
-
-## Revision Log
-
- `2026-04-27`: Initial accepted decision from `AGD-0030`.
--- a/discussion/workflow/plans/PLN-0043-runtime-270p-core-migration.md
+++ b/discussion/workflow/plans/PLN-0043-runtime-270p-core-migration.md
@ -1,123 +0,0 @@
---
-id: PLN-0043
-ticket: internal-viewport-270p
-title: Runtime 270p Core Migration
-status: done
-created: 2026-04-27
-completed: 2026-04-27
-tags: [gfx, runtime, viewport, resolution, frame-composer]
---
-
-## Briefing
-
-This plan executes the first mandatory slice of `DEC-0022`: migrate the canonical runtime resolution from `320x180` to `480x270` inside the core runtime path before any host-facing or documentation-only propagation.
-
-This plan intentionally prioritizes runtime ownership, framebuffer sizing, `FrameComposer` baseline, resolver/cache sizing behavior, and runtime-local tests. It does not include host window/input propagation or specs/docs publication.
-
-## Decisions de Origem
-
- `DEC-0022` - Internal Viewport 270p (480x270) as Canonical Runtime Contract
-
-## Alvo
-
-Make the runtime itself operate canonically at `480x270` RGB565 and preserve the existing scene/cache/resolver architecture under the new baseline.
-
-## Escopo
-
- Update canonical runtime width/height constants.
- Propagate the new resolution through `Hardware`, `Gfx`, and `FrameComposer`.
- Preserve `SceneViewportResolver` and `SceneViewportCache` architecture while updating runtime assumptions and tests derived from the old baseline.
- Recompute runtime expectations that explicitly depended on `320x180`.
-
-## Fora de Escopo
-
- Host desktop surface creation and pointer mapping.
- Host overlay RGBA fixtures.
- Specs and docs publication.
- Asset migrations or text/glyph content redesign.
-
-## Plano de Execucao
-
-### Step 1 - Promote runtime-wide canonical dimensions
-
-**What:**
-Change the runtime’s canonical internal framebuffer dimensions from `320x180` to `480x270`.
-
-**How:**
-Update the canonical constants and any runtime-local documentation/comments that still publish the old baseline, ensuring all `Gfx` and `FrameComposer` construction paths inherit the new dimensions from the same source of truth.
-
-**File(s):**
- `crates/console/prometeu-drivers/src/hardware.rs`
- `crates/console/prometeu-drivers/src/gfx.rs`
-
-### Step 2 - Rebaseline frame composition and scene runtime sizing
-
-**What:**
-Make `FrameComposer` use `480x270` as the canonical viewport baseline for scene binding and scene-runtime construction.
-
-**How:**
-Keep the existing ownership split (`FrameComposer` -> `SceneViewportCache` + `SceneViewportResolver`) intact, but update construction-time expectations and tests that hardcode `320x180`. Preserve the current cache sizing algorithm and hysteresis derivation; do not introduce configurable dual-mode resolution.
-
-**File(s):**
- `crates/console/prometeu-drivers/src/frame_composer.rs`
-
-### Step 3 - Rebaseline resolver expectations under 270p
-
-**What:**
-Update resolver tests and derived numeric expectations to the `480x270` viewport.
-
-**How:**
-Adjust test fixtures that currently instantiate `SceneViewportResolver::new(320, 180, 25, 16, 12, 20)` and recompute anchor, clamp, and refresh-region assertions from the 270p baseline. Preserve behavioral intent:
- anchor initialization;
- parallax propagation;
- hysteresis stability;
- edge clamping;
- incremental refresh behavior.
-
-**File(s):**
- `crates/console/prometeu-hal/src/scene_viewport_resolver.rs`
-
-### Step 4 - Rebaseline runtime integration tests
-
-**What:**
-Update runtime-level tests that validate compositor/runtime invariants using the old resolution.
-
-**How:**
-Migrate runtime integration assertions so they derive expected sizes from the new baseline or from the runtime constants. Keep scene-cache and sprite-order semantics unchanged; only the canonical viewport contract changes.
-
-**File(s):**
- `crates/console/prometeu-drivers/src/hardware.rs`
- `crates/console/prometeu-drivers/src/frame_composer.rs`
- `crates/console/prometeu-drivers/src/gfx.rs`
-
-## Criterios de Aceite
-
- `Hardware::W == 480` and `Hardware::H == 270`.
- Runtime-owned frame composition uses `480x270` as the canonical viewport.
- Runtime tests no longer hardcode `320x180` as the canonical internal resolution.
- Resolver/cache behavior remains architecturally unchanged apart from the dimensional baseline.
- No configurable `180p/270p` runtime mode is introduced.
-
-## Tests / Validacao
-
-### Unit Tests
-
- `cargo test` for:
-  `prometeu-drivers`
-  `prometeu-hal`
-
-### Integration Tests
-
- Verify `FrameComposer` scene-binding/runtime tests under the new viewport.
- Verify resolver numeric assertions after updating the viewport baseline.
-
-### Manual Verification
-
- Inspect runtime constants and constructor callsites to confirm a single canonical source of truth.
- Confirm no new runtime API for resolution selection was added.
-
-## Riscos
-
- Resolver tests may fail with multiple derived-value changes at once, requiring careful recomputation rather than blind constant replacement.
- Some runtime assertions may accidentally embed old visible-framing assumptions instead of true contract checks.
- Runtime-only completion does not yet yield correct host presentation; that gap is intentional and deferred to the next plan.
--- a/discussion/workflow/plans/PLN-0044-host-and-tests-270p-propagation.md
+++ b/discussion/workflow/plans/PLN-0044-host-and-tests-270p-propagation.md
@ -1,120 +0,0 @@
---
-id: PLN-0044
-ticket: internal-viewport-270p
-title: Host and Test Propagation for 270p
-status: done
-created: 2026-04-27
-completed: 2026-04-27
-tags: [host, tests, viewport, resolution, touch, overlay]
---
-
-## Briefing
-
-This plan executes the second mandatory slice of `DEC-0022`: propagate the accepted `480x270` runtime contract into host presentation, absolute pointer mapping, host-side overlay/test fixtures, and any remaining test surfaces that still assume `320x180`.
-
-This plan depends on `PLN-0043` completing first. It must not redefine the runtime contract; it only propagates the already-accepted 270p baseline into host-owned behavior and validation surfaces.
-
-## Decisions de Origem
-
- `DEC-0022` - Internal Viewport 270p (480x270) as Canonical Runtime Contract
-
-## Alvo
-
-Make the desktop host and test surface faithfully consume the new canonical runtime resolution and touch domain.
-
-## Escopo
-
- Update host framebuffer/surface creation to `480x270`.
- Update absolute pointer/touch mapping to the new canonical domain.
- Update host overlay fixtures and tests that still allocate or draw against `320x180`.
- Sweep remaining test hardcodes outside the core runtime step.
-
-## Fora de Escopo
-
- Core runtime ownership changes already covered by `PLN-0043`.
- Specs and docs publication.
- Post-migration visual redesign or typography/layout tuning beyond strict propagation.
-
-## Plano de Execucao
-
-### Step 1 - Rebaseline host presentation surface
-
-**What:**
-Make the desktop host create and present its base `Pixels` surface using the new canonical runtime dimensions.
-
-**How:**
-Update host initialization and redraw flow so `PixelsBuilder`, frame copy, and overlay composition all consume `Hardware::W/H` after the runtime constants move to `480x270`.
-
-**File(s):**
- `crates/host/prometeu-host-desktop-winit/src/runner.rs`
- `crates/host/prometeu-host-desktop-winit/src/utilities.rs`
-
-### Step 2 - Rebaseline absolute input mapping
-
-**What:**
-Align pointer/touch translation with the new canonical framebuffer domain.
-
-**How:**
-Update `window_to_fb()` and any clamping logic to map window coordinates into `[0, 479] x [0, 269]` through the canonical `Hardware::W/H` path.
-
-**File(s):**
- `crates/host/prometeu-host-desktop-winit/src/input.rs`
-
-### Step 3 - Update host overlay fixtures and tests
-
-**What:**
-Remove host overlay hardcodes that still allocate or draw a `320x180` RGBA buffer.
-
-**How:**
-Update overlay tests and any host-owned fixtures so they use `480x270` or derive from the canonical hardware constants where appropriate. Preserve overlay semantics; do not redesign the overlay in this plan.
-
-**File(s):**
- `crates/host/prometeu-host-desktop-winit/src/overlay.rs`
-
-### Step 4 - Sweep remaining non-doc resolution assertions
-
-**What:**
-Capture and update any remaining code or tests outside specs/docs that still depend on the old baseline.
-
-**How:**
-Search for `320x180`, `320, 180`, and equivalent fixed-size assumptions under host/runtime test surfaces and migrate them to the accepted 270p contract or to canonical constants.
-
-**File(s):**
- `crates/host/prometeu-host-desktop-winit/src/*`
- any remaining test modules under `crates/console/*`
-
-## Criterios de Aceite
-
- The desktop host creates its base surface from the `480x270` canonical runtime dimensions.
- Absolute pointer/touch mapping uses the new framebuffer domain.
- Host overlay tests no longer hardcode `320x180`.
- No host-owned code path reintroduces the old baseline as an implicit contract.
-
-## Tests / Validacao
-
-### Unit Tests
-
- `cargo test` for:
-  `prometeu-host-desktop-winit`
-  any directly impacted console crates
-
-### Integration Tests
-
- Verify runtime frame copy still lands correctly in the host RGBA surface.
- Verify pointer mapping clamps to the new canonical framebuffer bounds.
-
-### Manual Verification
-
- Launch the desktop host and confirm the window presents a `480x270` logical framebuffer.
- Confirm overlay still renders and aligns within the new frame domain.
- Confirm pointer/touch interaction reaches the expected screen edges.
-
-## Riscos
-
- Host visual regressions may appear only at runtime even when tests pass.
- Overlay layout may become visually awkward at 270p even if functionally correct; cosmetic tuning is intentionally deferred.
- Partial migration risks mismatch between runtime dimensions and host test fixtures if `PLN-0043` is not completed first.
-
-## Dependencies
-
- `PLN-0043` MUST complete first.
--- a/discussion/workflow/plans/PLN-0045-specs-and-docs-270p-publication.md
+++ b/discussion/workflow/plans/PLN-0045-specs-and-docs-270p-publication.md
@ -1,105 +0,0 @@
---
-id: PLN-0045
-ticket: internal-viewport-270p
-title: Specs and Docs Publication for 270p
-status: review
-created: 2026-04-27
-completed:
-tags: [specs, docs, runtime, viewport, resolution]
---
-
-## Briefing
-
-This plan executes the final mandatory slice of `DEC-0022`: publish the accepted `480x270` console contract in canonical specs and supporting documentation after runtime and host propagation are already in place.
-
-This plan must run last. It exists to prevent public documentation from getting ahead of executable reality.
-
-## Decisions de Origem
-
- `DEC-0022` - Internal Viewport 270p (480x270) as Canonical Runtime Contract
-
-## Alvo
-
-Update canonical published documentation so the repository describes Prometeu as a `480x270` console with matching framebuffer and touch coordinate semantics.
-
-## Escopo
-
- Update runtime specs that explicitly publish `320x180`.
- Update any nearby prose that describes visual behavior in a way that now depends on the new baseline.
- Update related README/index material if it repeats the old resolution as canonical fact.
-
-## Fora de Escopo
-
- Runtime or host code changes.
- Asset migration.
- Any broader narrative cleanup unrelated to the 270p contract.
-
-## Plano de Execucao
-
-### Step 1 - Update framebuffer and graphics specs
-
-**What:**
-Publish `480x270` as the canonical graphics/framebuffer resolution in the runtime graphics spec.
-
-**How:**
-Update the base-resolution and related descriptive sections so they state the new canonical resolution without ambiguity. Any prose that references `320x180` as a defining visual baseline must be revised to stay accurate.
-
-**File(s):**
- `docs/specs/runtime/04-gfx-peripheral.md`
-
-### Step 2 - Update touch coordinate contract
-
-**What:**
-Publish the new absolute touch domain that matches the 270p framebuffer.
-
-**How:**
-Update the touch spec so resolution, coordinate ranges, and any coordinate-space examples reflect `[0, 479] x [0, 269]`.
-
-**File(s):**
- `docs/specs/runtime/07-touch-peripheral.md`
-
-### Step 3 - Sweep remaining resolution references in runtime docs
-
-**What:**
-Remove remaining canonical `320x180` references from runtime docs and supporting material where they now contradict `DEC-0022`.
-
-**How:**
-Search runtime specs and adjacent docs for explicit resolution references and update only the ones that are part of the public console contract. Do not rewrite unrelated prose that merely mentions resolution in a different context unless it becomes incorrect after the migration.
-
-**File(s):**
- `docs/specs/runtime/*.md`
- `docs/specs/runtime/README.md`
- any other directly affected docs under `docs/`
-
-## Criterios de Aceite
-
- Canonical runtime docs publish `480x270` as the official internal resolution.
- Touch docs publish coordinate ranges consistent with `480x270`.
- No remaining public spec text describes `320x180` as the canonical console baseline.
- Documentation order reflects executable truth: runtime/host migration is already completed before docs close.
-
-## Tests / Validacao
-
-### Unit Tests
-
- No code unit tests are required for documentation-only changes.
-
-### Integration Tests
-
- Re-run any repository validation or doc-linked checks that are already part of the normal workflow if available.
-
-### Manual Verification
-
- Read the updated specs end-to-end for `gfx` and `touch` to confirm they agree with `DEC-0022`.
- Confirm no public-facing contradiction remains between docs and the implemented runtime baseline.
-
-## Riscos
-
- Publishing docs before code would create a contract/execution mismatch; this is why this plan must remain last.
- Resolution references can hide in explanatory prose and examples, not only in obvious headings.
- Over-editing adjacent docs can accidentally turn a narrowly scoped publication task into a broad editorial rewrite.
-
-## Dependencies
-
- `PLN-0043` MUST complete first.
- `PLN-0044` SHOULD complete first, and MUST complete first if any host-facing docs mention live desktop behavior.
--- a/docs/specs/runtime/04-gfx-peripheral.md
+++ b/docs/specs/runtime/04-gfx-peripheral.md
@ -23,7 +23,7 @@ It is an explicit 2D graphics device based on:

 ### Base resolution

- **320 × 180 pixels**
+- **480 × 270 pixels**
 - aspect ratio close to 16:9
 - scalable by the host (nearest-neighbor)

@ -142,9 +142,9 @@ The cache is a window of tiles around the camera.

 Example:

- Screen: 320×180
- 16×16 tiles → 20×12 visible
- Cache: 22×14 (1-tile margin)
+- Screen: 480×270
+- 16×16 tiles → approximately 30×17 visible
+- Current runtime cache sizing with 16×16 layers: 35×21 tiles

 It stores tiles already resolved from the tilemap.

@ -316,7 +316,7 @@ In v1, deferred `gfx.*` overlay/debug primitives are drained after both fades an

 The fade is implemented without continuous per-pixel alpha and without floats.
 It uses a **discrete integer level** (0..31), which in practice produces an
-"almost continuous" visual result in 320×180 pixel art.
+"almost continuous" visual result in Prometeu's `480x270` pixel-art framebuffer.

 ---

--- a/docs/specs/runtime/07-touch-peripheral.md
+++ b/docs/specs/runtime/07-touch-peripheral.md
@ -20,11 +20,11 @@ Core contract:
 ## 2 Coordinate Space

 - TOUCH coordinates use **the same space as the framebuffer**
- Resolution: **320×180**
+- Resolution: **480×270**
 - Origin: top-left corner `(0,0)`
 - Ranges:
-    - `x ∈ [0, 319]`
-    - `y ∈ [0, 179]`
+    - `x ∈ [0, 479]`
+    - `y ∈ [0, 269]`

 TOUCH is **absolute**: