[Automated] Update newman CLI Options

[thomhurst]

Summary

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

[claude]

Code Review

Summary

This automated PR only updates the timestamp in — from to . There are no changes to the newman CLI options themselves (no new commands, updated flags, or modified types).

Observation: Noisy Automation

The generator re-ran and produced a PR purely for a timestamp bump. This creates PR noise without any functional value. Consider whether the options generator should:

1. Skip PR creation when no substantive changes exist — diff the generated options files (excluding the timestamp) before opening a PR. If the only difference is the field, suppress the PR entirely.
2. Batch updates across tools — rather than one PR per tool per run, a single PR covering all tools with real changes would reduce review burden.
3. Use a commit-only flow for timestamp-only runs — if the intent is to record when the tool was last checked, commit directly to main (or a dedicated branch) without opening a PR for human review.

The Change Itself

The single-line change is correct and harmless. No concerns with what was generated.

Verdict

The automation logic that decides when to open a PR is worth revisiting — a PR that touches only a metadata timestamp adds overhead without meaningful signal for reviewers.

[claude]

Code Review

Summary

This automated PR only updates the GeneratedAt timestamp in AssemblyInfo.Generated.cs — from 2026-04-26T03:38:06Z to 2026-05-03T03:42:58Z. There are no changes to the newman CLI options themselves (no new commands, updated flags, or modified types).

Observation: Noisy Automation

The generator re-ran and produced a PR purely for a timestamp bump. This creates PR noise without any functional value. Consider whether the options generator should:

1. Skip PR creation when no substantive changes exist — diff the generated options files (excluding the timestamp) before opening a PR. If the only difference is the GeneratedAt field, suppress the PR entirely.
2. Batch updates across tools — rather than one PR per tool per run, a single PR covering all tools with real changes would reduce review burden.
3. Use a commit-only flow for timestamp-only runs — if the intent is to record when the tool was last checked, commit directly to main (or a dedicated branch) without opening a PR for human review.

The Change Itself

The single-line change is correct and harmless. No concerns with what was generated.

Verdict

The automation logic that decides when to open a PR is worth revisiting. A PR that touches only a metadata timestamp adds overhead without meaningful signal for reviewers.

[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.}