fix: default --end to +30 for reports schedule

[robzolkos]

Problem

basecamp reports schedule with no flags (and with only --start) always returns HTTP 400:

Error: API error (status 400)

Ref: https://3.basecamp.com/2914079/buckets/46292715/card_tables/cards/9717714333

Root cause

The bc3 DateParams concern uses params.require for both window_starts_on and window_ends_on. Either missing triggers ActionController::ParameterMissing, which UpcomingController rescues with head :bad_request.

A previous fix defaulted --start to today, but --end was left without a default. The SDK skips the WindowEndsOn field when endDate is empty, so every bare invocation was still sending only one of the two required params.

Verified via app/controllers/concerns/date_params.rb and app/controllers/reports/schedules/upcoming_controller.rb in bc3.

Fix

Default --end to +30 (30 days from start), parallel to the existing --start default. Update the Long description and both flag help strings to document the defaults so users and agents know what window they're getting.

Testing

Three new offline BATS tests in e2e/schedule.bats:

• --help output contains default: today and default: +30
• Bare reports schedule reaches the API stage (no usage error in output)
• --start alone also reaches the API stage

Updated the smoke test comment in e2e/smoke/smoke_reports.bats to clarify the escape hatch is for environment configuration issues only, not missing params. Added an explicit-window smoke variant.

bin/ci passes.

---

Summary by cubic

Defaulted --end to +30 and anchored it to the resolved --start for basecamp reports schedule, so bare runs and --start-only use a 30‑day window and no longer return HTTP 400. Updated help text and added a resolver with tests to verify the behavior.

• Bug Fixes
  • Default end date to +30, anchored to the parsed start; bare runs now send both required params and succeed.
  • Updated the long description and --start/--end flag help to show defaults.
  • Added a window resolver and tests: unit tests for the resolver; hardened e2e stub to assert a single API call with both params and proper anchoring; --help default checks; and a smoke test with an explicit-window variant (while marking environment-only API errors as unverifiable).

^{Written for commit f69e442. Summary will update on new commits.}

[Copilot]

Pull request overview

This PR fixes basecamp reports schedule failing with HTTP 400 when invoked without --end by introducing a default end window and updating CLI help/tests to document and validate the new defaults.

Changes:

• Default reports schedule --end to +30 when omitted, aligning with the existing default --start behavior.
• Update the command long description and flag help text to document the default window.
• Add/adjust BATS tests (offline + smoke) to ensure the command reaches the API stage without usage errors and that help output reflects defaults.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
internal/commands/reports.go	Adds an --end default and updates schedule command help text.
e2e/smoke/smoke_reports.bats	Clarifies smoke-test behavior and adds an explicit-window smoke variant.
e2e/schedule.bats	Adds offline tests asserting help text and that bare/start-only invocations reach the API stage.

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cubic-dev-ai]

2 issues found across 3 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="e2e/schedule.bats">

<violation number="1" location="e2e/schedule.bats:169">
P2: These new tests are too weak to catch the reported `status 400` regression; they only assert absence of usage text, which also passes on the broken behavior.</violation>
</file>

<file name="internal/commands/reports.go">

<violation number="1" location="internal/commands/reports.go:280">
P2: Defaulting `endDate` to `"+30"` evaluates to 30 days from *today*, not 30 days from the start date. If a user provides a future start date like `--start +60` without providing an `--end`, the end date will be calculated as before the start date. To fix this, the default end date should be calculated relative to the parsed start date.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[robzolkos]

Fixed — cubic identified two valid issues here: the default --end now anchors to the resolved start date, and the reports schedule BATS coverage now uses a local stub to assert the actual window_starts_on / window_ends_on query params.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.