@semacode/cli 2.2.0 → 2.3.0

package/docs/descoberta-capacidades.md

@@ -0,0 +1,106 @@
+# Capability Discovery
+
+Sema exposes one explainable catalog so an AI can distinguish a validation
+profile, an orchestration pipeline, a specialized workflow, a generator, a
+governance gate, an adapter descriptor, and an opaque capability token.
+
+Discovery is local, deterministic, and read-only. It recommends or explains a
+capability but never executes the recommended command:
+
+```bash
+sema descobrir catalogo --json
+sema descobrir recomendar --intencao "validar simulador 3D autonomo calibrado" --json
+sema descobrir recomendar --intencao "port a 16-bit game to another engine and declare losses" --json
+sema descobrir explicar interactive.portability --json
+sema pipeline listar --json
+sema pipeline descrever interactive.playtest --json
+sema capabilities --json
+```
+
+The response schema is `sema.discovery/v1` and always reports:
+
+- `executed: false`;
+- `workspaceMutated: false`;
+- `externalCalls: false`;
+- actionable command templates with placeholders;
+- required inputs and execution boundaries;
+- matched signals, reasons, missing inputs, and stable scores.
+
+Advanced interactive intent is routed to the narrowest local validator or
+analyzer (`validar-temporal`, `validar-playtest-fuzz`, `analisar-portabilidade`,
+and peers). A broad profile or engine descriptor does not outrank that specific
+pipeline, and the suggested template retains every required file and flag.
+
+Raw paths and credential-like values supplied in intents or filters are used
+only for the in-memory lookup and are redacted from JSON and human output.
+
+## Catalog coverage
+
+The interactive catalog exposes **35 unique pipelines** and **28 unique
+external adapter descriptors**. The pipeline set covers the original game and
+simulation lifecycle plus P0/P1/P2 operational capabilities:
+
+- P0 representation and observation: Experience IR, engine snapshots, asset
+  provenance, editor state, multimodal evidence, resumable jobs, and acceptance
+  locks;
+- P1 behavior over time: timeline validation, shot/camera checks, physics
+  relations, temporal QA, clean-install/launch/smoke checks, and hardware
+  budgets;
+- P2 autonomy and scale: safe repair cycles, bot playtests, state fuzzing,
+  multiplayer authority, engine migration, portability with declared losses,
+  and distributed job DAGs.
+
+These entries apply across 3D, 2.5D, 2D, 8-bit, 16-bit, text, XR, and headless
+games and simulations. Discovery ranks the requested goal independently from
+the spatial model and visual profile.
+
+The 28 adapters are **descriptors for external capabilities**. Catalog lookup
+does not detect an installed engine, inspect an editor, enumerate plug-ins,
+probe processes, contact a worker, or prove that any integration is available.
+An external runner must establish runtime availability and return bound
+evidence.
+
+## Capability kinds
+
+- `GOVERNANCE_FLOW`: contract, drift, impact, verification, and closure gates.
+- `PROFILE_GATE`: semantic validation such as game, simulation, software, or ops.
+- `SPECIALIZED_WORKFLOW`: dedicated surfaces such as `sema author`.
+- `ORCHESTRATION_PIPELINE`: a staged workflow such as content, interactive
+  playtest, temporal validation, portability, or distributed jobs.
+- `CAPABILITY_TOKEN`: an opaque producer, evaluator, runtime, or evidence token.
+- `GENERATOR`: code generation targets.
+- `ADAPTER`: compatibility descriptors for external engines, editors, runtimes,
+  observers, verifiers, asset tools, build systems, and workers.
+
+`author` is intentionally a specialized workflow, not a fake
+`sema profile validar author` command. Likewise, `profile.game` validates game
+semantics; it is not the same thing as the `interactive.playtest` pipeline.
+
+## Deterministic recommendation
+
+The base router normalizes accents and aliases, applies positive and negative
+signals, scores the entry kind and domain, and sorts by score then stable ID.
+The minimum recommendation score is 60. When the top two candidates are within
+seven points, the response reports ambiguity and does not choose a command.
+
+This rule is deliberate: an AI should request more concrete intent instead of
+silently running the wrong pipeline.
+
+Interactive pipeline entries point to declarative planning with
+`sema interativo planejar <definition.json> --json`. The definition must list
+the recommended pipeline ID; the secondary `descrever` template remains
+available when the AI first needs the pipeline contract. Advanced entries point
+to their dedicated `sema interativo` validator or analyzer. Those commands
+still return local, non-authoritative results and do not execute engines,
+editors, plug-ins, or workers.
+
+Legacy views remain available:
+
+```bash
+sema profile capabilities --json
+sema conteudo capabilities --json
+sema interativo capabilities --json
+```
+
+They are projections of the same authoritative catalog sources, not separate
+manually maintained product maps.

package/docs/documentation.md

@@ -35,5 +35,14 @@ sema finalizar-mudanca \
 - Keep commands, file paths, package names, environment variable names, and DSL
   keywords literal.
 - Do not include private or sensitive operational material.
-- Prefer local CLI examples.
-- Point support requests to suporte@otimitare.online.
+- Prefer local CLI examples.
+- Point support requests to suporte@otimitare.online.
+
+## Contract Split Plan
+
+`contratos/sema/governanca_ia_documentacao.sema` is close to the 500-line
+blocking limit. Before adding another documentation capability, split it by
+responsibility into contracts for required-document resolution, localization,
+and change-finalization evidence. Preserve the existing task names, guarantees,
+implementations, and links; the contracts may continue to govern the same CLI
+files through multiple `vinculos`. Do not create numbered part files.

package/docs/profiles.md

@@ -21,6 +21,7 @@ When a profile returns `bloqueado: true`, the artifact is not approved.
 ```bash
 sema profile capabilities --json
 sema profile validar software contratos/example.sema --maturidade production --preset default --json
+sema profile validar simulation contratos/example.sema --maturidade production --preset calibration --json
 sema rule-packs --profile software --json
 ```
 
@@ -32,8 +33,8 @@ sema rule-packs --profile software --json
 - `legal`: terms, privacy, compliance, risk, and regulated language.
 - `research`: comparisons, uncertainty, evidence, citations, and decisions.
 - `game`: rules, loops, player states, scoring, and playability checks.
-- `author`: creative writing, narrative continuity, cliche review, and style
-  guardrails.
+- `simulation`: models, assumptions, units, scenarios, calibration, uncertainty,
+  deterministic replay, and tolerance evidence.
 - `redacao`: editorial and creative writing, narrative structure, voice,
   clarity, and publication-ready evidence.
 - `propostas`: commercial proposals, scope clarity, deliverables, constraints,
@@ -43,3 +44,11 @@ sema rule-packs --profile software --json
 
 Profiles are local CLI checks. They do not create or require external service
 accounts.
+
+`author` remains a dedicated workflow under `sema author`; it is not exposed as
+a fake `sema profile validar author` gate. Use `sema descobrir explicar workflow.author`
+to inspect that boundary.
+
+The legacy `sema profile capabilities` view lists only profiles accepted by
+`profile validar`; its separate `workflowsEspecializados` field points Author
+to `sema author` without advertising an invalid validation command.

package/docs/sistemas-interativos.md

@@ -0,0 +1,381 @@
+# AI-native Interactive Systems
+
+Sema Interactive is the declarative control plane for games, simulations, and
+hybrid interactive systems. The same core covers 3D, 2.5D, 2D, text, retro
+8/16-bit presentation, XR, and headless execution.
+
+It does not embed a game engine or silently control an editor. Sema validates
+definitions, calculates required capabilities, selects compatible external
+adapter descriptors, expands pipelines into evidence-bearing stages, and
+derives non-authoritative local results. An explicitly integrated external
+runner must perform any engine, editor, plug-in, build, verifier, or worker
+operation.
+
+The public CLI is a read-only control plane. It does **not** detect, probe,
+launch, install, or control Unreal, Unity, Godot, Blender, PICO-8, TIC-80,
+LÖVE, a browser runtime, a custom engine, a plug-in, or a distributed worker.
+Catalog presence means only that a descriptor exists; it is not runtime
+availability evidence.
+
+## The dimensions are independent
+
+An interactive definition separates concerns that are often incorrectly mixed:
+
+| Axis | Examples |
+| --- | --- |
+| Kind | `GAME`, `SIMULATION`, `HYBRID` |
+| Spatial model | `NON_SPATIAL`, `TWO_D`, `TWO_POINT_FIVE_D`, `THREE_D` |
+| Render mode | `HEADLESS`, `TEXT`, `VISUAL`, `XR` |
+| Visual profile | `NONE`, `PIXEL_8_BIT`, `PIXEL_16_BIT`, `RASTER`, `VECTOR`, `STYLIZED`, `REALISTIC` |
+| Fidelity | `ARCADE`, `STYLIZED`, `SYSTEMIC`, `REALISTIC`, `CALIBRATED` |
+| Control | human, scripted, AI, hybrid, autonomous, or uncontrolled/emergent |
+| Time | fixed step, variable step, turn based, event driven, or accelerated |
+| Determinism | strict, seeded, best effort, or stochastic |
+
+`PIXEL_8_BIT` and `PIXEL_16_BIT` are visual/technical profiles, not spatial
+dimensions or lesser product classes. A 16-bit economic simulation and a 3D
+flight simulation use the same world/state/time/evidence core with different
+budgets and adapters.
+
+## Core commands
+
+```bash
+sema interativo capabilities --json
+sema interativo schema --json
+sema interativo pipelines --json
+sema interativo adapters --spatial-model TWO_D --render-mode VISUAL --json
+sema interativo validar exemplos/sistemas-interativos/game-pixel-16-bit.json --json
+sema interativo planejar exemplos/sistemas-interativos/game-pixel-16-bit.json --json
+sema interativo validar-evidencias <definition.json> [--plano-arquivo <plan.json>] --bundle-arquivo <bundle.json> --json
+sema interativo status <definition.json> [--plano-arquivo <plan.json>] --bundle-arquivo <bundle.json> --json
+sema interativo validar-protocolo <adapter-run.json> --json
+```
+
+Every command above is local and declarative. Responses report
+`executed: false` and `workspaceMutated: false`. The CLI does not open an
+engine, editor, browser runtime, or custom simulator.
+
+`--evidencias-arquivo` is accepted as an alias for `--bundle-arquivo`. When
+`--plano-arquivo` is omitted, the CLI recomputes the deterministic plan and
+still rejects any bundle whose definition or plan digest does not match.
+
+`schema` is the stable, read-only machine contract for definition generation.
+It exposes required fields, supported enum values, cross-field constraints,
+the capability matrix, and canonical example paths. Its advanced command map
+links every positional/option surface to input and output schemas; each data
+schema exposes required top-level fields and official fixtures. Each subcommand
+has an explicit argument allowlist: unknown flags, duplicate semantic flags,
+missing values, and invalid enum values fail closed instead of producing an
+empty successful result.
+
+## Advanced read-only commands
+
+The advanced command surface exposes the same pure validators and planners to
+AI agents. File-based commands read JSON, every command returns structured JSON,
+and engine, editor, process, plug-in, and worker inspection remains an external
+integration responsibility.
+
+Experience IR:
+
+```bash
+sema interativo validar-ir <experience-ir.json> --json
+sema interativo indexar-ir <experience-ir.json> --json
+sema interativo consultar-ir <experience-ir.json> --semantic-id <id> --json
+sema interativo chunk-ir <experience-ir.json> --semantic-id <id> [--raso] --json
+sema interativo descrever-ir --json
+```
+
+Operational snapshots, provenance, jobs, acceptance, and multimodal evidence:
+
+```bash
+sema interativo validar-engine-snapshot <snapshot.json> --json
+sema interativo diff-engine-snapshots <before.json> <after.json> --json
+sema interativo validar-asset-provenance <provenance.json> --json
+sema interativo validar-editor-state <editor-state.json> --json
+sema interativo planejar-jobs <jobs.json> --json
+sema interativo validar-acceptance <acceptance-lock.json> --json
+sema interativo operar-acceptance <acceptance-lock.json> --operation <VALIDATE|EVALUATE|INVALIDATE> --context-file <context.json> --json
+sema interativo validar-multimodal <evidence.json> --json
+```
+
+Time, autonomy, portability, and distributed work:
+
+```bash
+sema interativo validar-temporal <temporal-contract.json> --json
+sema interativo validar-evidencia-temporal <temporal-contract.json> --bundle-arquivo <temporal-evidence.json> --json
+sema interativo validar-autonomia <repair-cycle.json> --json
+sema interativo validar-playtest-fuzz <playtest-fuzz.json> --json
+sema interativo validar-multiplayer <authority-model.json> --json
+sema interativo analisar-portabilidade <portability-plan.json> --json
+sema interativo validar-workers <distributed-jobs.json> --json
+```
+
+These commands validate descriptions and derive plans, diffs, indexes, queries,
+chunks, eligibility, or assignments. They do not perform the described work.
+
+`sema interativo schema --json` publishes distinct input and output shapes for
+all 20 extension commands. The advertised multimodal input includes claim and
+producer/verifier bindings; autonomy includes cycle and acceptance-lock fields;
+and `jobOrchestrationPlan` exposes `requestDigest`, `planDigest`, and an ordered
+`queue` whose entries are the declared job assignments. Result shapes are
+checked against the official fixtures, and every command publishes
+`outputTargets` path segments from the payload root, so an agent never has to
+reuse an input shape or guess where a validator's output lives.
+
+## Bound control runs
+
+`validar-control-run` is the fail-closed bridge from a planned pipeline to one
+specific advanced validator invocation. It binds a strict manifest to the
+definition digest, recomputed canonical plan, selected pipeline descriptor,
+validation contract, schema-declared input digests, evidence, producer and
+verifier identity, and the exact validator result. The CLI reruns the selected
+pure validator and rejects a result, contract, input, evidence, or pipeline
+borrowed from another run.
+
+```bash
+sema interativo validar-control-run <control-run.json> \
+  --definition-arquivo <definition.json> \
+  --plano-arquivo <plan.json> \
+  --contrato-arquivo <validation-contract.json> \
+  --entrada-arquivo <input.json> \
+  [--entrada-auxiliar-arquivo <supporting-input.json>] \
+  --evidencia-arquivo <evidence.json> \
+  --resultado-arquivo <result.json> \
+  --json
+```
+
+This proves deterministic local binding only. A valid control run still returns
+`completed: false`, `authoritative: false`, and
+`awaitingExternalAttestation: true`; it does not prove that an engine, editor,
+worker, verifier, or external adapter actually ran.
+
+## Experience IR
+
+Experience IR is the engine-neutral semantic substrate below the advanced
+pipelines. Version `sema.experience-ir/v1` models 20 kinds of project, world,
+scene, entity, component, transform, camera, light, material, texture, audio,
+physics, constraint, animation, VFX, timeline, input, save, network, and build
+objects. Stable semantic IDs and explicit references make the graph queryable
+without relying on engine-specific object paths.
+
+The v1 kind set remains unchanged. Eight engine-neutral concepts use optional,
+typed semantic roles in their natural containers, so existing v1 documents
+remain valid while newer documents can expose the concepts explicitly:
+
+| Semantic role | Typed v1 representation |
+| --- | --- |
+| `LEVEL` | `SCENE.semanticRole` |
+| `PIVOT` | `TRANSFORM.semanticRole` |
+| `COLLIDER` | `PHYSICS.colliders[]` |
+| `EMITTER` | `VFX.emitters[]` |
+| `TRACK` | `TIMELINE.tracks[].semanticRole` |
+| `CLIP` | `TIMELINE.tracks[].clips[]` |
+| `EVENT` | `TIMELINE.tracks[].events[]` |
+| `GAME_STATE` | `SAVE.semanticRole` |
+
+`descrever-ir` publishes this mapping as
+`sema.experience-ir.semantic-roles/v1`. Index and chunk entries expose their
+canonical `semanticRoles`, while node `kind` remains one of the original 20.
+Typed clips participate in reference validation and dependency closure.
+
+The IR declares units and coordinate systems, records asset provenance, and
+uses content-addressed digests for deterministic indexing and chunking. JSON is
+the native canonical serialization. CBOR is an explicitly external codec path;
+the CLI does not pretend to encode it. Indexing, lookup, and dependency-aware
+chunks are in-memory read-only operations. They do not import assets, convert a
+project, materialize a scene, or execute a build.
+
+Validation also rejects sensitive values under neutral keys, including private
+keys, Bearer credentials, and common `sk`, `ghp`, or `github_pat` token forms,
+as well as credential-bearing URI queries such as `access_token`, `api_key`,
+`signature`, or `X-Amz-*`, without echoing the value or caller-controlled key
+path. Entity and transform
+parent graphs must be acyclic. Network nodes apply cross-field policy:
+`OFFLINE` means `NONE`, no replicated IDs, and tick zero; `CLIENT_SERVER`
+requires `SERVER`; `PEER_TO_PEER` accepts `OWNER` or `DISTRIBUTED`; and
+`LOCKSTEP` requires `DISTRIBUTED`. Every online mode requires declared
+replication and a positive integer tick rate.
+
+## P0, P1, and P2 coverage
+
+The advanced surface is grouped by operational responsibility, not rendering
+style:
+
+| Priority | Covered responsibilities |
+| --- | --- |
+| P0 — represent and observe | Experience IR; semantic engine snapshots and diffs; asset origin, license, hashes, transforms, and derivatives; editor-state descriptors; multimodal evidence descriptors; job budgets, locks, heartbeats, checkpoints, resume tokens, and recovery; artifact/time-bound acceptance locks. |
+| P1 — validate behavior over time | 4D phases, tracks, clips, and invariants; shots and camera visibility; collision, attachment, and separation relations; flicker, ghosting, popping, exposure, and jitter QA; materialization, clean-install, launch, and smoke-playtest requirements; target hardware budgets. |
+| P2 — diagnose, scale, and migrate | `diagnose -> propose -> simulate -> prove` repair cycles with safe rollback; bounded bots, fuzzing, and save/load recovery; explicit multiplayer authority and reconnect rules; versioned engine migration and cross-engine portability with declared losses; distributed worker DAGs with capabilities, leases, budgets, and checkpoints. |
+
+All three groups apply to 3D, 2.5D, 2D, 8-bit, 16-bit, text, XR, and headless
+games or simulations. A visual profile changes constraints and evidence needs;
+it does not switch to a weaker governance model.
+
+## Canonical pipelines
+
+The canonical catalog exposes **35 unique pipelines** and **28 unique external
+adapter descriptors**. Pipelines are reusable goals rather than one workflow
+per rendering style.
+
+Core pipelines:
+
+- `interactive.prototype`
+- `interactive.playtest`
+- `interactive.package`
+- `interactive.release`
+- `interactive.replay`
+- `interactive.calibrate`
+- `interactive.safety`
+- `game.balance`
+- `game.progression`
+- `game.multiplayer`
+- `simulation.scenario`
+- `simulation.batch_run`
+- `simulation.calibrate`
+- `simulation.validate`
+- `simulation.safety`
+
+P0/P1/P2 pipelines:
+
+- `interactive.experience_ir`
+- `interactive.observe`
+- `interactive.asset_provenance`
+- `interactive.editor_state`
+- `interactive.evidence_capture`
+- `interactive.job_recovery`
+- `interactive.acceptance_lock`
+- `interactive.temporal_validate`
+- `interactive.shot_validate`
+- `interactive.physics_validate`
+- `interactive.temporal_qa`
+- `interactive.clean_install_smoke`
+- `interactive.hardware_budget`
+- `interactive.autonomous_repair`
+- `interactive.bot_playtest`
+- `interactive.state_fuzz`
+- `interactive.multiplayer_authority`
+- `interactive.engine_migration`
+- `interactive.portability`
+- `interactive.distributed_jobs`
+
+Spatial model, render mode, and visual profile influence capabilities, budgets,
+evidence, and adapter compatibility. They do not decide the workflow goal.
+`THREE_D + HEADLESS` is therefore valid, while `XR` requires `THREE_D`.
+
+## Adapter boundary
+
+Adapter descriptors represent runtime, editor, asset, build, telemetry,
+observation, IR, autonomy, portability, or distributed-job capabilities. They
+describe compatibility; they do not prove that an engine, editor, plug-in, or
+worker is installed, reachable, or running.
+
+The protocol model uses a read-only observation prefix:
+
+```text
+DETECT -> PROBE -> SNAPSHOT -> PLAN
+```
+
+Those names describe phases that an external adapter must implement; the local
+CLI does not perform `DETECT` or `PROBE`. Read-only adapters continue with
+`VALIDATE -> EVIDENCE`. Mutating adapters add `APPLY` and must support
+`ROLLBACK`:
+
+```text
+DETECT -> PROBE -> SNAPSHOT -> PLAN -> APPLY -> VALIDATE -> EVIDENCE
+                                                \-> ROLLBACK on failure
+```
+
+Stable semantic target IDs bind every phase. A failed external mutation without
+rollback evidence is a blocking result.
+
+The descriptor catalog includes general targets for Unreal, Unity, Godot,
+Blender, web canvas, LÖVE, PICO-8, TIC-80, headless runtimes, simulation
+runners, validators, telemetry, assets, builds, operational observers, IR,
+autonomy, portability, and distributed jobs. These are compatibility
+descriptors, not bundled integrations, probes, detections, or installation
+claims.
+
+Planning is provider-aware. `adapterTargets` is an explicit composition, not a
+decorative preference: every expanded stage capability must be supplied by at
+least one selected compatible descriptor. An empty or partial selection
+produces a blocked plan with deterministic candidate and
+recommended-composition output. A telemetry descriptor cannot stand in for an
+executor, and a generic headless descriptor cannot claim packaging capabilities
+it does not declare.
+
+## Evidence and operational truth
+
+Pipeline stages declare exact evidence types. Examples include runtime boot,
+first input, loop completion, failure state, deterministic replay, calibration,
+tolerance comparison, package creation, packaged launch, smoke execution, and
+rollback observation.
+
+Compilation does not prove playability. Opening an editor does not prove a
+simulation is valid. An editor playtest does not prove a packaged build. A
+runner saying “success” does not replace observed evidence.
+
+The portable evidence bundle in v1 is explicitly non-authoritative. It
+validates binding, digests, stage coverage, stable IDs, non-empty observation
+data, and the producing adapter ID/version against the selected provider for
+each stage. High-assurance environments must additionally provide signed
+envelopes, quorum, anti-replay state, and externally retained checkpoints
+through an appropriate trust/ledger layer. Sema does not label a local JSON file
+as a strong trust boundary.
+
+When all local structural checks and supplied observation records pass, status
+is `STRUCTURALLY_COMPLETE`. This is **not authoritative completion**. It means
+only that local structural coverage is complete; it deliberately keeps
+`completed: false`, `authoritative: false`, and
+`awaitingExternalAttestation: true`. It does not prove that an engine ran, an
+editor was inspected, a plug-in existed, a worker accepted a job, a package
+launched, or an external observer attested the result.
+
+## Semantic budget split plan
+
+The current operational facade remains compatible, but three governed artifacts
+have crossed the planning threshold: `operations.ts` has 1,112 lines,
+`sistemas_interativos_operacao.sema` has 304 lines, and the installed-package
+smoke `scripts/testar-pacote-cli-publico.mjs` has 1,009 lines. Before any of
+them reaches its blocking limit, split by responsibility as follows:
+
+- move engine snapshots, semantic diffs, asset provenance, and editor-state
+  observation into `engineObservation.ts`;
+- move queues, locks, budgets, leases, checkpoints, and recovery planning into
+  `jobOrchestration.ts`;
+- move acceptance locks, invalidation, and multimodal claim evidence into
+  `acceptanceEvidence.ts`;
+- keep `operations.ts` as the stable re-export facade while callers migrate;
+- split the contract into `sistemas_interativos_observacao_engine.sema`,
+  `sistemas_interativos_orquestracao_jobs.sema`, and
+  `sistemas_interativos_acceptance_evidencias.sema`, with all three contracts
+  linked to the shared facade and their actual implementation files;
+- split the installed-package smoke into helpers for public-boundary security,
+  Codex bootstrap, content-pipeline compatibility, interactive systems, and
+  generated toolchains, while retaining the current script as the stable
+  orchestrator and preserving one end-to-end isolated installation.
+
+This is a responsibility split, not a numbered-file workaround. Existing
+exports, schema versions, fixtures, digests, and fail-closed behavior must remain
+backward compatible through the migration.
+
+## Fidelity rules
+
+Visual realism and model validity are separate. A `REALISTIC` or `CALIBRATED`
+simulation must declare reference data, units, calibration method, tolerances,
+uncertainty, and telemetry. A photorealistic scene without those items is only
+photorealistic, not a validated simulation.
+
+Strict or seeded determinism requires a seed, snapshots, event log, reproducible
+step model, and replay result digest. Autonomous or uncontrolled systems require
+stopping criteria, boundaries, and safety evidence.
+
+## Examples
+
+The fixtures under `exemplos/sistemas-interativos/` deliberately cover opposing
+cases: human-controlled retro games, 2D simulations, 3D calibrated simulations,
+and autonomous headless batch execution. The `advanced/` fixtures mirror the
+public schemas for IR-adjacent operations, temporal validation, autonomy,
+multiplayer authority, portability, distributed jobs, and fully bound control
+runs. They are synthetic validation inputs, not captured runtime evidence. The coverage matrix proves
+that kind, spatial model, render mode, visual profile, control, fidelity, and
+runtime are composable rather than hardcoded around one showcase project.

package/docs/testing.md

@@ -9,6 +9,8 @@ npm run build
 npm run status:check
 npm run repo:verificar-publico
 npm run plugin:testar-codex
+npm run cli:empacotar-publica
+npm run cli:testar-pacote-publico
 node pacotes/cli/dist/index.js --help
 node pacotes/cli/dist/index.js --version
 node pacotes/cli/dist/index.js resumo exemplos/calculadora.sema --micro --json
@@ -26,8 +28,15 @@ encoding in every published document. The plugin smoke must validate the repo
 marketplace, manifest version, installed skill copy, and absence of Sema MCP.
 After push and npm publication, `npm run release:verificar-distribuicao` must
 repeat that installation from the remote `gerlanss/Sema` marketplace and prove
-that GitHub HEAD, the installed skill, and npm 2.2.0 all describe the same
-release.
+that GitHub HEAD, the installed skill, and the manifest-declared npm version
+all describe the same release.
+
+The local public-package smoke installs the generated tarball in an isolated
+sandbox. It must import the root API without executing the CLI, materialize
+nested interactive examples, and execute discovery, interactive schema,
+definition validation, planning, and adapter-protocol validation through the
+installed binary. Passing this smoke proves the local tarball only; it does not
+mean that npm or a GitHub release was published.
 
 Native generator evidence is mandatory when changing C#/.NET or C++ support.
 The `dotnet` smoke must compile and execute through the local .NET SDK. The