@mmerterden/multi-agent-pipeline 20.6.0 → 20.8.0

package/pipeline/skills/shared/external/realitykit-ar/evals/evals.json

@@ -2,45 +2,42 @@
   "skill_name": "realitykit-ar",
   "evals": [
     {
-      "id": 1,
-      "name": "ar-camera-setup-review",
-      "prompt": "Review this SwiftUI AR setup: it presents RealityView on every iPhone, has no NSCameraUsageDescription, assumes a black camera view means the model failed to load, and says there is never a device capability setting for RealityKit because RealityKit handles AR automatically. What should change?",
-      "expected_output": "A correction-focused review that covers camera privacy, runtime AR support checks, user-facing fallback handling, required-device capability tradeoffs, and RealityViewCameraContent's AR/non-AR behavior.",
+      "id": "ar-camera-setup-review",
+      "prompt": "Testers say our furniture preview shows a black screen on some iPhones and iPads. The team thinks the USDZ loading is broken. Review the AR setup and tell us what to change, including whether the app should require ARKit.",
+      "expected_output": "A setup review covering the camera usage string, support checks, permission and unavailable-AR fallbacks, a correct stance on the required-capability key, and the RealityViewCameraContent default and fallback.",
       "files": [],
       "assertions": [
-        "Requires NSCameraUsageDescription for camera-based AR.",
-        "Checks ARWorldTrackingConfiguration.isSupported or the relevant ARConfiguration.isSupported before presenting AR-only UI.",
-        "Handles denied camera permission or unavailable AR with a fallback instead of treating a black view as only a model-loading failure.",
-        "Explains that arkit in UIRequiredDeviceCapabilities is appropriate only when AR is core required functionality; otherwise use runtime gating.",
-        "Mentions that RealityViewCameraContent uses an AR camera view by default on iOS and can fall back to non-AR mode when AR or camera access is unavailable."
+        "Requires NSCameraUsageDescription in Info.plist",
+        "Checks ARWorldTrackingConfiguration.isSupported before presenting AR",
+        "Adds fallback UI for denied camera access and unsupported AR instead of blaming model loading",
+        "Adds arkit to UIRequiredDeviceCapabilities only if AR is the app's core purpose",
+        "Explains that RealityViewCameraContent shows the AR camera by default and offers a non-AR virtual camera fallback"
       ]
     },
     {
-      "id": 2,
-      "name": "surface-raycast-placement-review",
-      "prompt": "A developer wants tap-to-place on a physical table. Their plan is to use SpatialTapGesture with RealityViewCameraContent.hitTest, assume any hit is a detected table surface, and create a world anchor at that point. Review the plan and give the correct RealityKit/ARKit placement approach.",
-      "expected_output": "A source-grounded review that distinguishes RealityKit entity hit testing from ARKit real-world surface raycasts, then recommends plane anchors or ARKit raycast results for physical-surface placement.",
+      "id": "surface-raycast-placement-review",
+      "prompt": "Our code places a picture frame where the user taps by calling hitTest on the RealityView content, and if that misses it uses ray(through:in:to:) and drops the frame at the end of the ray. Is this right for hanging art on a real wall?",
+      "expected_output": "A review separating virtual picking from real-surface detection, with plane anchors for simple cases and an ARKit raycast for tap placement.",
       "files": [],
       "assertions": [
-        "Explains that RealityViewCameraContent.hitTest intersects RealityKit entity collision shapes, not arbitrary detected physical surfaces.",
-        "States that RealityViewCameraContent.ray produces a camera ray in RealityKit coordinates and is not by itself proof of a real-world surface hit.",
-        "Recommends AnchorEntity(.plane(...)) for simple placement on detected horizontal or vertical planes.",
-        "Recommends ARRaycastQuery with ARSession.raycast(_:) and AnchorEntity(raycastResult:) when a one-shot real-world surface intersection is needed.",
-        "Requires CollisionComponent shapes only for interactive entity hit testing and gestures, not as a substitute for ARKit surface detection."
+        "States that hitTest finds collision shapes on virtual entities, not physical surfaces",
+        "States that ray(through:in:to:) is not evidence of a real surface",
+        "Suggests AnchorEntity(.plane(...)) for simple plane placement",
+        "Uses ARRaycastQuery with ARSession.raycast(_:) and AnchorEntity(raycastResult:) for one-shot placement",
+        "Keeps collision shapes for entity interaction only"
       ]
     },
     {
-      "id": 3,
-      "name": "ios-visionos-boundary-review",
-      "prompt": "A team found a visionOS sample using ARKitSession, WorldTrackingProvider, and PlaneDetectionProvider. They want to copy those APIs into an iOS RealityView app and also migrate an older SCNView/SCNNode scene in the same pass. Write a short architecture note about what belongs in the RealityKit iOS path and what should be treated as a boundary or migration.",
-      "expected_output": "A boundary-aware note that keeps iOS RealityKit guidance centered on RealityViewCameraContent, ARKit iOS configuration/support checks, and entities/anchors, while treating visionOS provider APIs and SceneKit node APIs as separate domains or migration concerns.",
+      "id": "ios-visionos-boundary-review",
+      "prompt": "We are porting a visionOS scene to iPhone. It uses ARKitSession with WorldTrackingProvider and PlaneDetectionProvider, and an older part of the app still renders a SceneKit SCNView with SCNNode and SCNPhysicsBody. Plan the iOS architecture and the notes for the accessibility and gesture teams.",
+      "expected_output": "An iOS plan that drops visionOS providers, uses the iOS RealityKit path, treats SceneKit separately, and hands off gesture and accessibility policy.",
       "files": [],
       "assertions": [
-        "States that ARKitSession, WorldTrackingProvider, and PlaneDetectionProvider are visionOS-specific and are not the iOS RealityKit path.",
-        "Uses RealityViewCameraContent, ARWorldTrackingConfiguration.isSupported, entities, and AnchorEntity patterns for the iOS RealityKit path.",
-        "Avoids claiming that SceneKit SCNView, SCNNode, or SCNPhysicsBody APIs can be patched directly with RealityKit entity APIs.",
-        "Frames SceneKit work as a separate maintenance path or an explicit migration to RealityKit, not as mixed API usage in the same scene graph.",
-        "Keeps detailed SwiftUI gesture composition or accessibility policy as handoff topics while still naming RealityKit requirements such as InputTargetComponent, CollisionComponent, and AccessibilityComponent when relevant."
+        "Says the visionOS ARKitSession providers are not the iOS path",
+        "Uses RealityViewCameraContent, ARWorldTrackingConfiguration.isSupported, entities and AnchorEntity on iOS",
+        "Does not claim SCNView, SCNNode or SCNPhysicsBody can be patched with RealityKit entity APIs",
+        "Treats SceneKit as a separate path or an explicit migration",
+        "Hands off gesture and accessibility policy while naming InputTargetComponent, CollisionComponent and AccessibilityComponent"
       ]
     }
   ]