PR #206 — Fix T-1799: Reject invalid calendar date filters

diff --git a/CHANGELOG.md b/CHANGELOG.mdindex 0365791..bd359a9 100644--- a/CHANGELOG.md+++ b/CHANGELOG.md@@ -7,6 +7,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). ## [Unreleased]  ### Fixed+- T-1799: QueryTasksIntent absolute date filters now require exact ASCII `YYYY-MM-DD` values representing valid dates in the user's current calendar. Local `Calendar.current` parsing, non-lenient formatter round-trip validation, and regressions reject normalized invalid days/months, non-padded values, and non-ASCII input while preserving inclusive ranges and relative filters. - MCP `create_task`, `create_milestone`, `CreateTaskIntent`, and `CreateMilestoneIntent` now distinguish missing required fields from present non-string `name`/`type` values (T-1598). Numeric, boolean, array, object, and null inputs return field-specific `name must be a string` / `type must be a string` validation errors before mutation, while missing-field and invalid-string-type behavior remains unchanged. Symmetric regression coverage verifies all four create paths and confirms malformed requests create no records. - `QueryTasksIntent` now rejects explicit JSON `null` in nested `completionDate` and `lastStatusChangeDate` fields (`relative`, `from`, and `to`) before Codable decoding can erase presence. Malformed nested date-filter shapes retain the established `INVALID_INPUT` contract, omitted fields remain unchanged, and regressions cover both filters and no-broadening behavior (T-1644). - `Color.hexString` now rounds resolved RGB components to the nearest byte after finite-checking and clamping instead of truncating values just below byte boundaries (T-1807). Project colors no longer darken when an editor saves an unchanged color. Regression coverage exercises every `0...255` RGB value, deterministic sRGB resolved components immediately below each boundary, and the existing uppercase six-digit RGB/no-alpha format.

diff --git a/Transit/Transit/Intents/Shared/Utilities/DateFilterHelpers.swift b/Transit/Transit/Intents/Shared/Utilities/DateFilterHelpers.swiftindex 624bca7..7d1fbbc 100644--- a/Transit/Transit/Intents/Shared/Utilities/DateFilterHelpers.swift+++ b/Transit/Transit/Intents/Shared/Utilities/DateFilterHelpers.swift@@ -14,12 +14,23 @@ enum DateFilterHelpers {         case absolute(from: Date?, toDate: Date?)     } +    // Preserve the user's calendar identifier while fixing the locale and timezone used+    // for machine-readable date-only values. This matches the documented Calendar.current+    // semantics and keeps absolute comparisons aligned with the parser across DST changes.+    private static let localDayCalendar: Calendar = {+        var calendar = Calendar.current+        calendar.locale = Locale(identifier: "en_US_POSIX")+        calendar.timeZone = TimeZone.current+        return calendar+    }()+     private static let localDayFormatter: DateFormatter = {         let formatter = DateFormatter()-        formatter.dateFormat = "yyyy-MM-dd"-        formatter.calendar = Calendar.current-        formatter.timeZone = TimeZone.current+        formatter.calendar = localDayCalendar+        formatter.timeZone = localDayCalendar.timeZone         formatter.locale = Locale(identifier: "en_US_POSIX")+        formatter.dateFormat = "yyyy-MM-dd"+        formatter.isLenient = false         return formatter     }() @@ -97,7 +108,7 @@ enum DateFilterHelpers {             return dateInPreviousPeriod(date, component: .year, now: now, calendar: calendar)          case .absolute(let from, let toDate):-            return dateInAbsoluteRange(date, from: from, toDate: toDate, calendar: calendar)+            return dateInAbsoluteRange(date, from: from, toDate: toDate, calendar: localDayCalendar)         }     } @@ -139,6 +150,23 @@ enum DateFilterHelpers {     }      private static func dateFromString(_ value: String) -> Date? {-        localDayFormatter.date(from: value)+        guard hasExactDateShape(value),+              let date = localDayFormatter.date(from: value),+              localDayFormatter.string(from: date) == value else {+            return nil+        }+        return date+    }++    private static func hasExactDateShape(_ value: String) -> Bool {+        let bytes = Array(value.utf8)+        guard bytes.count == 10, bytes[4] == 45, bytes[7] == 45 else {+            return false+        }++        for (index, byte) in bytes.enumerated() where index != 4 && index != 7 {+            guard (48...57).contains(byte) else { return false }+        }+        return true     } }

diff --git a/Transit/TransitTests/DateFilterHelpersTests.swift b/Transit/TransitTests/DateFilterHelpersTests.swiftindex bb793c9..d473a40 100644--- a/Transit/TransitTests/DateFilterHelpersTests.swift+++ b/Transit/TransitTests/DateFilterHelpersTests.swift@@ -41,6 +41,45 @@ struct DateFilterHelpersTests {         #expect(parsed == nil)     } +    @Test("parse absolute filter accepts real Gregorian leap-day dates")+    func parseAbsoluteFilterAcceptsLeapDay() {+        let parsed = DateFilterHelpers.parseDateFilter([+            "from": "2024-02-29",+            "to": "2024-03-01"+        ])++        guard case .absolute(let from, let toDate) = parsed else {+            Issue.record("Expected absolute range")+            return+        }+        #expect(from != nil)+        #expect(toDate != nil)+    }++    @Test("parse absolute filter rejects non-calendar and non-ASCII date strings", arguments: [+        "2023-02-29", // Non-leap year day overflow+        "2024-02-30", // Leap-year month day overflow+        "2026-04-31", // Month day overflow+        "2026-00-01", // Month below lower boundary+        "2026-13-01", // Month above upper boundary+        "2026-02-00", // Day below lower boundary+        "0000-01-01", // Gregorian year below lower boundary+        "2026-２-01", // Full-width non-ASCII digit+        "2026−02−01" // Unicode minus separators+    ])+    func parseAbsoluteFilterRejectsInvalidCalendarDateStrings(value: String) {+        #expect(DateFilterHelpers.parseDateFilter(["from": value]) == nil)+    }++    @Test("parse absolute filter rejects non-padded date strings", arguments: [+        "2026-2-01",+        "2026-02-1",+        "2026-2-1"+    ])+    func parseAbsoluteFilterRejectsNonPaddedDateStrings(value: String) {+        #expect(DateFilterHelpers.parseDateFilter(["from": value]) == nil)+    }+     @Test func absoluteRangeComparisonIsInclusive() {         let calendar = Calendar.current         let from = calendar.startOfDay(for: Date.now)

diff --git a/Transit/TransitTests/QueryTasksIntentDateFilterTests.swift b/Transit/TransitTests/QueryTasksIntentDateFilterTests.swiftindex c52c1df..22e40b5 100644--- a/Transit/TransitTests/QueryTasksIntentDateFilterTests.swift+++ b/Transit/TransitTests/QueryTasksIntentDateFilterTests.swift@@ -4,6 +4,7 @@ import Testing @testable import Transit  @MainActor @Suite(.serialized)+// swiftlint:disable:next type_body_length struct QueryTasksIntentDateFilterTests {      private struct Services {@@ -266,6 +267,28 @@ struct QueryTasksIntentDateFilterTests {         #expect(parsed["error"] as? String == "INVALID_INPUT")     } +    @Test("QueryTasksIntent rejects malformed absolute date strings", arguments: [+        "2026-02-30", // Normalized invalid day+        "2026-13-01", // Invalid month boundary+        "2026-2-01", // Non-padded month+        "2026-02-１" // Non-ASCII digit+    ])+    func malformedAbsoluteDateStringsReturnInvalidInput(value: String) throws {+        let svc = try makeServices()++        for field in ["completionDate", "lastStatusChangeDate"] {+            let result = QueryTasksIntent.execute(+                input: "{\"\(field)\":{\"from\":\"\(value)\"}}",+                projectService: svc.project,+                taskService: svc.task,+                milestoneService: svc.milestone+            )++            let parsed = try parseJSON(result)+            #expect(parsed["error"] as? String == "INVALID_INPUT")+        }+    }+     @Test func existingQueriesRemainCompatibleWithoutDateFilters() throws {         let svc = try makeServices()         let project = makeProject(in: svc.context)

diff --git a/specs/bugfixes/query-tasks-intent-accepts-invalid-calendar-date-strings/report.md b/specs/bugfixes/query-tasks-intent-accepts-invalid-calendar-date-strings/report.mdnew file mode 100644index 0000000..c155f0d--- /dev/null+++ b/specs/bugfixes/query-tasks-intent-accepts-invalid-calendar-date-strings/report.md@@ -0,0 +1,92 @@+# Bugfix Report: Query Tasks Intent Accepts Invalid Calendar Date Strings++**Date:** 2026-08-02+**Status:** Fixed++## Description of the Issue++`QueryTasksIntent` documents absolute date filters as `YYYY-MM-DD`, but `DateFilterHelpers` delegates parsing to a lenient `DateFormatter`. Foundation accepts non-padded values and normalizes invalid calendar components, so inputs such as `2026-02-30` can be treated as a different valid date instead of returning `INVALID_INPUT`.++**Reproduction steps:**+1. Invoke `QueryTasksIntent` with `{"completionDate":{"from":"2026-02-30"}}` or a non-padded value such as `2026-2-01`.+2. Observe that the date filter is accepted rather than rejected.+3. Compare with the documented exact `YYYY-MM-DD` contract.++**Impact:** CLI, Shortcuts, and agent callers can receive results for a silently altered date filter. The issue affects absolute `completionDate` and `lastStatusChangeDate` filters; relative filters are unaffected.++## Investigation Summary++- **Symptoms examined:** Invalid days/months, non-padded fields, Unicode digits/separators, valid leap-day input, inclusive absolute ranges, and relative date filters.+- **Code inspected:** `DateFilterHelpers`, `QueryTasksIntent` validation/application paths, `FindTasksIntent` shared-helper usage, and existing date-filter tests.+- **Hypotheses tested:** The defect is in shared date parsing rather than intent JSON decoding or task filtering. Focused pre-fix regressions fail for normalized invalid days, non-padded values, and non-ASCII input while existing valid and relative cases pass.++## Discovered Root Cause++`DateFilterHelpers.dateFromString` calls `DateFormatter.date(from:)` with only a `yyyy-MM-dd` format. That API does not enforce exact lexical width/ASCII characters and can normalize invalid date components before returning a `Date`. `QueryTasksIntent` treats any non-`nil` parsed date as valid.++**Defect type:** Missing input validation and date normalization.++**Why it occurred:** The formatter was configured for output shape but not strict input validation. No lexical check or parsed-date round-trip check guarded the public filter boundary.++**Contributing factors:** Foundation date parsing is permissive; both JSON date fields share the helper, so a single parser defect affects both absolute filters.++## Resolution for the Issue++**Changes made:**+- `Transit/Transit/Intents/Shared/Utilities/DateFilterHelpers.swift` - Preserved `Calendar.current` with the current local time zone and POSIX locale; rejected every input without exactly ten ASCII bytes in `YYYY-MM-DD` shape; disabled formatter leniency; and required formatter round-trip equality so normalized invalid dates are rejected. Absolute range comparisons use the same local current-calendar semantics as parsing, while relative filters retain their existing behavior.+- `Transit/TransitTests/DateFilterHelpersTests.swift` - Added valid leap-day coverage plus invalid leap-year, month/day boundary, non-ASCII, and non-padded regressions.+- `Transit/TransitTests/QueryTasksIntentDateFilterTests.swift` - Added intent-level `INVALID_INPUT` coverage for malformed values in both absolute date-filter fields.++**Approach rationale:** Exact byte-shape validation prevents Foundation from accepting alternate lexical forms, and round-trip equality detects dates that Foundation normalizes. Explicit locale/time-zone configuration preserves the documented `Calendar.current` date semantics and keeps parsing and inclusive comparisons aligned across local DST changes without changing relative filters.++**Alternatives considered:**+- Relying only on `DateFormatter.isLenient = false` - Not sufficient for the documented exact ASCII lexical contract, so shape validation and round-trip equality are both required.+- Parsing with `Date.ISO8601FormatStyle` - Would introduce different date-only/time-zone semantics and is unnecessary for this existing helper boundary.++## Regression Test++**Test files:**+- `Transit/TransitTests/DateFilterHelpersTests.swift`+- `Transit/TransitTests/QueryTasksIntentDateFilterTests.swift`++**Test names:**+- `parseAbsoluteFilterAcceptsLeapDay()`+- `parseAbsoluteFilterRejectsInvalidCalendarDateStrings(value:)`+- `parseAbsoluteFilterRejectsNonPaddedDateStrings(value:)`+- `malformedAbsoluteDateStringsReturnInvalidInput(value:)`++**What it verifies:** Absolute filters accept real Gregorian leap days, reject invalid month/day boundaries and non-leap-year dates, reject non-ASCII and non-padded values, and surface `INVALID_INPUT` through both QueryTasksIntent date fields.++**Run command:** `make test-quick`++## Affected Files++| File | Change |+|------|--------|+| `Transit/Transit/Intents/Shared/Utilities/DateFilterHelpers.swift` | Strict exact-shape, current-calendar, local-time-zone, round-trip date parsing |+| `Transit/TransitTests/DateFilterHelpersTests.swift` | Parser regressions |+| `Transit/TransitTests/QueryTasksIntentDateFilterTests.swift` | Intent-level regressions |+| `specs/bugfixes/query-tasks-intent-accepts-invalid-calendar-date-strings/report.md` | Investigation and resolution report |+| `CHANGELOG.md` | Unreleased fix entry |++## Verification++**Automated:**+- [x] Focused helper and QueryTasksIntent tests pass on macOS+- [x] Full `make test-quick` suite passes+- [x] `make lint` and the SwiftData ownership validator pass++**Manual verification:**+- The pre-fix focused run reproduced failures for normalized invalid days, non-padded values, non-ASCII input, and the intent-level validation path.+- The post-fix focused run passed all existing relative/inclusive cases and all new regressions.++## Prevention++- Validate exact input shape before invoking Foundation date parsing.+- Preserve `Calendar.current` while explicitly configuring locale and local time-zone semantics for machine-readable dates.+- Require formatter round-trip equality before accepting a parsed calendar date.+- Keep parser-level and intent-level regressions for externally documented input formats.++## Related++- Transit ticket T-1799