oxe-cc 1.8.3 → 1.10.0

package/oxe/templates/SPEC.template.md

@@ -72,6 +72,16 @@ Use **IDs estáveis** (A1, A2, …) para o plano e o verify vincularem cada tare
 - Conteúdo mínimo obrigatório por área/módulo: …
 - Exemplos concretos que devem existir na entrega: …
 
+## Entradas visuais e interpretação
+
+- Status: ready | partial | blocked | not_applicable
+- Artefato visual: `.oxe/investigations/visual/VISUAL-INPUTS.md` | not_applicable
+- Imagens/anexos usados como fonte: …
+- Capacidade visual do runtime hospedeiro: supported | unsupported | unknown
+- Requisitos derivados de imagem: R-ID/A* | not_applicable
+- Ambiguidades visuais ainda abertas: …
+- Observação: se a imagem for crítica para UI, layout, fluxo ou regra funcional, `VISUAL-INPUTS` precisa estar pronto antes do PLAN sustentar confiança > 90%.
+
 ## Suposições
 
 - …

package/oxe/templates/VISUAL-INPUTS.template.json

@@ -0,0 +1,27 @@
+{
+  "schema_version": "1",
+  "generated_at": "YYYY-MM-DDTHH:mm:ssZ",
+  "ready": false,
+  "visualInputReadiness": "blocked",
+  "critical_gaps": [],
+  "inputs": [
+    {
+      "id": "VI-01",
+      "source_ref": "chat-attachment",
+      "source_kind": "visual_attachment",
+      "runtime_support": "unknown",
+      "inspection_status": "unavailable",
+      "reproducibility": "chat_attachment_only",
+      "critical": true,
+      "confidence": 0,
+      "visual_summary": "",
+      "detected_text": [],
+      "layout_regions": [],
+      "ui_components": [],
+      "states": [],
+      "ambiguities": [],
+      "derived_requirements": [],
+      "limitations": []
+    }
+  ]
+}

package/oxe/templates/VISUAL-INPUTS.template.md

@@ -0,0 +1,36 @@
+# OXE — Visual Inputs
+
+> Extração textual estruturada de imagens/anexos visuais usados na SPEC. O OXE não interpreta pixels nativamente; este artefato registra o que o agente hospedeiro conseguiu inspecionar e o que virou requisito.
+
+## Status
+
+- **Status:** ready | partial | blocked | not_applicable
+- **Runtime com visão:** supported | unsupported | unknown
+- **Critical gaps abertos:** nenhum | listar
+
+## Entradas
+
+### VI-01 — (nome curto da imagem)
+
+- **Source ref:** chat-attachment | path relativo | URL | textual_only
+- **Source kind:** visual_attachment | screenshot | mockup | image_description
+- **Runtime support:** vision_supported | vision_unavailable | unknown
+- **Inspection status:** inspected | partial | unavailable | not_applicable
+- **Reproducibility:** local_file | materialized_copy | chat_attachment_only | textual_only
+- **Critical:** true | false
+- **Confidence:** 0.00–1.00
+- **Visual summary:** descrição objetiva do que aparece.
+- **Detected text:** textos legíveis extraídos da imagem, ou `not_applicable`.
+- **Layout regions:** header, sidebar, content, footer, cards, modals etc.
+- **UI components:** botões, campos, tabelas, cards, menus, gráficos etc.
+- **States inferred:** loading, empty, error, success, disabled, hover, selected etc.
+- **Ambiguities:** o que não foi possível confirmar visualmente.
+- **Derived requirements:** R-ID/A* que dependem desta imagem.
+- **Limitations:** limitações da inspeção ou do runtime.
+
+## Regras
+
+- Imagem crítica para UI, layout, fluxo ou regra funcional exige `inspection_status: inspected`, descrição suficiente e requisitos derivados explícitos.
+- Anexo efêmero de chat deve ser tratado como `chat_attachment_only`; não é referência reproduzível por padrão.
+- Se o runtime não suportar visão, usar `inspection_status: unavailable` e bloquear requisitos visuais críticos até o usuário fornecer descrição textual suficiente.
+- Não inventar detalhes invisíveis na imagem; registrar como `Ambiguities`.

package/oxe/workflows/execute.md

@@ -131,6 +131,8 @@ Quando o comando `**Verificar:**` de uma tarefa `Tn` falha, **não parar silenci
 
 O `execute` é **pack-first**, não apenas `plan-first`. Esses artefatos existem para impedir improviso de paths, interfaces, referências externas e fixtures. Se estiverem ausentes, inconsistentes ou com `critical_gap`, a execução deve bloquear e devolver para replanejamento.
 
+**Entradas visuais como gate:** quando `SPEC.md`, `UI-SPEC.md`, `PLAN.md` ou `REFERENCE-ANCHORS.md` referenciarem imagem, screenshot, mockup, anexo visual ou `VI-*`, ler `.oxe/investigations/visual/VISUAL-INPUTS.md|json` antes de qualquer mutação. Se `visualInputReadiness: blocked`, se uma entrada crítica estiver `inspection_status != inspected`, ou se a imagem existir só como anexo efêmero sem extração textual suficiente, bloquear e recomendar `/oxe-plan --replan` ou `/oxe-spec` para materializar a descrição visual.
+
 **Agente executor especializado:** quando um runtime suportar agentes OXE, o papel esperado é `oxe-executor`. Para ondas com UI, debug, integração ou validação pesada, consultar os agentes especializados correspondentes, mas manter o estado operacional em `.oxe/` e no runtime.
 
 **Runtime operacional:** usar `EXECUTION-RUNTIME.md` do escopo resolvido como artefato tático da execução. Ele deve refletir agentes ativos, onda atual, handoffs, evidências, retries, checkpoints pendentes e tarefas bloqueadas. O `PLAN.md` continua estratégico; o runtime regista a operação do ciclo.
@@ -203,6 +205,7 @@ Se condições não atendidas: responder sem persona; sugerir `/oxe-plan-agent`
    - `FIXTURE-PACK.json` deve existir, estar `ready` e cobrir tarefas de parser/layout/integração/transformação/fila/migração/builder;
    - se algum pack tiver `critical_gap`, **não executar**. Registrar o bloqueio explicitamente em `EXECUTION-RUNTIME.md` / `STATE.md` e recomendar um único próximo passo: normalmente `/oxe-plan --replan`.
    - se uma tarefa mutável usar path com `...`, símbolo indefinido, write-set aberto ou fixture obrigatória ausente, bloquear a tarefa mesmo que o `PLAN.md` pareça completo.
+   - se houver requisito visual crítico sem `VISUAL-INPUTS.ready === true` ou sem anchor visual resolvido, bloquear a tarefa antes de mutar UI/código.
 3. Antes da primeira mudança, verificar `CHECKPOINTS.md` e `EXECUTION-RUNTIME.md` do escopo resolvido:
    - se houver checkpoint `pending_approval` que se aplique à onda atual, **não avançar**;
    - inicializar ou atualizar o runtime com onda atual, status, agentes ativos, handoffs e evidências esperadas.

package/oxe/workflows/plan.md

@@ -34,12 +34,13 @@ Contrato de implementação por tarefa `Tn`, com:
 - snippets somente quando ancorados em evidência local ou materializada.
 - sequência mínima de implementação, rollback/contensão para risco high/critical e imports/dependências obrigatórias.
 
-### REFERENCE-ANCHORS
-Materializa referências críticas que hoje ficam frouxas no plano:
-- predecessor, layout, contrato externo ou `external-ref`;
-- origem local ou materializada em `.oxe/investigations/externals/`;
-- `source_ref`, `path`, `relevance`, `action`, `summary`, `status`;
-- estados válidos: `resolved`, `missing`, `stale`, `conflicting`, `not_applicable`.
+### REFERENCE-ANCHORS
+Materializa referências críticas que hoje ficam frouxas no plano:
+- predecessor, layout, contrato externo ou `external-ref`;
+- origem local ou materializada em `.oxe/investigations/externals/`;
+- `source_ref`, `path`, `relevance`, `action`, `summary`, `status`;
+- estados válidos: `resolved`, `missing`, `stale`, `conflicting`, `not_applicable`.
+- referências visuais vindas de imagem/screenshot/mockup devem usar `source_type="visual_attachment|screenshot|mockup|image_description"`, apontar `visual_ref="VI-*"` e declarar `extraction_confidence`, `reproducibility`, limitações e requisitos derivados.
 
 ### FIXTURE-PACK
 Fixtures mínimos por fluxo/tarefa de risco:
@@ -52,6 +53,7 @@ Regra de readiness:
 - `IMPLEMENTATION-PACK` precisa estar `ready`;
 - `REFERENCE-ANCHORS` não pode ter âncora crítica em `missing|stale|conflicting`;
 - `FIXTURE-PACK` é obrigatório para tarefas mutáveis com parser/layout/integração/transformação/fila/migração/builder;
+- se a SPEC depender de entrada visual crítica, `VISUAL-INPUTS` precisa estar `ready` e todo requisito visual crítico precisa de anchor resolvido;
 - qualquer `critical_gap` aberto derruba a prontidão executável do plano.
 
 **Contrato adicional para app/UI estático:** quando a trilha for página HTML/CSS/JS, dashboard, microsite, app sem framework ou experiência educacional:
@@ -104,7 +106,8 @@ Resumo operacional:
 - **LESSONS + OBS juntos:** se houver tanto LESSONS quanto OBS pendentes, LESSONS orientam o *como planejar* e OBS orientam o *o que incluir*. Não confundir os papéis.
 - Não inventar APIs inexistentes: cruzar com **STRUCTURE.md**, **INTEGRATIONS.md** e arquivos reais; respeitar **CONCERNS.md** (evitar agravar dívida conhecida sem tarefa explícita).
 - Se existir **`.oxe/NOTES.md`**, rever entradas em aberto: incorporar em tarefas (com **Aceite vinculado** quando aplicável) ou registar na secção **Replanejamento** / nota explícita *fora de âmbito desta trilha*. Se não existir e houver necessidade de registrar notas, criar a partir de `oxe/templates/NOTES.template.md`.
-- Se existir `UI-SPEC.md` no escopo resolvido, as tarefas de UI devem referenciar secções do UI-SPEC no texto de **Implementação** ou **Verificar**.
+- Se existir `UI-SPEC.md` no escopo resolvido, as tarefas de UI devem referenciar secções do UI-SPEC no texto de **Implementação** ou **Verificar**.
+- Se existir `VISUAL-INPUTS.md|json` no escopo resolvido, ou se a SPEC declarar entradas visuais críticas, ler antes de definir tarefas de UI. Tarefa que implemente layout, copy, componente, fluxo ou estado derivado de imagem deve citar `VI-*` no `REFERENCE-ANCHORS` e no `IMPLEMENTATION-PACK`.
 - Se existir `DISCUSS.md` no escopo resolvido, alinhar tarefas às decisões registradas. Referenciar IDs **D-NN** no campo **Decisão vinculada:** de cada tarefa impactada — se nenhuma decisão impactar a tarefa, omitir o campo. A rastreabilidade D-NN → Tn → verify é usada pela seção **Fidelidade de decisões** do verify.
 - Se existir `RESEARCH.md` e notas em `research/*.md` do escopo resolvido, ler o índice e as notas cujo **Tema** cruza o âmbito do plano (ou as mais recentes relevantes). Se o índice marcar **Estado** pendente em tópico bloqueante, pedir nova sessão **research** ou **discuss**, ou registar **suposição explícita** no PLAN antes de ondas que dependam dessa decisão.
 - Se existir `plan-agents.json` no escopo resolvido (gerado por **`/oxe-plan-agent`**), um **--replan** ou renumerar tarefas deve **atualizar o JSON em conjunto** com o `PLAN.md` (cobertura `taskIds`, ondas e dependências entre agentes) — ver **`oxe/workflows/plan-agent.md`**. Preferir **`/oxe-plan-agent --replan`** para regerar **`runId`**, **`lifecycle`** (`pending_execute`) e alinhar **STATE.md**; se só **`/oxe-plan`** for usado, ou o JSON fica manualmente sincronizado, ou marcar no JSON `lifecycle.invalidatedBy: new_plan` até novo plan-agent.
@@ -488,8 +491,9 @@ Antes de finalizar a resposta ao utilizador, o agente **deve** percorrer este ga
 14. **Cobertura R-ID:** se `SPEC.md` contiver tabela de requisitos com IDs `R-NN` e status `v1`/`v2`, cada R-ID em escopo deve ter ao menos um critério A* mapeado em **Aceite vinculado:** de alguma tarefa — rastrear `R-NN → A* → Tn`. R-IDs com `v1`/`v2` sem nenhuma tarefa associada = falha do gate; documentar como gap explícito quando intencional (ex.: `<!-- R-03: adiado para próximo ciclo -->`).
 15. **Contexto estruturado:** se houver pack do workflow `plan`, as lacunas e conflitos críticos do pack aparecem na autoavaliação do plano ou são explicitamente dados como resolvidos durante a leitura direta.
 16. **Implementation contract:** toda tarefa mutável deve aparecer em `IMPLEMENTATION-PACK.json` com `exact_paths`, `symbols`, `contracts`, `write_set: "closed"`, `expected_checks` e `ready: true`. Path com `...`, símbolo indefinido ou contrato ausente = falha do gate.
-17. **Reference anchors:** toda referência `external-ref`, "copiar do predecessor", "usar layout X" ou equivalente deve aparecer em `REFERENCE-ANCHORS.md` com `status: resolved`. Âncora crítica em `missing|stale|conflicting` = falha do gate.
-18. **Fixture coverage:** toda tarefa de parser/layout/integração/transformação/fila/migração/builder deve ter fixture `ready` em `FIXTURE-PACK.json`, salvo `not_applicable` explicitamente justificado. Ausência de fixture em tarefa de risco = falha do gate.
+17. **Reference anchors:** toda referência `external-ref`, "copiar do predecessor", "usar layout X" ou equivalente deve aparecer em `REFERENCE-ANCHORS.md` com `status: resolved`. Âncora crítica em `missing|stale|conflicting` = falha do gate.
+17a. **Visual anchors:** se a SPEC ou UI-SPEC depender de imagem/screenshot/mockup, todo requisito visual crítico deve ter `VISUAL-INPUTS` pronto e anchor visual `resolved`. `chat_attachment_only` sem extração textual suficiente = falha do gate.
+18. **Fixture coverage:** toda tarefa de parser/layout/integração/transformação/fila/migração/builder deve ter fixture `ready` em `FIXTURE-PACK.json`, salvo `not_applicable` explicitamente justificado. Ausência de fixture em tarefa de risco = falha do gate.
 19. **Confiança > 90 de verdade:** `Confiança > 90%` só é válida se `IMPLEMENTATION-PACK`, `REFERENCE-ANCHORS` e `FIXTURE-PACK` estiverem íntegros e sem `critical_gap` aberto. Caso contrário, reduzir a confiança para `<= 90%` e recomendar refino.
 
 Se após correções estruturais persistir ambiguidade de produto: **uma** frase recomendando `oxe:discuss` ou `oxe:spec`.

package/oxe/workflows/references/workflow-runtime-contracts.json

@@ -266,8 +266,9 @@
         "session_summary",
         "plan",
         "implementation_pack_json",
-        "reference_anchors",
-        "fixture_pack_json",
+        "reference_anchors",
+        "visual_inputs_json",
+        "fixture_pack_json",
         "runtime",
         "verify",
         "active_run",
@@ -327,8 +328,9 @@
         "runtime",
         "checkpoints",
         "implementation_pack_json",
-        "reference_anchors",
-        "fixture_pack_json"
+          "reference_anchors",
+          "visual_inputs_json",
+          "fixture_pack_json"
       ],
       "optional_artifacts": [
         "plan",
@@ -350,10 +352,11 @@
           "state",
           "runtime",
           "checkpoints",
-          "plan",
-          "implementation_pack_json",
-          "reference_anchors",
-          "fixture_pack_json",
+          "plan",
+          "implementation_pack_json",
+          "reference_anchors",
+          "visual_inputs_json",
+          "fixture_pack_json",
           "quick",
           "phase_summary"
         ],
@@ -361,10 +364,11 @@
           "state",
           "runtime",
           "checkpoints",
-          "plan",
-          "implementation_pack_json",
-          "reference_anchors",
-          "fixture_pack_json",
+          "plan",
+          "implementation_pack_json",
+          "reference_anchors",
+          "visual_inputs_json",
+          "fixture_pack_json",
           "quick",
           "phase_summary",
           "session_summary",
@@ -380,8 +384,10 @@
           "plan",
           "implementation_pack_md",
           "implementation_pack_json",
-          "reference_anchors",
-          "fixture_pack_md",
+          "reference_anchors",
+          "visual_inputs_md",
+          "visual_inputs_json",
+          "fixture_pack_md",
           "fixture_pack_json",
           "quick",
           "active_run",
@@ -543,8 +549,10 @@
         "calibration",
         "implementation_pack_md",
         "implementation_pack_json",
-        "reference_anchors",
-        "fixture_pack_md",
+        "reference_anchors",
+        "visual_inputs_md",
+        "visual_inputs_json",
+        "fixture_pack_md",
         "fixture_pack_json"
       ],
       "context_tiers": {
@@ -566,8 +574,9 @@
           "capabilities_index",
           "checkpoints",
           "implementation_pack_json",
-          "reference_anchors",
-          "fixture_pack_json"
+        "reference_anchors",
+        "visual_inputs_json",
+        "fixture_pack_json"
         ],
         "full": [
           "state",
@@ -582,10 +591,12 @@
           "azure_inventory",
           "checkpoints",
           "calibration",
-          "implementation_pack_md",
-          "implementation_pack_json",
-          "reference_anchors",
-          "fixture_pack_md",
+          "implementation_pack_md",
+          "implementation_pack_json",
+          "reference_anchors",
+          "visual_inputs_md",
+          "visual_inputs_json",
+          "fixture_pack_md",
           "fixture_pack_json"
         ]
       },
@@ -611,9 +622,11 @@
         "state",
         "spec"
       ],
-      "optional_artifacts": [
-        "plan",
-        "project_summary",
+      "optional_artifacts": [
+        "plan",
+        "visual_inputs_md",
+        "visual_inputs_json",
+        "project_summary",
         "session_summary",
         "phase_summary",
         "capabilities_index"
@@ -775,10 +788,12 @@
         "state"
       ],
       "optional_artifacts": [
-        "discuss",
-        "spec",
-        "investigations_index",
-        "project_summary",
+        "discuss",
+        "spec",
+        "investigations_index",
+        "visual_inputs_md",
+        "visual_inputs_json",
+        "project_summary",
         "session_summary",
         "phase_summary",
         "codebase_overview",

package/oxe/workflows/spec.md

@@ -48,6 +48,14 @@ Se **`.oxe/config.json`** tiver `discuss_before_plan: true`: mencionar no final
 - interações mínimas esperadas;
 - regras objetivas de responsividade e acessibilidade;
 - critérios de aceite verificáveis por comportamento visível, não só por intenção narrativa.
+
+**Entradas visuais / imagens anexadas:** quando o usuário enviar ou mencionar imagem, screenshot, mockup, wireframe ou anexo visual:
+- deixar explícito que a inspeção visual depende do runtime hospedeiro (Copilot/Claude/Codex/etc.) e do modelo ativo;
+- se o runtime permitir ver a imagem, antes de escrever requisitos gerar `.oxe/investigations/visual/VISUAL-INPUTS.md` e `.oxe/investigations/visual/VISUAL-INPUTS.json` usando `oxe/templates/VISUAL-INPUTS.template.*`;
+- se o runtime não permitir ver a imagem, registrar `inspection_status: unavailable`, não inventar detalhes e pedir descrição textual quando a imagem for crítica;
+- tratar anexo efêmero de chat como `reproducibility: chat_attachment_only`, salvo se houver arquivo local/materializado;
+- requisitos derivados de imagem devem apontar para `VI-*` e para um anchor visual em `REFERENCE-ANCHORS` no plano;
+- imagem crítica para UI, layout, fluxo ou regra funcional sem extração textual suficiente deve virar bloqueio explícito para `execute`.
 
 **Resolução de sessão:** antes de ler ou escrever artefatos desta trilha, resolver `active_session` em `.oxe/STATE.md` conforme `oxe/workflows/references/session-path-resolution.md`. Com sessão ativa:
 - `SPEC.md`, `ROADMAP.md` e `DISCUSS.md` vivem em `.oxe/<active_session>/spec/`
@@ -55,19 +63,21 @@ Se **`.oxe/config.json`** tiver `discuss_before_plan: true`: mencionar no final
 - `LESSONS.md` continua global em `.oxe/global/LESSONS.md`
 - sem sessão ativa, manter o modo legado na raiz `.oxe/`
 
-Ler no início:
+Ler no início:
 - `.oxe/STATE.md` — fase atual, decisões, workstream ativo
 - `EXECUTION-RUNTIME.md`, `CHECKPOINTS.md` e `memory/` do escopo ativo se existirem — usar como contexto auxiliar, nunca como substituto da SPEC
 - `.oxe/codebase/OVERVIEW.md` e `STACK.md` se existirem — não contradizer o repo
 - **OBS do escopo ativo** — se houver entradas `pendente` com impacto `spec` ou `all`, incorporá-las na Fase 3 (Requisitos) e marcá-las `incorporada → spec (data)` após uso
 - **`.oxe/global/LESSONS.md`** — se existir, ler entradas com `Aplicar em: spec` e status `ativo`. **Priorizar entradas com `Frequência >= 2` ou `Impacto: alto`** — aplicar como restrições explícitas. Entradas com `Frequência: 1` e `Impacto: baixo` são contexto secundário. Usar durante a Fase 1 (perguntas) e Fase 3 (requisitos). Exemplo: se uma lição diz "perguntar explicitamente sobre integração com X", adicionar essa pergunta no Bloco B da Fase 1.
-- `.oxe/CAPABILITIES.md` e `.oxe/INVESTIGATIONS.md` — usar para sugerir capacidades e pesquisas já existentes antes de abrir novas lacunas
+- `.oxe/CAPABILITIES.md` e `.oxe/INVESTIGATIONS.md` — usar para sugerir capacidades e pesquisas já existentes antes de abrir novas lacunas
+- `.oxe/investigations/visual/VISUAL-INPUTS.md|json` — se existirem ou se houver imagem/anexo no chat, usar como fonte visual estruturada; quando ausentes e imagem for crítica, gerar antes de fechar a SPEC
 - Se o problema tocar Azure, ler `.oxe/cloud/azure/profile.json`, `auth-status.json` e `INVENTORY.md` antes de fechar requisitos; se o inventário estiver ausente ou stale, exigir discovery via `oxe-cc azure sync` antes de consolidar a spec
 
 **Brownfield (COBOL, JCL, copybooks, VB6, SP):** quando o objetivo for documentar ou planear migração, ver **`oxe/workflows/references/legacy-brownfield.md`** — épicos por trilha, critérios A* verificáveis por Grep/leitura/checklist.
 
-Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.template.md`**.
-</context>
+Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.template.md`**.
+Para entradas visuais, usar também **`oxe/templates/VISUAL-INPUTS.template.md`** e **`oxe/templates/VISUAL-INPUTS.template.json`**.
+</context>
 
 <fase_1_perguntas>
 ## Fase 1 — Perguntas
@@ -101,14 +111,15 @@ Usar templates: **`oxe/templates/SPEC.template.md`** e **`oxe/templates/ROADMAP.
 - Rodada 3 (máx): apenas se ainda houver ambiguidade crítica
 - Após rodada 3: avançar para Fase 2 mesmo com suposições explícitas
 
-**Ao final:** "Acho que entendi completamente. Confirma antes de avançarmos para pesquisa/requisitos? [resumo em 3-5 bullets]"
-
-**Registar incertezas estruturadas:** ao fim de cada rodada, consolidar:
+**Ao final:** "Acho que entendi completamente. Confirma antes de avançarmos para pesquisa/requisitos? [resumo em 3-5 bullets]"
+
+**Registar incertezas estruturadas:** ao fim de cada rodada, consolidar:
 - o que já está estável;
 - o que segue ambíguo;
 - quais evidências faltam;
 - quais riscos podem reduzir a confiança do plano.
-- quais anchors, fixtures ou investigações serão obrigatórios para permitir `Confiança > 90%` no plano.
+- quais anchors, fixtures ou investigações serão obrigatórios para permitir `Confiança > 90%` no plano.
+- se houver imagem/anexo visual: quais elementos foram inspecionados, quais ficaram ambíguos e se `VISUAL-INPUTS` está `ready`, `partial` ou `blocked`.
 </fase_1_perguntas>
 
 <fase_2_pesquisa>

package/oxe/workflows/ui-spec.md

@@ -14,11 +14,12 @@ Produzir **`.oxe/UI-SPEC.md`**: contrato de UI/UX derivado de **`.oxe/SPEC.md`**
 - Se o projeto **não** tiver interface (só API/CLI/backend), não gerar UI-SPEC; indicar no chat que esta vertical não se aplica.
 - Não substituir a SPEC: UI-SPEC **refina** entrega visual/UX alinhada aos **A***.
 - Secções obrigatórias em `UI-SPEC.md`: **Âmbito** (ecrãs/componentes), **Design system**, **Tokens**, **Estados** (vazio/carregamento/erro/sucesso), **Copywriting**, **Acessibilidade** (foco, labels, teclado), **Breakpoints**, **Registry safety** e **Checker sign-off**.
+- Se existir `.oxe/investigations/visual/VISUAL-INPUTS.md|json`, usar como fonte primária para layout, hierarquia visual, componentes, copy, estados inferidos e ambiguidades. Cada decisão derivada de imagem deve citar `VI-*`; não inferir detalhes não visíveis.
 - Agentes úteis: `oxe-ui-researcher` cria o contrato; `oxe-ui-checker` valida se ele é implementável antes do plano.
-</context>
+</context>
 
 <process>
-1. Resolver `active_session` conforme `session-path-resolution.md`; ler `SPEC.md` do escopo resolvido e, se existirem, `OVERVIEW.md` / `CONVENTIONS.md` em `.oxe/codebase/`.
+1. Resolver `active_session` conforme `session-path-resolution.md`; ler `SPEC.md` do escopo resolvido e, se existirem, `OVERVIEW.md` / `CONVENTIONS.md` em `.oxe/codebase/` e `VISUAL-INPUTS.md|json`.
 2. Criar ou atualizar **`UI-SPEC.md`** em `.oxe/<active_session>/spec/` (ou `.oxe/` legado) com as secções acima preenchidas de forma verificável (checklist ou critérios numerados **U1**, **U2**… opcionais). Se componente externo/registry for citado, registrar origem, inspeção mínima e risco.
 3. Atualizar **`.oxe/STATE.md`** global: nota de fase ou próximo passo `oxe:plan` (se ainda não há PLAN) ou manter `oxe:execute` se o plano já referencia UI.
 4. Resumo no chat: o que ficou no UI-SPEC e como o **`/oxe-plan`** deve citar as secções (ex.: “cumprir UI-SPEC §2”).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oxe-cc",
-  "version": "1.8.3",
+  "version": "1.10.0",
   "description": "OXE — spec-driven workflows in .oxe/ with runtime enterprise, evidence-first verification and multi-runtime integrations (npx)",
   "license": "MIT",
   "author": "",
@@ -71,13 +71,16 @@
     "test:root": "node --test tests/install.test.cjs tests/oxe-project-health.test.cjs tests/oxe-dashboard.test.cjs tests/oxe-operational.test.cjs tests/oxe-azure.test.cjs tests/oxe-sdk.test.cjs tests/oxe-manifest.test.cjs tests/oxe-agent-install.test.cjs tests/oxe-install-resolve-full.test.cjs tests/oxe-health-extended.test.cjs tests/oxe-workflows-edge.test.cjs tests/oxe-sdk-edge.test.cjs tests/oxe-cli-edge.test.cjs tests/oxe-npm-version.test.cjs tests/oxe-scripts.test.cjs tests/oxe-retro-health.test.cjs tests/oxe-security-permissions.test.cjs tests/oxe-runtime-semantics.test.cjs tests/oxe-plugins.test.cjs",
     "test:runtime": "cd packages/runtime && npm test",
     "test:runtime-smoke": "node scripts/runtime-smoke-matrix.cjs",
+    "test:runtime-real": "node scripts/runtime-real-suite.cjs",
     "test:recovery-fixtures": "node scripts/run-recovery-fixtures.cjs",
     "test:multi-agent-soak": "node scripts/run-multi-agent-soak.cjs",
-    "test": "npm run build:runtime && npm run test:root && npm run test:runtime && npm run test:runtime-smoke && npm run test:recovery-fixtures && npm run test:multi-agent-soak",
+    "test:multi-agent-real": "node scripts/run-multi-agent-real.cjs",
+    "test": "npm run build:runtime && npm run test:root && npm run test:runtime && npm run test:runtime-smoke && npm run test:runtime-real && npm run test:recovery-fixtures && npm run test:multi-agent-soak && npm run test:multi-agent-real",
     "test:coverage": "c8 --check-coverage --lines 82 --functions 85 --branches 58 --statements 82 npm test",
     "scan:assets": "node scripts/oxe-assets-scan.cjs",
+    "release:pack-check": "node scripts/release-pack-check.cjs",
     "build:vscode-ext": "cd vscode-extension && npx @vscode/vsce package --no-yarn --allow-missing-repository",
-    "prepublishOnly": "npm test && npm run scan:assets && npm run build:vscode-ext && npm run release:manifest && node bin/oxe-cc.js --version"
+    "prepublishOnly": "npm test && npm run scan:assets && npm run build:vscode-ext && npm run release:manifest && npm run release:pack-check && node bin/oxe-cc.js --version"
   },
   "c8": {
     "all": true,

package/packages/runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@oxe/runtime",
-  "version": "1.8.3",
+  "version": "1.10.0",
   "private": true,
   "license": "MIT",
   "description": "OXE agentic execution engine — enterprise runtime core",