@mmerterden/multi-agent-pipeline 20.7.0 → 20.8.1

package/pipeline/skills/shared/external/core-data/evals/evals.json

@@ -2,42 +2,45 @@
   "skill_name": "core-data",
   "evals": [
     {
-      "id": 1,
-      "prompt": "Review this Core Data staged migration plan for an iOS 26 app: the team creates NSLightweightMigrationStage([\"ModelV1\", \"ModelV2\"]), constructs NSManagedObjectModelReference(named: \"ModelV2\", in: .main), and expects NSStagedMigrationManager to run without wiring it into the persistent store description. Give concise corrected guidance with Swift where useful.",
-      "expected_output": "A review that corrects staged migration checksum usage, NSManagedObjectModelReference initializer requirements, and store-description wiring.",
+      "id": 0,
+      "name": "staged-migration-setup",
+      "prompt": "We're moving our Core Data app to NSStagedMigrationManager on iOS 17+. Our draft passes model names like \"Model_v2\" to NSLightweightMigrationStage, builds the custom stage from just the destination model, and sets the manager option after calling loadPersistentStores. Fix it.",
+      "expected_output": "Uses version checksums instead of names for lightweight stages, builds NSManagedObjectModelReference(name:in:versionChecksum:) values, gives NSCustomMigrationStage both a source and a destination reference, and sets NSPersistentStoreStagedMigrationManagerOptionKey on the store description before loading stores.",
       "files": [],
-      "assertions": [
-        "States that NSLightweightMigrationStage takes version checksums, not human-readable model names.",
-        "Uses NSManagedObjectModelReference(name:in:versionChecksum:) or an equivalent initializer with a versionChecksum.",
-        "Includes source and destination model references for an NSCustomMigrationStage.",
-        "Shows or describes setting NSPersistentStoreStagedMigrationManagerOptionKey before loading the persistent stores."
+      "expectations": [
+        "Uses version checksums, not model names, for lightweight stages",
+        "Uses NSManagedObjectModelReference(name:in:versionChecksum:)",
+        "Supplies both source and destination references to the custom stage",
+        "Sets NSPersistentStoreStagedMigrationManagerOptionKey before loadPersistentStores"
       ]
     },
     {
-      "id": 2,
-      "prompt": "Review this Core Data multi-target sync plan: a widget and app share a SQLite store, batch inserts and deletes run on background contexts, the viewContext never merges SQL-level changes, no persistent history token is stored, and objects are passed directly to detached tasks. Explain what to fix.",
-      "expected_output": "A review that fixes batch-operation merging, persistent history tracking, token storage, and object/thread boundaries.",
+      "id": 1,
+      "name": "app-and-widget-store-review",
+      "prompt": "Our notes app and its widget share one Core Data store in an app group. The widget runs NSBatchDeleteRequest to trim old notes, and the app never sees the deletions until relaunch. The app also passes NSManagedObject instances into Task.detached, and our Note entity relies on a Deny delete rule. Review this.",
+      "expected_output": "Explains that batch requests bypass the context and must be merged or observed through persistent history, enables NSPersistentHistoryTrackingKey and remote change notifications, observes NSPersistentStoreRemoteChange, keeps a separate history token per target, hands off objectIDs instead of managed objects, and warns that batch delete ignores the Deny rule and skips validation beyond basic delete rules.",
       "files": [],
-      "assertions": [
-        "Explains that batch inserts, updates, and deletes bypass normal managed-object context change tracking and must be merged or consumed through persistent history.",
-        "Recommends enabling NSPersistentHistoryTrackingKey for multi-target or multi-process stores.",
-        "Recommends observing NSPersistentStoreRemoteChange notifications when remote-change delivery is needed.",
-        "States that each target or consumer should persist its own persistent history token.",
-        "States that NSManagedObject instances must not cross context or thread boundaries; pass NSManagedObjectID and re-fetch.",
-        "Mentions that batch delete bypasses validation beyond basic delete rules and is incompatible with the Deny delete rule."
+      "expectations": [
+        "States batch operations bypass context change tracking and need merging or persistent history",
+        "Enables NSPersistentHistoryTrackingKey",
+        "Observes NSPersistentStoreRemoteChange",
+        "Keeps a persisted history token per target or consumer",
+        "Passes NSManagedObjectID across concurrency boundaries",
+        "Warns batch delete does not enforce the Deny rule"
       ]
     },
     {
-      "id": 3,
-      "prompt": "A team asks for a Core Data plan, but the real request is to run Core Data and SwiftData side by side against the same existing SQLite store and then migrate new screens to @Model. How should the agent route the work and what high-level boundary guidance should it give?",
-      "expected_output": "A boundary answer that identifies Core Data + SwiftData coexistence/migration as SwiftData-owned while giving only high-level handoff guidance.",
+      "id": 2,
+      "name": "swiftdata-coexistence-routing",
+      "prompt": "We want SwiftData screens to read the same data as our existing Core Data stack. Write us the full coexistence and migration guide.",
+      "expected_output": "Routes the full coexistence or migration work to the swiftdata skill, keeps only the high-level rules here (reuse the existing store URL, keep entity and property names and schema compatible, map renames with @Attribute(originalName:)), and still answers any plain Core Data questions.",
       "files": [],
-      "assertions": [
-        "States that Core Data + SwiftData coexistence or migration should use the swiftdata skill.",
-        "Avoids turning the Core Data skill into a full SwiftData migration guide.",
-        "Gives high-level boundary guidance such as matching store URL, entity names, property names, and schema.",
-        "Mentions using @Attribute(originalName:) or equivalent rename mapping for renamed properties.",
-        "Preserves standalone Core Data guidance for apps that have not adopted SwiftData."
+      "expectations": [
+        "Hands the coexistence or migration guide to the swiftdata skill",
+        "Does not write a full migration guide inside this skill",
+        "Mentions reusing the existing store URL and compatible entity, property and schema names",
+        "Mentions @Attribute(originalName:) for renamed properties",
+        "Keeps standalone Core Data guidance available"
       ]
     }
   ]