@mmerterden/multi-agent-pipeline 20.7.0 → 20.8.1

package/pipeline/skills/shared/external/swift-codable/evals/evals.json

@@ -3,40 +3,40 @@
   "evals": [
     {
       "id": 0,
-      "prompt": "Review and correct this Codable API plan for an iOS 26 app: the team made every response model Codable, uses JSONDecoder().decode before checking HTTP status, configures .convertFromSnakeCase and expects image_url to populate imageURL automatically, decodes ISO 8601 timestamps with the default Date strategy, and decodes a wrapped response with `decoder` outside the function where it was declared. Give concise corrected Swift examples where useful. Explicitly correct every read-only API response model to Decodable, not Codable; state that image_url maps to imageUrl, not imageURL; and note that the envelope helper needs its own decoder because another function's decoder is out of scope.",
-      "expected_output": "A correction-focused Codable review that uses Decodable, not Codable, for read-only responses, validates HTTP status before decoding, configures date and key strategies in scope, handles imageURL with CodingKeys because image_url maps to imageUrl, and decodes a generic API envelope with a decoder declared in the same helper.",
+      "prompt": "Write the networking model layer for a read-only podcast directory API. Responses look like {\"data\": [...], \"meta\": {\"page\": 1, \"total_pages\": 9}}, dates are ISO 8601 strings, and each show has fields like show_title, image_url and published_at. We want a reusable helper that unwraps the envelope.",
+      "expected_output": "Decodable models, a status-checked fetch, an ISO 8601 date strategy, correct handling of image_url, and an envelope helper that owns its decoder.",
       "files": [],
       "assertions": [
-        "Uses `Decodable` rather than `Codable` for read-only API response models.",
-        "Validates `HTTPURLResponse` status before attempting to decode the body.",
-        "Configures `JSONDecoder.dateDecodingStrategy = .iso8601` for ISO 8601 date strings.",
-        "Explains that `.convertFromSnakeCase` maps `image_url` to `imageUrl`, not `imageURL`, and uses `CodingKeys` for that field.",
-        "Shows the generic envelope decode with a decoder variable that is declared in the same helper where it is used."
+        "Declares the response models Decodable rather than Codable",
+        "Checks the HTTPURLResponse status code before decoding",
+        "Sets dateDecodingStrategy to .iso8601",
+        "Notes that convertFromSnakeCase turns image_url into imageUrl, so an imageURL property needs an explicit CodingKeys entry",
+        "Declares the decoder inside the envelope helper instead of referring to a decoder from another function"
       ]
     },
     {
       "id": 1,
-      "prompt": "A teammate says we can delete all CodingKeys because `decoder.keyDecodingStrategy = .convertFromSnakeCase` will handle `user_id`, `image_url`, `base_uri`, and `display_name`. Review that claim and show the model code you would keep.",
-      "expected_output": "A key-strategy review that keeps automatic snake_case conversion for simple lower-camel properties while retaining CodingKeys for URL, URI, and ID initialism spellings that conversion cannot infer.",
+      "prompt": "Our API is all snake_case: display_name, created_at, image_url, base_uri, user_id. A colleague set keyDecodingStrategy to convertFromSnakeCase, but imageURL, baseURI and userID come back missing. Another colleague wants to delete the strategy and hand-write CodingKeys for every field. What is the right fix?",
+      "expected_output": "Keep the strategy for ordinary keys and add explicit keys only for the acronym-cased properties.",
       "files": [],
       "assertions": [
-        "States that `.convertFromSnakeCase` is suitable for simple snake_case to lower-camel mappings such as `display_name` to `displayName`.",
-        "States that `.convertFromSnakeCase` cannot infer initialism capitalization such as URL, URI, or ID.",
-        "Uses explicit `CodingKeys` for fields like `imageURL`, `baseURI`, or `userID`.",
-        "Avoids recommending manual CodingKeys for every simple snake_case property when a decoder strategy is enough."
+        "Confirms the strategy correctly maps display_name to displayName",
+        "Explains that the strategy cannot produce URL, URI or ID capitalization",
+        "Adds explicit CodingKeys for imageURL, baseURI and userID",
+        "Advises against hand-mapping every simple snake_case key"
       ]
     },
     {
       "id": 2,
-      "prompt": "Review this storage plan: a SwiftData `@Model` has an optional `Address` struct that conforms to Codable, and a SwiftUI settings screen stores a `UserPreferences` Codable struct in `@AppStorage`. The draft says Codable value types only work in SwiftData on iOS 18+ and proposes transformable/blob workarounds. The @AppStorage type can rely on synthesized Codable defaults if the stored JSON is `{}`. Give corrected boundary-aware guidance. State clearly that SwiftData persists compatible noncomputed stored properties declared on @Model types, including Codable structs and enums when they are part of the durable model schema. Do not propose @Attribute(.transformable), encoded Data, or encoded String blob storage as a fallback; use typed SwiftData properties and a complete RawRepresentable JSON String bridge for @AppStorage, including init?(rawValue:) and rawValue self-encoding/decoding.",
-      "expected_output": "A boundary-aware Codable storage review that uses source-backed SwiftData compatibility wording for compatible noncomputed @Model properties, avoids unsupported iOS 18+/transformable/blob fallback claims, stores @AppStorage values through a complete RawRepresentable JSON String raw-value bridge, and explains missing-key defaults need custom decoding or tolerant rawValue handling.",
+      "prompt": "We store a Codable struct ShippingAddress on a SwiftData @Model and a small Codable ReaderPrefs struct in @AppStorage. Someone suggested marking the address @Attribute(.transformable) and saving it as encoded Data because Codable structs only work on iOS 18. ReaderPrefs also has default property values but decoding \"{}\" fails. Sort this out.",
+      "expected_output": "Typed Codable properties on the model, a complete and non-recursive RawRepresentable bridge for AppStorage, and a correct explanation of defaults, without drifting into general SwiftData or SwiftUI state design.",
       "files": [],
       "assertions": [
-        "States that @Model types can persist compatible noncomputed stored properties and explicitly includes Codable structs or enums, without asserting an unsupported iOS 18+ threshold.",
-        "Does not propose `@Attribute(.transformable)`, encoded `Data`, or encoded `String` blob storage as a fallback for the SwiftData Codable value property.",
-        "Uses a complete `RawRepresentable` JSON `String` raw-value bridge for storing a Codable value with `@AppStorage`.",
-        "Explains that synthesized `Decodable` does not use stored property default values when a nonoptional key is missing, so `{}` needs custom decoding or fallback handling.",
-        "Keeps the answer focused on Codable integration boundaries rather than expanding into full SwiftData schema design or SwiftUI state management."
+        "States that @Model persists supported noncomputed stored properties, including Codable structs and enums, without claiming an iOS 18 requirement",
+        "Does not recommend transformable, encoded Data or encoded String fallbacks",
+        "Provides a complete RawRepresentable bridge with a JSON String rawValue for @AppStorage",
+        "Explains that synthesized Decodable ignores property defaults, so {} needs custom decoding with decodeIfPresent or a tolerant rawValue initializer",
+        "Stays on the Codable boundary rather than redesigning the SwiftData schema or SwiftUI state"
       ]
     }
   ]