diff --git a/crates/console/prometeu-drivers/src/gfx.rs b/crates/console/prometeu-drivers/src/gfx.rs index 8cc86272..6fca0a2f 100644 --- a/crates/console/prometeu-drivers/src/gfx.rs +++ b/crates/console/prometeu-drivers/src/gfx.rs @@ -908,7 +908,7 @@ impl Gfx { let col_start = (-x).clamp(0, glyph_w) as usize; let col_end = (screen_w - x).clamp(0, glyph_w) as usize; - for row_idx in row_start..row_end { + for (row_idx, _) in glyph.iter().enumerate().take(row_end).skip(row_start) { let row = glyph[row_idx]; let py = (y + row_idx as i32) as usize; let base = py * self.w; diff --git a/crates/console/prometeu-firmware/src/firmware/firmware.rs b/crates/console/prometeu-firmware/src/firmware/firmware.rs index e97659f0..3679f393 100644 --- a/crates/console/prometeu-firmware/src/firmware/firmware.rs +++ b/crates/console/prometeu-firmware/src/firmware/firmware.rs @@ -175,7 +175,8 @@ mod tests { use prometeu_bytecode::assembler::assemble; use prometeu_bytecode::model::{BytecodeModule, FunctionMeta, SyscallDecl}; use prometeu_drivers::hardware::Hardware; - use prometeu_hal::cartridge::{AppMode, AssetsPayloadSource}; + use prometeu_hal::app_mode::AppMode; + use prometeu_hal::cartridge::AssetsPayloadSource; use prometeu_hal::color::Color; use prometeu_hal::primitives::Rect; use prometeu_hal::syscalls::caps; diff --git a/crates/console/prometeu-firmware/src/firmware/firmware_step_load_cartridge.rs b/crates/console/prometeu-firmware/src/firmware/firmware_step_load_cartridge.rs index b9d033c3..e8b1351e 100644 --- a/crates/console/prometeu-firmware/src/firmware/firmware_step_load_cartridge.rs +++ b/crates/console/prometeu-firmware/src/firmware/firmware_step_load_cartridge.rs @@ -2,7 +2,8 @@ use crate::firmware::firmware_state::{ AppCrashesStep, FirmwareState, GameRunningStep, ShellRunningStep, }; use crate::firmware::prometeu_context::PrometeuContext; -use prometeu_hal::cartridge::{AppMode, Cartridge}; +use prometeu_hal::app_mode::AppMode; +use prometeu_hal::cartridge::Cartridge; use prometeu_hal::color::Color; use prometeu_hal::log::{LogLevel, LogSource}; use prometeu_hal::primitives::Rect; diff --git a/crates/console/prometeu-hal/src/app_mode.rs b/crates/console/prometeu-hal/src/app_mode.rs new file mode 100644 index 00000000..01f35f08 --- /dev/null +++ b/crates/console/prometeu-hal/src/app_mode.rs @@ -0,0 +1,7 @@ +use serde::{Deserialize, Serialize}; + +#[derive(Debug, Clone, Copy, PartialEq, Eq, Deserialize, Serialize)] +pub enum AppMode { + Game, + Shell, +} diff --git a/crates/console/prometeu-hal/src/cartridge.rs b/crates/console/prometeu-hal/src/cartridge.rs index 8fa72386..42c7f735 100644 --- a/crates/console/prometeu-hal/src/cartridge.rs +++ b/crates/console/prometeu-hal/src/cartridge.rs @@ -1,3 +1,4 @@ +use crate::app_mode::AppMode; use crate::asset::{AssetEntry, PreloadEntry}; use crate::syscalls::CapFlags; use serde::{Deserialize, Serialize}; @@ -10,12 +11,6 @@ pub const ASSETS_PA_MAGIC: [u8; 4] = *b"ASPA"; pub const ASSETS_PA_SCHEMA_VERSION: u32 = 1; pub const ASSETS_PA_PRELUDE_SIZE: usize = 32; -#[derive(Debug, Clone, Copy, PartialEq, Eq, Deserialize, Serialize)] -pub enum AppMode { - Game, - Shell, -} - #[derive(Debug, Clone)] pub struct Cartridge { pub app_id: u32, diff --git a/crates/console/prometeu-hal/src/debugger_protocol.rs b/crates/console/prometeu-hal/src/debugger_protocol.rs index cc6e8950..e6428be7 100644 --- a/crates/console/prometeu-hal/src/debugger_protocol.rs +++ b/crates/console/prometeu-hal/src/debugger_protocol.rs @@ -1,4 +1,4 @@ -use crate::cartridge::AppMode; +use crate::app_mode::AppMode; use prometeu_bytecode::Value; use serde::{Deserialize, Serialize}; diff --git a/crates/console/prometeu-hal/src/lib.rs b/crates/console/prometeu-hal/src/lib.rs index 2e603b6b..fe0cd2e9 100644 --- a/crates/console/prometeu-hal/src/lib.rs +++ b/crates/console/prometeu-hal/src/lib.rs @@ -1,3 +1,4 @@ +pub mod app_mode; pub mod asset; pub mod asset_bridge; pub mod audio_bridge; diff --git a/crates/console/prometeu-system/src/os/facades/vm.rs b/crates/console/prometeu-system/src/os/facades/vm.rs index 4f38d314..1cf284b3 100644 --- a/crates/console/prometeu-system/src/os/facades/vm.rs +++ b/crates/console/prometeu-system/src/os/facades/vm.rs @@ -1,6 +1,7 @@ use crate::CrashReport; use crate::os::SystemOS; -use prometeu_hal::cartridge::{AppMode, Cartridge}; +use prometeu_hal::app_mode::AppMode; +use prometeu_hal::cartridge::Cartridge; use prometeu_hal::telemetry::{CertificationConfig, TelemetryFrame}; use prometeu_hal::{HardwareBridge, InputSignals}; use prometeu_vm::VirtualMachine; diff --git a/crates/console/prometeu-system/src/services/vm_runtime/dispatch.rs b/crates/console/prometeu-system/src/services/vm_runtime/dispatch.rs index e73c2d03..6ddf9bb2 100644 --- a/crates/console/prometeu-system/src/services/vm_runtime/dispatch.rs +++ b/crates/console/prometeu-system/src/services/vm_runtime/dispatch.rs @@ -2,8 +2,8 @@ use super::*; use crate::fs::{FsState, VirtualFS}; use crate::services::memcard::{MemcardService, MemcardSlotState, MemcardStatus}; use prometeu_bytecode::{TRAP_INVALID_SYSCALL, TRAP_OOB, TRAP_TYPE, Value}; +use prometeu_hal::app_mode::AppMode; use prometeu_hal::asset::{AssetId, AssetOpStatus, BankType, SlotRef}; -use prometeu_hal::cartridge::AppMode; use prometeu_hal::color::Color; use prometeu_hal::glyph::Glyph; use prometeu_hal::log::{LogLevel, LogSource}; diff --git a/crates/console/prometeu-system/src/services/vm_runtime/mod.rs b/crates/console/prometeu-system/src/services/vm_runtime/mod.rs index 8ecf6a5b..19e55af7 100644 --- a/crates/console/prometeu-system/src/services/vm_runtime/mod.rs +++ b/crates/console/prometeu-system/src/services/vm_runtime/mod.rs @@ -6,7 +6,7 @@ mod tick; use crate::CrashReport; use prometeu_bytecode::string_materialization_count; -use prometeu_hal::cartridge::AppMode; +use prometeu_hal::app_mode::AppMode; use prometeu_hal::log::LogService; use prometeu_hal::telemetry::{AtomicTelemetry, CertificationConfig, Certifier}; use prometeu_vm::VirtualMachine; diff --git a/crates/host/prometeu-host-desktop-winit/src/input.rs b/crates/host/prometeu-host-desktop-winit/src/input.rs index 53f71c62..ea58835e 100644 --- a/crates/host/prometeu-host-desktop-winit/src/input.rs +++ b/crates/host/prometeu-host-desktop-winit/src/input.rs @@ -38,13 +38,7 @@ impl FbViewport { let viewport_x = ((win_w - viewport_w) * 0.5).floor(); let viewport_y = ((win_h - viewport_h) * 0.5).floor(); - Some(FbViewport { - x: viewport_x, - y: viewport_y, - w: viewport_w, - h: viewport_h, - scale, - }) + Some(FbViewport { x: viewport_x, y: viewport_y, w: viewport_w, h: viewport_h, scale }) } } @@ -126,10 +120,7 @@ impl HostInputHandler { let fb_x = (local_x / viewport.scale).floor() as i32; let fb_y = (local_y / viewport.scale).floor() as i32; - Some(( - fb_x.clamp(0, Hardware::W as i32 - 1), - fb_y.clamp(0, Hardware::H as i32 - 1), - )) + Some((fb_x.clamp(0, Hardware::W as i32 - 1), fb_y.clamp(0, Hardware::H as i32 - 1))) } } -} \ No newline at end of file +} diff --git a/discussion/index.ndjson b/discussion/index.ndjson index 74bc40e3..f23e712e 100644 --- a/discussion/index.ndjson +++ b/discussion/index.ndjson @@ -34,4 +34,4 @@ {"type":"discussion","id":"DSC-0031","status":"done","ticket":"runtime-mode-separation-game-system","title":"Agenda - Runtime Mode Separation: Game and System","created_at":"2026-05-11","updated_at":"2026-05-14","tags":["runtime","firmware","hub","system-apps","game-mode","scheduler"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0040","file":"discussion/lessons/DSC-0031-runtime-mode-separation-game-system/LSN-0040-system-pipeline-separation.md","status":"done","created_at":"2026-05-14","updated_at":"2026-05-14"}]} {"type":"discussion","id":"DSC-0032","status":"done","ticket":"system-os-lifecycle-process-task-contract","title":"Agenda - SystemOS Lifecycle, Process and Task Contract","created_at":"2026-05-14","updated_at":"2026-05-15","tags":["runtime","os","lifecycle","process","task","shell","firmware"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0041","file":"discussion/lessons/DSC-0032-system-os-lifecycle-process-task-contract/LSN-0041-systemos-lifecycle-authority.md","status":"done","created_at":"2026-05-15","updated_at":"2026-05-15"}]} {"type":"discussion","id":"DSC-0033","status":"done","ticket":"system-os-service-ownership-and-module-layout","title":"Agenda - SystemOS Service Ownership and Module Layout","created_at":"2026-05-14","updated_at":"2026-05-15","tags":["runtime","os","services","module-layout","vm","window-manager","logging"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0042","file":"discussion/lessons/DSC-0033-system-os-service-ownership-and-module-layout/LSN-0042-systemos-service-ownership-boundary.md","status":"done","created_at":"2026-05-15","updated_at":"2026-05-15"}]} -{"type":"discussion","id":"DSC-0036","status":"in_progress","ticket":"prometeu-hub-ui-direction","title":"Agenda - Prometeu Hub UI Direction","created_at":"2026-05-15","updated_at":"2026-05-15","tags":["hub","ui","shell","system-apps","lifecycle","design-system"],"agendas":[{"id":"AGD-0036","file":"AGD-0036-prometeu-hub-ui-direction.md","status":"accepted","created_at":"2026-05-15","updated_at":"2026-05-15"}],"decisions":[{"id":"DEC-0028","file":"DEC-0028-prometeu-hub-initial-retro-shell-ui-slice.md","status":"accepted","created_at":"2026-05-15","updated_at":"2026-05-15","ref_agenda":"AGD-0036"}],"plans":[{"id":"PLN-0062","file":"PLN-0062-native-shell-launch-and-lifecycle-wiring.md","status":"done","created_at":"2026-05-15","updated_at":"2026-05-15","ref_decisions":["DEC-0028"]},{"id":"PLN-0063","file":"PLN-0063-hub-mouse-input-and-click-routing.md","status":"done","created_at":"2026-05-15","updated_at":"2026-05-15","ref_decisions":["DEC-0028"]},{"id":"PLN-0064","file":"PLN-0064-retro-hub-home-and-fake-shell-ui.md","status":"done","created_at":"2026-05-15","updated_at":"2026-05-15","ref_decisions":["DEC-0028"]},{"id":"PLN-0065","file":"PLN-0065-pixel-operator-font-integration.md","status":"done","created_at":"2026-05-15","updated_at":"2026-05-15","ref_decisions":["DEC-0028"]},{"id":"PLN-0066","file":"PLN-0066-hub-ui-slice-validation-and-lesson.md","status":"done","created_at":"2026-05-15","updated_at":"2026-05-15","ref_decisions":["DEC-0028"]}],"lessons":[{"id":"LSN-0045","file":"discussion/lessons/DSC-0036-prometeu-hub-ui-direction/LSN-0045-hub-ui-slices-should-prove-os-boundaries.md","status":"done","created_at":"2026-05-15","updated_at":"2026-05-15"}]} +{"type":"discussion","id":"DSC-0036","status":"done","ticket":"prometeu-hub-ui-direction","title":"Agenda - Prometeu Hub UI Direction","created_at":"2026-05-15","updated_at":"2026-05-22","tags":["hub","ui","shell","system-apps","lifecycle","design-system"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0045","file":"discussion/lessons/DSC-0036-prometeu-hub-ui-direction/LSN-0045-hub-ui-slices-should-prove-os-boundaries.md","status":"done","created_at":"2026-05-22","updated_at":"2026-05-22"}]} diff --git a/discussion/workflow/agendas/AGD-0036-prometeu-hub-ui-direction.md b/discussion/workflow/agendas/AGD-0036-prometeu-hub-ui-direction.md deleted file mode 100644 index 7b00eacf..00000000 --- a/discussion/workflow/agendas/AGD-0036-prometeu-hub-ui-direction.md +++ /dev/null @@ -1,193 +0,0 @@ ---- -id: AGD-0036 -ticket: prometeu-hub-ui-direction -title: Agenda - Prometeu Hub UI Direction -status: accepted -created: 2026-05-15 -resolved: -decision: -tags: [hub, ui, shell, system-apps, lifecycle, design-system] ---- - -## Contexto - -O Prometeu Hub esta entrando em uma etapa em que a Shell precisa deixar de ser apenas uma superficie funcional e passar a expressar uma identidade visual propria do Prometeu OS. - -A direcao desejada e uma UI retro/minimalista inspirada em console portatil, fantasy console e Homebrew Channel: baixa resolucao, tipografia pixelada, poucos tons, bordas marcadas, componentes simples, leitura clara e navegacao confortavel por controle. - -O alvo inicial nao e criar um toolkit completo. A etapa deve estabelecer a linguagem visual e um conjunto pequeno de componentes suficientes para validar a Home do Hub e o fluxo de lifecycle ja construido. - -Componentes iniciais esperados: - -- Channel/Card -- Button -- Panel -- Tabs -- List -- Status bar -- Footer/help bar -- Focus highlight - -O Hub deve continuar respeitando a arquitetura atual: - -- Hub renderiza e navega. -- Hub emite acao. -- SystemOS/Firmware executa lifecycle, task, process e window. - -Portanto, a UI do Hub nao deve manipular diretamente VM, process/task lifecycle ou window ownership fora das facades do SystemOS. - -## Problema - -A ausencia de uma direcao visual clara cria risco de o Hub virar uma UI desktop/mobile generica ou um conjunto de componentes sem coesao. Ao mesmo tempo, tentar resolver um design system completo agora pode atrasar a validacao do fluxo mais importante: Home -> abrir app Shell nativo fake -> fechar app -> retornar ao Hub. - -O problema central e definir o primeiro contrato de direcao da UI: qual experiencia visual e interativa sera validada agora, quais componentes fazem parte do primeiro corte, e quais limites arquiteturais nao podem ser atravessados pela implementacao da Shell. - -## Pontos Criticos - -- A estetica retro precisa melhorar legibilidade e identidade, nao apenas adicionar decoracao. -- A baixa resolucao deve ser tratada como linguagem de composicao, escala e foco, sem comprometer leitura. -- Navegacao por controle precisa ser primeira classe: foco visivel, ordem previsivel e acoes claras. -- A Home precisa listar canais/apps e acionar apps sem assumir posse do lifecycle. -- Apps nativos fake devem existir para validar janela, retorno, fechamento e estado de foco, mas nao devem virar arquitetura definitiva de apps. -- Os componentes iniciais devem ser pequenos o bastante para evoluir depois para um toolkit, mas nao acoplados prematuramente a um toolkit completo. -- O Hub nao pode atravessar as facades do SystemOS para manipular VM, process/task lifecycle ou ownership de window. - -## Opcoes - -### Opcao A - Slice visual minimo dentro do Hub - -Criar uma primeira Home retro consistente diretamente no Hub, com componentes locais simples e dois apps Shell nativos fake para validar navegacao, abertura, fechamento e retorno. - -**Tradeoffs:** - -- Pro: entrega rapidamente a experiencia desejada e valida o fluxo real de Shell/lifecycle. -- Pro: evita desenhar um toolkit abstrato antes de entender as necessidades concretas. -- Contra: pode gerar componentes locais que precisarao ser extraidos ou reorganizados depois. -- Risco: se os componentes nao tiverem limites claros, a implementacao pode misturar visual, navegacao e chamadas de lifecycle. - -### Opcao B - Definir um mini toolkit antes da Home - -Criar primeiro um modulo formal de componentes retro do Hub, depois construir a Home sobre ele. - -**Tradeoffs:** - -- Pro: melhora consistencia e reaproveitamento desde o inicio. -- Pro: facilita testes isolados de componentes e futuras telas do sistema. -- Contra: aumenta escopo antes de validar a experiencia principal. -- Risco: o toolkit pode cristalizar abstracoes erradas antes de haver uso suficiente. - -### Opcao C - Prototipo descartavel de UI antes de integrar lifecycle - -Criar uma tela visual isolada, focada apenas em look and feel, sem acoplar ainda ao fluxo de lifecycle, tasks, process e windows. - -**Tradeoffs:** - -- Pro: permite iterar visualmente com baixo risco arquitetural. -- Pro: reduz chance de alterar indevidamente SystemOS durante exploracao visual. -- Contra: nao valida a parte mais importante do Hub como Shell operacional. -- Risco: o prototipo pode parecer aprovado visualmente, mas falhar quando integrado ao fluxo real. - -## Sugestao / Recomendacao - -Seguir pela Opcao A, mas com escopo reduzido pelas respostas da agenda: implementar um slice visual minimo dentro do Hub, com Home manual em 270p, dois botoes clicaveis e dois apps Shell nativos fake. - -A recomendacao e tratar essa etapa como uma direcao de Shell, nao como toolkit completo. O primeiro objetivo deve ser uma Home visualmente consistente que prove: - -- dois botoes manuais para abrir ShellA e ShellB; -- ShellA como app/janela verde simples; -- ShellB como app/janela azul simples; -- abertura de app via acao emitida pelo Hub e executada pelo SystemOS/Firmware; -- fechamento de app como comando da propria app/janela; -- retorno ao Hub apos fechamento; -- estilo retro/minimalista consistente em viewport 270p; -- uso de mouse/click como input inicial; -- respeito estrito ao limite Hub -> SystemOS facade. - -A extracao para toolkit, a lista/grid de canais, Tabs, Status bar e Footer/help bar devem ficar para waves futuras, guiadas por uso real dos componentes. - -## Perguntas em Aberto - -- [x] A Home deve priorizar grid de canais, lista vertical, ou alternar entre os dois via Tabs? na verdade eu tinha pensado em montar os dois shell fakes na mao mesmo, sem lista de canais e coisas mais sofisticadas -- [x] Qual resolucao logica deve orientar a composicao visual desta UI: a viewport interna atual do runtime, uma escala propria do Hub, ou uma convencao derivada da Shell? a viewport toda, 270p. -- [x] A fonte pixelada sera um asset proprio, uma fonte embutida existente, ou uma simulacao inicial via estilo/render atual? podemos ir de proprio mas temos um asset pronto em `assets/pixel_operator.zip` -- [x] Quais dois apps Shell nativos fake devem existir neste primeiro corte? ShellA e ShellB, uma simples tela verde e outro tela azul. -- [x] O fechamento de app deve ser exposto como comando da app, comando global da Shell, ou ambos? na primeira wave comando da app. toda app vai ser embrulhada em uma janela controle (como no windows) -- [x] O footer/help bar deve mapear acoes de controle de forma fixa ou depender do item/app focado? o footer fica para uma proxima wave -- [x] A navegacao inicial precisa suportar apenas controle/teclado, ou tambem mouse para debug/host desktop? vamos usar o mouse primeiramente (como clique) -- [x] Quais facades do SystemOS ja sao suficientes para abrir/fechar/retornar, e quais lacunas precisam virar trabalho separado? eu acredito que estamos bem com session e lifecycle, qq coisa a gente vai implementando no caminho - -## Criterio para Encerrar - -Esta agenda pode ser encerrada quando houver acordo sobre: - -- direcao visual inicial da Shell; -- escopo exato da Home e dos dois apps fake; -- componentes minimos do primeiro corte; -- comportamento esperado de foco/navegacao; -- fronteira operacional entre Hub UI e SystemOS/Firmware; -- se a implementacao deve seguir como slice local do Hub ou exigir uma decisao separada para toolkit. - -Com essas respostas, a agenda deve virar uma decisao normativa antes de qualquer plano ou edicao de codigo. - -## Discussao - -Entrada inicial: a UI deve ter aparencia de sistema embarcado/fantasy console, proxima em espirito a Switch/Homebrew Channel, mas com estetica propria de console retro. O objetivo pratico e inaugurar a identidade visual do Prometeu OS validando a Home do Hub e o lifecycle de apps Shell nativos fake. - -### Analise apos respostas iniciais - -As respostas mudam o primeiro corte de "Home com grid/lista de canais" para uma wave menor e mais direta: uma Shell/Home manual, em 270p, com dois apps nativos fake montados na mao. Isso reduz bastante o risco de criar um toolkit cedo demais. - -O escopo recomendado para a primeira wave passa a ser: - -- Hub em tela cheia 270p, com linguagem retro/minimalista consistente; -- dois affordances clicaveis para ShellA e ShellB, sem lista de canais generica; -- ShellA como janela/tela verde simples; -- ShellB como janela/tela azul simples; -- fonte pixelada propria usando o asset `assets/pixel_operator.zip`, se o pipeline de asset/font permitir sem abrir outro problema arquitetural; -- fechamento como comando da propria app/janela; -- mouse/click como input inicial; -- footer/help bar fora da primeira wave. - -Isso enfraquece a necessidade de `Tabs`, `List`, `Status bar` e `Footer/help bar` no primeiro corte. Eles podem continuar como direcao de linguagem, mas nao devem ser criterios de aceite da wave inicial. Os componentes realmente necessarios agora sao: - -- Panel ou frame de janela; -- Button/click target; -- Focus/hover/active highlight, mesmo que inicialmente guiado por mouse; -- Channel/Card apenas se os dois atalhos manuais da Home forem desenhados como cards. - -Sobre as facades do SystemOS, o codigo atual ja tem pecas importantes: - -- `os.sessions().create_native_shell_task(app_id, title)` cria process/task de Shell nativo e coloca a task em foreground. -- `os.lifecycle().close_task(task_id)` fecha task e marca o processo como stopped. -- `os.windows().add_window(...)`, `set_focus(...)`, `close_window(...)` e `focused_window_belongs_to_task(...)` permitem registrar, focar e observar janelas. -- `ShellRunningStep` ja retorna ao Hub quando a task fecha ou quando a janela focada nao pertence mais a task. - -Mas a superficie ainda nao esta ideal para o contrato da agenda: - -- o Hub atual cria janelas diretamente como `WindowOwner::Hub`, nao como `WindowOwner::Task(task_id)`; -- `PrometeuHub::update_shell_profile` retorna apenas crash, entao nao ha ainda um resultado explicito tipo "launch ShellA/ShellB" para o Firmware transicionar para `ShellRunningStep(task_id)`; -- `sessions().create_native_shell_task` cria task/process, mas nao cria uma janela owned-by-task em uma unica operacao de alto nivel; -- `WindowFacade::remove_all_windows()` e `WindowOwner` exposto no Hub facilitam um corte rapido, mas tambem permitem a UI atravessar demais o contrato de ownership se virarem padrao; -- fechar apenas a janela nao e semanticamente igual a fechar a app; para Shell nativa, o comando de fechar deve terminar em `lifecycle().close_task(task_id)`, e a janela deve ser removida como consequencia operacional ou mantida coerente pela mesma facade. - -Sugestao para fechar a lacuna sem criar toolkit: - -- manter a UI local no Hub; -- introduzir um resultado de Hub mais explicito, por exemplo `HubAction::LaunchNativeShell { app_id, title, kind }` ou equivalente, em vez de o Hub executar tudo diretamente; -- deixar Firmware/SystemOS criar a task nativa via `sessions().create_native_shell_task`; -- criar a janela com `WindowOwner::Task(task_id)` no mesmo fluxo de launch, preferencialmente por uma facade de sessao/janela de nivel mais alto, para nao espalhar ownership manual no Hub; -- fazer o comando de fechar da app chamar `lifecycle().close_task(task_id)` ou emitir uma acao equivalente para o SystemOS, nao apenas remover a janela; -- manter `ShellRunningStep` como responsavel pelo retorno ao Hub quando a task fechar. - -Com isso, a arquitetura continua: Hub renderiza/navega e emite acao; SystemOS/Firmware executa lifecycle, task, process e window. - -### Pontos que ainda precisam de resposta - -- Confirmar se a primeira wave deve abandonar completamente grid/lista/tabs/footer, ou apenas deixar isso fora dos criterios de aceite. -- nao vamos nos ater no componentes nessa wave, mas caso seja necessario, podemos criar alguns. -- Confirmar se a Home manual tera dois cards/botoes clicaveis para ShellA/ShellB ou se as janelas fake aparecem direto na Home. -- Um btn para cada shell. -- Confirmar se `assets/pixel_operator` deve ser extraido/registrado como asset de fonte nesta wave ou se pode entrar como follow-up caso o pipeline de fonte nao esteja pronto. -- jah estah extraido -- Confirmar se a decisao deve exigir uma nova facade de alto nivel para launch de Shell nativa com janela owned-by-task, ou se o plano pode aceitar um uso transitorio de `sessions()` + `windows()` desde que fique encapsulado fora dos componentes visuais. -- vamos tentar usar o que temos. - -## Resolucao - -Validada para decisao, pendente apenas de confirmacao explicita para aceitar a agenda e iniciar o artefato de decisao. diff --git a/discussion/workflow/decisions/DEC-0028-prometeu-hub-initial-retro-shell-ui-slice.md b/discussion/workflow/decisions/DEC-0028-prometeu-hub-initial-retro-shell-ui-slice.md deleted file mode 100644 index c7b5da5f..00000000 --- a/discussion/workflow/decisions/DEC-0028-prometeu-hub-initial-retro-shell-ui-slice.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -id: DEC-0028 -ticket: prometeu-hub-ui-direction -title: Prometeu Hub Initial Retro Shell UI Slice -status: accepted -created: 2026-05-15 -ref_agenda: AGD-0036 -tags: [hub, ui, shell, system-apps, lifecycle, design-system] ---- - -## Context - -AGD-0036 resolved the first visual direction for Prometeu Hub after the runtime gained the basic SystemOS, lifecycle, task, process, and task-owned window contracts. - -The target is not a general UI toolkit yet. The target is the first executable Hub/Shell UI slice that establishes the Prometeu OS visual identity and validates the existing lifecycle flow with native fake Shell apps. - -The accepted agenda narrowed the original "channel grid/list" idea into a smaller wave: - -- a manual Hub/Home surface rendered in the full 270p viewport; -- two clickable entries, one for `ShellA` and one for `ShellB`; -- `ShellA` as a simple green native Shell fake app; -- `ShellB` as a simple blue native Shell fake app; -- mouse/click input first; -- app close initiated from the app/window itself; -- no Footer/help bar, Tabs, generic List, or complete Channel/Card system in this wave; -- use of the existing SystemOS session, lifecycle, and window facades unless implementation proves a narrower helper is required. - -The decision depends on the existing operating model captured by the related lessons: - -- System apps belong to the Runtime/Hub system pipeline, not the game pipeline. -- SystemOS owns lifecycle semantics. -- SystemOS owns shared OS services through domain facades. -- Shell window liveness is tied to a task-owned focused window. - -## Decision - -Prometeu Hub SHALL implement the first retro Shell UI as a narrow, local Hub slice rather than a reusable UI toolkit. - -The first slice SHALL provide a full-viewport 270p Hub/Home with a retro/minimalist visual style inspired by portable console and fantasy-console UI: low-resolution composition, pixel-style typography, limited color use, strong borders, simple panels, and clear clickable affordances. - -The first Hub/Home SHALL expose exactly two manual launch buttons: - -- `ShellA` -- `ShellB` - -The first slice SHALL launch two native fake Shell apps: - -- `ShellA` SHALL render as a simple green app/window. -- `ShellB` SHALL render as a simple blue app/window. - -The first slice SHALL use mouse/click input as the initial navigation and activation mechanism. Controller-first focus navigation MAY be added later, but it is not part of this decision's first acceptance surface. - -The first slice SHALL treat app close as an app/window command. Closing a Shell app MUST result in the corresponding Shell task being closed through SystemOS lifecycle semantics and returning to Hub/Home. - -The first slice MUST NOT introduce a complete UI toolkit, generic app catalog, channel grid, Tabs, List, Status bar, or Footer/help bar. Small local primitives such as button, panel/frame, text drawing, hover/active highlight, and simple window chrome MAY be created when needed to implement the slice. - -The Hub MUST remain a visual Shell/Home program: - -- Hub SHALL render and handle local UI navigation. -- Hub SHALL emit user-intent actions such as "launch ShellA", "launch ShellB", or "close current Shell app". -- SystemOS/Firmware SHALL execute lifecycle, task, process, and window ownership effects. -- Hub MUST NOT directly own VM execution, task/process lifecycle policy, or final window ownership semantics outside SystemOS facades. - -The implementation SHOULD first attempt to use the existing `sessions()`, `lifecycle()`, and `windows()` facades. A new high-level facade is not required by this decision, but if implementation starts duplicating cross-domain launch/close policy in Hub components, the plan MUST introduce a small SystemOS/Firmware helper instead of spreading that policy through visual code. - -## Rationale - -This decision keeps the first UI wave small enough to execute while still validating the important architecture. - -Building a complete toolkit now would force abstractions before there are enough Hub surfaces to justify them. A local slice lets the project discover real component needs from a concrete Home and two Shell apps. - -Skipping lifecycle integration would validate only aesthetics and would not prove the console OS model. The first UI slice must exercise the route from Hub/Home to a native Shell task, task-owned window liveness, app close, lifecycle close, and return to Hub. - -Starting with mouse/click is acceptable because this wave is primarily about visual identity and lifecycle integration. Controller navigation remains part of the broader Hub direction, but making it a hard requirement now would expand the first slice beyond the accepted agenda. - -Using the existing facades respects the current architecture and avoids inventing a new OS API prematurely. The guardrail is that the Hub may compose calls at a local boundary, but visual components must not become lifecycle or ownership authorities. - -## Invariants / Contract - -- The internal composition target for this UI slice is the current 270p viewport. -- `assets/pixel_operator.zip` or its already-extracted content SHOULD be used for pixel-style typography when the existing rendering/font path can support it without unrelated architecture work. -- `ShellA` and `ShellB` are fake native Shell apps for lifecycle and UI validation. They MUST NOT be treated as a final app model or plugin/catalog contract. -- A launched Shell app MUST have task/process state created through SystemOS session/lifecycle pathways. -- A Shell app window used for liveness MUST be owned by `WindowOwner::Task(task_id)`, not by `WindowOwner::Hub`. -- Returning to Hub after app close MUST follow lifecycle closure. Removing a window alone is not a valid app-close semantic. -- The first wave MAY use local Hub UI primitives. Those primitives MUST remain scoped to the slice until a later decision defines a shared toolkit. -- Game cartridges MUST NOT be pulled into this windowed Shell model by implication. This decision applies to native fake Shell apps only. - -## Impacts - -### Specs - -No canonical runtime spec change is required before the first implementation unless the plan introduces a new public SystemOS, Shell, or asset/font contract. If a new public contract is introduced, the canonical specs must be updated in English. - -### Runtime / SystemOS - -Implementation may need small integration work around native Shell launch and task-owned windows. The preferred path is: - -1. Hub emits a launch intent for `ShellA` or `ShellB`. -2. Firmware/SystemOS creates the native Shell task through `sessions().create_native_shell_task(...)`. -3. The launch flow creates/focuses a window owned by `WindowOwner::Task(task_id)`. -4. `ShellRunningStep` drives the Shell app and returns to Hub when lifecycle/window liveness says the app is closed. - -If this cannot be expressed cleanly with current facades, the plan may add a narrow helper/facade that coordinates session creation and task-owned window creation. - -### Hub UI - -The Hub UI should be reshaped from the current button-to-window debug surface into a first-person Shell/Home surface with: - -- retro background/panel treatment; -- two clickable launch buttons; -- simple hover/active visual state for mouse input; -- app/window chrome sufficient to expose close from the app/window; -- clear visual distinction between Hub/Home and an opened Shell app. - -### Host / Input - -The first wave relies on existing host mouse mapping/click input if available. Keyboard/controller focus is not required by this decision. - -### Firmware - -Firmware remains the coordinator for state transitions between Hub/Home and Shell-running state. It must not delegate lifecycle authority to visual components. - -### Tooling / Tests - -Tests should cover the behavior that matters architecturally: - -- launch `ShellA` creates a native Shell task and task-owned window; -- launch `ShellB` creates a native Shell task and task-owned window; -- closing the app closes lifecycle state rather than only removing the window; -- closed Shell returns to Hub/Home; -- Hub UI actions do not require direct task/process manager access. - -## Propagation Targets - -- specs: only if a new public Shell/SystemOS/font contract is introduced. -- plans: create an execution plan from this decision before code changes. -- code: `crates/console/prometeu-system`, `crates/console/prometeu-firmware`, and possibly host/input/rendering code if mouse/font integration requires it. -- tests: SystemOS/Firmware tests for launch/close/return behavior; UI rendering tests only if the repository already has an appropriate surface. -- docs: post-execution lesson in English after the implementation is complete. - -## References - -- Agenda: AGD-0036 -- `LSN-0040` - System Pipeline Separation -- `LSN-0041` - SystemOS Lifecycle Authority -- `LSN-0042` - SystemOS Service Ownership Boundary -- `LSN-0043` - SystemOS Domain Facades -- `LSN-0044` - Task Window Liveness Belongs to the Task - -## Revision Log - -- 2026-05-15: Initial decision draft from AGD-0036. diff --git a/discussion/workflow/plans/PLN-0062-native-shell-launch-and-lifecycle-wiring.md b/discussion/workflow/plans/PLN-0062-native-shell-launch-and-lifecycle-wiring.md deleted file mode 100644 index 12e98a9d..00000000 --- a/discussion/workflow/plans/PLN-0062-native-shell-launch-and-lifecycle-wiring.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -id: PLN-0062 -ticket: prometeu-hub-ui-direction -title: Native Shell Launch and Lifecycle Wiring -status: done -created: 2026-05-15 -ref_decisions: [DEC-0028] -tags: [hub, ui, shell, system-apps, lifecycle, design-system] ---- - -## Briefing - -Implement the OS/Firmware wiring required by `DEC-0028` so the Hub can emit a launch intent for `ShellA` or `ShellB`, and SystemOS/Firmware can create a native Shell task, create a task-owned window, run the Shell state, close through lifecycle, and return to Hub/Home. - -Source decision: `DEC-0028`. - -## Objective - -Make the launch/close path architecturally correct before the visual slice depends on it: - -- Hub emits launch intent. -- SystemOS/Firmware creates native Shell task/process. -- The Shell app has a `WindowOwner::Task(task_id)` window. -- Close uses `os.lifecycle().close_task(task_id)`. -- `ShellRunningStep` returns to Hub/Home after close. - -## Dependencies - -- `DEC-0028` must remain accepted. -- This plan should execute before `PLN-0064`, because the UI buttons need a real launch target. -- This plan may execute before or alongside `PLN-0063` if tests can trigger Hub actions without mouse input. - -## Scope - -- Update the Hub update result shape so it can report launch/close actions, not only crashes. -- Add native fake Shell app identity for `ShellA` and `ShellB`. -- Wire Firmware/SystemOS launch handling from Hub intent to `sessions().create_native_shell_task(...)`. -- Create and focus a task-owned window for the launched native Shell task. -- Ensure app close routes to lifecycle close, not only window removal. -- Preserve the existing task-owned window liveness rule in `ShellRunningStep`. - -## Non-Goals - -- No generic app catalog. -- No reusable UI toolkit. -- No game cartridge window model. -- No background/minimize/overlay preservation semantics. -- No controller focus navigation. -- No public spec change unless implementation introduces a new public API. - -## Execution Method - -1. Inspect current launch state. - - What changes: identify the exact update path from `HubHomeStep` to `PrometeuHub::update_shell_profile` and `ShellRunningStep`. - - How: read the current firmware state transitions and Hub update result. - - Files: `crates/console/prometeu-firmware/src/firmware/firmware_step_hub_home.rs`, `crates/console/prometeu-firmware/src/firmware/firmware_step_shell_running.rs`, `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs`. - -2. Replace crash-only Hub output with an action-bearing result. - - What changes: extend or replace `SystemProfileUpdate` so it can carry `LaunchNativeShell(ShellA|ShellB)` and close intent while preserving crash reporting. - - How: add a small enum local to the Hub/system profile boundary; keep visual components free of lifecycle mutation. - - Files: `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs` and firmware call sites. - -3. Handle launch in Firmware/SystemOS. - - What changes: when Hub emits launch intent, create the native Shell task through `os.sessions().create_native_shell_task(app_id, title)`. - - How: map `ShellA` and `ShellB` to stable local app ids/titles for this fake-app slice. - - Files: `crates/console/prometeu-firmware/src/firmware/firmware_step_hub_home.rs`; add helper code in `prometeu-system` only if needed to avoid duplication. - -4. Create the task-owned Shell window. - - What changes: after task creation, create and focus a window with `WindowOwner::Task(task_id)`. - - How: use the existing window facade first; introduce a narrow helper only if the launch sequence becomes duplicated or leaks into visual components. - - Files: `crates/console/prometeu-system/src/os/facades/sessions.rs`, `crates/console/prometeu-system/src/os/facades/window.rs`, or firmware step depending on the smallest clean integration point. - -5. Route close through lifecycle. - - What changes: app/window close must call `os.lifecycle().close_task(task_id)` or emit an equivalent action handled by Firmware/SystemOS. - - How: keep window removal separate from lifecycle semantics; do not treat `close_window` as app close. - - Files: `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs`, `crates/console/prometeu-firmware/src/firmware/firmware_step_shell_running.rs`. - -6. Add behavior tests. - - What changes: add tests proving launch creates native Shell task/window and close returns to Hub. - - How: test at SystemOS/Firmware boundary rather than only manager internals. - - Files: existing firmware/system test modules, preferably near current lifecycle/window tests. - -## Acceptance Criteria - -- [x] Launching `ShellA` creates a native Shell task/process. -- [x] Launching `ShellB` creates a native Shell task/process. -- [x] Each launched Shell app receives a focused `WindowOwner::Task(task_id)` window. -- [x] Closing the Shell app closes lifecycle state through `os.lifecycle().close_task(task_id)`. -- [x] Closing the Shell app returns firmware to `HubHome`. -- [x] Hub visual code does not directly mutate task/process managers. -- [x] Existing shell liveness behavior remains intact. - -## Tests - -- Unit tests for any new Hub action enum or mapping logic. -- SystemOS tests for any new helper/facade that creates native Shell task plus task-owned window. -- Firmware tests for HubHome launch to ShellRunning and ShellRunning close to HubHome. -- Regression tests for `focused_window_belongs_to_task(task_id)` behavior if touched. - -## Affected Artifacts - -- `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs` -- `crates/console/prometeu-firmware/src/firmware/firmware_step_hub_home.rs` -- `crates/console/prometeu-firmware/src/firmware/firmware_step_shell_running.rs` -- `crates/console/prometeu-system/src/os/facades/sessions.rs` -- `crates/console/prometeu-system/src/os/facades/window.rs` -- Existing SystemOS/Firmware tests diff --git a/discussion/workflow/plans/PLN-0063-hub-mouse-input-and-click-routing.md b/discussion/workflow/plans/PLN-0063-hub-mouse-input-and-click-routing.md deleted file mode 100644 index 6d967108..00000000 --- a/discussion/workflow/plans/PLN-0063-hub-mouse-input-and-click-routing.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -id: PLN-0063 -ticket: prometeu-hub-ui-direction -title: Hub Mouse Input and Click Routing -status: done -created: 2026-05-15 -ref_decisions: [DEC-0028] -tags: [hub, ui, shell, system-apps, lifecycle, design-system] ---- - -## Briefing - -Implement the input path needed by `DEC-0028`: Hub/Home must support mouse/click activation for the two manual Shell launch buttons and, in Shell app view, for the app/window close command. - -Source decision: `DEC-0028`. - -## Objective - -Provide reliable 270p mouse hit testing and click routing for the initial Hub UI slice without introducing controller navigation or a generic input framework. - -## Dependencies - -- `DEC-0028` must remain accepted. -- This plan should execute before or alongside `PLN-0064`, because the visual buttons need clickable behavior. -- It depends on existing host pointer mapping if available; if unavailable, this plan must add the narrowest input bridge required for Hub clicks. - -## Scope - -- Confirm how host mouse coordinates are mapped into the internal framebuffer/viewport. -- Expose pointer position and click edge to the Hub update path. -- Add deterministic hit testing for `ShellA`, `ShellB`, and close controls. -- Preserve current game/controller input behavior. - -## Non-Goals - -- No controller focus navigation in this wave. -- No keyboard navigation beyond existing debug behavior. -- No drag/drop, resize, window move, scroll, hover menus, or double-click behavior. -- No generic retained-mode UI event system. - -## Execution Method - -1. Inspect current input bridge. - - What changes: identify existing pointer position and click signals. - - How: trace host `winit` input into HAL/runtime input signals. - - Files: `crates/host/prometeu-host-desktop-winit/src/input.rs`, HAL input signal definitions, firmware context wiring. - -2. Add or expose a minimal pointer snapshot. - - What changes: make Hub update code able to read current pointer coordinates in 270p logical space and click pressed/released edge. - - How: reuse existing `window_to_fb` mapping and input structures if present; add a small field/method only if needed. - - Files: host input module, HAL input signal structures, firmware context. - -3. Define Hub hit-test rectangles. - - What changes: create explicit rects for `ShellA`, `ShellB`, and close command. - - How: keep rect definitions close to the local Hub UI slice so visual and hit target stay synchronized. - - Files: `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs`; optional local submodule if the file grows too large. - -4. Route click results to Hub actions. - - What changes: clicking `ShellA` or `ShellB` emits the launch action from `PLN-0062`; clicking close emits close intent. - - How: hit test only on click edge; avoid repeated launch while button is held. - - Files: `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs`. - -5. Add tests around pure hit-test logic. - - What changes: test button rect boundaries and click-edge behavior without needing a desktop window. - - How: isolate hit-test/action selection into pure functions where practical. - - Files: Hub module tests or a local Hub UI submodule test. - -## Acceptance Criteria - -- [x] Pointer coordinates are interpreted in the internal 270p coordinate space. -- [x] Clicking the `ShellA` button emits the `ShellA` launch action exactly once per click. -- [x] Clicking the `ShellB` button emits the `ShellB` launch action exactly once per click. -- [x] Clicking the close command emits close intent for the active Shell app. -- [x] Holding the mouse button does not repeatedly launch apps. -- [x] Existing controller/game input paths are not regressed. - -## Tests - -- Unit tests for hit-test rectangles. -- Unit tests for click edge to action mapping. -- Existing host/system tests to ensure input changes compile across crates. -- Manual verification in desktop host: click `ShellA`, close, click `ShellB`, close. - -## Affected Artifacts - -- `crates/host/prometeu-host-desktop-winit/src/input.rs` -- HAL input signal definitions, if pointer data is not already exposed -- Firmware context/input plumbing, if needed -- `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs` diff --git a/discussion/workflow/plans/PLN-0064-retro-hub-home-and-fake-shell-ui.md b/discussion/workflow/plans/PLN-0064-retro-hub-home-and-fake-shell-ui.md deleted file mode 100644 index 8ee30c86..00000000 --- a/discussion/workflow/plans/PLN-0064-retro-hub-home-and-fake-shell-ui.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -id: PLN-0064 -ticket: prometeu-hub-ui-direction -title: Retro Hub Home and Fake Shell UI -status: done -created: 2026-05-15 -ref_decisions: [DEC-0028] -tags: [hub, ui, shell, system-apps, lifecycle, design-system] ---- - -## Briefing - -Implement the visible Hub/Home and fake Shell app surfaces required by `DEC-0028`: a retro/minimalist 270p Hub with two manual buttons, plus green `ShellA` and blue `ShellB` native fake app/window views. - -Source decision: `DEC-0028`. - -## Objective - -Replace the current debug-style window surface with the first Prometeu OS visual identity slice while keeping all UI primitives local and avoiding a reusable toolkit. - -## Dependencies - -- `PLN-0062` should provide the launch/close/lifecycle wiring. -- `PLN-0063` should provide click routing. -- `PLN-0065` may provide pixel font rendering; this plan must still remain executable with current text rendering if font integration is deferred. - -## Scope - -- Full 270p Hub/Home composition. -- Retro/minimalist palette, borders, panels, and two clickable launch buttons. -- Local drawing primitives for panel/frame/button/highlight only when needed. -- `ShellA` fake app view as green. -- `ShellB` fake app view as blue. -- App/window chrome with close affordance. -- Clear visual separation between Hub/Home and Shell app state. - -## Non-Goals - -- No full UI toolkit. -- No generic app catalog. -- No Tabs/List/Status bar/Footer/help bar. -- No controller focus UI. -- No production app plugin model. -- No game cartridge visual changes. - -## Execution Method - -1. Define the 270p layout constants. - - What changes: establish local coordinates for Hub background, title area, two buttons, and optional simple panel/frame. - - How: use fixed 480x270 logical viewport coordinates consistent with the runtime viewport. - - Files: `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs` or local Hub UI submodule. - -2. Add local retro drawing primitives. - - What changes: add small helper functions for panel/frame, button, highlight, and simple text placement. - - How: keep them private/local to the Hub slice; do not expose as a toolkit. - - Files: Hub module or `crates/console/prometeu-system/src/programs/prometeu_hub/` submodules. - -3. Render Hub/Home. - - What changes: draw a consistent retro/minimalist Home surface with exactly two launch buttons. - - How: use low-resolution composition, strong outlines, limited color use, and button labels `ShellA` and `ShellB`. - - Files: Hub render path. - -4. Render native fake Shell app views. - - What changes: draw `ShellA` as a green app/window and `ShellB` as a blue app/window, with a visible close command. - - How: use the task-owned window information and app identity established by `PLN-0062`. - - Files: Hub render path and any local fake-app state/mapping. - -5. Keep visual state separate from lifecycle state. - - What changes: UI code may know the current view/app identity but must not mutate lifecycle directly. - - How: return actions to the boundary defined by `PLN-0062`. - - Files: Hub update/render code. - -6. Add lightweight tests for layout/action coupling. - - What changes: ensure visible button rects match clickable rects from `PLN-0063`. - - How: put button definitions in a shared local data structure used by render and hit testing. - - Files: Hub module tests. - -## Acceptance Criteria - -- [x] Hub/Home renders full-screen in the 270p viewport. -- [x] Hub/Home shows exactly two manual launch buttons: `ShellA` and `ShellB`. -- [x] The visual style is retro/minimalist with strong borders and limited palette. -- [x] `ShellA` renders as a simple green native fake Shell app/window. -- [x] `ShellB` renders as a simple blue native fake Shell app/window. -- [x] Each Shell app view exposes a visible close command. -- [x] Local primitives are not exported as a general toolkit. -- [x] No Tabs/List/Status bar/Footer/help bar are added in this wave. - -## Tests - -- Unit tests for shared local layout/button definitions. -- Compile and runtime tests from `PLN-0062` and `PLN-0063`. -- Manual desktop verification of the full flow: Hub -> ShellA -> close -> Hub -> ShellB -> close -> Hub. -- Screenshot/manual visual check at 480x270 internal composition if repository tooling supports it. - -## Affected Artifacts - -- `crates/console/prometeu-system/src/programs/prometeu_hub/prometeu_hub.rs` -- Possible local modules under `crates/console/prometeu-system/src/programs/prometeu_hub/` -- Tests colocated with Hub module diff --git a/discussion/workflow/plans/PLN-0065-pixel-operator-font-integration.md b/discussion/workflow/plans/PLN-0065-pixel-operator-font-integration.md deleted file mode 100644 index a2047fd6..00000000 --- a/discussion/workflow/plans/PLN-0065-pixel-operator-font-integration.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -id: PLN-0065 -ticket: prometeu-hub-ui-direction -title: Pixel Operator Font Integration -status: done -created: 2026-05-15 -ref_decisions: [DEC-0028] -tags: [hub, ui, shell, system-apps, lifecycle, design-system] ---- - -## Briefing - -Integrate the already-available Pixel Operator font asset into the first Hub UI slice when the existing rendering path can support it without creating a new public font system. - -Source decision: `DEC-0028`. - -## Objective - -Use pixel-style typography for the Hub/Home and fake Shell app labels while keeping font work scoped to the initial UI slice. - -## Dependencies - -- `DEC-0028` must remain accepted. -- `PLN-0064` can proceed without this plan if font integration exposes unrelated architecture work. -- The asset is expected to exist already under `assets/pixel_operator` or from `assets/pixel_operator.zip`. - -## Scope - -- Locate and verify the extracted Pixel Operator asset. -- Determine the current text rendering path available to Hub/System UI. -- Add a local font binding or asset loading path if one already fits the runtime. -- Use the font for Hub button labels and simple Shell app text. -- Document any reason this must be deferred. - -## Non-Goals - -- No general font manager unless one already exists and only needs registration. -- No text layout engine. -- No multilingual shaping. -- No public asset/font spec change unless implementation requires a durable contract. -- No dependency download. - -## Execution Method - -1. Verify the asset. - - What changes: confirm exact files and format under `assets/pixel_operator`. - - How: inspect asset directory and identify usable font/bitmap files. - - Files: `assets/pixel_operator*`. - -2. Inspect current text rendering. - - What changes: determine whether Hub can draw text through existing HAL/GFX primitives or asset-backed glyph rendering. - - How: search current text/glyph/font rendering APIs and examples. - - Files: `crates/console/prometeu-hal`, `crates/console/prometeu-system`, current asset/glyph code. - -3. Add the narrowest local integration. - - What changes: make Hub text use Pixel Operator if the path is straightforward. - - How: register/load the asset in the same style as existing assets; keep code local to Hub UI if there is no general font contract. - - Files: Hub module and asset-loading modules identified in step 2. - -4. Add fallback behavior. - - What changes: if font rendering is not currently suitable, keep the visual slice working with existing text/primitive rendering and record a follow-up. - - How: do not block `PLN-0064` on broad font architecture. - - Files: Hub module and this plan's execution notes. - -5. Validate typography use. - - What changes: button labels and simple Shell app labels render legibly in 270p. - - How: manual visual verification plus any available render tests. - - Files: Hub render path. - -## Acceptance Criteria - -- [x] Pixel Operator asset location and format are verified. -- [x] Hub text rendering uses Pixel Operator when the existing rendering path supports it. -- [x] If deferred, the reason is recorded and `PLN-0064` remains executable. -- [x] No broad font/text toolkit is introduced. -- [x] Text remains legible at 270p. - -## Tests - -- Compile tests for any asset/font binding. -- Unit tests only if new parsing/registration logic is added. -- Manual visual verification of button labels and Shell labels. - -## Affected Artifacts - -- `assets/pixel_operator*` -- `crates/console/prometeu-system/src/programs/prometeu_hub/` -- Existing HAL/GFX/asset modules if they already host font or glyph rendering - -## Execution Notes - -The asset is present under `assets/pixel-operator/` as TrueType files, including: - -- `PixelOperator.ttf` -- `PixelOperator8.ttf` -- `PixelOperatorMono.ttf` -- `PixelOperatorMono8.ttf` - -The included license is CC0 1.0 Universal. - -The current runtime text path does not have a TTF loader, font manager, glyph rasterizer, or asset-backed font registration path. Hub/System UI currently reaches text through `GfxBridge::draw_text`, backed by the built-in 3x5 bitmap glyph path in `crates/console/prometeu-drivers/src/gfx.rs`. - -Because `DEC-0028` explicitly forbids expanding this wave into a broad toolkit and this plan forbids introducing a general font manager/text engine, Pixel Operator rendering is deferred. `PLN-0064` remains executable and tested with the existing bitmap text path, which is already pixel-style and legible at 270p. diff --git a/discussion/workflow/plans/PLN-0066-hub-ui-slice-validation-and-lesson.md b/discussion/workflow/plans/PLN-0066-hub-ui-slice-validation-and-lesson.md deleted file mode 100644 index daa75453..00000000 --- a/discussion/workflow/plans/PLN-0066-hub-ui-slice-validation-and-lesson.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -id: PLN-0066 -ticket: prometeu-hub-ui-direction -title: Hub UI Slice Validation and Lesson -status: done -created: 2026-05-15 -ref_decisions: [DEC-0028] -tags: [hub, ui, shell, system-apps, lifecycle, design-system] ---- - -## Briefing - -Validate the completed `DEC-0028` implementation family, collect evidence, and prepare the post-execution lesson required by the repository workflow. - -Source decision: `DEC-0028`. - -## Objective - -Prove that the initial Hub retro Shell UI slice satisfies the accepted decision and leave the discussion workflow ready for housekeeping after implementation. - -## Dependencies - -- `PLN-0062` must be implemented. -- `PLN-0063` must be implemented or explicitly documented as unnecessary because mouse/click was already available. -- `PLN-0064` must be implemented. -- `PLN-0065` must be implemented or explicitly deferred with evidence. - -## Scope - -- Run relevant crate tests. -- Perform manual desktop verification of the end-to-end flow. -- Check that no forbidden scope leaked into implementation. -- Record evidence in plan execution notes or final implementation summary. -- Draft an English lesson after execution is complete. - -## Non-Goals - -- No new UI implementation work except small fixes required to satisfy acceptance criteria. -- No new architecture decisions. -- No lesson before code/spec state is published. -- No housekeeping until plans are done. - -## Execution Method - -1. Run automated tests. - - What changes: execute the crates affected by plans `PLN-0062` through `PLN-0065`. - - How: run targeted cargo tests for firmware/system/host crates. - - Files: test output only; no source changes unless failures expose implementation bugs. - -2. Verify end-to-end desktop behavior. - - What changes: manually exercise Hub -> ShellA -> close -> Hub -> ShellB -> close -> Hub. - - How: run the desktop host or project runner used for Hub boot, click the buttons, and observe lifecycle return. - - Files: none, unless bugs are found. - -3. Check decision compliance. - - What changes: inspect implementation against `DEC-0028` invariants. - - How: verify no toolkit, no catalog, no Tabs/List/Footer, no direct task/process manager mutation from visual components, and task-owned Shell windows. - - Files: implementation files from the prior plans. - -4. Record validation evidence. - - What changes: update the relevant plans or implementation summary with commands run, manual checks, failures, and fixes. - - How: keep evidence concise and tied to acceptance criteria. - - Files: plan artifacts if the workflow records execution notes there. - -5. Prepare post-execution lesson. - - What changes: create an English lesson only after implementation is complete and published. - - How: use `discussion-housekeep` when all plans are done; lesson should explain how to think about Hub visual slices without making lessons normative. - - Files: `discussion/lessons/DSC-0036-prometeu-hub-ui-direction/...`. - -## Acceptance Criteria - -- [x] Automated tests for affected crates pass or failures are documented as unrelated. -- [x] Manual flow passes: Hub -> ShellA -> close -> Hub. -- [x] Manual flow passes: Hub -> ShellB -> close -> Hub. -- [x] Shell windows are task-owned. -- [x] App close uses lifecycle close. -- [x] No complete UI toolkit or catalog was introduced. -- [x] Pixel font integration outcome is recorded. -- [x] A post-execution lesson is ready for housekeeping after plans are marked done. - -## Execution Notes - -Validation evidence: - -- `cargo test -p prometeu-system`: 83 passed. -- `cargo test -p prometeu-firmware`: 17 passed. -- `cargo test -p prometeu-host-desktop-winit`: 25 passed, 5 ignored. -- `discussion validate`: passed. - -The ShellA/ShellB flows were verified through firmware integration tests that -simulate Hub click input and Shell close input. A live desktop manual click -session was not run in this environment; the host crate still compiles and its -test suite passes. - -Lesson prepared: - -- `discussion/lessons/DSC-0036-prometeu-hub-ui-direction/LSN-0045-hub-ui-slices-should-prove-os-boundaries.md` - -## Tests - -- `cargo test -p prometeu-system` -- `cargo test -p prometeu-firmware` -- `cargo test -p prometeu-host-desktop-winit` if host/input code changed -- Manual desktop host verification -- `discussion validate` after marking plans and housekeeping artifacts - -## Affected Artifacts - -- Implementation files touched by `PLN-0062` through `PLN-0065` -- `discussion/workflow/plans/PLN-0062-native-shell-launch-and-lifecycle-wiring.md` -- `discussion/workflow/plans/PLN-0063-hub-mouse-input-and-click-routing.md` -- `discussion/workflow/plans/PLN-0064-retro-hub-home-and-fake-shell-ui.md` -- `discussion/workflow/plans/PLN-0065-pixel-operator-font-integration.md` -- Future lesson under `discussion/lessons/DSC-0036-prometeu-hub-ui-direction/` diff --git a/files/config/runtime-edge-coverage-domains.json b/files/config/runtime-edge-coverage-domains.json index bd9321bc..8a4a77b4 100644 --- a/files/config/runtime-edge-coverage-domains.json +++ b/files/config/runtime-edge-coverage-domains.json @@ -40,7 +40,7 @@ ] }, "firmware": { - "baseline_percent": 72, + "baseline_percent": 80, "paths": [ "crates/console/prometeu-firmware/src/" ]