@mmerterden/multi-agent-pipeline 20.7.0 → 20.8.1

package/pipeline/skills/shared/external/ios-localization/evals/evals.json

@@ -4,45 +4,45 @@
     {
       "id": 0,
       "name": "generated-symbols-plurals",
-      "prompt": "I am updating an iOS 26 SwiftUI shop app for localization. We have a new Localizable.xcstrings file, a manually managed key named item_available whose English value is \"Add this item\", and a parameterized key named products_count for \"42 products\". Give me a concise migration plan and Swift snippets that use Xcode generated localizable symbols, plural-friendly placeholders, and modern string APIs. Also say what to do with old NSLocalizedString calls.",
-      "expected_output": "A concise migration plan that uses String Catalogs, generated symbols, correct positional named placeholders, modern String(localized:) / LocalizedStringResource guidance, plural variants, and legacy NSLocalizedString migration notes.",
+      "prompt": "Our iOS 26 SwiftUI grocery app has a Localizable.xcstrings with a hand-added key item_available and a parameterized key products_count. Several older screens still call NSLocalizedString. Lay out how we move to generated string symbols, how the plural placeholder should look, which modern string APIs to use where, and what happens to the NSLocalizedString calls.",
+      "expected_output": "First says catalogs have been the preferred localization path from Xcode 15 and that generated symbols are a separate Xcode 26 layer on top of them. Turns on Generate String Catalog Symbols, keeps stable manual keys, shows Text(.itemAvailable) and Text(.productsCount(count: 42)) with the placeholder %1$(count)lld, explains String(localized:) for values needed now versus LocalizedStringResource for deferred or system resolution, and treats NSLocalizedString as legacy whose literal keys Xcode can still export and migrate.",
       "files": [],
       "expectations": [
-        "Frames String Catalogs as the Xcode 15+ recommended workflow and does not claim they require iOS 17.",
-        "Mentions enabling Generate String Catalog Symbols and using stable manually managed keys.",
-        "Uses generated symbol examples such as Text(.itemAvailable) and Text(.productsCount(count: 42)).",
-        "Uses a positional named placeholder such as %1$(count)lld for the parameterized generated symbol.",
-        "Distinguishes String(localized:) for resolved strings from LocalizedStringResource for deferred or system-framework resolution.",
-        "Treats NSLocalizedString as legacy for new Swift code while acknowledging literal keys can still be exported or migrated."
+        "Places catalogs at Xcode 15 onward and never ties them to Xcode 26 or iOS 17",
+        "Enables Generate String Catalog Symbols and recommends stable manual keys rather than English copy as keys",
+        "Shows Text(.itemAvailable) and Text(.productsCount(count: 42))",
+        "Uses the named positional placeholder %1$(count)lld for the plural key",
+        "Distinguishes String(localized:) as an immediately resolved String from LocalizedStringResource as a deferred or system-resolved value",
+        "Calls NSLocalizedString legacy for new code while noting Xcode can still export or migrate its literal keys"
       ]
     },
     {
       "id": 1,
       "name": "package-bundle-localization",
-      "prompt": "Please review this Swift package localization setup. SharedUI has Resources/Localizable.xcstrings and Package.swift includes .process(\"Resources\"). Inside the package target we wrote Text(\"Save\") and String(localized: \"settings.title\") with no bundle argument. In the app target the same keys work, but in the package they fall back to English. What should we change?",
-      "expected_output": "A review that explains package resources need explicit bundle lookup, recommends bundle: .module for Swift Package strings and SwiftUI Text, and keeps the guidance scoped to localization rather than package architecture.",
+      "prompt": "I have a Swift package SharedUI with Sources/SharedUI/Resources/Localizable.xcstrings and resources: [.process(\"Resources\")] in the manifest. French translations exist, but on a French device the package's screens still show English. What is wrong?",
+      "expected_output": "Explains that code outside the main bundle has to name its bundle, gives a String(localized:) call for settings.title and a Text call for Save, both passing bundle: .module, states that Text in a package does not use .module by itself, and asks to confirm defaultLocalization and that the catalog is in the processed resources path. Stays on bundle lookup rather than redesigning the package.",
       "files": [],
       "expectations": [
-        "States that code outside the main app bundle needs an explicit bundle for localized resources.",
-        "Recommends String(localized: \"settings.title\", bundle: .module) or equivalent for Swift Package code.",
-        "Recommends SwiftUI Text with an explicit package bundle, such as Text(\"Save\", bundle: .module), or an equivalent localized label wrapper.",
-        "Does not claim SwiftUI Text inside a package automatically uses .module.",
-        "Mentions verifying the .xcstrings file is included in the package target resources.",
-        "Keeps the answer focused on localization bundle lookup rather than unrelated package architecture."
+        "Says package code must pass its own bundle explicitly",
+        "Includes a String(localized:) lookup for settings.title that passes bundle: .module",
+        "Includes a SwiftUI Text for Save that passes bundle: .module",
+        "Does not claim that SwiftUI Text in a package uses .module automatically",
+        "Asks to verify defaultLocalization and that the catalog sits inside the processed resources folder",
+        "Keeps the answer on bundle lookup instead of package architecture"
       ]
     },
     {
       "id": 2,
       "name": "formatstyle-boundary",
-      "prompt": "I am not adding new languages yet. I need to design a custom ParseableFormatStyle for follower counts like 12.5K, audit Date.IntervalFormatStyle usage, and format URLs for display. Should the iOS localization skill own this, or is there a better skill/domain? Give a short routing answer with the minimum localization advice that still matters.",
-      "expected_output": "A boundary answer that routes deep standalone FormatStyle API design to swift-formatstyle while giving minimal locale-facing localization cautions.",
+      "prompt": "We want a custom ParseableFormatStyle that turns follower counts like 12.4K back into integers, an audit of our Date.IntervalFormatStyle usage, and a nicer URL display format. We are not adding languages yet. Can you build all of that?",
+      "expected_output": "Routes the custom and parseable style, the interval style audit and URL formatting to swift-formatstyle, explains that this skill owns FormatStyle only for locale-aware display, and limits itself to short locale advice: no hard-coded user-facing formats and respect the user's locale even in a one-language app, with a suggestion to preview several locales. Does not write the full custom implementation.",
       "files": [],
       "expectations": [
-        "Routes custom ParseableFormatStyle, Date.IntervalFormatStyle, and URL.FormatStyle design to the swift-formatstyle skill or domain.",
-        "Explains that ios-localization covers FormatStyle when the task is locale-aware display for localization and internationalization.",
-        "Keeps minimum localization advice, such as not hardcoding user-facing formats and respecting user locale.",
-        "Does not expand into a full custom FormatStyle implementation.",
-        "Does not collapse swift-formatstyle's standalone formatting scope into ios-localization."
+        "Sends the parseable style, the interval style audit and URL formatting to swift-formatstyle",
+        "Explains that ios-localization owns FormatStyle only for locale-aware display",
+        "Gives only brief locale advice such as avoiding hard-coded formats and respecting the user locale",
+        "Does not provide a full custom format style implementation",
+        "Does not absorb swift-formatstyle's scope into this skill"
       ]
     }
   ]