Invoke-WcdStep: one Step runner behind every Module

[DireDoch]

Every Module writes the same twelve lines around the one line that does the
work:

Invoke-WcdProgressCallback ... -Event 'Start'
try {
    <the work>
    Write-WcdLog -Level 'INFO' ...
    Invoke-WcdProgressCallback ... -Event 'Finish' -Kind 'success'
    $results += [pscustomobject]@{ Step = $key; Success = $true; Error = '' }
} catch {
    Write-WcdLog -Level 'ERROR' ...
    Invoke-WcdProgressCallback ... -Event 'Finish' -Kind 'error'
    $results += [pscustomobject]@{ Step = $key; Success = $false; Error = $_.Exception.Message; RemedyKey = '...' }
}

The Result shape is a literal written 71 times across 12 files. Its optional
fields — Severity, RemedyKey, RemedyArgs, Applied, RebootPending —
have no schema anywhere. A typo in a property name is not an error; the
Diagnostic reads $null and the row quietly renders as a plain success.

The runner

$results += Invoke-WcdStep -Module 'Config-Power' -Key $key `
    -LogPath $resolvedLogPath -ProgressCallback $ProgressCallback `
    -SuccessLog 'Power: screen timeout on AC set to 15 min.' `
    -FailureLabel 'Screen timeout on AC' -FailureRemedy 'PowerCfgFailed' `
    -Action { Invoke-WcdPowerCfg '/change' 'monitor-timeout-ac' '15' }

Invoke-WcdStep owns the progress events, both log lines, the try/catch, and
the Result shape. The Action returns nothing on success, or emits a Result
fragment when the Step has something to say beyond OK.

What it has to absorb

Not every Step is the simple case, and the runner is only worth it if it covers
these without a -Raw escape hatch that half the callers use:

• Steps that succeed with a warning. Config-Power unelevated returns
  Success = $true; Severity = 'WARNING'; RemedyKey = 'RequiresAdmin' without
  running anything. The Action needs a way to say "did not run, here is why".
• Steps that carry extra fields. Applied on ComputerName / DomainJoin,
  RebootPending on WindowsUpdateReboot. Both are read by the Diagnostic to
  decide whether to raise the restart row.
• Steps whose severity depends on the reading. Config-Disk and
  Config-BitLocker pick OK / WARNING from what the machine reported, not from
  whether the call threw.
• Steps with RemedyArgs. The remediation template takes format arguments.
• One Module, many dynamic Steps. Config-Applications and
  Config-Printer loop over manifest entries.

If those five need five parameters, this is not a deepening — reconsider.

Do it incrementally

This touches all 12 Modules and all 12 test files. Convert Config-Power and
Config-TaskbarLeft first and stop there. Two adapters is enough to know
whether the interface holds; twelve at once is enough to know only that the
tests still pass.

Do #17 first — it settles what a Module owes the orchestrator, and this
issue settles what a Step owes a Module. Wrong order and this gets rewritten.

Done when

• Invoke-WcdStep in src/WcdHelpers.ps1, with comment-based help
• tests/WcdHelpers.Tests.ps1 covers: success, throw, did-not-run-with-reason,
  severity chosen by the Action, extra fields carried through, RemedyArgs
• Config-Power and Config-TaskbarLeft converted
• Their existing tests pass unchanged — the Results are identical
• A short note in the manual on when a Module should use the runner and when
  it should not
• Remaining 10 Modules left alone, deliberately, for a follow-up

[DireDoch]

Fait dans d7e1394 (PR #32).

Invoke-WcdStep est dans src/WcdHelpers.ps1. Les cinq cas difficiles de l'issue sont absorbes par un mecanisme, pas cinq parametres: l'Action ne retourne rien quand l'Etape a simplement marche, ou un hashtable fusionne dans le Resultat.

@{ Severity; Error; RemedyKey }   n'a pas tourne, et pourquoi — rapporte, pas echoue
@{ Severity; Error }              severite lue sur la machine, pas gagnee par un throw
@{ Applied }, @{ RebootPending }  champs supplementaires que le Diagnostic lit
@{ RemedyKey; RemedyArgs }        arguments de format du remede
@{ Log }                          une ligne de log autre que -SuccessLog

Ce que l'Action ecrit dans le pipeline et qui n'est pas un hashtable est ignore, donc une Action appelant une commande bavarde veut toujours dire "ca a marche".

Le seul parametre en plus est -OnFailure, qui classe une erreur attrapee. Config-TaskbarLeft ecrivait la classification registre/GPO deux fois; c'est maintenant un scriptblock partage par ses deux Etapes. Sans ca, ce Module aurait eu besoin de l'echappatoire -Raw contre laquelle l'issue met en garde.

Les kinds de progression viennent de Complete-WcdProgressStep, qui avait deja decide ce mapping — le runner ne le repete pas.

Resultats identiques, verifies. Les tests existants passent inchanges, mais ils ne couvrent que 2 des 8 chemins. Un harnais compare donc contre main chaque propriete de Resultat, chaque ligne de log (horodatage retire) et chaque evenement de progression pour portable/bureau x eleve/non eleve, powercfg qui leve, et l'ecriture registre reussie / refusee / en echec generique. 58 lignes, zero difference — y compris l'ordre des proprietes, que le rapport JSON reprend et qui a demande [ordered] sur le fragment de Config-Power.

tests/WcdHelpers.Tests.ps1 gagne 12 tests: succes, throw, bruit de pipeline ignore, n'a-pas-tourne-avec-raison, OnFailure qui classe, OnFailure a qui on n'autorise pas de declarer un succes, severite choisie par l'Action, champs supplementaires, RemedyArgs, l'override Log qui reste hors du Resultat, aucune ligne de log quand il n'y a rien a dire, et Step/Success/Error qui restent en tete.

Les 10 autres Modules sont laisses tels quels deliberement, et le manuel dit pourquoi: Config-Applications et Config-Printer bouclent sur des entrees de manifeste, Config-Network branche sur ce que les adaptateurs ont rapporte, et un runner dont la moitie des appelants s'echappe n'est pas un runner.