@mmerterden/multi-agent-pipeline 8.6.1 → 10.0.6

package/pipeline/skills/shared/external/swift-testing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: swift-testing
-description: "Write and migrate tests using the Swift Testing framework with @Test, @Suite, #expect, #require, confirmation, parameterized tests, test tags, traits, withKnownIssue, XCTest UI testing, XCUITest, test plan, mocking, test doubles, testable architecture, snapshot testing, async test patterns, test organization, and test-driven development in Swift. Use when writing or migrating tests with Swift Testing framework, implementing parameterized tests, working with test traits, converting XCTest to Swift Testing, or setting up test organization and mocking patterns."
+description: "Writes and migrates Swift Testing framework tests with @Test, @Suite, #expect, #require, confirmation, traits, withKnownIssue, Attachment.record, processExitsWith exit tests and capture lists, Test.cancel, Issue.record warnings/manual failures, XCTest-to-Swift Testing migration, XCUITest UI-test boundaries, performance/snapshot boundaries, mocking, async patterns, and test organization. Use when writing tests, converting XCTest assertions such as XCTUnwrap or XCTFail, reviewing advanced Swift Testing API availability, or deciding when to keep XCTest/XCUITest."
 ---
 
 # Swift Testing
@@ -10,18 +10,18 @@ Swift Testing is the modern testing framework for Swift (Xcode 16+, Swift 6+). P
 ## Contents
 
 - [Basic Tests](#basic-tests)
-- [@Test Traits](#test-traits)
+- [`@Test Traits`](#test-traits)
 - [#expect and #require](#expect-and-require)
-- [@Suite and Test Organization](#suite-and-test-organization)
+- [`@Suite and Test Organization`](#suite-and-test-organization)
+- [Execution Model](#execution-model)
+- [XCTest Migration Boundaries](#xctest-migration-boundaries)
 - [Known Issues](#known-issues)
 - [Additional Patterns](#additional-patterns)
-- [Parameterized Tests In Depth](#parameterized-tests-in-depth)
-- [Tags and Suites In Depth](#tags-and-suites-in-depth)
-- [Async Testing Patterns](#async-testing-patterns)
-- [Traits In Depth](#traits-in-depth)
 - [Common Mistakes](#common-mistakes)
 - [Test Attachments](#test-attachments)
 - [Exit Testing](#exit-testing)
+- [Version-Gated APIs](#version-gated-apis)
+- [Advanced API Review Checklist](#advanced-api-review-checklist)
 - [Review Checklist](#review-checklist)
 - [References](#references)
 
@@ -40,7 +40,7 @@ func updateDisplayName() {
 }
 ```
 
-## @Test Traits
+## `@Test` Traits
 
 ```swift
 @Test("Validates email format")                                    // display name
@@ -84,330 +84,149 @@ let first = try #require(items.first)
 
 **Rule: Use `#require` when subsequent assertions depend on the value. Use `#expect` for independent checks.**
 
-## @Suite and Test Organization
+## `@Suite` and Test Organization
 
-See `references/testing-patterns.md` for suite organization, confirmation patterns, and known-issue handling.
+See [references/testing-patterns.md](references/testing-patterns.md) for suite organization, confirmation patterns, known-issue handling, and execution-model details.
 
-## Known Issues
+## Execution Model
 
-Mark expected failures so they do not cause test failure:
+Swift Testing runs tests in parallel by default. Do not assume test order, shared suite instances, or exclusive access to mutable state unless you explicitly design for it.
 
 ```swift
-withKnownIssue("Propane tank is empty") {
-    #expect(truck.grill.isHeating)
-}
-
-// Intermittent / flaky failures
-withKnownIssue(isIntermittent: true) {
-    #expect(service.isReachable)
-}
-
-// Conditional known issue
-withKnownIssue {
-    #expect(foodTruck.grill.isHeating)
-} when: {
-    !hasPropane
+@Suite(.serialized)
+struct KeychainTests {
+    @Test func storesToken() throws { /* ... */ }
+    @Test func deletesToken() throws { /* ... */ }
 }
 ```
 
-If no known issues are recorded, Swift Testing records a distinct issue notifying you the problem may be resolved.
-
-## Additional Patterns
+Use `.serialized` when a test or suite must run one-at-a-time because it touches shared external state. It does not make unrelated tests outside that scope run serially.
 
-See `references/testing-patterns.md` for complete examples of:
+**Rules:**
+- Each test must set up its own state.
+- Shared mutable globals are a bug unless protected or intentionally serialized.
+- `@Suite(.serialized)` is for exclusive execution, not for expressing logical ordering between tests.
+- If tests depend on sequence, combine them into one test or move the sequence into shared helper code.
 
-- **TestScoping** -- custom test lifecycle with setup/teardown consolidation
-- **Mocking and Test Doubles** -- protocol-based doubles and testable architecture
-- **View Model Testing** -- environment injection and dependency isolation
-- **Async Patterns** -- clock injection and error path testing
-- **XCUITest** -- page objects, performance testing, snapshot testing, and test file organization
+## XCTest Migration Boundaries
 
-## Parameterized Tests In Depth
+Swift Testing unit tests do not inherit from `XCTestCase`. Declare `@Test` on free functions, global functions, or methods on suite types such as `struct`, `class`, or `actor`; use `static` or `class` methods when instance fixtures are not needed.
 
-### @Test with Arguments
+When reviewing migration code or plans, do not collapse every XCTest construct into `#expect`. Include a compact assertion-mapping note or table in the answer so required unwraps and unconditional manual failures are not lost, even when the user only says "replace every XCTAssert with #expect."
 
-Pass any `Sendable` & `Collection` to `arguments:`. Each element runs as an independent test case.
+State coexistence explicitly: XCTest and Swift Testing can coexist during migration. Keep UI automation, performance benchmarks, and common snapshot-test flows on XCTest/XCUITest or snapshot tooling, and separate files or targets when that makes runner expectations clearer.
 
-```swift
-// Enum-based: runs one case per enum value
-enum Environment: String, CaseIterable, Sendable {
-    case development, staging, production
-}
-
-@Test("Base URL is valid for all environments", arguments: Environment.allCases)
-func baseURLIsValid(env: Environment) throws {
-    let url = try #require(URL(string: Config.baseURL(for: env)))
-    #expect(url.scheme == "https")
-}
-```
-
-### Ranges as Arguments
+Migration defaults:
+- `XCTAssert*` -> `#expect(...)`
+- `XCTUnwrap` or any value required by later checks -> `try #require(...)`
+- `XCTFail("...")` or manual unconditional issues -> `Issue.record("...")`
+- UI tests, performance benchmarks, and common snapshot-test flows stay on XCTest/XCUITest or snapshot tooling.
+- Put `@available` on individual `@Test` functions, not on suite types or their containing types.
 
 ```swift
-@Test("Fibonacci is positive for small inputs", arguments: 1...20)
-func fibonacciPositive(n: Int) {
-    #expect(fibonacci(n) > 0)
-}
-```
-
-### Multiple Parameter Sources
+let user = try #require(optionalUser)
+#expect(user.isActive)
 
-Two argument collections produce a **cartesian product** (every combination):
-
-```swift
-@Test(arguments: ["light", "dark"], ["iPhone", "iPad"])
-func snapshotTest(colorScheme: String, device: String) {
-    // Runs 4 combinations: light+iPhone, light+iPad, dark+iPhone, dark+iPad
-    let config = SnapshotConfig(colorScheme: colorScheme, device: device)
-    #expect(config.isValid)
+guard featureFlag.isEnabled else {
+    Issue.record("Expected feature flag to be enabled")
+    return
 }
 ```
 
-Use `zip` for **1:1 pairing** (avoids cartesian product):
-
-```swift
-@Test(arguments: zip(
-    [200, 201, 204],
-    ["OK", "Created", "No Content"]
-))
-func httpStatusDescription(code: Int, expected: String) {
-    #expect(HTTPStatus(code).description == expected)
-}
-```
+See [references/testing-patterns.md](references/testing-patterns.md) for migration examples and [references/testing-advanced.md](references/testing-advanced.md) for Swift/Xcode version gates.
 
-### Custom Argument Generators
+## Known Issues
 
-Create a `CustomTestArgumentProviding` conformance or use computed static properties:
+Mark expected failures so they do not cause test failure:
 
 ```swift
-struct APIEndpoint: Sendable {
-    let path: String
-    let expectedStatus: Int
-
-    static let testCases: [APIEndpoint] = [
-        .init(path: "/users", expectedStatus: 200),
-        .init(path: "/missing", expectedStatus: 404),
-    ]
-}
-
-@Test("API returns expected status", arguments: APIEndpoint.testCases)
-func apiStatus(endpoint: APIEndpoint) async throws {
-    let response = try await client.get(endpoint.path)
-    #expect(response.statusCode == endpoint.expectedStatus)
+withKnownIssue("Propane tank is empty") {
+    #expect(truck.grill.isHeating)
 }
-```
-
-## Tags and Suites In Depth
-
-### Custom Tag Definitions
 
-Declare tags as static members on `Tag`:
-
-```swift
-extension Tag {
-    @Tag static var networking: Self
-    @Tag static var database: Self
-    @Tag static var slow: Self
-    @Tag static var critical: Self
-    @Tag static var smoke: Self
+// Intermittent / flaky failures
+withKnownIssue(isIntermittent: true) {
+    #expect(service.isReachable)
 }
-```
-
-### Filtering Tests by Tag
-
-Run tagged tests from Xcode Test Plans or the command line:
 
-```bash
-# Run only tests tagged .networking
-swift test --filter tag:networking
-
-# Exclude slow tests
-swift test --skip tag:slow
-```
-
-In Xcode, configure Test Plans to include/exclude tags for different CI configurations (smoke tests vs full suite).
-
-### @Suite for Grouping
-
-```swift
-@Suite("Shopping Cart Operations")
-struct ShoppingCartTests {
-    let cart: ShoppingCart
-
-    // init acts as setUp -- runs before each test in the suite
-    init() {
-        cart = ShoppingCart()
-        cart.add(Product(name: "Widget", price: 9.99))
-    }
-
-    @Test func itemCount() {
-        #expect(cart.items.count == 1)
-    }
-
-    @Test func totalPrice() {
-        #expect(cart.total == 9.99)
-    }
+// Conditional known issue
+withKnownIssue {
+    #expect(foodTruck.grill.isHeating)
+} when: {
+    !hasPropane
 }
 ```
 
-### Suite-Level Setup and Teardown
-
-Use `init` for setup and `deinit` for teardown. For async cleanup, use a `TestScoping` trait:
-
-```swift
-@Suite(.tags(.database))
-struct DatabaseTests {
-    let db: TestDatabase
-
-    init() async throws {
-        db = try await TestDatabase.createTemporary()
-    }
-
-    // deinit works for synchronous cleanup (struct suites only use init)
-    // For async teardown, use TestScoping trait instead
+If no known issues are recorded, Swift Testing records a distinct issue notifying you the problem may be resolved.
 
-    @Test func insertRecord() async throws {
-        try await db.insert(Record(id: 1, name: "Test"))
-        let count = try await db.count()
-        #expect(count == 1)
-    }
-}
-```
+## Additional Patterns
 
-## Async Testing Patterns
+See [references/testing-patterns.md](references/testing-patterns.md) for parameterized tests, tags and suites, async testing, traits, and execution-model details.
 
-### Testing Async Functions
+## Test Attachments
 
-`@Test` functions can be `async` and `throws` directly:
+Attach diagnostic data to test results for debugging failures. See [references/testing-patterns.md](references/testing-patterns.md) for full examples.
 
 ```swift
-@Test func fetchUserProfile() async throws {
-    let service = UserService(client: MockHTTPClient())
-    let user = try await service.fetchProfile(id: 42)
-    #expect(user.name == "Alice")
+@Test func generateReport() async throws {
+    let report = try generateReport()
+    Attachment.record(report.data, named: "report.json")
+    #expect(report.isValid)
 }
 ```
 
-### Testing Actor-Isolated Code
-
-Access actor-isolated state with `await`:
+Image attachments require Swift 6.3 / Xcode 26.4 or newer. Import `Testing` plus the relevant UI framework, then record the platform image value directly:
 
 ```swift
-actor Counter {
-    private(set) var value = 0
-    func increment() { value += 1 }
-}
-
-@Test func counterIncrements() async {
-    let counter = Counter()
-    await counter.increment()
-    await counter.increment()
-    let value = await counter.value
-    #expect(value == 2)
-}
-```
-
-### Timeout for Hanging Tests
-
-Use `.timeLimit` to prevent tests from hanging indefinitely:
+import Testing
+import UIKit
 
-```swift
-@Test(.timeLimit(.seconds(5)))
-func networkCallCompletes() async throws {
-    let result = try await api.fetchData()
-    #expect(result.isEmpty == false)
+@Test func renderedChart() async throws {
+    let image = renderer.image { ctx in chartView.drawHierarchy(in: bounds, afterScreenUpdates: true) }
+    Attachment.record(image, named: "chart", as: .png)
 }
 ```
 
-If the test exceeds the time limit, it fails immediately with a clear timeout diagnostic.
-
-### Confirmation (Replacing XCTestExpectation)
+## Exit Testing
 
-`confirmation` replaces `XCTestExpectation` / `fulfill()` / `waitForExpectations`. It verifies that an event occurs the expected number of times:
+Test code that calls `exit()`, `fatalError()`, or `preconditionFailure()`. Exit testing requires Swift 6.2 / Xcode 26.0 or newer and is supported on macOS, Linux, FreeBSD, OpenBSD, and Windows runtime targets, not iOS, tvOS, or watchOS. When correcting exit-test code, name both the toolchain floor and runtime support. See [references/testing-patterns.md](references/testing-patterns.md) for details.
 
 ```swift
-@Test func notificationPosted() async throws {
-    // Expects the closure to call confirm() exactly once
-    try await confirmation("UserDidLogin posted") { confirm in
-        let center = NotificationCenter.default
-        let observer = center.addObserver(
-            forName: .userDidLogin, object: nil, queue: .main
-        ) { _ in
-            confirm()
-        }
-        await loginService.login(user: "test", password: "pass")
-        center.removeObserver(observer)
-    }
-}
-
-// Expect multiple confirmations
-@Test func batchProcessing() async throws {
-    try await confirmation("Items processed", expectedCount: 3) { confirm in
-        processor.onItemComplete = { _ in confirm() }
-        await processor.process(items: [a, b, c])
+@Test func invalidInputCausesExit() async {
+    await #expect(processExitsWith: .failure) {
+        processInvalidInput()  // calls fatalError()
     }
 }
 ```
 
-## Traits In Depth
-
-### Conditional Traits
-
-```swift
-// Enable only on CI
-@Test(.enabled(if: ProcessInfo.processInfo.environment["CI"] != nil))
-func integrationTest() async throws { ... }
-
-// Disable with a reason
-@Test(.disabled("Blocked by #123 -- server migration"))
-func brokenEndpoint() async throws { ... }
-
-// Bug reference -- links test to an issue tracker
-@Test(.bug("https://github.com/org/repo/issues/42", "Intermittent timeout"))
-func flakyNetworkTest() async throws { ... }
-```
+## Version-Gated APIs
 
-### Time Limits
+For advanced Swift Testing APIs, check the toolchain before recommending them. When reviewing user code that mentions one of these APIs, name the gate for each API you correct:
+- Exit testing requires Swift 6.2 / Xcode 26.0 and does not support iOS, tvOS, or watchOS runtime targets.
+- Exit-test capture lists require the Swift 6.3 compiler. If an exit-test closure reads parent-process values, use an explicit capture list and state that captured values must be `Sendable` and `Codable`.
+- `Test.cancel(_:)`, `Issue.record(_:severity:)`, and image attachment recording require Swift 6.3 / Xcode 26.4-era support as noted in [references/testing-advanced.md](references/testing-advanced.md).
+- When fixing a `Test.cancel(_:)` sample, state both shape and gate: the test must be `throws` or `async throws`, and `Test.cancel(_:)` requires Swift 6.3 / Xcode 26.4-era support.
 
 ```swift
-@Test(.timeLimit(.minutes(2)))
-func longRunningImport() async throws {
-    try await importer.importLargeDataset()
-}
-
-// Apply time limit to entire suite
-@Suite(.timeLimit(.seconds(30)))
-struct FastTests {
-    @Test func quick1() { ... }
-    @Test func quick2() { ... }
+@Test func exitsWithCapturedCode() async {
+    let expectedCode: Int32 = 42
+    await #expect(processExitsWith: .failure) { [expectedCode] in
+        exit(expectedCode)
+    }
 }
 ```
 
-### Custom Trait Definitions
+## Advanced API Review Checklist
 
-Create reusable traits for common test configurations:
+When reviewing stale or beta-era Swift Testing samples, include the exact correction and the gate for every API the prompt mentions:
 
-```swift
-struct DatabaseTrait: TestTrait, SuiteTrait, TestScoping {
-    func provideScope(
-        for test: Test,
-        testCase: Test.Case?,
-        performing function: @Sendable () async throws -> Void
-    ) async throws {
-        let db = try await TestDatabase.setUp()
-        defer { Task { await db.tearDown() } }
-        try await function()
-    }
-}
-
-extension Trait where Self == DatabaseTrait {
-    static var database: Self { .init() }
-}
-
-// Usage: any test with .database trait gets a fresh database
-@Test(.database)
-func insertUser() async throws { ... }
-```
+| User code to correct | Current guidance |
+|---|---|
+| `#expect(exitsWith:)` | Use `await #expect(processExitsWith: .failure) { ... }`. Exit testing requires Swift 6.2 / Xcode 26.0 or newer and is supported on macOS, Linux, FreeBSD, OpenBSD, and Windows runtime targets, not iOS, tvOS, or watchOS. For an iOS app target, test fatal-path logic through a smaller non-exiting API or a supported host/tool target. |
+| Exit-test closure reads outer values | Add an explicit capture list, for example `{ [expectedCode] in ... }`. Exit-test capture lists require the Swift 6.3 compiler; captured values must be `Sendable` and `Codable`. |
+| `Test.cancel()` in a test that awaits work | Make the test `async throws` and call `try Test.cancel("reason")`. `Test.cancel(_:)` requires Swift 6.3 / Xcode 26.4-era support. |
+| `Issue.record(..., severity: .warning)` | Use `Issue.record("message", severity: .warning)`. Warning severity is reported but does not fail the test, and requires Swift 6.3 / Xcode 26.4-era support. |
+| `Attachment(image, named:).record()` | Use `Attachment.record(image, named: "name", as: .png)`. Import `Testing` plus the relevant image framework; Apple-platform image values include `UIImage`, `CGImage`, `CIImage`, and `NSImage`. Image attachment recording requires Swift 6.3 / Xcode 26.4-era support. |
 
 ## Common Mistakes
 
@@ -418,32 +237,10 @@ func insertUser() async throws { ... }
 5. **Missing accessibility identifiers in UI tests.** XCUITest queries rely on them.
 6. **Using `sleep` in tests.** Use `confirmation`, clock injection, or `withKnownIssue`.
 7. **Not testing cancellation.** If code supports `Task` cancellation, verify it cancels cleanly.
-8. **Mixing XCTest and Swift Testing in one file.** Keep them in separate files.
+8. **Unclear XCTest migration boundaries.** Apple allows XCTest and Swift Testing in one file during migration; prefer separate files when it keeps imports, ownership, and runner expectations clearer.
 9. **Non-Sendable test helpers shared across tests.** Ensure test helper types are Sendable when shared across concurrent test cases. Annotate MainActor-dependent test code with `@MainActor`.
-
-## Test Attachments
-
-Attach diagnostic data to test results for debugging failures. See `references/testing-patterns.md` for full examples.
-
-```swift
-@Test func generateReport() async throws {
-    let report = try generateReport()
-    Attachment(report.data, named: "report.json").record()
-    #expect(report.isValid)
-}
-```
-
-## Exit Testing
-
-Test code that calls `exit()`, `fatalError()`, or `preconditionFailure()`. See `references/testing-patterns.md` for details.
-
-```swift
-@Test func invalidInputCausesExit() async {
-    await #expect(processExitsWith: .failure) {
-        processInvalidInput()  // calls fatalError()
-    }
-}
-```
+10. **Assuming tests run in declaration order.** Swift Testing runs in parallel by default; use `.serialized` only when exclusive execution is required.
+11. **Using `.serialized` to express workflow steps.** Serialized execution does not make one test feed another; keep dependent steps in one test.
 
 ## Review Checklist
 
@@ -455,8 +252,11 @@ Test code that calls `exit()`, `fatalError()`, or `preconditionFailure()`. See `
 - [ ] Tags applied for filtering (`.critical`, `.slow`)
 - [ ] Mocks conform to protocols, not subclass concrete types
 - [ ] No shared mutable state between tests
+- [ ] Tests do not rely on declaration order or shared suite instances
+- [ ] `.serialized` used only for truly exclusive state, not to model workflow sequencing
 - [ ] Cancellation tested for cancellable async operations
 
 ## References
 
-- Testing patterns: `references/testing-patterns.md`
+- Testing patterns: [references/testing-patterns.md](references/testing-patterns.md)
+- Advanced testing (warnings, cancellation, image attachments): [references/testing-advanced.md](references/testing-advanced.md)

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

@@ -0,0 +1,44 @@
+{
+  "skill_name": "swift-testing",
+  "evals": [
+    {
+      "id": 0,
+      "prompt": "Review this migration plan from XCTest to Swift Testing: keep the XCTestCase subclass, convert setUp/tearDown into a shared singleton fixture, put @available on the whole suite type for iOS 18 APIs, replace every XCTest assertion with #expect including XCTUnwrap, keep XCTFail(\"missing user\") for guard-failure paths, and keep UI tests in the same target because Swift Testing can replace XCTest everywhere. They also want to know whether XCTest and Swift Testing can coexist during migration. Give corrected guidance with concise Swift examples where useful.",
+      "expected_output": "A migration review that converts XCTestCase classes into Swift Testing suites or free functions, uses isolated per-test fixtures, puts availability on test functions rather than suite types, maps XCTAssert/XCTUnwrap/XCTFail to #expect/#require/Issue.record, and preserves XCTest for UI testing.",
+      "files": [],
+      "assertions": [
+        "Rejects keeping XCTestCase inheritance for migrated Swift Testing unit tests and uses @Test functions or suites instead.",
+        "Recommends per-test fixture setup using suite init or isolated fixtures rather than shared singleton mutable state.",
+        "States that @available belongs on individual @Test functions, not on suite types or containing types.",
+        "Explains that not every XCTest assertion should become #expect and uses #require for required values or unwraps.",
+        "Keeps XCUITest UI tests on XCTest rather than claiming Swift Testing replaces XCTest everywhere."
+      ]
+    },
+    {
+      "id": 1,
+      "prompt": "I'm targeting iOS 26 with Swift 6.3 and wrote Swift Testing samples using #expect(exitsWith: .failure) in an exit-test closure that reads a local expectedCode, Test.cancel() in a sync test that awaits a network check, Issue.record(severity: .warning), and Attachment(image, named:).record(). Review the samples for current API spelling, availability, platform support, which pieces are Swift 6.2/Xcode 26.0 versus Swift 6.3/Xcode 26.4-era APIs, and any code-shape fixes.",
+      "expected_output": "An advanced Swift Testing review that uses processExitsWith for exit tests, notes exit testing availability and supported runtime targets, fixes async Test.cancel sample shape, notes Swift 6.3/Xcode 26.4 availability for warning severity and image attachments, and records images with Attachment.record(..., as:).",
+      "files": [],
+      "assertions": [
+        "Replaces stale #expect(exitsWith:) with #expect(processExitsWith:).",
+        "States that exit testing requires Swift 6.2/Xcode 26.0 or newer and is not supported on iOS/tvOS/watchOS runtime targets.",
+        "Mentions Swift 6.3 capture-list requirements when discussing captured parent-process values in exit tests.",
+        "Marks the Test.cancel example async when it awaits work and explains Test.cancel requires Swift 6.3/Xcode 26.4 or newer.",
+        "Uses Issue.record(..., severity: .warning) and image Attachment.record(..., named: ..., as: .png) with Swift 6.3/Xcode 26.4 availability."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Plan tests for a SwiftUI checkout flow: unit-test a price calculator, verify async coupon events, snapshot the checkout screen in dark mode and Dynamic Type, measure parser performance, and automate the login-to-checkout UI path. Which pieces should use Swift Testing, which should stay with XCTest or snapshot tooling, and how should the test files be organized during migration?",
+      "expected_output": "A boundary-aware test plan that uses Swift Testing for unit and async behavior tests, confirmation for callback/event checks, XCTest/XCUITest for UI automation and performance measurement, snapshot tooling for visual regression, and allows mixed files during migration while preferring clear separation for maintainability.",
+      "files": [],
+      "assertions": [
+        "Uses Swift Testing for pure unit/business logic tests such as the price calculator.",
+        "Uses confirmation or Swift concurrency patterns for async coupon events instead of sleeps.",
+        "Keeps UI automation with XCTest/XCUITest.",
+        "Keeps performance measurement and common snapshot testing flows in XCTest or dedicated snapshot tooling.",
+        "States that XCTest and Swift Testing can coexist during migration while recommending clear file or target organization when it reduces confusion."
+      ]
+    }
+  ]
+}