Map EKEvent.notes to Event.description

[nashysolutions-bot]

Closes #20. (Opened from the Async Digital org account; #20 was filed under my personal account, nashysolutions.)

Ontology.Event had no property for an event's notes, so EKEvent.notes was dropped in init(_ event: EKEvent). Downstream in iMCP that makes notes write-only: events_create accepts a notes argument and sets it on the event, but events_fetch returns Ontology.Event, so the field can never be read back — including by the client that just wrote it.

It compounds with iMCP#129: until events_update exists, amending an event means delete-plus-recreate, and since the notes cannot be read first, that silently discards them.

The change

Mirrors the existing treatment of the Reminders equivalent, where PlanAction.init(_ reminder: EKReminder) already maps reminder.notes to description:

• public var description: String? on Event, positioned as in PlanAction
• self.description = event.notes in init(_ event: EKEvent)
• description added to CodingKeys, with the matching encodeIfPresent / decodeIfPresent

description is a valid property on schema.org/Event, so the JSON-LD spelling needs no special-casing.

Tests

Two added to EventTests:

• Event initialization preserves notes as description — the mapping happens, and stays nil when the event has no notes.
• Event round-trip serialization preserves notes — the value appears as description in the encoded JSON-LD and survives a decode.

Both were checked against the unpatched type as a control: they do not merely fail, they do not compile, since Event has no description member without this change.

swift test --filter EventTests → 7/7 passing.

One unrelated observation

PlaceTests' "Place initialization from MKMapItem" fails on my machine on place.telephone == "555-6789", getting "55 5678 9". It fails identically on an unmodified checkout, and CI on main is green, so it looks locale-sensitive rather than broken — CNPhoneNumber's formatting differs under an en_GB system locale. Untouched here; mentioning it only because any contributor outside a US locale will see a red suite locally and wonder whether they caused it.

[mattt]

Hi @nashysolutions. Thanks for the clear write-up and for mirroring the PlanAction treatment. This landed on main as 9181735, credited to you rather than the bot account, and it's out in 0.9.0. iMCP picks it up in its next release.