refactor(Initialize-NovaModule): align with terminal-ux-design principles

[stiwicourage]

Summary

Audit and refactor Initialize-NovaModule (src/public/InitializeNovaModule.ps1) and its nova CLI route, if any, against the terminal-ux-design skill (Atlassian's 10 design principles for delightful CLIs). Depends on the introduction of that skill.

Depends on

• feat: introduce terminal-ux-design skill and instruction for delightful command UX #214

Audit checklist (Atlassian's 10 principles)

For each item: confirm the command already meets it, or list a concrete change.

• 1. Align with established conventions — verb-noun naming, parameter conventions, exit codes, output streams.
• 2. Build help into the command — comment-based help is complete (synopsis, description, parameters, examples, links); Get-Help Initialize-NovaModule -Full and % nova <route> --help produce parity output.
• 3. Show progress visually — long-running steps use Write-Progress or equivalent, broken into meaningful stages.
• 4. Create a reaction for every action — every command path ends with a clear success/failure summary line, not silent return.
• 5. Craft human-readable error messages — every Stop-NovaOperation (or equivalent) has a stable ErrorId, a description of what failed, and an actionable suggestion or link.
• 6. Support skim-readers — help text and console output use short paragraphs, headings or bullets, sparing iconography.
• 7. Suggest the next best step — successful runs surface the next logical command (e.g. after Invoke-NovaBuild, point at Test-NovaBuild).
• 8. Consider your options — prompt for missing required values where interactive, supply sensible defaults, and document them in help.
• 9. Provide an easy way out — long-running or interactive flows respect Ctrl+C / cancellation and tell the user how to abort.
• 10. Flags over args — named parameters with sensible short aliases; no positional-only arguments for newly added parameters.

Out of scope

• Behavioral changes that go beyond UX alignment (functional bugs get their own issue).
• Cross-command refactors (any shared helper extracted must be small and limited to what this command needs).

Acceptance criteria

• Audit checklist completed in the PR description.
• Updated PlatyPS help under docs/NovaModuleTools/en-US/Initialize-NovaModule.md if user-visible help or parameters changed.
• Updated CHANGELOG.md entry under Unreleased → Changed if user-visible behavior changed.
• pwsh -NoLogo -NoProfile -File ./run.ps1 passes.
• ./scripts/build/Invoke-ScriptAnalyzerCI.ps1 reports no new findings.

Validation

• pwsh -NoLogo -NoProfile -File ./run.ps1
• ./scripts/build/Invoke-ScriptAnalyzerCI.ps1

Recommended follow-on agent

powershell-developer for implementation; reviewer for merge gate.

Additional checklist — Jakob Nielsen's usability heuristics (only those not already covered above)

For each item: confirm the command already meets it, or list a concrete change.

• Match between system and the real world (Nielsen #1: feat: add semantic-release based release automation #2) — terminology in help, prompts, warnings, and errors matches the user's mental model and the surrounding ecosystem (PowerShell verbs, nova CLI vocabulary). No internal jargon leaks into user-facing strings.
• Error prevention (Nielsen Generate Code Coverage Report and Upload Coverage to CodeScene #5) — risky operations require confirmation (-Confirm / ShouldProcess / -OverrideWarning); dangerous defaults are avoided; pre-flight validation catches likely mistakes before they happen.
• Recognition rather than recall (Nielsen Standardized CLI and Automated Release Flow for Nova PowerShell Module #6) — required values are surfaced via help, prompts, completers, or defaults; the user does not have to remember IDs, paths, or option names from earlier commands.
• Flexibility and efficiency of use (Nielsen Add Repository Links to Changelog #7) — common flows have short aliases / parameter aliases / nova CLI shortcuts for power users, without hurting first-time discoverability.
• Aesthetic and minimalist design (Nielsen Implement project metadata command (nova info) #8) — terminal output stays focused on what the user needs; no noisy banners, repeated information, or decorative output in non-verbose modes.

Launcher / CLI router changes are out of scope

Changes to src/resources/nova, Invoke-NovaCli routing, or shared src/private/cli/*.ps1 helpers are not in scope for this issue. If the audit surfaces a CLI-wide concern (for example exit-code translation, --help parity, or Ctrl+C handling at the router), raise it against #220 or #222 instead.