Default check-ins answer date to today

[robzolkos]

Summary

Default basecamp checkins answer create to use today's date when --date is omitted.

Changes

• default checkins answer create --date / group_on to today
• preserve explicit --date when provided
• update --date help text to mention the default
• update skills/basecamp/SKILL.md to document the behavior

Why

The web UI preselects today for check-in answers, and live API behavior requires a date for successful answer creation. This makes the CLI match the web experience while still allowing an explicit override.

---

Summary by cubic

Default basecamp checkins answer create and TUI hub answer creation to use today’s date when --date is omitted, matching the web UI and avoiding API errors. Explicit --date kept; help/docs updated; tests cover default and explicit dates.

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

[Copilot]

Pull request overview

Default basecamp checkins answer create to use today’s date when --date is omitted, aligning CLI behavior with the Basecamp web UI and avoiding API failures when group_on is missing.

Changes:

• Default checkins answer create --date / group_on to today when omitted
• Preserve explicit --date when provided and update --date help text accordingly
• Add command tests and update Basecamp skill docs to reflect the new default

Reviewed changes

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

File	Description
skills/basecamp/SKILL.md	Documents that checkins answer create defaults --date to today when omitted.
internal/commands/checkins.go	Implements the defaulting behavior and updates --date flag help text.
internal/commands/checkins_test.go	Adds tests verifying default-date behavior and explicit-date preservation.

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]

No issues found across 3 files

[robzolkos]

Fixed — avoided mutating the flag-backed --date variable inside RunE and made the default-date test deterministic by capturing the expected date once.

[Copilot]

Pull request overview

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

---

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

[jeremy]

Review

The default-to-today behavior is correct and well-tested. All prior Copilot feedback has been addressed across the 3 commits (local effectiveGroupOn, injectable clock, body close).

Suggestion: expand --date to accept natural language dates

Every command that takes a user-facing date (todos, cards, lineup, reports) runs input through dateparse.Parse(), which supports natural language ("today", "tomorrow", "next monday", "+3", "eow") alongside YYYY-MM-DD. checkins answer create --date currently passes raw input straight to the API.

Proposed change in internal/commands/checkins.go:780-783:

now := checkinsNow()
effectiveGroupOn := groupOn
if effectiveGroupOn == "" {
    effectiveGroupOn = now.Format("2006-01-02")
} else {
    effectiveGroupOn = dateparse.ParseFrom(effectiveGroupOn, now)
}

Using ParseFrom(input, checkinsNow()) rather than Parse(input) keeps a single clock source for both the default and explicit paths — deterministic in tests via the injected checkinsNow, consistent in production with one time.Now() call.

Accompanying updates needed:

• Flag help (checkins.go:835): change to "Date to group answer (natural language or YYYY-MM-DD; defaults to today)" — matches the pattern in todos/cards
• Skill docs (SKILL.md:761): update to mention natural language support
• Test: add TestCheckinsAnswerCreateParsesNaturalLanguageDate passing --date tomorrow and asserting against the injected clock

(schedule is intentionally excluded from this pattern — its --date is a YYYYMMDD occurrence key, not a user date.)