@mmerterden/multi-agent-pipeline 20.6.0 → 20.8.0

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

@@ -1,264 +1,277 @@
 ---
 name: swift-testing
-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."
+description: "Writing, migrating and reviewing Swift Testing tests: @Test, @Suite, #expect, #require, confirmation, traits, withKnownIssue, Attachment.record, exit tests with processExitsWith and capture lists, Test.cancel, Issue.record warnings and manual failures, XCTest conversion (XCTUnwrap, XCTFail), mocking, async patterns, test organisation. Use when writing or migrating Swift tests, checking which Swift Testing APIs a toolchain supports, or deciding where XCTest and XCUITest still belong for UI, performance and snapshot tests."
 metadata:
-  source: "dpearson2699/swift-ios-skills (PolyForm Perimeter 1.0.0)"
+  source: multi-agent-pipeline
 ---
 
 # Swift Testing
 
-Swift Testing is the modern testing framework for Swift (Xcode 16+, Swift 6+). Prefer it over XCTest for all new unit tests. Use XCTest only for UI tests, performance benchmarks, and snapshot tests.
-
-## Contents
-
-- [Basic Tests](#basic-tests)
-- [`@Test Traits`](#test-traits)
-- [#expect and #require](#expect-and-require)
-- [`@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)
-- [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)
+Swift Testing needs Xcode 16 or later and Swift 6 or later. Use it for every
+new unit test. XCTest keeps UI tests (XCUITest), performance measurements and
+most snapshot workflows.
 
----
+More material: [patterns and migration](references/testing-patterns.md) and
+[newer APIs and version gates](references/testing-advanced.md).
 
-## Basic Tests
+## A First Test
 
 ```swift
 import Testing
+@testable import Ledger
 
-@Test("User can update their display name")
-func updateDisplayName() {
-    var user = User(name: "Alice")
-    user.name = "Bob"
-    #expect(user.name == "Bob")
+@Test("A new account starts with a zero balance")
+func newAccountIsEmpty() {
+    let account = Account(owner: "Ada")
+    #expect(account.balance == 0)
 }
 ```
 
-## `@Test` Traits
+## Traits
 
 ```swift
-@Test("Validates email format")                                    // display name
-@Test(.tags(.validation, .email))                                  // tags
-@Test(.disabled("Server migration in progress"))                   // disabled
-@Test(.enabled(if: ProcessInfo.processInfo.environment["CI"] != nil)) // conditional
-@Test(.bug("https://github.com/org/repo/issues/42"))               // bug reference
-@Test(.timeLimit(.minutes(1)))                                     // time limit
-@Test("Timeout handling", .tags(.networking), .timeLimit(.seconds(30))) // combined
-```
+@Test("Rejects malformed IBANs", .tags(.validation, .banking))
+func rejectsMalformedIBAN() { }
 
-## #expect and #require
-
-```swift
-// #expect records failure but continues execution
-#expect(result == 42)
-#expect(name.isEmpty == false)
-#expect(items.count > 0, "Items should not be empty")
-
-// #expect with error type checking
-#expect(throws: ValidationError.self) {
-    try validate(email: "not-an-email")
-}
+@Test(.disabled("Waiting for the sandbox to come back"))
+func sandboxTransfer() { }
 
-// #expect with specific error value
-#expect {
-    try validate(email: "")
-} throws: { error in
-    guard let err = error as? ValidationError else { return false }
-    return err == .empty
-}
+@Test(.enabled(if: ProcessInfo.processInfo.environment["CI"] == "true"))
+func nightlyReconciliation() { }
 
-// #require records failure AND stops test (like XCTUnwrap)
-let user = try #require(await fetchUser(id: 1))
-#expect(user.name == "Alice")
+@Test(.bug("https://tracker.example.com/issue/481"))
+func roundingRegression() { }
 
-// #require for optionals -- unwraps or fails
-let first = try #require(items.first)
-#expect(first.isValid)
+@Test("Imports a year of statements", .tags(.slow), .timeLimit(.minutes(2)))
+func importsAYear() async throws { }
 ```
 
-**Rule: Use `#require` when subsequent assertions depend on the value. Use `#expect` for independent checks.**
+- The first string argument is the display name.
+- `.tags(...)`, `.disabled("reason")`, `.enabled(if:)`, `.bug(...)` and
+  `.timeLimit(...)` combine freely in one `@Test`.
+- `.timeLimit` takes whole minutes only (`.minutes(_:)`). There is no
+  `.seconds` form.
 
-## `@Suite` and Test Organization
+## `#expect` and `#require`
 
-See [references/testing-patterns.md](references/testing-patterns.md) for suite organization, confirmation patterns, known-issue handling, and execution-model details.
+```swift
+@Test func transferValidation() async throws {
+    let ledger = Ledger()
 
-## Execution Model
+    #expect(ledger.accounts.isEmpty, "A fresh ledger has no accounts")
 
-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.
+    #expect(throws: LedgerError.self) {
+        try ledger.transfer(amount: -5, from: "A", to: "B")
+    }
 
-```swift
-@Suite(.serialized)
-struct KeychainTests {
-    @Test func storesToken() throws { /* ... */ }
-    @Test func deletesToken() throws { /* ... */ }
+    let error = #expect(throws: LedgerError.self) {
+        try ledger.transfer(amount: 10, from: "A", to: "A")
+    }
+    #expect(error == .sameAccount)
+
+    let first = try #require(await ledger.loadAccounts().first)
+    #expect(first.currency == "EUR")
 }
 ```
 
-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.
+- `#expect` records a failure and lets the test continue. An optional message
+  follows the condition.
+- `#expect(throws: SomeError.self) { ... }` checks the error type. Since Swift
+  6.1 it returns the thrown error, so you can inspect its value afterwards. The
+  older form with a trailing `throws: { error in ... }` predicate closure is
+  deprecated.
+- `try #require(...)` records a failure and stops the test, like `XCTUnwrap`.
+  It unwraps optionals and accepts `await` expressions.
+- Pick `#require` when the rest of the test needs that value to exist; pick
+  `#expect` for checks that stand on their own.
 
-**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.
+## How Tests Run
 
-## XCTest Migration Boundaries
+Unless told otherwise, Swift Testing runs tests concurrently. Never count on an
+order, on one suite instance shared between tests, or on having anything to
+yourself.
 
-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.
-
-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."
-
-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
+@Suite(.serialized)
+struct KeychainStoreTests {
+    @Test func savesToken() throws { }
+    @Test func deletesToken() throws { }
+}
+```
 
-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.
+`.serialized` makes the tests in that suite run one at a time. It does not
+affect tests outside the suite.
+
+- Every test builds its own state.
+- A shared mutable global is a bug unless it is protected or serialized.
+- `.serialized` is for exclusive access, not for ordering.
+- Steps that depend on each other belong in one test or a shared helper.
+
+## Migrating from XCTest
+
+- Swift Testing tests do not subclass `XCTestCase`. Put `@Test` on a free
+  function, or on a method of a `struct`, `class` or `actor` suite. Use a
+  `static` or `class` method when no instance fixture is needed.
+- Do not rewrite every assertion as `#expect`. Keep a mapping so required
+  unwraps and explicit failures keep their meaning, even when asked to "just
+  use #expect everywhere".
+- XCTest and Swift Testing can live side by side while you migrate.
+- Leave UI automation, performance measurements and common snapshot flows on
+  XCTest, XCUITest or the snapshot tool. Separate files or targets help when
+  they make it clear which runner owns what.
+
+| XCTest | Swift Testing |
+|--------|---------------|
+| `XCTAssert...` | `#expect(...)` |
+| `XCTUnwrap`, or a value later checks rely on | `try #require(...)` |
+| `XCTFail("...")`, any unconditional failure | `Issue.record("...")` |
 
 ```swift
-let user = try #require(optionalUser)
-#expect(user.isActive)
-
-guard featureFlag.isEnabled else {
-    Issue.record("Expected feature flag to be enabled")
-    return
+@Test func parsesHeader() throws {
+    guard let header = Header(raw: "v2;utf8") else {
+        Issue.record("Header did not parse")
+        return
+    }
+    #expect(header.version == 2)
 }
 ```
 
-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.
+Put `@available` on the individual `@Test` function, never on a suite type or
+the type that contains it.
 
 ## Known Issues
 
-Mark expected failures so they do not cause test failure:
-
 ```swift
-withKnownIssue("Propane tank is empty") {
-    #expect(truck.grill.isHeating)
+@Test func legacyExport() {
+    withKnownIssue("Exporter drops the BOM; fix scheduled") {
+        #expect(Exporter().csv().hasPrefix("\u{FEFF}"))
+    }
 }
 
-// Intermittent / flaky failures
-withKnownIssue(isIntermittent: true) {
-    #expect(service.isReachable)
+@Test func flakyMirror() async {
+    await withKnownIssue(isIntermittent: true) {
+        try await ReplicaSync.run()
+    }
 }
 
-// Conditional known issue
-withKnownIssue {
-    #expect(foodTruck.grill.isHeating)
-} when: {
-    !hasPropane
+@Test func arm64OnlyBug() {
+    withKnownIssue {
+        #expect(Checksum.fast([1, 2, 3]) == Checksum.slow([1, 2, 3]))
+    } when: {
+        Platform.isARM64
+    }
 }
 ```
 
-If no known issues are recorded, Swift Testing records a distinct issue notifying you the problem may be resolved.
-
-## Additional Patterns
-
-See [references/testing-patterns.md](references/testing-patterns.md) for parameterized tests, tags and suites, async testing, traits, and execution-model details.
-
-## Test Attachments
+A known issue does not fail the test. If the body records no issue at all,
+Swift Testing reports a separate issue telling you the problem may have been
+fixed, so the marker does not linger.
 
-Attach diagnostic data to test results for debugging failures. See [references/testing-patterns.md](references/testing-patterns.md) for full examples.
+## Attachments
 
 ```swift
-@Test func generateReport() async throws {
-    let report = try generateReport()
-    Attachment.record(report.data, named: "report.json")
-    #expect(report.isValid)
+@Test func exportsReport() throws {
+    let data = try ReportBuilder().json()
+    Attachment.record(data, named: "report.json")
+    #expect(!data.isEmpty)
 }
 ```
 
-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:
+Images (Swift 6.3, Xcode 26.4 or later) need the UI framework imported next to
+`Testing`:
 
 ```swift
 import Testing
 import UIKit
 
-@Test func renderedChart() async throws {
-    let image = renderer.image { ctx in chartView.drawHierarchy(in: bounds, afterScreenUpdates: true) }
-    Attachment.record(image, named: "chart", as: .png)
+@MainActor
+@Test func rendersGauge() {
+    let gauge = GaugeView(frame: CGRect(x: 0, y: 0, width: 160, height: 160))
+    let image = UIGraphicsImageRenderer(bounds: gauge.bounds).image { _ in
+        gauge.drawHierarchy(in: gauge.bounds, afterScreenUpdates: true)
+    }
+    Attachment.record(image, named: "gauge", as: .png)
 }
 ```
 
-## Exit Testing
+## Exit Tests
 
-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.
+Exit tests check code that ends the process: `exit()`, `fatalError()`,
+`preconditionFailure()`. They need Swift 6.2 (Xcode 26.0) and run on macOS,
+Linux, FreeBSD, OpenBSD and Windows. They are not available on iOS, tvOS or
+watchOS. When fixing exit-test code, state both limits: the toolchain floor and
+the platforms it runs on.
 
 ```swift
-@Test func invalidInputCausesExit() async {
+@Test func rejectsCorruptConfig() async {
     await #expect(processExitsWith: .failure) {
-        processInvalidInput()  // calls fatalError()
+        _ = Config.loadOrDie(path: "/dev/null")
     }
 }
 ```
 
-## Version-Gated APIs
+## Version Gates
+
+Check the toolchain before recommending newer APIs, and name the gate for each
+API you correct.
 
-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.
+| API | Needs |
+|-----|-------|
+| Exit tests (`processExitsWith:`) | Swift 6.2, Xcode 26.0; not iOS, tvOS, watchOS |
+| Capture lists in exit tests | Swift 6.3 compiler; captured values must be `Sendable` and `Codable` |
+| `Test.cancel(_:)`, `Issue.record(_:severity:)`, image attachments | Swift 6.3, Xcode 26.4 |
 
 ```swift
-@Test func exitsWithCapturedCode() async {
-    let expectedCode: Int32 = 42
-    await #expect(processExitsWith: .failure) { [expectedCode] in
-        exit(expectedCode)
+@Test func exitsWithConfiguredCode() async {
+    let status: Int32 = 42
+    await #expect(processExitsWith: .exitCode(status)) { [status = status as Int32] in
+        exit(status)
     }
 }
 ```
 
-## Advanced API Review Checklist
+Give each captured value an explicit type (`[name = name as Type]`). A bare
+`[status]` fails to compile with "Type of captured value is ambiguous",
+because the macro cannot infer the type on its own.
+
+A test that calls `Test.cancel(_:)` must be `throws` or `async throws`.
 
-When reviewing stale or beta-era Swift Testing samples, include the exact correction and the gate for every API the prompt mentions:
+## Correcting Advanced API Code
 
-| 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. |
+| Found | Replace with |
+|-------|--------------|
+| `#expect(exitsWith:)` | `await #expect(processExitsWith: .failure) { ... }`. In an iOS app target, test the logic behind a smaller API that does not exit, or move the exit test to a supported host or tool target. |
+| Exit-test closure reading outer values with no capture list | An explicit, typed capture list (`[code = code as Int32]`); Swift 6.3 compiler; values `Sendable` and `Codable` |
+| `Test.cancel()` in a test that is not throwing | Mark the test `async throws` and call `try Test.cancel("reason")` |
+| A warning that should not fail the run | `Issue.record("message", severity: .warning)`: reported, test still passes; Swift 6.3, Xcode 26.4 |
+| `Attachment(image, named:).record()` | `Attachment.record(image, named: "...", as: .png)`; accepts `UIImage`, `CGImage`, `CIImage`, `NSImage`; Swift 6.3, Xcode 26.4 |
 
 ## Common Mistakes
 
-1. **Testing implementation, not behavior.** Test what the code does, not how.
-2. **No error path tests.** If a function can throw, test the throw path.
-3. **Flaky async tests.** Use `confirmation` with expected counts, not `sleep` calls.
-4. **Shared mutable state between tests.** Each test sets up its own state via `init()` in `@Suite`.
-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. **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`.
-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.
+- Testing how the code works instead of what it does.
+- No tests for the error paths of throwing functions.
+- Waiting with sleeps in async tests. Use `confirmation` with an expected
+  count, an injected clock, or `withKnownIssue` for known flakiness.
+- Shared mutable state between tests. Set up in the suite's `init()`.
+- UI tests without accessibility identifiers; XCUITest queries rely on them.
+- Never testing that a `Task` stops when cancelled.
+- Unclear migration boundaries. Both frameworks may share a file, but separate
+  files are usually clearer for imports, ownership and runner expectations.
+- Non-`Sendable` helpers shared across concurrent tests. Mark test code that
+  needs the main actor `@MainActor`.
+- Relying on declaration order.
+- Using `.serialized` to chain the steps of a workflow. Put dependent steps in
+  one test.
 
 ## Review Checklist
 
-- [ ] All new tests use Swift Testing (`@Test`, `#expect`), not XCTest assertions
-- [ ] Test names describe behavior (`fetchUserReturnsNilOnNetworkError` not `testFetchUser`)
-- [ ] Error paths have dedicated tests
-- [ ] Async tests use `confirmation()`, not `Task.sleep`
-- [ ] Parameterized tests used for repetitive variations
-- [ ] 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](references/testing-patterns.md)
-- Advanced testing (warnings, cancellation, image attachments): [references/testing-advanced.md](references/testing-advanced.md)
+- [ ] New tests use `@Test` and `#expect`, not XCTest assertions
+- [ ] Names describe behaviour (`fetchUserReturnsNilOnNetworkError`, not `testFetchUser`)
+- [ ] Error paths have their own tests
+- [ ] Async events verified with `confirmation()` rather than `Task.sleep`
+- [ ] Repetitive variations are parameterized
+- [ ] Tags such as `.critical` or `.slow` exist for filtering
+- [ ] Mocks conform to protocols; no subclassing of concrete types
+- [ ] No shared mutable state, no dependence on order or on a shared suite instance
+- [ ] `.serialized` used only for exclusive resources
+- [ ] Cancellable async work has a cancellation test

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

@@ -2,42 +2,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.",
+      "id": 1,
+      "prompt": "I'm moving our CartServiceTests from XCTest to Swift Testing. My plan: keep `final class CartServiceTests: XCTestCase` but add @Test to the methods, share one CartService through a static singleton so setUp goes away, put @available(iOS 18, *) on the class, turn every assertion including XCTUnwrap into #expect, and move the checkout UI tests into the same Swift Testing file. Review it.",
+      "expected_output": "A migration review that corrects each part of the plan and explains how the two frameworks coexist.",
       "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."
+        "Rejects keeping XCTestCase as the parent of Swift Testing tests and proposes a struct, class or actor suite or free functions.",
+        "Recommends a fresh fixture per test through the suite init() instead of a shared singleton.",
+        "Moves @available onto the individual @Test functions, not the suite type.",
+        "Converts XCTUnwrap to try #require and XCTFail to Issue.record rather than turning everything into #expect.",
+        "Keeps the checkout UI tests on XCTest with XCUITest.",
+        "States that XCTest and Swift Testing can coexist during the migration."
       ]
     },
     {
-      "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:).",
+      "id": 2,
+      "prompt": "We build with Xcode 26.4 and Swift 6.3 for an iOS 26 app. Review these tests: `#expect(exitsWith: .failure) { Vault.unlock(code: badCode) }` where badCode is a local, `func skipsOffline() { Test.cancel(\"offline\") }`, `Issue.record(\"slow parse\")` that should only warn, and `Attachment(chartImage, named: \"chart\").record()`.",
+      "expected_output": "Each API corrected to its current spelling, with the toolchain gate and platform limits named for every change.",
       "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."
+        "Replaces exitsWith: with await #expect(processExitsWith: .failure).",
+        "States that exit tests need Swift 6.2 and Xcode 26.0 and do not run on iOS, tvOS or watchOS, and suggests testing the non-exiting logic in the app target.",
+        "Adds an explicit capture list for badCode, requiring the Swift 6.3 compiler and Sendable plus Codable values.",
+        "Makes the cancelling test async throws (or throws) and calls try Test.cancel.",
+        "Uses Issue.record with severity: .warning and names the Swift 6.3 and Xcode 26.4 gate.",
+        "Uses Attachment.record(chartImage, named:, as: .png) and names the Swift 6.3 and Xcode 26.4 gate."
       ]
     },
     {
-      "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.",
+      "id": 3,
+      "prompt": "Plan the tests for our checkout feature: a price calculator with discounts, a coupon service that posts async events, the login-to-checkout flow, a launch-time benchmark, and screenshots in dark mode and at large text sizes.",
+      "expected_output": "A test plan that assigns each area to the right framework or tool.",
       "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."
+        "Uses Swift Testing (@Test, #expect, parameterized arguments) for the price calculator.",
+        "Uses confirmation for the async coupon events and rules out sleeps.",
+        "Uses XCUITest for the login-to-checkout flow.",
+        "Keeps the benchmark on XCTest performance APIs and the dark-mode and Dynamic Type screenshots on snapshot tooling.",
+        "Says both frameworks may share a target during migration but recommends clear file or target separation."
       ]
     }
   ]