@mmerterden/multi-agent-pipeline 20.7.0 → 20.8.1

package/pipeline/skills/shared/external/live-activities/evals/evals.json

@@ -3,41 +3,41 @@
   "evals": [
     {
       "id": 1,
-      "prompt": "I'm adding a food delivery Live Activity to an iOS app. Sketch the ActivityKit implementation for the attributes, request/update/end lifecycle, Lock Screen view, Dynamic Island regions, and server push token handling. Call out the Info.plist keys and availability checks I need.",
-      "expected_output": "A source-grounded ActivityKit implementation outline with Swift snippets and review notes for local lifecycle, Lock Screen/Dynamic Island presentation, push token forwarding, stale handling, and cleanup.",
+      "prompt": "We sell groceries and want a Live Activity that follows each order from packing to the doorstep, with an arrival-window countdown driven by our backend. Sketch the model, the start/update/end code and the layouts.",
+      "expected_output": "An ActivityContent-based design with a small ContentState, host-app Info.plist key, update-token forwarding, Lock Screen first with all three Dynamic Island modes, stale handling and ending on every terminal path.",
       "files": [],
       "expectations": [
-        "Uses ActivityContent-based Activity.request/update/end APIs rather than deprecated contentState lifecycle APIs.",
-        "Mentions NSSupportsLiveActivities in the host app Info.plist and keeps ContentState small.",
-        "Forwards update tokens with activity.pushTokenUpdates and notes that tokens can rotate.",
-        "Designs Lock Screen as the primary surface and includes Dynamic Island compact, expanded, and minimal presentations only for devices with Dynamic Island.",
-        "Handles staleDate/context.isStale and ends the activity on success, error, and cancellation paths."
+        "Uses ActivityContent for request, update and end, and does not use the deprecated contentState-based APIs",
+        "Puts NSSupportsLiveActivities in the main app target's Info.plist and keeps the ContentState compact",
+        "Forwards update tokens from activity.pushTokenUpdates and notes that they rotate",
+        "Treats the Lock Screen as primary and adds compact, expanded and minimal Dynamic Island layouts only as the presentation for capable devices",
+        "Sets a staleDate, reads context.isStale in the view, and ends the activity whether the order succeeds, fails or is cancelled"
       ]
     },
     {
       "id": 2,
-      "prompt": "Review this Live Activity plan for mistakes: use Activity.request(attributes:content:pushType:start:) on iOS 26 to schedule an order-status board; use style: .transient but guard it as iOS 26 only; send a push-to-start payload without alert because the user already opted into notifications; set NSSupportsLiveActivitiesFrequentUpdates and push updates every 30 seconds; say ended activities always disappear after 8 hours.",
-      "expected_output": "A correction-focused review that identifies stale or inaccurate ActivityKit claims and replaces them with current Apple-source behavior.",
+      "prompt": "Review this plan: we will schedule match Live Activities by calling the three-argument request and passing a start date separately, use style: which is iOS 26 only, skip the alert in push-to-start because users already allowed notifications, push every 30 seconds guaranteed, and assume ended activities vanish after 8 hours.",
+      "expected_output": "A correction of each point: the iOS 26 scheduled overload, style availability from iOS 18, required alert in push-to-start, no guaranteed cadence, and the separate 8/12/4 hour limits.",
       "files": [],
       "expectations": [
-        "Corrects scheduled Live Activity requests to the iOS 26 overload that includes style, alertConfiguration, and start/startDate.",
-        "Corrects Activity.request style parameter availability to iOS 18+ rather than iOS 26-only.",
-        "States that push-to-start payloads require an alert.",
-        "Avoids a fixed 30-second or once-per-minute frequent-update guarantee and recommends frequentPushesEnabled/frequentPushEnablementUpdates when cadence matters.",
-        "Distinguishes active duration up to 8 hours, Lock Screen persistence up to 12 hours after system end, and default app-ended dismissal up to 4 hours."
+        "Points scheduling at the iOS 26 request overload whose parameters include style, alertConfiguration and start",
+        "Corrects style: availability to iOS 18 and later rather than iOS 26 only",
+        "Explains that an alert is required in every push-to-start payload, whatever the user's notification permission",
+        "Refuses to promise any fixed cadence such as every 30 seconds and points to frequentPushesEnabled and frequentPushEnablementUpdates",
+        "Replaces the 8 hour claim with 8 hours active, up to 12 hours total on the Lock Screen after a system end, and up to 4 hours linger after an app end with .default"
       ]
     },
     {
       "id": 3,
-      "prompt": "I have a Live Activity that receives APNs updates, but now I need help rotating my APNs auth key, registering normal remote notifications, and deciding whether the widget should use a TimelineProvider. Which parts belong in ActivityKit guidance and where should the rest go?",
-      "expected_output": "A boundary-aware answer that keeps ActivityKit-specific Live Activity token/payload concerns in scope and redirects generic APNs registration/auth and WidgetKit timeline architecture to sibling domains.",
+      "prompt": "Our server team is setting up APNs for the first time. How do we send Live Activity updates, and should we use a TimelineProvider to refresh the Live Activity?",
+      "expected_output": "An ActivityKit-scoped answer on the Live Activity push contract; generic APNs setup goes to push-notifications and timeline widgets to widgetkit.",
       "files": [],
       "expectations": [
-        "Keeps ActivityKit-specific guidance focused on Live Activity update tokens, push-to-start tokens, liveactivity push type, topic suffix, and content-state payloads.",
-        "Does not turn the answer into a full generic APNs authentication or remote notification setup guide.",
-        "Does not recommend TimelineProvider for Live Activity lifecycle updates and distinguishes Live Activities from ordinary widgets.",
-        "Points generic APNs registration/key rotation toward push-notifications guidance and broad widget timeline architecture toward WidgetKit guidance.",
-        "Mentions that Live Activity push payload content-state must match the actual ContentState Codable shape and must not assume Date or ClosedRange<Date> use Unix timestamp lowerBound/upperBound dictionaries unless explicitly coordinated."
+        "Keeps the answer on per-activity update tokens, push-to-start tokens, the liveactivity push type, the .push-type.liveactivity topic and the content-state JSON",
+        "Does not turn into a full generic APNs auth or remote-notification registration guide",
+        "Rejects TimelineProvider as a way to drive a Live Activity and explains how a Live Activity differs from a Home Screen widget",
+        "Sends APNs registration and key rotation to push-notifications and timeline widget design to widgetkit",
+        "States that content-state must match the real ContentState Codable shape and warns against assuming Unix timestamps or lowerBound/upperBound objects for Date or ClosedRange<Date> unless both sides agreed"
       ]
     }
   ]