Files
TeslaSuite/Console/tests/TeslaConsole.DiffTests
CydandClaude Fable 5 13f8e0456b vPOD: real-launch auto-restart watchdog + optional postinstall.bat
Two additions to the virtual launcher's real-process mode:

- Auto-restart watchdog. Replaces the poll-on-query PruneExitedProcesses
  with a per-process watcher thread (StartWatcher): when a real-launched
  app exits on its own -- not via a Kill*/Uninstall, which untrack it
  first -- it is dropped from the running list and, if its LaunchData has
  AutoRestart and the "Auto-restart after the app exits (watchdog)"
  toggle is on, relaunched after the Agent's 2 s delay. A watchdog
  generation counter cancels pending restarts when the pod goes dark
  (power off / reboot / reprovision / WipeApps); the console's KillAllApps
  leaves them pending, matching the real Agent's race.

- postinstall.bat toggle. A "Run postinstall.bat after install" checkbox
  (above "Actually launch apps", off by default) makes an install execute
  a packaged postinstall.bat via cmd /c (waited up to 5 min) before
  deleting it, like the real service. Off, it is logged and removed unrun
  as before -- it runs package script code on the host.

Both are opt-in from the vPOD window. Verified against the real
LauncherRpcServer over a loopback socket: the watchdog test relaunches an
exited ping.exe with a new PID and stops once toggled off; a crafted
package's postinstall.bat runs (and is removed) only when enabled. Full
differential suite 103/103.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-10 16:30:28 -05:00
..

TeslaConsole.DiffTests — differential equivalence suite

Verifies that the reconstructed TeslaConsole.exe (built from the decompiled source in this repo) behaves identically to the original reference binary in original/TeslaConsole.exe.

How it works

The suite loads each assembly into its own child AppDomain (DifferentialFixture) and drives it through a MarshalByRefObject proxy (Invoker). This is why the project targets net48 — AppDomains are a .NET Framework feature. The original is the 4.11.3.37076 baseline; the recovered build is the modernized 4.11.4.x line (same TeslaConsole assembly name, an intentionally newer version). Because the two versions differ, the public-member comparison strips Version= stamps before diffing — it compares type/member names, not assembly versions.

Each child domain is given a probe directory (the recovered build's output, which ships every dependency DLL) so the original — which is distributed without its proprietary dependencies — still resolves its references for metadata inspection.

What is compared

  1. Public API surface (PublicApiSurfaceTests) Every public type and public member (signature-for-signature) exposed by the original must also be exposed by the recovered build. Compiler-generated members and property/event accessor methods are excluded — the README at the repo root notes those legitimately differ between a decompilation and the lost sources.

  2. Recovered-only characterization (CatalogTests, BTGoldenEggTests) Features that were added in the reconstruction have no counterpart in the original exe, so these run against the recovered build only:

    • CatalogTests — the data-driven product catalog reproduces the exact LaunchData the old hardcoded code emitted.
    • BTGoldenEggTests — the new TeslaConsole.BattleTech mission builder is diffed field-by-field against two golden eggs captured from the original consoles (BattleTech/cavern.egg, BattleTech/TESTARN.EGG). The comparison is per-section and order-independent (the pod parses eggs INI-style; the two golden eggs themselves disagree on field order). Font-rendered name-bitmap pixel rows are excluded, but TESTARN's ordinal art — identical to the RP-inherited rows — is compared byte-exactly. Also covers the EggFileMessage wire framing (NUL-delimited ASCII, 1000-byte chunks, byte-exact reassembly), role-block de-duplication, the No Return mode (same scenario=freeforall, different role), and the shipped BattleTech\BTConfig.xml catalog contents.
  3. Behavioral output (BehavioralEquivalenceTests) The same deterministic, dependency-free methods are invoked in both assemblies over a battery of inputs and the results must match byte-for-byte:

    • RPStrings.GetTimeString (mm:ss formatting + 0.5 s rounding)
    • HostTypeHelper.Parse(...).ToString() (incl. invalid-input exceptions)
    • PlasmaBitmaps.ConvertBitmap (1-bpp packing of a known pixel pattern)
    • PlasmaBitmaps.GenerateString (full GDI text → 1-bpp plasma pipeline)
    • RPMap / RPVehicle XML parsing
    • SiteManagement well-known application GUID constants
    • Tuple.Create<,> generic factory

    A negative-control test (Harness_Distinguishes_Different_Outputs) proves the harness can actually see a difference, so a green run is never vacuous.

The project also carries two byte-compatibility guards — not original-vs-recovered comparisons, but checks that the modernized protocol/crypto stays compatible with the original binaries:

  • PodRpcProtocolTests — round-trips the framed-JSON RPC (Contract/PodRpcProtocol.cs) in-process: every request/response shape encodes and decodes back to the same values.
  • SecureConfigCompatTests — asserts the source-built OFBCryptoStream produces byte-identical ciphertext to the original TeslaSecureConfiguration.dll, so the pod provisioning handshake stays wire-compatible.

Running

dotnet test tests/TeslaConsole.DiffTests/TeslaConsole.DiffTests.csproj

A project reference builds the reconstruction first, and the suite always tests the most recently built bin/{Debug,Release}/net48/TeslaConsole.exe.

Scope / limitations

This compares deterministic logic. It deliberately does not drive the WinForms UI, the pod networking, secure-configuration, or hardware-facing code — those require the live console, its pods, and the proprietary services, and are not reproducible in a unit test. The API-surface test still asserts those types exist with matching signatures even though their behavior isn't exercised.