[Automated] Update yq CLI Options

[thomhurst]

Summary

This PR contains automatically generated updates to yq 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

PR #2576 — [Automated] Update yq CLI Options

This is a single-line, fully automated change updating the GeneratedAt timestamp metadata in AssemblyInfo.Generated.cs:

- [assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-04-26T03:26:03.4316897Z")]
+ [assembly: AssemblyMetadata("ModularPipelines.OptionsGenerator.GeneratedAt", "2026-05-03T03:43:56.3005617Z")]

Assessment

No issues found. The change is exactly what is expected from the automated yq CLI options generator — a timestamp refresh confirming the tool was re-run against the latest installed yq CLI. There are no logic, API, or behavioral changes.

A few observations on the broader automation pattern (not blocking):

1. PR description vs. diff: The PR description says "Updated options classes to reflect latest CLI documentation / Added new commands if any were detected / Updated option types and descriptions", but the actual diff is only a timestamp bump with no yq option changes. It would improve traceability if the automation tailored the description to reflect that no yq option changes were detected this cycle — currently the boilerplate description is misleading for timestamp-only runs.

2. Value of timestamp-only PRs: Emitting a PR when the only change is the generation timestamp adds noise. Consider suppressing the PR (or skipping the commit) if no options content changed. This would reduce reviewer fatigue for truly no-op runs.

Neither of these is a problem with this specific PR; the change itself is safe and correct.

✅ Approved for merge.