@mmerterden/multi-agent-pipeline 20.6.0 → 20.8.0

package/pipeline/skills/shared/external/healthkit/evals/evals.json

@@ -3,43 +3,44 @@
   "evals": [
     {
       "id": 0,
-      "prompt": "Review this HealthKit setup plan for an iOS 26/iPadOS app: the team says HealthKit never works on iPad, creates HKHealthStore before any availability check, treats authorizationStatus as proof that read permission was denied, and assumes denied reads always return empty arrays. Give concise corrected guidance.",
-      "expected_output": "A correction-focused review that explains current platform availability, availability checks, write-vs-read authorization privacy, and partial app-owned results after read denial.",
+      "prompt": "Review our HealthKit onboarding for a universal iPhone and iPad hydration app: we create an HKHealthStore in every view model, call requestAuthorization for water and caffeine, then call authorizationStatus(for:) on water to decide whether we can show the user's history. If it says sharingDenied we hide the chart. Anything wrong?",
+      "expected_output": "Notes that Health data is available on iPadOS 17 and later, that isHealthDataAvailable() must be checked first, that one shared HKHealthStore should be used, that authorizationStatus(for:) reports only write access, that denied reads surface as the app's own samples so results look empty or partial, and that the capability plus NSHealthShareUsageDescription and NSHealthUpdateUsageDescription are required.",
       "files": [],
       "assertions": [
-        "States that HealthKit data is available on iPadOS 17 or later, not categorically unsupported on iPad.",
-        "Requires HKHealthStore.isHealthDataAvailable() before using other HealthKit APIs.",
-        "Explains that authorizationStatus(for:) reports write/share authorization, not whether read access was granted.",
-        "Explains that denied read access can return only samples the app saved, so results may be empty or partial rather than a reliable denial signal.",
-        "Mentions required HealthKit capability and NSHealthShareUsageDescription or NSHealthUpdateUsageDescription as appropriate."
+        "States that iPad support starts at iPadOS 17",
+        "Calls HKHealthStore.isHealthDataAvailable() before other HealthKit APIs",
+        "Explains that authorizationStatus(for:) covers write (share) access only",
+        "Explains that denied reads return only app-saved samples, looking empty or partial",
+        "Mentions the HealthKit capability and both usage description keys"
       ]
     },
     {
       "id": 1,
-      "prompt": "Review this background step-count sync plan: enableBackgroundDelivery(.immediate) is called after the first dashboard screen appears, the HKObserverQuery is created only when the screen is visible, the completion handler is skipped on errors, and QA plans to validate the behavior only in Simulator. What should change?",
-      "expected_output": "A review that fixes HealthKit background delivery setup, launch-time observer registration, completion handling, device testing, entitlement, and frequency expectations.",
+      "prompt": "Our step-goal app should refresh within seconds of new steps. The plan: call enableBackgroundDelivery(for: stepCount, frequency: .immediate) when the settings screen opens, start an HKObserverQuery for heart rate in the app delegate, only call the observer's completion handler when our network sync succeeds, and verify it in Simulator. Review this.",
+      "expected_output": "Requires the background delivery entitlement, creates the observer query at launch for the same type that is enabled, always calls the completion handler, explains that frequencies are maximums and that step count is capped at hourly on iOS, and says background delivery must be tested on a device, not Simulator.",
       "files": [],
       "assertions": [
-        "Requires the HealthKit Background Delivery capability or com.apple.developer.healthkit.background-delivery entitlement.",
-        "Says observer queries should be set up as the app launches, not only when a screen appears.",
-        "Pairs enableBackgroundDelivery with an HKObserverQuery for the same sample type.",
-        "Requires calling the observer completion handler even when processing fails.",
-        "States that Simulator is not a valid background-delivery test target.",
-        "Explains that requested frequency is a maximum and some types such as iOS step count may be capped hourly."
+        "Requires the com.apple.developer.healthkit.background-delivery entitlement",
+        "Registers the observer query at app launch",
+        "Pairs the observer query with the same sample type passed to enableBackgroundDelivery",
+        "Always calls the observer completion handler, for example with defer",
+        "Rules out Simulator testing for background delivery",
+        "Explains that the frequency is a maximum and that iOS step count is limited to hourly"
       ]
     },
     {
       "id": 2,
-      "prompt": "A team is building an iOS 26 workout recorder with HKWorkoutSession and HKLiveWorkoutBuilder. They also want the same code path to support iOS 17 devices, assume iPhone has live heart-rate samples like Apple Watch, and mirror Apple Watch workouts to iPhone whenever possible. Review the plan and identify HealthKit pitfalls.",
-      "expected_output": "A workout-session review that distinguishes HKWorkoutSession and HKLiveWorkoutBuilder availability, handles live heart-rate collection on iPhone/iPad, and outlines correct mirroring setup.",
+      "prompt": "We want live workout tracking on iPhone (iOS 18 and later) and Apple Watch, with heart rate on both and the phone showing what the watch records. The phone is often locked in an armband. How should we structure it?",
+      "expected_output": "Separates HKWorkoutSession availability (iOS 17+) from HKLiveWorkoutBuilder (iOS 26+), gates the live builder for iOS 18 to 25 with a non-live save path, notes that iPhone needs an external heart-rate sensor while the watch records high-frequency heart rate, starts mirroring from the watchOS session and sets workoutSessionMirroringStartHandler early at iPhone launch, and plans for Lock Screen workout-data access.",
       "files": [],
       "assertions": [
-        "Distinguishes HKWorkoutSession availability from HKLiveWorkoutBuilder availability.",
-        "States that HKLiveWorkoutBuilder requires iOS/iPadOS 26 or watchOS 5 and should be availability-gated for older iOS/iPadOS targets.",
-        "States that iPhone and iPad need a paired external heart-rate sensor for live heart-rate collection.",
-        "Mentions that Apple Watch can collect high-frequency heart-rate samples during workouts.",
-        "For mirroring, starts mirroring from the watchOS session and assigns workoutSessionMirroringStartHandler early on the iOS app.",
-        "Mentions lock-screen or locked-device workout data access considerations when showing live iPhone metrics."
+        "Distinguishes HKWorkoutSession availability from HKLiveWorkoutBuilder availability",
+        "Gates the live builder for iOS versions before 26",
+        "Requires an external heart-rate sensor for live heart rate on iPhone",
+        "Notes that Apple Watch sessions collect high-frequency heart rate",
+        "Starts mirroring from the primary watchOS session",
+        "Assigns workoutSessionMirroringStartHandler early at iPhone app launch",
+        "Addresses Lock Screen access to workout data on a locked iPhone"
       ]
     }
   ]