@semacode/cli 2.3.1 → 3.0.0

package/exemplos/profile_simulation.sema

@@ -1,211 +1,211 @@
-module exemplos.profile.simulation {
-  docs {
-    resumo: "Starter do Profile Simulation com contrato primeiro. Modelo espacial, modo de renderizacao e visual_profile sao eixos separados; THREE_D headless preserva ambos, e PIXEL_8_BIT ou PIXEL_16_BIT nunca substituem spatial_model nem render_mode."
-  }
-
-  type SimulationSpec {
-    fields {
-      objetivo: Texto
-      modelo: Texto
-      assumptions: Lista
-      condicoes_iniciais: Lista
-      condicoes_contorno: Lista
-      outputs: Lista
-      unidades: Lista
-      spatial_model: Texto
-      render_mode: Texto
-      visual_profile: Texto
-      validation: Texto
-      controle: Texto
-      tempo: Texto
-      fidelity: Texto
-      referencia: Texto
-      calibracao: Texto
-      tolerancias: Texto
-      incerteza: Texto
-      telemetria: Texto
-      determinism: Texto
-      seed: Texto
-      snapshot: Texto
-      replay: Texto
-    }
-    invariants {
-      objetivo existe
-      modelo existe
-      assumptions existe
-      condicoes_iniciais existe
-      condicoes_contorno existe
-      outputs existe
-      unidades existe
-      spatial_model existe
-      render_mode existe
-      visual_profile existe
-      validation existe
-      controle existe
-      tempo existe
-      fidelity existe
-      incerteza existe
-    }
-  }
-
-  task validar_simulacao {
-    input {
-      objetivo: Texto required
-      modelo: Texto required
-      assumptions: Lista required
-      condicoes_iniciais: Lista required
-      condicoes_contorno: Lista required
-      outputs: Lista required
-      unidades: Lista required
-      spatial_model: Texto required
-      render_mode: Texto required
-      visual_profile: Texto required
-      validation: Texto required
-      controle: Texto required
-      tempo: Texto required
-      fidelity: Texto required
-      referencia: Texto required
-      calibracao: Texto required
-      tolerancias: Texto required
-      incerteza: Texto required
-      telemetria: Texto required
-      determinism: Texto
-      seed: Texto
-      snapshot: Texto
-      replay: Texto
-      scenario_id: Texto
-      acceptance: Texto
-      batch: Texto
-      replications: Inteiro
-      seed_strategy: Texto
-      aggregation: Texto
-      resource_budget: Texto
-      stop_condition: Texto
-      authority_boundary: Texto
-      fail_safe: Texto
-      human_takeover: Texto
-      isolamento: Texto
-    }
-    output {
-      aprovado: Booleano
-      bloqueios: Lista
-    }
-    rules {
-      modelo deve_ser testavel
-      assumptions deve_ser nao_vazio
-      condicoes_iniciais deve_ser nao_vazio
-      condicoes_contorno deve_ser nao_vazio
-      outputs deve_ser observaveis
-      unidades deve_ser explicitas
-      spatial_model deve_ser em [NON_SPATIAL, TWO_D, TWO_POINT_FIVE_D, THREE_D]
-      render_mode deve_ser em [HEADLESS, TEXT, VISUAL, XR]
-      visual_profile deve_ser em [NONE, PIXEL_8_BIT, PIXEL_16_BIT, RASTER, VECTOR, STYLIZED, REALISTIC]
-      spatial_model deve_ser separado_de render_mode_e_visual_profile
-      render_mode deve_ser exigir_spatial_model_THREE_D_quando_XR
-      render_mode deve_ser exigir_visual_profile_NONE_quando_HEADLESS_ou_TEXT
-      validation deve_ser testavel
-      controle deve_ser em [HUMAN, SCRIPTED, AI, HYBRID, AUTONOMOUS, UNCONTROLLED]
-      tempo deve_ser explicito
-      fidelity deve_ser em [ARCADE, STYLIZED, SYSTEMIC, REALISTIC, CALIBRATED]
-      referencia deve_ser rastreavel
-      calibracao deve_ser ter_metodo_reproduzivel
-      tolerancias deve_ser numericas_com_unidade
-      incerteza deve_ser declarada
-      telemetria deve_ser observavel
-      determinism deve_ser exigir_seed_fixed_step_snapshot_e_replay_quando_declarado
-      scenario_id deve_ser ligado_a_condicoes_e_acceptance_quando_fornecido
-      batch deve_ser exigir_replications_seed_strategy_aggregation_resource_budget_e_stop_condition_quando_fornecido
-      controle deve_ser exigir_authority_boundary_resource_budget_stop_condition_fail_safe_human_takeover_e_isolamento_quando_AUTONOMOUS_ou_UNCONTROLLED
-    }
-    effects {
-      auditoria simulation_profile_exemplo criticidade = media
-    }
-    forbidden {
-      PIXEL_8_BIT_como_spatial_model_ou_render_mode
-      PIXEL_16_BIT_como_spatial_model_ou_render_mode
-      aparencia_visual_provar_fidelidade
-      calibracao_sem_referencia_tolerancia_ou_incerteza
-      determinismo_sem_seed_snapshot_e_replay
-      autonomia_sem_fronteira_budget_parada_e_fail_safe
-    }
-    execucao {
-      idempotencia: verdadeiro
-      timeout: "10s"
-      retry: "nenhum"
-      criticidade_operacional: media
-    }
-    guarantees {
-      aprovado existe
-      bloqueios existe
-    }
-    tests {
-      caso "simulacao 2D retro controlada" {
-        given {
-          objetivo: "comparar fluxo de trafego"
-          modelo: "agentes em grid TWO_D"
-          assumptions: "velocidade limitada"
-          condicoes_iniciais: "100 agentes"
-          condicoes_contorno: "bordas fechadas"
-          outputs: "tempo medio e congestionamento"
-          unidades: "segundos metros agentes"
-          spatial_model: "TWO_D"
-          render_mode: "VISUAL"
-          visual_profile: "PIXEL_16_BIT"
-          validation: "comparar outputs com baseline e tolerancia"
-          controle: "HUMAN"
-          tempo: "FIXED_STEP"
-          fidelity: "SYSTEMIC"
-          referencia: "baseline versionada"
-          calibracao: "metodo reproduzivel"
-          tolerancias: "erro <= 2 percent"
-          incerteza: "intervalo de confianca"
-          telemetria: "metricas por tick"
-        }
-
-        expect {
-          sucesso: verdadeiro
-          aprovado: verdadeiro
-        }
-      }
-
-      caso "simulacao espacial 3D headless autonoma" {
-        given {
-          objetivo: "validar estabilidade orbital"
-          modelo: "mundo espacial THREE_D sem renderer"
-          assumptions: "massa constante"
-          condicoes_iniciais: "seed e snapshot inicial"
-          condicoes_contorno: "limite orbital"
-          outputs: "state digest e result digest"
-          unidades: "metros segundos quilogramas"
-          spatial_model: "THREE_D"
-          render_mode: "HEADLESS"
-          visual_profile: "NONE"
-          validation: "invariantes orbitais e comparacao com dataset"
-          controle: "AUTONOMOUS"
-          tempo: "FIXED_STEP"
-          fidelity: "CALIBRATED"
-          referencia: "dataset versionado"
-          calibracao: "metodo reproduzivel"
-          tolerancias: "erro <= 1 percent"
-          incerteza: "intervalo de confianca"
-          telemetria: "event log por tick"
-          determinism: "SEEDED"
-          seed: "42"
-          snapshot: "state_digest"
-          replay: "event_log"
-          resource_budget: "limite de CPU e memoria"
-          stop_condition: "maximo de 10000 ticks"
-          authority_boundary: "sem escrita externa"
-          fail_safe: "kill switch"
-          human_takeover: "operador pode interromper"
-          isolamento: "sandbox local"
-        }
-
-        expect {
-          sucesso: verdadeiro
-          aprovado: verdadeiro
-        }
-      }
-    }
-  }
-}
+module exemplos.profile.simulation {
+  docs {
+    resumo: "Starter do Profile Simulation com contrato primeiro. Modelo espacial, modo de renderizacao e visual_profile sao eixos separados; THREE_D headless preserva ambos, e PIXEL_8_BIT ou PIXEL_16_BIT nunca substituem spatial_model nem render_mode."
+  }
+
+  type SimulationSpec {
+    fields {
+      objetivo: Texto
+      modelo: Texto
+      assumptions: Lista
+      condicoes_iniciais: Lista
+      condicoes_contorno: Lista
+      outputs: Lista
+      unidades: Lista
+      spatial_model: Texto
+      render_mode: Texto
+      visual_profile: Texto
+      validation: Texto
+      controle: Texto
+      tempo: Texto
+      fidelity: Texto
+      referencia: Texto
+      calibracao: Texto
+      tolerancias: Texto
+      incerteza: Texto
+      telemetria: Texto
+      determinism: Texto
+      seed: Texto
+      snapshot: Texto
+      replay: Texto
+    }
+    invariants {
+      objetivo existe
+      modelo existe
+      assumptions existe
+      condicoes_iniciais existe
+      condicoes_contorno existe
+      outputs existe
+      unidades existe
+      spatial_model existe
+      render_mode existe
+      visual_profile existe
+      validation existe
+      controle existe
+      tempo existe
+      fidelity existe
+      incerteza existe
+    }
+  }
+
+  task validar_simulacao {
+    input {
+      objetivo: Texto required
+      modelo: Texto required
+      assumptions: Lista required
+      condicoes_iniciais: Lista required
+      condicoes_contorno: Lista required
+      outputs: Lista required
+      unidades: Lista required
+      spatial_model: Texto required
+      render_mode: Texto required
+      visual_profile: Texto required
+      validation: Texto required
+      controle: Texto required
+      tempo: Texto required
+      fidelity: Texto required
+      referencia: Texto required
+      calibracao: Texto required
+      tolerancias: Texto required
+      incerteza: Texto required
+      telemetria: Texto required
+      determinism: Texto
+      seed: Texto
+      snapshot: Texto
+      replay: Texto
+      scenario_id: Texto
+      acceptance: Texto
+      batch: Texto
+      replications: Inteiro
+      seed_strategy: Texto
+      aggregation: Texto
+      resource_budget: Texto
+      stop_condition: Texto
+      authority_boundary: Texto
+      fail_safe: Texto
+      human_takeover: Texto
+      isolamento: Texto
+    }
+    output {
+      aprovado: Booleano
+      bloqueios: Lista
+    }
+    rules {
+      modelo deve_ser testavel
+      assumptions deve_ser nao_vazio
+      condicoes_iniciais deve_ser nao_vazio
+      condicoes_contorno deve_ser nao_vazio
+      outputs deve_ser observaveis
+      unidades deve_ser explicitas
+      spatial_model deve_ser em [NON_SPATIAL, TWO_D, TWO_POINT_FIVE_D, THREE_D]
+      render_mode deve_ser em [HEADLESS, TEXT, VISUAL, XR]
+      visual_profile deve_ser em [NONE, PIXEL_8_BIT, PIXEL_16_BIT, RASTER, VECTOR, STYLIZED, REALISTIC]
+      spatial_model deve_ser separado_de render_mode_e_visual_profile
+      render_mode deve_ser exigir_spatial_model_THREE_D_quando_XR
+      render_mode deve_ser exigir_visual_profile_NONE_quando_HEADLESS_ou_TEXT
+      validation deve_ser testavel
+      controle deve_ser em [HUMAN, SCRIPTED, AI, HYBRID, AUTONOMOUS, UNCONTROLLED]
+      tempo deve_ser explicito
+      fidelity deve_ser em [ARCADE, STYLIZED, SYSTEMIC, REALISTIC, CALIBRATED]
+      referencia deve_ser rastreavel
+      calibracao deve_ser ter_metodo_reproduzivel
+      tolerancias deve_ser numericas_com_unidade
+      incerteza deve_ser declarada
+      telemetria deve_ser observavel
+      determinism deve_ser exigir_seed_fixed_step_snapshot_e_replay_quando_declarado
+      scenario_id deve_ser ligado_a_condicoes_e_acceptance_quando_fornecido
+      batch deve_ser exigir_replications_seed_strategy_aggregation_resource_budget_e_stop_condition_quando_fornecido
+      controle deve_ser exigir_authority_boundary_resource_budget_stop_condition_fail_safe_human_takeover_e_isolamento_quando_AUTONOMOUS_ou_UNCONTROLLED
+    }
+    effects {
+      auditoria simulation_profile_exemplo criticidade = media
+    }
+    forbidden {
+      PIXEL_8_BIT_como_spatial_model_ou_render_mode
+      PIXEL_16_BIT_como_spatial_model_ou_render_mode
+      aparencia_visual_provar_fidelidade
+      calibracao_sem_referencia_tolerancia_ou_incerteza
+      determinismo_sem_seed_snapshot_e_replay
+      autonomia_sem_fronteira_budget_parada_e_fail_safe
+    }
+    execucao {
+      idempotencia: verdadeiro
+      timeout: "10s"
+      retry: "nenhum"
+      criticidade_operacional: media
+    }
+    guarantees {
+      aprovado existe
+      bloqueios existe
+    }
+    tests {
+      caso "simulacao 2D retro controlada" {
+        given {
+          objetivo: "comparar fluxo de trafego"
+          modelo: "agentes em grid TWO_D"
+          assumptions: "velocidade limitada"
+          condicoes_iniciais: "100 agentes"
+          condicoes_contorno: "bordas fechadas"
+          outputs: "tempo medio e congestionamento"
+          unidades: "segundos metros agentes"
+          spatial_model: "TWO_D"
+          render_mode: "VISUAL"
+          visual_profile: "PIXEL_16_BIT"
+          validation: "comparar outputs com baseline e tolerancia"
+          controle: "HUMAN"
+          tempo: "FIXED_STEP"
+          fidelity: "SYSTEMIC"
+          referencia: "baseline versionada"
+          calibracao: "metodo reproduzivel"
+          tolerancias: "erro <= 2 percent"
+          incerteza: "intervalo de confianca"
+          telemetria: "metricas por tick"
+        }
+
+        expect {
+          sucesso: verdadeiro
+          aprovado: verdadeiro
+        }
+      }
+
+      caso "simulacao espacial 3D headless autonoma" {
+        given {
+          objetivo: "validar estabilidade orbital"
+          modelo: "mundo espacial THREE_D sem renderer"
+          assumptions: "massa constante"
+          condicoes_iniciais: "seed e snapshot inicial"
+          condicoes_contorno: "limite orbital"
+          outputs: "state digest e result digest"
+          unidades: "metros segundos quilogramas"
+          spatial_model: "THREE_D"
+          render_mode: "HEADLESS"
+          visual_profile: "NONE"
+          validation: "invariantes orbitais e comparacao com dataset"
+          controle: "AUTONOMOUS"
+          tempo: "FIXED_STEP"
+          fidelity: "CALIBRATED"
+          referencia: "dataset versionado"
+          calibracao: "metodo reproduzivel"
+          tolerancias: "erro <= 1 percent"
+          incerteza: "intervalo de confianca"
+          telemetria: "event log por tick"
+          determinism: "SEEDED"
+          seed: "42"
+          snapshot: "state_digest"
+          replay: "event_log"
+          resource_budget: "limite de CPU e memoria"
+          stop_condition: "maximo de 10000 ticks"
+          authority_boundary: "sem escrita externa"
+          fail_safe: "kill switch"
+          human_takeover: "operador pode interromper"
+          isolamento: "sandbox local"
+        }
+
+        expect {
+          sucesso: verdadeiro
+          aprovado: verdadeiro
+        }
+      }
+    }
+  }
+}

package/exemplos/sistemas-interativos/README.md

@@ -1,100 +1,100 @@
-# Interactive system examples
-
-This directory exercises the same declarative control plane across games and simulations. Spatial model, render mode, visual profile, fidelity, control, time, and determinism are independent axes. In particular, `PIXEL_8_BIT` and `PIXEL_16_BIT` are visual profiles attached to a `TWO_D` spatial model and `VISUAL` rendering; they are not spatial models or render modes.
-
-## Coverage matrix
-
-| Fixture | Kind | Spatial model | Render mode | Visual profile | Fidelity | Control | Time |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| `game-3d-human.json` | Game | 3D | Visual | Realistic | Systemic | Human | Real time |
-| `game-2d.json` | Game | 2D | Visual | Vector | Systemic | Human | Fixed step |
-| `game-pixel-8-bit.json` | Game | 2D | Visual | Pixel 8-bit | Arcade | Human | Fixed step |
-| `game-pixel-16-bit.json` | Game | 2D | Visual | Pixel 16-bit | Stylized | Human | Fixed step |
-| `game-xr-human.json` | Game | 3D | XR | Realistic | Stylized | Human | Real time |
-| `hybrid-2-5d.json` | Hybrid | 2.5D | Visual | Stylized | Systemic | Hybrid | Fixed step |
-| `simulation-3d-calibrated-autonomous.json` | Simulation | 3D | Visual | Realistic | Calibrated | Autonomous | Fixed step |
-| `simulation-2d-controlled.json` | Simulation | 2D | Visual | Vector | Systemic | Scripted (controlled) | Fixed step |
-| `simulation-pixel-16-bit.json` | Simulation | 2D | Visual | Pixel 16-bit | Systemic | Uncontrolled | Event driven |
-| `simulation-text-controlled.json` | Simulation | Non-spatial | Text | None | Systemic | Scripted (controlled) | Turn based |
-| `simulation-headless-autonomous-batch.json` | Simulation | Non-spatial | Headless | None | Systemic | Autonomous | Accelerated |
-
-This is a representative matrix, not a Cartesian product of every axis. It exercises every public spatial model (`NON_SPATIAL`, `TWO_D`, `TWO_POINT_FIVE_D`, and `THREE_D`) and render mode (`HEADLESS`, `TEXT`, `VISUAL`, and `XR`), while the canonical catalog and automated tests enumerate the complete compatibility surface. The fixtures intentionally cover human, scripted, autonomous, uncontrolled, and hybrid modes, plus realistic, calibrated, vector, headless, and constrained pixel-art surfaces. A visual profile never makes a simulation scientifically valid; the calibrated fixture therefore declares its reference, method, tolerances, uncertainty, and telemetry separately.
-
-## Validate and plan
-
-From the repository root, after building the CLI:
-
-```powershell
-sema interativo validar exemplos/sistemas-interativos/game-3d-human.json --json
-sema interativo planejar exemplos/sistemas-interativos/simulation-headless-autonomous-batch.json --json
-```
-
-Run the same validation command for every game and simulation JSON in the coverage matrix. Each fixture declares an explicit compatible adapter composition that covers every planned stage capability. Validation and planning are local and declarative: they do not start an engine, mutate a workspace, or prove that an external run occurred.
-
-## Advanced fixtures
-
-The `advanced/` directory mirrors the public P0/P1/P2 JSON schemas used by the
-read-only validators and planners:
-
-| Fixture | Purpose |
-| --- | --- |
-| `temporal-valid.json` and `temporal-evidence-valid.json` | 4D phases/tracks, order invariant, shot, collision, temporal QA, clean-install/launch/smoke requirements, hardware budget, and a complete supplied structural evidence bundle. |
-| `autonomy-repair-valid.json` | `diagnose -> propose -> simulate -> prove` cycle with a derived recovery token, snapshot, checkpoint, resource lock, and rollback plan. |
-| `playtest-fuzz-valid.json` | Bounded deterministic bot, save/load recovery cases, budgets, stop criteria, and required evidence. |
-| `multiplayer-authority-valid.json` | Server authority, sensitive replicated state, conflict handling, reconnect, and security invariants. |
-| `portability-valid.json` | Cross-engine exact, approximate, and unsupported mappings with explicit losses, fallbacks, acceptance criteria, and rollback-ready version migration. |
-| `distributed-workers-valid.json` | Cook, shader, render, and test DAG with worker capabilities, budgets, leases, heartbeats, checkpoints, and evidence requirements. |
-| `engine-snapshot-before-valid.json` and `engine-snapshot-after-valid.json` | Engine-neutral semantic snapshots for a deterministic local diff. |
-| `asset-provenance-valid.json` | Opaque origin reference, license evidence, hashes, transformations, and derivative lineage. |
-| `editor-state-valid.json` | Supplied editor-state description with scene, selection, mode, dirty state, jobs, plug-ins, modals, and opaque process references. |
-| `job-orchestration-valid.json` | Local queue/lock/budget/heartbeat/checkpoint/resume planning input. |
-| `acceptance-lock-valid.json` and `acceptance-context-evaluate-valid.json` | Artifact, scene, and time-range acceptance binding plus an evaluation context. |
-| `multimodal-evidence-valid.json` | Ten typed supplied channels with an independent-verifier descriptor and decision record. |
-| `control-run-definition-valid.json` and `control-run-valid.json` | A complete local binding across definition, canonical plan, temporal pipeline, validation contract, schema inputs, evidence, and rerun validator result. |
-
-Experience IR itself is represented by `experience-ir-valid.json` in the parent
-directory. Its JSON serialization is native; CBOR remains an external-codec
-path.
-
-The advanced files are synthetic validation inputs. In particular,
-`editor-state-valid.json` is **not** proof that an editor was inspected, and
-`multimodal-evidence-valid.json` is **not** captured runtime evidence. The CLI
-does not detect or execute engines, editors, plug-ins, verifiers, processes, or
-workers when reading them.
-
-The control-run fixtures are templates for deterministic binding. The plan and
-result files are intentionally generated by the CLI during tests instead of
-being checked in as stale derived artifacts. See `validar-control-run` in
-`docs/sistemas-interativos.md` for the full command.
-
-## Adapter protocol records
-
-- `protocol-read-only-valid.json` models a successful read-only `DETECT -> PROBE -> SNAPSHOT -> PLAN -> VALIDATE -> EVIDENCE` record.
-- `protocol-mutating-rollback-valid.json` models a mutating adapter whose validation failed and whose rollback completed with a declared rollback evidence identifier.
-
-Validate them with:
-
-```powershell
-sema interativo validar-protocolo exemplos/sistemas-interativos/protocol-read-only-valid.json --json
-sema interativo validar-protocolo exemplos/sistemas-interativos/protocol-mutating-rollback-valid.json --json
-```
-
-The protocol fixtures use real SHA-256 digests of two explicit UTF-8 literals:
-
-| Literal | SHA-256 |
-| --- | --- |
-| `fixture:protocol-input` | `sha256:8faad66a2e59a27af6bbc6e1421493a2f3758f376515c44e2e16fbcb340ac082` |
-| `fixture:protocol-output` | `sha256:4f135cff766c846e90720c6e50676c37a7b98023bbe7b1ef6b3fa46fd54ffc2d` |
-
-Those hashes exist only to exercise protocol structure. They are not runtime observations, artifact evidence, signatures, or authoritative proof.
-
-## Evidence boundary
-
-No core pipeline evidence bundle claiming a real engine run is included. The
-advanced temporal and multimodal records are explicitly synthetic validator
-fixtures. In production, create evidence only from actual runner or adapter
-observations, bind every observation to the selected producer adapter
-ID/version and the exact definition/plan digests, and provide non-empty
-observation data. Even a local `STRUCTURALLY_COMPLETE` result keeps
-`completed: false` and remains non-authoritative until an external trust layer
-supplies the required attestation.
+# Interactive system examples
+
+This directory exercises the same declarative control plane across games and simulations. Spatial model, render mode, visual profile, fidelity, control, time, and determinism are independent axes. In particular, `PIXEL_8_BIT` and `PIXEL_16_BIT` are visual profiles attached to a `TWO_D` spatial model and `VISUAL` rendering; they are not spatial models or render modes.
+
+## Coverage matrix
+
+| Fixture | Kind | Spatial model | Render mode | Visual profile | Fidelity | Control | Time |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| `game-3d-human.json` | Game | 3D | Visual | Realistic | Systemic | Human | Real time |
+| `game-2d.json` | Game | 2D | Visual | Vector | Systemic | Human | Fixed step |
+| `game-pixel-8-bit.json` | Game | 2D | Visual | Pixel 8-bit | Arcade | Human | Fixed step |
+| `game-pixel-16-bit.json` | Game | 2D | Visual | Pixel 16-bit | Stylized | Human | Fixed step |
+| `game-xr-human.json` | Game | 3D | XR | Realistic | Stylized | Human | Real time |
+| `hybrid-2-5d.json` | Hybrid | 2.5D | Visual | Stylized | Systemic | Hybrid | Fixed step |
+| `simulation-3d-calibrated-autonomous.json` | Simulation | 3D | Visual | Realistic | Calibrated | Autonomous | Fixed step |
+| `simulation-2d-controlled.json` | Simulation | 2D | Visual | Vector | Systemic | Scripted (controlled) | Fixed step |
+| `simulation-pixel-16-bit.json` | Simulation | 2D | Visual | Pixel 16-bit | Systemic | Uncontrolled | Event driven |
+| `simulation-text-controlled.json` | Simulation | Non-spatial | Text | None | Systemic | Scripted (controlled) | Turn based |
+| `simulation-headless-autonomous-batch.json` | Simulation | Non-spatial | Headless | None | Systemic | Autonomous | Accelerated |
+
+This is a representative matrix, not a Cartesian product of every axis. It exercises every public spatial model (`NON_SPATIAL`, `TWO_D`, `TWO_POINT_FIVE_D`, and `THREE_D`) and render mode (`HEADLESS`, `TEXT`, `VISUAL`, and `XR`), while the canonical catalog and automated tests enumerate the complete compatibility surface. The fixtures intentionally cover human, scripted, autonomous, uncontrolled, and hybrid modes, plus realistic, calibrated, vector, headless, and constrained pixel-art surfaces. A visual profile never makes a simulation scientifically valid; the calibrated fixture therefore declares its reference, method, tolerances, uncertainty, and telemetry separately.
+
+## Validate and plan
+
+From the repository root, after building the CLI:
+
+```powershell
+sema interativo validar exemplos/sistemas-interativos/game-3d-human.json --json
+sema interativo planejar exemplos/sistemas-interativos/simulation-headless-autonomous-batch.json --json
+```
+
+Run the same validation command for every game and simulation JSON in the coverage matrix. Each fixture declares an explicit compatible adapter composition that covers every planned stage capability. Validation and planning are local and declarative: they do not start an engine, mutate a workspace, or prove that an external run occurred.
+
+## Advanced fixtures
+
+The `advanced/` directory mirrors the public P0/P1/P2 JSON schemas used by the
+read-only validators and planners:
+
+| Fixture | Purpose |
+| --- | --- |
+| `temporal-valid.json` and `temporal-evidence-valid.json` | 4D phases/tracks, order invariant, shot, collision, temporal QA, clean-install/launch/smoke requirements, hardware budget, and a complete supplied structural evidence bundle. |
+| `autonomy-repair-valid.json` | `diagnose -> propose -> simulate -> prove` cycle with a derived recovery token, snapshot, checkpoint, resource lock, and rollback plan. |
+| `playtest-fuzz-valid.json` | Bounded deterministic bot, save/load recovery cases, budgets, stop criteria, and required evidence. |
+| `multiplayer-authority-valid.json` | Server authority, sensitive replicated state, conflict handling, reconnect, and security invariants. |
+| `portability-valid.json` | Cross-engine exact, approximate, and unsupported mappings with explicit losses, fallbacks, acceptance criteria, and rollback-ready version migration. |
+| `distributed-workers-valid.json` | Cook, shader, render, and test DAG with worker capabilities, budgets, leases, heartbeats, checkpoints, and evidence requirements. |
+| `engine-snapshot-before-valid.json` and `engine-snapshot-after-valid.json` | Engine-neutral semantic snapshots for a deterministic local diff. |
+| `asset-provenance-valid.json` | Opaque origin reference, license evidence, hashes, transformations, and derivative lineage. |
+| `editor-state-valid.json` | Supplied editor-state description with scene, selection, mode, dirty state, jobs, plug-ins, modals, and opaque process references. |
+| `job-orchestration-valid.json` | Local queue/lock/budget/heartbeat/checkpoint/resume planning input. |
+| `acceptance-lock-valid.json` and `acceptance-context-evaluate-valid.json` | Artifact, scene, and time-range acceptance binding plus an evaluation context. |
+| `multimodal-evidence-valid.json` | Ten typed supplied channels with an independent-verifier descriptor and decision record. |
+| `control-run-definition-valid.json` and `control-run-valid.json` | A complete local binding across definition, canonical plan, temporal pipeline, validation contract, schema inputs, evidence, and rerun validator result. |
+
+Experience IR itself is represented by `experience-ir-valid.json` in the parent
+directory. Its JSON serialization is native; CBOR remains an external-codec
+path.
+
+The advanced files are synthetic validation inputs. In particular,
+`editor-state-valid.json` is **not** proof that an editor was inspected, and
+`multimodal-evidence-valid.json` is **not** captured runtime evidence. The CLI
+does not detect or execute engines, editors, plug-ins, verifiers, processes, or
+workers when reading them.
+
+The control-run fixtures are templates for deterministic binding. The plan and
+result files are intentionally generated by the CLI during tests instead of
+being checked in as stale derived artifacts. See `validar-control-run` in
+`docs/sistemas-interativos.md` for the full command.
+
+## Adapter protocol records
+
+- `protocol-read-only-valid.json` models a successful read-only `DETECT -> PROBE -> SNAPSHOT -> PLAN -> VALIDATE -> EVIDENCE` record.
+- `protocol-mutating-rollback-valid.json` models a mutating adapter whose validation failed and whose rollback completed with a declared rollback evidence identifier.
+
+Validate them with:
+
+```powershell
+sema interativo validar-protocolo exemplos/sistemas-interativos/protocol-read-only-valid.json --json
+sema interativo validar-protocolo exemplos/sistemas-interativos/protocol-mutating-rollback-valid.json --json
+```
+
+The protocol fixtures use real SHA-256 digests of two explicit UTF-8 literals:
+
+| Literal | SHA-256 |
+| --- | --- |
+| `fixture:protocol-input` | `sha256:8faad66a2e59a27af6bbc6e1421493a2f3758f376515c44e2e16fbcb340ac082` |
+| `fixture:protocol-output` | `sha256:4f135cff766c846e90720c6e50676c37a7b98023bbe7b1ef6b3fa46fd54ffc2d` |
+
+Those hashes exist only to exercise protocol structure. They are not runtime observations, artifact evidence, signatures, or authoritative proof.
+
+## Evidence boundary
+
+No core pipeline evidence bundle claiming a real engine run is included. The
+advanced temporal and multimodal records are explicitly synthetic validator
+fixtures. In production, create evidence only from actual runner or adapter
+observations, bind every observation to the selected producer adapter
+ID/version and the exact definition/plan digests, and provide non-empty
+observation data. Even a local `STRUCTURALLY_COMPLETE` result keeps
+`completed: false` and remains non-authoritative until an external trust layer
+supplies the required attestation.

package/exemplos/sistemas-interativos/advanced/acceptance-context-evaluate-valid.json

@@ -1,5 +1,5 @@
-{
-  "artifactDigest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
-  "sceneId": "scene.main",
-  "timeRange": { "start": 0, "end": 240, "unit": "FRAME" }
-}
+{
+  "artifactDigest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
+  "sceneId": "scene.main",
+  "timeRange": { "start": 0, "end": 240, "unit": "FRAME" }
+}