@mmerterden/multi-agent-pipeline 20.7.0 → 20.8.1

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

@@ -3,44 +3,44 @@
   "evals": [
     {
       "id": 1,
-      "prompt": "Review this SwiftData CloudKit schema for an iOS 26 app: Profile uses @Attribute(.unique) on email, has a required @Relationship(deleteRule: .deny) owner, stores avatarData as Data, and a reviewer says every scalar property must become optional for sync. Give concise corrected guidance with a model sketch.",
-      "expected_output": "A review that flags SwiftData CloudKit schema incompatibilities, keeps scalar optionality precise, and covers CloudKit capability and schema rollout concerns.",
+      "prompt": "Our iOS 26 habit tracker is turning on iCloud sync. The models: Habit has @Attribute(.unique) var slug: String, a non-optional relationship var owner: Profile, and var icon: Data holding PNGs. Profile has #Unique<Profile>([\\.email]) and @Relationship(deleteRule: .deny) var habits: [Habit]. The container uses ModelConfiguration(cloudKitDatabase: .private(\"iCloud.example.habits\")). Review this before we ship.",
+      "expected_output": "A review that opens with a capabilities verdict and then lists schema changes needed for CloudKit, without telling the team to make every scalar optional.",
       "files": [],
       "assertions": [
-        "Flags @Attribute(.unique), #Unique, or unique constraints as incompatible with SwiftData CloudKit sync.",
-        "Flags the required relationship and recommends optional relationships for CloudKit-backed SwiftData models.",
-        "Flags the .deny delete rule as incompatible with SwiftData CloudKit sync.",
-        "Recommends @Attribute(.externalStorage) for large Data payloads such as image blobs.",
-        "Does not claim every scalar property must be optional.",
-        "Mentions iCloud CloudKit capability, Remote notifications background mode, or CloudKit schema promotion/additive rollout."
+        "Flags both @Attribute(.unique) and #Unique as incompatible with CloudKit sync.",
+        "Says the non-optional owner relationship must become optional.",
+        "Flags the .deny delete rule as unsupported with CloudKit and suggests enforcing the rule in app code.",
+        "Recommends @Attribute(.externalStorage) for the image Data.",
+        "Does not claim that every scalar property has to be optional for CloudKit.",
+        "Mentions the iCloud/CloudKit capability, Background Modes Remote notifications, and deploying the schema to production or keeping production changes additive."
       ]
     },
     {
       "id": 2,
-      "prompt": "A SwiftData list is slow. It filters trips by destination, sorts by startDate, and uses #Predicate with Date.now directly plus a helper method call on the model. The draft fix adds indexes to every property and says adding indexes never needs migration testing. Review the plan and give corrected predicate and indexing guidance.",
-      "expected_output": "A review that fixes predicate capture and unsupported-call risks, recommends targeted #Index usage for frequent filters/sorts, and avoids unsourced migration guarantees.",
+      "prompt": "A SwiftData list of 40,000 shipments scrolls badly. The view uses @Query(filter: #Predicate<Shipment> { $0.eta < Date.now && $0.isLate() }, sort: \\.eta). Someone proposes adding #Index on every property of Shipment and says index changes never need migration testing. What should we do?",
+      "expected_output": "Advice that fixes the predicate, proposes a targeted index strategy, and keeps migration testing and profiling in the plan.",
       "files": [],
       "assertions": [
-        "Recommends capturing changing values such as Date.now into a local let before building the predicate.",
-        "Warns against arbitrary unsupported helper method calls inside #Predicate and suggests stored properties or post-fetch filtering when needed.",
-        "Recommends targeted #Index declarations for frequently filtered or sorted properties rather than indexing every property.",
-        "Mentions compound indexes when a query filters and sorts by a repeated property combination.",
-        "Does not claim adding or removing indexes is always migration-free or never needs testing.",
-        "Suggests profiling or Instruments/Core Data diagnostics to verify query behavior."
+        "Moves Date.now out of the predicate into a local let that the predicate captures.",
+        "Warns that calling a helper method such as isLate() inside #Predicate is unsupported and suggests stored properties or filtering after the fetch.",
+        "Recommends indexing the few properties used in hot filters and sorts instead of every property.",
+        "Suggests a compound index when one filter plus sort combination is used repeatedly.",
+        "Does not state that adding or removing indexes needs no migration testing.",
+        "Suggests profiling with Instruments, for example the Core Data template, to confirm the gain."
       ]
     },
     {
       "id": 3,
-      "prompt": "A Core Data app wants to add SwiftData screens against the existing SQLite store while keeping the old stack alive. The model includes a Codable Address struct and a renamed persisted field. Explain how to route the work and what boundary guidance matters, without turning the answer into a full Core Data tutorial.",
-      "expected_output": "A boundary answer that treats Core Data + SwiftData coexistence or migration as SwiftData-owned, avoids unsupported Codable availability claims, and preserves store/schema alignment guidance.",
+      "prompt": "We have a Core Data app with an .xcdatamodeld containing Article (title String, savedAt Date, tags Transformable) and Author entities. We want new screens in SwiftData while old screens keep Core Data, reading the same data. How do we set that up?",
+      "expected_output": "Coexistence guidance that points SwiftData at the existing store and matches the schema, without turning into a general Core Data tutorial.",
       "files": [],
       "assertions": [
-        "States that Core Data + SwiftData coexistence or migration should use the swiftdata skill.",
-        "Explains that SwiftData must point at the existing persistent store URL when sharing or migrating data.",
-        "Mentions matching entity names, property names, types, and relationships across the Core Data model and SwiftData @Model classes.",
-        "Mentions @Attribute(originalName:) or equivalent rename mapping for renamed persisted fields.",
-        "States that compatible Codable structs or enums can be stored as SwiftData model properties without asserting an unsupported iOS 18+ threshold for Codable value storage.",
-        "Avoids expanding into a standalone Core Data stack tutorial."
+        "Treats Core Data and SwiftData coexistence as in scope for this skill.",
+        "Configures SwiftData with the existing store URL through ModelConfiguration(url:).",
+        "Requires @Model class names, property names, types and relationships to match the Core Data entities.",
+        "Mentions @Attribute(originalName:) for any renamed property.",
+        "States that compatible Codable structs or enums can replace the Transformable attribute, without claiming an iOS 18 minimum for storing Codable values.",
+        "Does not expand into a step-by-step tutorial for building a standalone Core Data stack."
       ]
     }
   ]