07222026 (#1)

* feat: replace bash scripts with Python equivalents for copyright checks and test coverage

* feat: refactor Rheingold DatabaseProvider and LicenseManagement Models

* feat: improve reportgenerator handling and error reporting in test coverage script

* test: enhance test coverage and refactor utility methods

* feat: add --enable-ista-voltage option to inject an ISTAVoltageControl.dll (tautcony#88)

Hooks into IstaOperation.exe's InitializeServices, loading
ISTAVoltageControl.dll at runtime and calling
Controller.StartFromIstaOperation to enable KL15/KL30 voltage tracking
over OBD/D-CAN or ENET. The injection is idempotent and wrapped in a
silent try/catch so it never crashes ISTA.

IMPORTANT — two external dependencies are required, neither of which is
part of this repository:

1. EdiabasLib (Api64.dll)
   The DLL is resolved at runtime via the BinPathModifications registry
   key (HKLM\SOFTWARE\BMWGroup\ISPI\Rheingold\BMW.Rheingold.ISTAGUI
   .BinPathModifications), falling back to the stock ISTA Ediabas BIN
   folder. Source: https://github.com/uholeschak/ediabaslib

2. ISTAVoltageControl.dll
   An external voltage-controller bridge that must be deployed into the
   folder resolved above before launching ISTA. This patch only installs
   the bootstrap call; all voltage logic (KL15/KL30 polling, VCI walk)
   lives inside that DLL.

   To implement your own, the expected contract is defined in
   PatchUtils.ISTAVoltage.cs (this repo): a public static method
   ISTAVoltageControl.Controller.StartFromIstaOperation(object serviceImpl).
   From there, use EdiabasVoltageBridge.TryRegister() (EdiabasLib) to
   receive KL15/KL30 samples via callback.

If the flag is used but either dependency is missing, the silent
try/catch ensures ISTA continues to start normally.

* feat: add --enable-skip-battery-demand option (tautcony#89)

* feat: block EDGE telemetry egress (Speedlink + OBFCM) in DataNotSend (tautcony#90)

* feat: block EDGE telemetry egress (Speedlink + OBFCM) in DataNotSend

The IsSend*Forbidden flags do not gate these channels: Logic.SendSpeedlinkDataInBackground and SendObfcmDataToVehicleShadowBackend fire the HTTP POST unconditionally (the forbidden flag only rides inside the payload), so the request still leaves the machine. Empty both senders (DnlibUtils.EmptyingMethod) so the telemetry call never happens.

Scope: telemetry only -- Speedlink (session/dealer) + OBFCM (fuel data to Vehicle Shadow). EDGEBattery / EDGEPDI are left functional. To extend to zero EDGE egress, empty EDGEProcessorImpl.SendDataToBackend instead (single chokepoint, blocks all channels).

* feat: block SCC vehicle-session upload in DataNotSend

SaveCurrentSCCCase -> SCCProcessorImpl.PostVehicleSession runs
unconditionally on session close and is not gated by the
IsSend*Forbidden flags, posting VIN, vehicle data and diagnosis data
(DTCs, technician statements, PDF files) to the SCC backend. Return
its own offline sentinel (ServiceUnavailable) so the call never
leaves the machine, mirroring PatchEdgeTelemetry.

* feat: support legacy ICOM (A1/A2) over SLP on ISTA 4.60+ (tautcony#92)

* feat: handle ICOM-Next device dispatch rewrite for ISTA 4.60+

ISTA 4.60 rewrote SLP device dispatch to only recognize DevType=="ICOM-Next";
legacy units reporting DevType=="ICOM" now fall through and get rejected
("newDevice is null or invalid"). Normalize DevType right after ParseAttrList
on 4.60+ so the existing ICOM-Next dispatch branch is taken; keep the prior
ReplaceDeviceType approach for versions below 4.60.

* fix(PatchSLP): bind injected SLP dictionary members to the target corlib

NormalizeDevType imported Dictionary.get_Item/set_Item via typeof(), which under
the net10.0 patcher binds to System.Private.CoreLib. That assembly does not exist
on ISTA's .NET Framework runtime, so the patched ScanDeviceFromAttrList failed to
resolve at JIT and broke VCI detection (including genuine ICOM-Next). Reuse the
existing mscorlib get_Item/op_Equality operands and build set_Item on the same
declaring type.

* feat(PatchSLP): A1/A2-aware ICOM dispatch with State gate (>= 4.60)

Differentiating variant: instead of remapping DevType in the dictionary, widen the
ICOM-Next dispatch condition to also accept DevType ICOM/ICOM A1/ICOM A2, mask their
DevTypeExt to ICOM_Next_A, and force the raw reported State only for A1/A2. DevType is
never rewritten, so A1/A2 stay distinguishable from a genuine ICOM-Next at the State
block; genuine ICOM-Next keeps the upstream dispatch, firmware check and State intact
(no firmware patch needed). Dictionary members are bound to the target corlib (mscorlib),
not System.Private.CoreLib.

* fix(PatchSLP): drive legacy ICOM off DevTypeExt, not DevType

Real legacy ICOM A1/A2 report DevType="ICOM" with DevTypeExt="ICOM_A1"/"ICOM_A2";
only ICOM-Next reports DevType="ICOM-Next". The previous variant keyed on a
non-existent DevType=="ICOM A1"/"ICOM A2" (dead branches) and overwrote DevTypeExt
with "ICOM_Next_A", erasing the A1/A2 identity. Now: widen dispatch to also accept
DevType=="ICOM"; leave DevTypeExt untouched; force raw State only when DevTypeExt is
"ICOM_A1"/"ICOM_A2", so genuine ICOM-Next (DevTypeExt="ICOM_Next_A") keeps its
upstream firmware/State. Reuses existing get_Item/ContainsKey/op_Equality operands.

* refactor(PatchSLP): extract dispatch widening and State gate into named helpers

Split the oversized RewriteIcomNextDispatch into WidenIcomDispatch and
KeepRawStateForLegacyIcom, shrinking PatchSLP and addressing the CodeFactor
complex-method report. Emitted IL is unchanged.

* fix: scope the ENET real-ECU voltage-check patch to the diagnostic module loader only (tautcony#93)

* feat: skip ENET real-ECU voltage check in ModuleBootstrapLoader.doIt()

VoltageUtils.CheckVoltageForEthernetConnection (RheingoldProgramming.dll)
reads real battery voltage via an ECU service program ("Batteriespannung")
on ENET connections, independent of VCI.Kl15/Kl30Voltage. This means
PatchISTAVoltageControl's injected voltage never covers it: an ENET
session on battery alone can still show a genuine "battery voltage
(terminal 30) below threshold value" message during plain diagnostic
work, even while ISTA's header displays a healthy injected value.

ModuleBootstrapLoader.doIt() -- the diagnostic test-module execution
loop, invoked on every module load -- is one of three independent
callers of that check. This patch targets only that call site: the
leading (short-circuit &&) branch on
ModuleLoader.IsModuleLoaderInitialized is turned into an unconditional
jump to the same target the false-case already used, so the guarded
block (including the voltage check call) is skipped regardless of the
flag's real value.

Logic.DoInitialElectricalChecks() (one-shot at connection) and the
Toyota-only call inside ProgrammingUtils.CheckVehicleProgramingProhibits
(a programming-plan gate) are deliberately left untouched -- this patch
never affects anything reachable from a coding/flashing session.

* docs: add missing <param>/<returns> tags (SA1611/SA1615)

PatchModuleBootstrapLoaderEthernetVoltageCheck's XML doc comment was
missing the <param name="module"> and <returns> tags flagged by
CodeFactor/StyleCop.

* feat: implement cancellation token support across commands and utilities

* feat: reorganize test namespaces and add global usings for improved structure

---------

Co-authored-by: TautCony <i@tautcony.xyz>
Co-authored-by: OrpheeGT <OrpheeGT@users.noreply.github.com>

Author: 3 people

AGENTS.md

@@ -44,7 +44,9 @@ dotnet build
 dotnet build -c Release
 dotnet test
 dotnet test src/ISTestA/ISTestA.csproj --filter FullyQualifiedName~UIAutomationTests
-bash scripts/check_copyright_years.sh
+python scripts/check_copyright_years.py
+python scripts/test-coverage.py
+python scripts/test-coverage.py --html --open
 ```
 
 Run the CLI:

openspec/changes/archive/2026-06-05-generate-xml-models-from-xsd/design.md

@@ -0,0 +1,36 @@
+## Approach
+
+Use the existing `ISTgenerAtor` analyzer project to generate source from XSD files supplied as `AdditionalFiles` by `ISTAlter.csproj`. The XSD files become the canonical description of the XML entities. The generator maps the supported XSD subset used by these contracts to C# classes, enums, XML serialization attributes, and data contract attributes.
+
+## Schema Scope
+
+The generator supports the constructs required by the current models:
+
+- top-level `xs:element`, `xs:complexType`, and `xs:simpleType`
+- ordered `xs:sequence` child elements
+- `xs:attribute` properties
+- inline simple enum restrictions
+- `maxOccurs="unbounded"` list properties
+- `nillable`, unqualified local elements, and XML data type annotations
+
+## Handwritten Extensions
+
+Behavior that cannot be represented by XSD remains in partial classes:
+
+- `LicenseInfo.Clone()`
+- `DealerMasterData.Serialize<T>()`
+- constructors that initialize nested objects and lists
+- inheritance from `EntitySerializer<T>` for license entities
+
+CLR-only generation hints are carried in `xs:annotation/xs:appinfo` under the
+`urn:ista-patcher:xsd-codegen` namespace. These annotations are intentionally
+outside the XML instance contract and use explicit names:
+
+- `codegen:class`
+- `xsdType`
+- `clrBaseTypes`
+- `clrUsingNamespace`
+
+## Tradeoffs
+
+The generator intentionally supports the repository's XSD subset instead of becoming a general-purpose XSD-to-C# compiler. That keeps implementation small and deterministic while still moving the source of truth to XSD.

openspec/changes/archive/2026-06-05-generate-xml-models-from-xsd/proposal.md

@@ -0,0 +1,16 @@
+## Why
+
+Rheingold XML model classes currently duplicate schema information in handwritten C# attributes. This makes XML contract changes error-prone because the schema and serializer attributes are not represented as first-class build inputs.
+
+## What
+
+- Add XSD files for the existing Rheingold license and dealer data XML contracts.
+- Generate the corresponding C# entity classes from those XSD files during compilation.
+- Keep non-schema behavior, such as cloning and serialization helpers, in handwritten partial classes.
+- Preserve existing public type names, namespaces, XML serialization attributes, and runtime behavior.
+
+## Impact
+
+- Affects `ISTAlter` XML model build inputs.
+- Extends `ISTgenerAtor` with XSD-driven model generation.
+- Existing code should continue using the same model type names.

openspec/changes/archive/2026-06-05-generate-xml-models-from-xsd/specs/xml-model-generation/spec.md

@@ -0,0 +1,23 @@
+## ADDED Requirements
+
+### Requirement: XSD-backed Rheingold XML Models
+
+Rheingold XML entity classes SHALL be generated from checked-in XSD schema files during compilation.
+
+#### Scenario: License XML models are generated
+
+- **GIVEN** the license schema is included in the project as a generator input
+- **WHEN** the project is compiled
+- **THEN** `LicenseInfo`, `LicensePackage`, and `LicenseType` are available with the existing XML serialization contract.
+
+#### Scenario: Dealer data XML models are generated
+
+- **GIVEN** the dealer data schema is included in the project as a generator input
+- **WHEN** the project is compiled
+- **THEN** dealer data classes and enums are available with the existing XML serialization contract.
+
+#### Scenario: Non-schema behavior is preserved
+
+- **GIVEN** generated XML model classes are used by existing code
+- **WHEN** callers clone licenses or serialize dealer master data
+- **THEN** those handwritten behaviors continue to work through partial class extensions.

openspec/changes/archive/2026-06-05-generate-xml-models-from-xsd/tasks.md

@@ -0,0 +1,12 @@
+## 1. Implementation
+
+- [x] Add XSD files that represent the existing XML-root model contracts.
+- [x] Add an XSD source generator to `ISTgenerAtor`.
+- [x] Wire XSD files into `ISTAlter.csproj` as generator inputs.
+- [x] Replace handwritten XML data entities with generated partial classes and handwritten behavior extensions.
+
+## 2. Verification
+
+- [x] Add or update focused tests for generated XML model behavior.
+- [x] Run targeted tests for XML serialization.
+- [x] Run build or full tests as needed.

openspec/changes/archive/2026-06-05-improve-test-coverage-from-results/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-06-05

openspec/changes/archive/2026-06-05-improve-test-coverage-from-results/coverage-baseline.md

@@ -0,0 +1,13 @@
+## Coverage Baseline
+
+Baseline run for this change:
+
+- Directory: `TestResults/20260605-203248`
+- Cobertura XML: `TestResults/20260605-203248/coverage.cobertura.xml`
+- HTML report: `TestResults/20260605-203248/coverage-report/index.html`
+- Overall line coverage: 27.6%
+- `ISTA-Patcher` line coverage: 0.0%
+- `ISTAvalon` line coverage: 67.4%
+- `ISTAlter` line coverage: 14.2%
+
+This baseline is used to compare package and class coverage after the planned tests are implemented.

openspec/changes/archive/2026-06-05-improve-test-coverage-from-results/coverage-results.md

@@ -0,0 +1,36 @@
+## Coverage Results
+
+Baseline:
+
+- Run: `TestResults/20260605-203248`
+- Overall lines: 27.67%
+- Overall branches: 27.86%
+- `ISTA-Patcher`: lines 0.00%, branches 0.00%
+- `ISTAvalon`: lines 67.43%, branches 58.24%
+- `ISTAlter`: lines 14.27%, branches 13.30%
+
+Current:
+
+- Run: `TestResults/20260605-205723`
+- Overall lines: 37.24%
+- Overall branches: 36.78%
+- `ISTA-Patcher`: lines 1.94%, branches 1.13%
+- `ISTAvalon`: lines 74.25%, branches 67.50%
+- `ISTAlter`: lines 26.71%, branches 23.38%
+
+Largest targeted improvements:
+
+- `ISTAPatcher.Utils.AvailablePorts`: 0% -> 100%
+- `ISTAvalon.Services.GuiObservationOptions`: 0% -> 100%
+- `ISTAvalon.Converters.LogMessageHighlighter`: 51.4% -> 85.6%
+- `ISTAlter.Models.Rheingold.LicenseManagement.LicenseStatusChecker`: 0% -> 100%
+- `ISTAlter.Utils.RegistryUtils`: 0% -> 95%
+- `ISTAlter.Utils.ResourceUtils`: 0% -> 57.1%
+- `ISTAlter.Core.PatchUtils`: 2.2% -> 11.7%
+
+Remaining deferred targets:
+
+- Real patch orchestration in `ISTAlter.Core.Patch`
+- High-complexity IL rewrites in `PatchUtils.Optional`
+- CLI command execution paths requiring real files, servers, or global process state
+- Platform/native utilities and telemetry initialization

openspec/changes/archive/2026-06-05-improve-test-coverage-from-results/design.md

@@ -0,0 +1,80 @@
+## Context
+
+The latest coverage artifact is `TestResults/20260605-203248/coverage.cobertura.xml`. It reports:
+
+- Overall line coverage: 27.6%
+- `ISTA-Patcher`: 0.0%
+- `ISTAvalon`: 67.4%
+- `ISTAlter`: 14.2%
+
+The largest uncovered regions are not all equally useful targets. Some functions require real ISTA assemblies, platform-specific APIs, registry state, or Sentry/global process state. The coverage plan should prioritize deterministic tests that improve confidence without introducing flaky environment coupling.
+
+## Goals / Non-Goals
+
+**Goals:**
+
+- Identify concrete functions that can raise coverage with stable, focused tests.
+- Prioritize tests by expected value and implementation risk.
+- Keep test changes in `src/ISTestA` unless a small test seam is needed.
+- Re-run `python scripts/test-coverage.py --html` and compare against `TestResults/20260605-203248`.
+
+**Non-Goals:**
+
+- Do not chase coverage by invoking real ISTA installations or patching unknown third-party binaries.
+- Do not require Windows registry, macOS Carbon/CoreFoundation, Linux machine IDs, or real network services for unit coverage.
+- Do not test Sentry delivery or external telemetry side effects.
+
+## Decisions
+
+### Prioritize Pure and Deterministic Functions First
+
+P1 targets are pure or near-pure functions with high confidence and low setup cost:
+
+- `ISTAvalon.Services.GuiObservationOptions.From`
+  - Current coverage: 0/41 lines in `From`, 0/1 in `Prefix`, 0/3 in `ParsePort`, 0/5 in `IsTruthy`.
+  - Test cases: env-only enablement, CLI enablement, falsey assignment, host via split and equals syntax, port via split and equals syntax, invalid port fallback, blank host fallback, `Prefix` formatting.
+- `ISTAvalon.Converters.LogMessageHighlighter.Highlight`
+  - Current uncovered areas: non-ANSI quote/number path, empty messages, every level brush branch, ANSI reset/unknown/extended color edge cases.
+  - Test cases: quoted strings strip quotes, numeric tokens use number brush, empty message returns one run, each `LogEventLevel` maps, ANSI 16-color/256-color/true-color/reset/invalid code behavior.
+- `ISTAPatcher.Utils.AvailablePorts.GetAvailablePort`
+  - Current coverage: 0/13 lines.
+  - Test cases: `startingPort > 65535` throws; starting from a valid high port returns a value in range. Avoid asserting a specific globally available port.
+
+Alternative considered: start with large uncovered `PatchUtils.Optional` methods. Rejected for first phase because they need careful dnlib fixture assemblies and carry more risk.
+
+### Add Focused Utility and Serialization Coverage Second
+
+P2 targets require small fixtures but are still deterministic:
+
+- `ISTAlter.Models.Rheingold.LicenseManagement.LicenseStatusChecker`
+  - Current coverage: 0%.
+  - Test cases: null `LicenseKey` returns false; generated key validates with matching RSA key; tampered license fails; deformatter creation uses expected hash algorithm path.
+- `ISTAlter.Utils.RegistryUtils.GenerateMockRegFile`
+  - Current coverage: 0%.
+  - Test cases: creates a `.reg` file without ISTA core DLL and defaults to native 64-bit hive; existing file is not overwritten when `force` is false; force overwrites. Assert generated text contains escaped license XML and `ForceDealerData`.
+- `ISTAlter.Utils.ResourceUtils`
+  - Current coverage: 0%.
+  - Test cases: update existing resource stream entry, preserve non-target entries, missing resource returns without throwing, missing file logs but preserves resource, `GetFromResource` returns target stream or throws when missing.
+
+Alternative considered: cover `AddWatermark` immediately. Deferred because it uses SkiaSharp image decoding/fonts and should be a separate small image-fixture task after resource table coverage.
+
+### Treat Patch and CLI Integration Paths as Third Phase
+
+P3 targets are valuable but need test seams or generated fixture assemblies:
+
+- `ISTAlter.Core.PatchUtils.Base`
+  - Candidate functions: `HavePatchedMark`, `AddPatchedAttribute`, `SetPatchedMarkInner`, `IsVersionInRange`, `IsPatchApplicable`, `PatchFunction`, `PatchGetter`, `PatchAsyncFunction`.
+  - Test strategy: build in-memory or temporary dnlib fixture assemblies with tiny types/methods and known attributes.
+- `ISTA-Patcher` commands and controllers
+  - Current package coverage: 0%.
+  - Test strategy: start with utility-level command dependencies (`AvailablePorts`), then add command tests only where file/network/console side effects can be isolated.
+- `TelemetryBootstrap.Initialize`
+  - Current coverage: 0%.
+  - Test strategy: either exclude from unit target or introduce a small test seam around Sentry/repository discovery before testing idempotence and tag fallback behavior.
+
+## Risks / Trade-offs
+
+- [Risk] Tests that assert exact available ports can be flaky on busy machines. → Mitigation: assert range and validity, not exact port, except for invalid input.
+- [Risk] Environment variable tests can leak process state. → Mitigation: save and restore `ISTA_GUI_DUMP_HTTP*` variables in setup/teardown.
+- [Risk] RSA/XML signature tests can become brittle if serialization changes intentionally. → Mitigation: assert round-trip validity and tamper failure, not fixed signature bytes.
+- [Risk] dnlib patch tests can overfit implementation details. → Mitigation: test public helper outcomes and assembly metadata changes before testing specific IL rewrites.

openspec/changes/archive/2026-06-05-improve-test-coverage-from-results/p3-evaluation.md

@@ -0,0 +1,21 @@
+## P3 Evaluation
+
+### Patch Function Helpers
+
+`PatchFunction` and `PatchGetter` can be covered with temporary dnlib metadata fixtures. The implementation now accepts `ModuleDef`, which matches the members actually used by the helpers and allows `ModuleDefUser` in-memory tests. `PatchAsyncFunction` is partially covered through the missing-method branch.
+
+Full positive-path `PatchAsyncFunction` coverage is deferred because a faithful async state-machine fixture requires constructing an `AsyncStateMachineAttribute`, nested generated type, override metadata, and a valid `MoveNext` body. That setup risks overfitting dnlib metadata details instead of testing stable behavior.
+
+### Telemetry Bootstrap
+
+`TelemetryBootstrap.Initialize` should remain out of the immediate unit coverage target. It initializes global Sentry state, reads git repository metadata, and is intentionally process-global/idempotent. Covering it well would require a seam around Sentry initialization and repository discovery. That seam is reasonable only if telemetry behavior changes.
+
+### CLI Command Coverage
+
+CLI command coverage should start with paths that avoid real ISTA files, live HTTP servers, global console state, or Sentry side effects:
+
+- Utility-level dependencies such as `AvailablePorts`.
+- Argument-to-model parsing where command descriptors can be constructed without executing patch operations.
+- File-generation commands only when all file system effects are isolated under temporary directories.
+
+Patch command execution, server startup, crypto file-list processing, and commands requiring real input files should remain integration-test candidates.