@@ -55,7 +55,7 @@ decisions:
   stability: stable
 
 - id: repo.examples.runtime_selection_boundary
-  statement: Every example application shall compile authored screens through `unified_ui` into canonical `UnifiedIUR` and render through the runtime selected for the launch session, with `live_ui` as the default runtime when no command-line runtime argument or equivalent override is provided.
+  statement: Every example application shall compile authored screens through `unified_ui` into canonical `UnifiedIUR` and render through the runtime selected for the launch session, with maintained launcher targets for `live_ui`, `desktop_ui`, `elm_ui`, and `terminal_ui`, and with `live_ui` as the default runtime when no command-line runtime argument or equivalent override is provided.
   priority: must
   stability: stable
 
 
@@ -46,7 +46,7 @@ decisions:
   stability: stable
 
 - id: repo.examples.structure.local_package_dependencies
-  statement: Each example application shall depend on `packages/unified-ui` and `packages/unified_iur` through local path dependencies and may depend on one or more supported runtime packages required for its launch targets, but no focused example application shall require an `examples/shared/` path dependency.
+  statement: Each example application shall depend on `packages/unified-ui` and `packages/unified_iur` through local path dependencies and shall include the supported runtime-package dependencies required for its maintained launch targets, including `live_ui`, `desktop_ui`, `elm_ui`, and `terminal_ui`, but no focused example application shall require an `examples/shared/` path dependency.
   priority: must
   stability: stable
 
 
@@ -26,7 +26,7 @@ decisions:
 
 ```spec-requirements
 - id: repo.examples.tooling.index_surface
-  statement: The example suite shall provide a top-level index under `examples/` that explains the common example-shell contract, the suite default theme/style baseline, the default runtime behavior, and the per-widget example-app catalog.
+  statement: The example suite shall provide a top-level index under `examples/` that explains the common example-shell contract, the suite default theme/style baseline, the supported runtime targets, the default runtime behavior, and the per-widget example-app catalog.
   priority: must
   stability: stable
 
@@ -36,12 +36,12 @@ decisions:
   stability: stable
 
 - id: repo.examples.tooling.runtime_selection_surface
-  statement: The suite shall provide a documented launch surface that accepts runtime selection through a command-line argument or equivalent override, and shall default to `live_ui` when no runtime is specified.
+  statement: The suite shall provide a documented launch surface that accepts runtime selection through a command-line argument or equivalent override for `live_ui`, `desktop_ui`, `elm_ui`, and `terminal_ui`, shall default to `live_ui` when no runtime is specified, and may satisfy non-browser runtimes through review-oriented runtime output when a standalone launcher is not yet maintained.
   priority: must
   stability: stable
 
 - id: repo.examples.tooling.shared_validation
-  statement: The suite shall provide a repeatable validation workflow that checks whether each catalog entry still preserves the common example-shell contract, the suite default theme/style baseline, and the runtime-selection contract.
+  statement: The suite shall provide a repeatable validation workflow that checks whether each catalog entry still preserves the common example-shell contract, the suite default theme/style baseline, and the documented runtime-selection contract.
   priority: must
   stability: stable
 
@@ -62,7 +62,7 @@ decisions:
 - id: repo.examples.tooling.review_example_suite
   given: A maintainer wants to review the standalone example-app suite after adding or changing a widget
   when: The maintainer uses the suite index and validation workflow
-  then: The maintainer can find the widget-focused app, run it independently, and verify that it still preserves the common example-shell contract, the suite default theme/style baseline, and the default runtime behavior
+  then: The maintainer can find the widget-focused app, run it independently through the chosen maintained runtime target, and verify that it still preserves the common example-shell contract, the suite default theme/style baseline, and the default runtime behavior
 ```
 
 ## Verification
 
@@ -10,16 +10,23 @@ Start with the contract layer before changing code or docs:
 
 1. `.spec/README.md`
 2. `.spec/AGENTS.md`
-3. `.spec/decisions/README.md`
-4. `.spec/specs/package.spec.md`
-5. `.spec/specs/architecture.spec.md`
-6. `.spec/specs/dsl_iur_symbiosis.spec.md`
-7. `.spec/specs/platform_runtimes.spec.md`
-8. `.spec/specs/signal_transport.spec.md`
-9. `.spec/specs/governance/governance_layer.spec.md`
-10. `.spec/specs/governance/contracts/workspace_governance_contract.spec.md`
+3. `.spec/conformance/README.md`
+4. `.spec/decisions/README.md`
+5. `.spec/specs/spec_system.spec.md`
+6. `.spec/specs/package.spec.md`
+7. `.spec/specs/architecture.spec.md`
+8. `.spec/specs/dsl_iur_symbiosis.spec.md`
+9. `.spec/specs/platform_runtimes.spec.md`
+10. `.spec/specs/signal_transport.spec.md`
+11. `.spec/specs/conformance_layer.spec.md`
+12. `.spec/specs/governance/governance_layer.spec.md`
+13. `.spec/specs/governance/contracts/workspace_governance_contract.spec.md`
 
 Read the relevant package specs under `.spec/specs/` before editing a package.
+If you are changing `packages/unified-ui`, also read
+`.spec/specs/governance/contracts/unified_ui_change_contract.spec.md`.
+If you are changing `packages/unified_iur`, also read
+`.spec/specs/governance/contracts/unified_iur_change_contract.spec.md`.
 If the change is durable and cross-cutting, also read the matching ADRs under
 `.spec/decisions/`.
 
@@ -37,16 +44,24 @@ If the change is durable and cross-cutting, also read the matching ADRs under
 
 The `.spec/` workspace is the current-truth contract layer for this repository.
 
+- `.spec/specs/spec_system.spec.md` defines the contract for the `.spec`
+  workspace itself
 - `.spec/specs/**/*.spec.md` are the canonical authored subjects
 - `.spec/specs/governance/` contains repository-wide governance contracts
+- `.spec/specs/conformance_layer.spec.md` defines the separate conformance
+  layer
 - `.spec/decisions/**/*.md` contains durable ADR rationale
-- `.spec/conformance/` contains machine-readable implementation evidence
+- `.spec/conformance/*/manifest.json` contains machine-readable implementation
+  evidence
 - `.spec/planning/*/spec-traceability.json` contains machine-readable plan
   coverage manifests
+- `.spec/planning/*/spec-traceability.md` contains generated review-facing plan
+  coverage mirrors
+- `.spec/state.json` is generated by `mix spec.plan` and `mix spec.verify`
 
 Governance and conformance are separate layers. Do not treat conformance
-manifests, planning mirrors, or branch-local notes as substitutes for authored
-spec subjects.
+manifests, generated planning mirrors, state output, or branch-local notes as
+substitutes for authored spec subjects.
 
 ## Core Architecture
 
@@ -98,16 +113,29 @@ package, and several runtime libraries.
 When you change canonical package surfaces, the specs must move with the code in
 the same change set.
 
-- Changes to canonical `unified_ui` DSL surface must update the affected
+- `unified_ui` surface changes are governed by
+  `.spec/specs/governance/contracts/unified_ui_change_contract.spec.md`
+- `unified_iur` surface changes are governed by
+  `.spec/specs/governance/contracts/unified_iur_change_contract.spec.md`
+- Changes to canonical `unified_ui` authored DSL surface for widgets, layouts,
+  layering, styling, theming, or interaction binding must update the affected
   subjects under `.spec/specs/unified-ui/`
-- Changes to canonical `unified_iur` interchange surface must update the
+- Changes to canonical `unified_iur` interchange surface for widgets, layouts,
+  layering, styling, theming, or interaction representation must update the
   affected subjects under `.spec/specs/unified-iur/`
 - Changes to canonical `unified_ui` widget, display-system, or theming surface
   intended for ecosystem-wide authoring must update the paired
   `.spec/specs/unified-iur/` subjects in the same change set
 - Changes to canonical `unified_iur` widget, display-system, or theming surface
   intended for ecosystem-wide authoring and rendering must update the paired
   `.spec/specs/unified-ui/` subjects in the same change set
+- `unified_ui` and `unified_iur` subjects must stay within the root ecosystem
+  bounds defined by `.spec/specs/architecture.spec.md`,
+  `.spec/specs/dsl_iur_symbiosis.spec.md`,
+  `.spec/specs/platform_runtimes.spec.md`, and
+  `.spec/specs/signal_transport.spec.md`
+- Runtime-library-native widget, runtime, styling, and local signal
+  responsibilities must not be absorbed into `unified_ui` or `unified_iur`
 - Repository-wide governance changes belong under `.spec/specs/governance/`
 - Durable cross-cutting policy changes must add or update an ADR under
   `.spec/decisions/`
@@ -156,6 +184,10 @@ Repository root:
 - `mix spec.check`
 - `mix spec.diffcheck`
 - `mix spec.report`
+- `mix spec.plancheck <package>`
+- `mix spec.traceability.generate <package>`
+- `mix spec.compliance <package>`
+- `mix spec.compliance.ci`
 
 Package-local commands:
 
@@ -174,12 +206,15 @@ Package-local commands:
 - If you edit `.spec`, follow `.spec/AGENTS.md`
 - Prefer targeted package-local tests over broad repository-wide runs
 - When changing repository-wide or package-wide policy, update the subject specs
-  first and ADRs second
+  first, ADRs second, and conformance evidence separately
 - When changing canonical DSL or canonical IUR surface, expect coordinated
-  changes across code, package specs, and possibly runtime rendering or
-  transport subjects
+  changes across code, package specs, paired canonical package subjects, and
+  possibly runtime rendering or transport subjects
 - Conformance evidence lives under `.spec/conformance/`; do not embed that
   evidence into governance subjects
+- Do not hand-edit generated `.spec/state.json` or
+  `.spec/planning/*/spec-traceability.md`; regenerate them through the Mix
+  tasks that own them
 - Generated traceability mirrors are review aids, not the source of truth
 - Packages currently target Elixir `~> 1.19`; older runtimes will fail before
   compilation
@@ -189,10 +224,15 @@ Package-local commands:
 - `CLAUDE.md`
 - `.spec/README.md`
 - `.spec/AGENTS.md`
+- `.spec/conformance/README.md`
+- `.spec/specs/spec_system.spec.md`
 - `.spec/specs/package.spec.md`
 - `.spec/specs/architecture.spec.md`
 - `.spec/specs/dsl_iur_symbiosis.spec.md`
 - `.spec/specs/platform_runtimes.spec.md`
 - `.spec/specs/signal_transport.spec.md`
+- `.spec/specs/conformance_layer.spec.md`
 - `.spec/specs/governance/governance_layer.spec.md`
 - `.spec/specs/governance/contracts/workspace_governance_contract.spec.md`
+- `.spec/specs/governance/contracts/unified_ui_change_contract.spec.md`
+- `.spec/specs/governance/contracts/unified_iur_change_contract.spec.md`
@@ -21,30 +21,32 @@ detail.
 
 ## Layout
 
-- `shared/`: the shared support library that owns the common dependency wiring,
-  DSL template, catalog, runtime helpers, release checks, and maintainer tasks
+- `shared/`: maintainer tooling, catalog, validation, and release-readiness
+  helpers that remain useful for suite-wide review workflows
 - one standalone app directory per implemented widget-focused example
 
 Directory convention:
 
 - every example app lives in `examples/<widget_name>/`
 - every example app is a standalone Phoenix LiveView app and Mix project
-- every example app depends on `examples/shared/` plus the local package paths
-  for `unified_ui`, `unified_iur`, and `live_ui`
-- every example app reuses the shared template in
-  `UnifiedExamples.Shared.Template`
+- focused example apps are self-contained and do not depend on
+  `examples/shared/`
+- every focused example app depends on the local package paths for
+  `unified_ui`, `unified_iur`, `live_ui`, `desktop_ui`, `elm_ui`, and
+  `terminal_ui`
+- every focused example app can be started from its own directory and defaults
+  to `live_ui` when no target package is specified
 
 ## Shared Baseline
 
-The shared authoring template gives every example app the same review surface:
+The shared authoring baseline gives every example app the same review surface:
 
 - shared `UnifiedUi` DSL shell macros: `example_panel/1` and
   `example_form_panel/1`
 - shared default theme id: `:example_suite_default`
 - shared default style profile keys: `:shell`, `:panel`, `:form_shell`,
   `:title`, `:summary`, `:notes`, `:button`, and `:text_input`
-- shared runtime flow through `examples/shared/` helpers rather than
-  app-specific boot code
+- a common app-local launcher surface through `mix example.start`
 - one meaningful authored interaction story per example so reviewers can
   understand what to try in the browser and what outcome to expect without
   opening source files
@@ -71,8 +73,13 @@ demonstrating:
 - `unified_ui` owns the authored DSL template and compiler surface
 - `unified_iur` owns the canonical intermediate representation produced by that
   authored DSL
-- `live_ui` owns the runtime rendering path that mounts the resulting canonical
-  screen under the shared theme and style baseline
+- `live_ui` is the default browser runtime target for the example suite
+- `desktop_ui` is the native desktop target currently wired into the app-local
+  launcher surface
+- `elm_ui` is available through the same launcher as a review-oriented runtime
+  snapshot of the Phoenix-and-Elm server/frontend path
+- `terminal_ui` is available through the same launcher as a review-oriented
+  runtime snapshot of the terminal runtime path
 
 The shared support library exposes traceability metadata for every app so
 reviewers can see the exact package roots, package specs, general ecosystem
@@ -84,9 +91,10 @@ Run these from `examples/shared/`:
 
 - `mix examples.list`: print the current suite catalog
 - `mix examples.launch <directory> --dry-run`: print the standalone Phoenix
-  launch command for one app
+  launch command or runtime-review command for one app
 - `mix examples.launch <directory> --smoke-test`: boot one app through its
-  Phoenix endpoint and verify the LiveView entrypoint responds
+  Phoenix endpoint and verify the LiveView entrypoint responds for browser-
+  runnable launch targets
 - `mix examples.preview <directory>`: inspect one app through the shared
   preview path
 - `mix examples.run <directory>`: run one app through its own test workflow
@@ -95,26 +103,66 @@ Run these from `examples/shared/`:
 - `mix examples.report`: print the cross-family review summary
 - `mix examples.release --strict`: run the full documentation, traceability,
   validation, and release-readiness workflow
-- `mix phx.server`: run from any `examples/<widget_name>/` directory to launch
-  that example directly in the browser
+- `mix example.start`: run from any example app directory to launch that app,
+  defaulting to `live_ui` and accepting `--target-package desktop_ui`,
+  `--target-package elm_ui`, and `--target-package terminal_ui`
+- `mix phx.server`: still works directly from example app directories for the
+  default `live_ui` browser path
 
 Direct browser workflow for any example app:
 
 ```bash
 cd examples/button
 mix deps.get
-mix phx.server
+mix example.start
 ```
 
 The default mount URL is `http://127.0.0.1:5000/`, and you can override the
-port with `PORT=4100 mix phx.server`.
+port with `mix example.start --port 4100`.
+
+Native desktop workflow for any focused example app:
+
+```bash
+cd examples/button
+mix deps.get
+mix example.start --target-package desktop_ui
+```
+
+ElmUi review workflow for any focused example app:
+
+```bash
+cd examples/button
+mix deps.get
+mix example.start --target-package elm_ui
+```
+
+This prints an `ElmUi` runtime snapshot to stdout for the compiled canonical
+example instead of launching the LiveView browser shell.
+
+TerminalUi review workflow for any focused example app:
+
+```bash
+cd examples/button
+mix deps.get
+mix example.start --target-package terminal_ui
+```
+
+Use `--backend-mode tty` when you want the fallback terminal-capability path:
+
+```bash
+cd examples/button
+mix example.start --target-package terminal_ui --backend-mode tty
+```
+
+This prints a `TerminalUi` runtime snapshot to stdout for the compiled
+canonical example instead of launching a browser or SDL window.
 
 Aggregate demo workflow:
 
 ```bash
 cd examples/demo
 mix deps.get
-mix phx.server
+mix example.start
 ```
 
 Or preview the demo launch contract from the shared tooling:
@@ -124,6 +172,14 @@ cd examples/shared
 mix examples.launch demo --dry-run
 ```
 
+You can also preview non-browser launch commands from the shared tooling:
+
+```bash
+cd examples/shared
+mix examples.launch button --runtime elm_ui --dry-run
+mix examples.launch button --runtime terminal_ui --dry-run
+```
+
 When you launch an example, look for two shared review surfaces in the browser:
 
 - `Meaningful Interaction Story`: explains what changed in human terms
 
@@ -11,8 +11,8 @@ From this directory:
 `mix deps.get`
 `mix phx.server`
 
-The app mounts at `http://127.0.0.1:4000/` by default. Override the port with
-`PORT=4100 mix phx.server`.
+The app mounts at `http://127.0.0.1:5000/` by default. Override the port with
+`PORT=5100 mix phx.server`.
 
 ## Try It
 
 
@@ -3,7 +3,11 @@ defmodule UnifiedExamples.AlertDialog do
   Self-contained standalone example-app entrypoint for the focused example project.
   """
 
-  @directory __MODULE__ |> Module.split() |> List.last() |> Macro.underscore() |> then(&"examples/#{&1}")
+  @directory __MODULE__
+             |> Module.split()
+             |> List.last()
+             |> Macro.underscore()
+             |> then(&"examples/#{&1}")
   @app @directory |> Path.basename() |> then(&String.to_atom("unified_example_#{&1}"))
   @purpose :widget_proof
 
@@ -68,17 +72,17 @@ defmodule UnifiedExamples.AlertDialog do
 
   @spec boot(keyword()) :: {:ok, LiveUi.Runtime.State.t()} | {:error, term()}
   def boot(opts \\ []) do
-    Runtime.mount(screen_module(), runtime_opts(opts))
+    __MODULE__.Runtime.mount(screen_module(), runtime_opts(opts))
   end
 
   @spec component_assigns(keyword()) :: {:ok, map()} | {:error, term()}
   def component_assigns(opts \\ []) do
-    Runtime.component_assigns(screen_module(), runtime_opts(opts))
+    __MODULE__.Runtime.component_assigns(screen_module(), runtime_opts(opts))
   end
 
   @spec render_html(keyword()) :: {:ok, String.t()} | {:error, term()}
   def render_html(opts \\ []) do
-    Runtime.render_html(screen_module(), runtime_opts(opts))
+    __MODULE__.Runtime.render_html(screen_module(), runtime_opts(opts))
   end
 
   @spec launch_path() :: String.t()