[Automated] Update go CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to go CLI options classes.

The generator scraped the latest CLI help output from the installed tool.

Changes

• Updated options classes to reflect latest CLI documentation
• Added new commands if any were detected
• Updated option types and descriptions

Verification

• Solution builds successfully

---

🤖 Generated with ModularPipelines.OptionsGenerator

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	✅ 0 (≤ 20 complexity)

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[claude]

Code Review

This PR contains a single change: updating the GeneratedAt timestamp in src/ModularPipelines.Go/AssemblyInfo.Generated.cs from 2026-04-19T03:34:40Z to 2026-04-26T03:45:10Z. No Go options classes were actually modified.

The code itself is fine — the timestamp update is correct and follows the established convention. However, this review surfaces a recurring systemic issue worth addressing.

---

Issue: Change detection does not filter timestamp-only PRs

File: .github/workflows/generate-cli-options.yml

The workflow's change detection step uses --ignore-all-space --ignore-blank-lines to suppress whitespace noise, but the GeneratedAt timestamp is a non-whitespace value change on a non-blank line. It always passes the "has_changes=true" gate, causing a PR to open every week even when the actual Go CLI options are 100% identical to the previous run.

Looking at the merged Go options PR history, this has been a recurring pattern — every recent Go options PR is a timestamp-only diff with no substantive options content changes. This generates weekly PR noise, wastes CI runner time, and requires human attention for a meaningless diff.

Root cause: GeneratorUtils.GenerateAssemblyInfo always writes DateTime.UtcNow unconditionally, so every regeneration produces a new timestamp regardless of whether the underlying CLI output changed.

Recommended fix: Exclude AssemblyInfo.Generated.cs from the change-detection diff (while still committing the file), so PRs are only opened when actual options content changes:

git add 'src/**/*.cs'
# Evaluate meaningful changes by ignoring only the timestamp file
if git diff --staged --quiet --ignore-all-space --ignore-blank-lines \
    -- ':(exclude)src/**/AssemblyInfo.Generated.cs'; then
  echo "has_changes=false" >> $GITHUB_OUTPUT
else
  echo "has_changes=true" >> $GITHUB_OUTPUT
fi

This preserves the timestamp commit (useful for traceability) while preventing timestamp-only PRs. Alternatively, the GeneratedAt value could track the Go CLI tool version/hash rather than wall-clock time — that way it only changes when the installed CLI version actually changes, which is the meaningful signal.

Why this matters: The current behaviour trains reviewers to auto-approve Go options PRs without scrutiny, which could mask a real options change when one eventually arrives.

---

Observation: Go options classes are empty despite scraper having parsing logic

All six Go options records (GoBuildOptions, GoTestOptions, GoVetOptions, etc.) are empty shells. The GoCliScraper contains FlagsSectionPattern and GoOptionPattern regex logic that should extract flags from go help <cmd> output, but the generated classes never reflect any flags.

This is not a blocker for this PR, but it is worth investigating whether the Go help text format matches what the scraper expects. Commands like go build and go test expose many stable, well-known flags (-race, -v, -tags, -ldflags, -run, -timeout, etc.) that would make the Go integration substantially more useful if exposed as typed options.

---

Summary

The timestamp update is correct and uncontroversial. The actionable work is fixing the change-detection logic in the CI workflow so future timestamp-only runs do not create PRs at all. This is a low-effort change with high ongoing benefit.