Feature: utilitiescs-nullable-reusabletypes

[drmoisan]

• Work Mode: full-feature

Problem / Why

The CI nullable gate (repaired by PR #361 to use msbuild /t:Rebuild ... /p:Nullable=enable /p:TreatWarningsAsErrors=true) was previously silently skipping a genuine recompile, allowing a
large body of pre-existing CS86xx nullable-reference-type diagnostics to accumulate. To enforce the
repaired gate without permanently blocking future PRs, the pre-existing nullable debt must be
remediated under a per-file #nullable enable opt-in architecture.

This child remediates the ReusableTypeClasses/ cluster: reusable base and value types (collections,
serialization bases, matrices, timed-action helpers) with cross-module consumers. Because these types
are consumed across module boundaries, their null annotations become part of the public contract
seen by downstream clusters - this is the cross_module_contract_change complexity floor signal.

Proposed Behavior

Bring each in-scope .cs file under UtilitiesCS/ReusableTypeClasses/ to zero CS86xx diagnostics
under a per-file #nullable enable pragma, with no behavior changes:

• Each remediated file receives a #nullable enable pragma at the top.
• Null annotations (?, null-forgiving where justified, nullable-aware generic constraints) and
  minimal null guards are added so the file compiles clean under
  msbuild /t:Rebuild /p:Nullable=enable /p:TreatWarningsAsErrors=true.
• Files not yet remediated remain non-opted-in and must not be cross-blocked.
• No runtime behavior change, no refactor, no API rename. Annotation and null-safety only.

Acceptance Criteria

• Every in-scope .cs file under UtilitiesCS/ReusableTypeClasses/ that is remediated carries a
  #nullable enable pragma.
• The solution builds with zero CS86xx diagnostics attributable to opted-in files under
  msbuild TaskMaster.sln /t:Rebuild /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true.
• No behavior changes: no method-body logic changes beyond null guards required for correctness.
• No reduction in coverage on changed lines.
• Non-opted-in files elsewhere in the repository are not cross-blocked by this change.

Constraints & Risks

• Per-file opt-in only; no project-level or solution-level <Nullable>enable</Nullable> flip.
• No editing of .claude/rules/* (policy prohibits it).
• Cross-module contract risk: annotations here are consumed by downstream Outlook/Email/Dialogs
  clusters; annotations must reflect the true null-state contract, not merely silence diagnostics.
• Serialization types (NewSmartSerializable/, SerializableNew/, Serializable/) and generic
  collection bases require care so that nullable annotations on generic parameters remain accurate.
• Designer-generated and WinForms-derived files (e.g. ConfigViewer.Designer.cs) may be exempt from
  the opt-in per the COM/VSTO/WinForms coverage-and-nullable posture; scope confirmed in research.

Test Conditions

• Nullable-gate rebuild passes for opted-in files.
• Existing MSTest suites covering these reusable types continue to pass unchanged.
• No coverage regression on changed lines.

Source

From: docs/features/potential/2026-07-18-utilitiescs-nullable-reusabletypes.md