@mmerterden/multi-agent-pipeline 8.6.1 → 10.0.6

package/pipeline/skills/shared/external/swift-concurrency/references/diagnostics.md

@@ -0,0 +1,52 @@
+# Concurrency Diagnostics
+
+Common Swift concurrency compiler warnings and errors with their fixes.
+
+## Diagnostic → Fix Reference
+
+| Diagnostic | Cause | Fix |
+| --- | --- | --- |
+| `Sending 'x' risks causing data races` | Passing a non-Sendable value across isolation boundaries | Make the type `Sendable`, use `sending` parameter, or restructure to avoid the crossing |
+| `Capture of 'x' with non-sendable type in a @Sendable closure` | Closure captures non-Sendable value | Make type Sendable, copy the value, or use an actor |
+| `Non-sendable type 'X' returned by implicitly asynchronous call` | Returning non-Sendable from cross-isolation call | Make return type Sendable or keep work on same isolation |
+| `Main actor-isolated property 'x' can not be mutated from a nonisolated context` | Accessing @MainActor state from non-main context | Add `@MainActor` to caller, use `await MainActor.run { }`, or restructure |
+| `Call to main actor-isolated function in a synchronous nonisolated context` | Calling @MainActor function without await | Add `await`, annotate caller `@MainActor`, or use `.task { }` in SwiftUI |
+| `Actor-isolated property 'x' can not be referenced from a nonisolated context` | Accessing actor state without await | Add `await` or move code into the actor |
+| `Type 'X' does not conform to protocol 'Sendable'` | Stored properties aren't all Sendable | Prefer an immutable value type or immutable snapshot; otherwise use actor isolation or synchronization. Use `@unchecked Sendable` only with documented internal locking |
+| `Passing closure as a 'sending' parameter risks causing data races` | Closure captures values that could race | Ensure captures are Sendable or don't escape the isolation domain |
+| `Task-isolated value of type 'X' passed as a strongly transferred parameter` | Moving a value out of a task unsafely | Copy the value or use `sending` return |
+| `Global variable 'x' is not concurrency-safe` | Mutable global without isolation | Add `@MainActor`, make it `nonisolated(unsafe)` (with justification), or use actor |
+
+## Swift 6.2 Approachable Concurrency Changes
+
+With `UpcomingFeature.InferSendableFromCaptures` (Swift 6.2):
+- Closures infer Sendable from their captures (fewer explicit annotations needed)
+- `nonisolated(nonsending)` is the new default for async functions (SE-0461)
+- `@concurrent` marks functions that intentionally run off-actor
+
+## Strict Concurrency Adoption Strategy
+
+1. **Know the language mode.** In Swift 6 / 6.3 language mode, strict
+   concurrency checking is complete and data-race diagnostics are errors.
+2. **Use migration levels only before Swift 6.** In Swift 5 language mode,
+   `Targeted` or `Minimal` can stage adoption before moving to `Complete`.
+3. **Fix diagnostics bottom-up.** Start with leaf types (models, DTOs), then
+   services, then UI.
+4. **Use `@preconcurrency import`** temporarily for third-party modules that
+   haven't adopted Sendable  -  document removal plan.
+
+For Sendable diagnostics, check this order before adding annotations:
+immutable `struct` / `enum`, immutable `let` properties on a `final` class,
+actor or global-actor isolation, a small synchronized wrapper, then
+`@unchecked Sendable` only when the compiler cannot see a proven lock invariant.
+
+## Runtime Diagnostics
+
+Enable the Thread Sanitizer (`-sanitize=thread`) to catch data races at runtime that the compiler can't statically prove.
+
+Xcode: Edit Scheme → Run → Diagnostics → Thread Sanitizer.
+
+Common TSan findings in concurrent code:
+- Simultaneous reads and writes to `Dictionary` or `Array` without actor protection
+- Delegate callbacks arriving on unexpected queues
+- Completion handlers racing with synchronous property access

package/pipeline/skills/shared/external/swift-concurrency/references/swiftui-concurrency.md

@@ -9,7 +9,7 @@ Concurrency patterns and best practices specific to SwiftUI applications.
 - [Sendable Closures and Data-Race Safety](#sendable-closures-and-data-race-safety)
 - [Structuring Async Work](#structuring-async-work)
 - [The .task Modifier](#the-task-modifier)
-- [@Observable View Models](#observable-view-models)
+- [`@Observable View Models`](#observable-view-models)
 - [Async Observation with Observations (SE-0475)](#async-observation-with-observations-se-0475)
 - [Performance-Driven Concurrency](#performance-driven-concurrency)
 - [Common SwiftUI Concurrency Mistakes](#common-swiftui-concurrency-mistakes)
@@ -106,7 +106,7 @@ Use `.task(id:)` to restart work when a value changes:
 }
 ```
 
-## @Observable View Models
+## `@Observable` View Models
 
 - Annotate view models with both `@Observable` and `@MainActor`.
 - Use `@State` to own an `@Observable` instance (replaces `@StateObject`).

package/pipeline/skills/shared/external/swift-concurrency/references/synchronization-primitives.md

@@ -52,7 +52,7 @@ Use `withLockIfAvailable` to attempt acquisition without blocking. Returns
 ```swift
 let counter = Mutex<Int>(0)
 
-// Non-blocking attempt — returns nil if lock is contended
+// Non-blocking attempt  -  returns nil if lock is contended
 if let value = counter.withLockIfAvailable({ $0 }) {
     print("Current count: \(value)")
 } else {
@@ -69,7 +69,7 @@ if let value = counter.withLockIfAvailable({ $0 }) {
 - **Non-recursive:** Attempting to lock a `Mutex` that you already hold on the
   same thread is undefined behavior.
 - **Synchronous only:** Do not `await` inside `withLock`. The lock is held for
-  the duration of the closure — blocking across a suspension point will
+  the duration of the closure  -  blocking across a suspension point will
   deadlock or starve other threads.
 
 ## OSAllocatedUnfairLock
@@ -120,7 +120,7 @@ When protecting external state or a code section rather than a specific value:
 let lock = OSAllocatedUnfairLock()
 
 lock.withLock {
-    // Critical section — no associated state
+    // Critical section  -  no associated state
     writeToSharedFile(data)
 }
 ```
@@ -146,11 +146,13 @@ defer { lock.unlock() }
 | **`withLockIfAvailable`** | Returns `nil` on contention | Returns `nil` on contention |
 | **Ownership assertions** | Not available | `precondition(.owner)` / `precondition(.notOwner)` |
 | **Manual lock/unlock** | Not available | Available (`lock()` / `unlock()`) |
-| **Recommendation** | Preferred for iOS 18+ code | Use when targeting iOS 16–17 |
+| **Recommendation** | Preferred for iOS 18+ code | Use when targeting iOS 16-17 |
 
-**Guideline:** Use `Mutex` for new code targeting iOS 18+. Use
-`OSAllocatedUnfairLock` when you need to support iOS 16–17, or when you need
-ownership assertions for debugging.
+**Guideline:** Use `Mutex` for new code targeting iOS 18+. For apps that run on
+iOS 16 through current releases, either keep the shared abstraction backed by
+`OSAllocatedUnfairLock` or branch with `#available(iOS 18, *)` so iOS 18+ uses
+`Mutex` and iOS 16-17 uses `OSAllocatedUnfairLock`. Prefer
+`OSAllocatedUnfairLock` when you need ownership assertions for debugging.
 
 ## Atomic
 
@@ -207,15 +209,15 @@ Atomic operations require an explicit memory ordering:
 
 | Ordering | Use case |
 |---|---|
-| `.relaxed` | Counters, statistics — no ordering guarantees needed |
+| `.relaxed` | Counters, statistics  -  no ordering guarantees needed |
 | `.acquiring` | Read that must see all writes before a corresponding release |
 | `.releasing` | Write that must be visible to a corresponding acquire |
 | `.acquiringAndReleasing` | Compare-and-swap, read-modify-write |
-| `.sequentiallyConsistent` | Strongest guarantee — rarely needed |
+| `.sequentiallyConsistent` | Strongest guarantee  -  rarely needed |
 
 **Guideline:** Use `.relaxed` for simple counters. Use
 `.acquiringAndReleasing` for compare-and-swap patterns. Avoid
-`.sequentiallyConsistent` unless you have a proven need — it is the most
+`.sequentiallyConsistent` unless you have a proven need  -  it is the most
 expensive ordering.
 
 ### When to Use Atomics vs Mutex
@@ -231,6 +233,9 @@ expensive ordering.
 
 - **Async isolation is natural.** The protected state is accessed from async
   contexts and you can afford the hop.
+- **Callers can suspend.** Actor-isolated APIs are `async` from outside the
+  actor, so they fit task-based code but not synchronous C callbacks, real-time
+  hooks, or other no-suspension call sites.
 - **Structured concurrency.** You want the compiler to enforce isolation
   boundaries and prevent data races statically.
 - **Most Swift code.** Actors are the default recommendation for shared mutable
@@ -303,7 +308,7 @@ Need shared mutable state protection?
 a lock creates double synchronization and risks deadlocks.
 
 ```swift
-// WRONG: Lock inside an actor — double synchronization
+// WRONG: Lock inside an actor  -  double synchronization
 actor BadCache {
     let lock = Mutex<[String: Data]>([:])  // Unnecessary!
     // The actor already protects its state
@@ -319,10 +324,11 @@ actor GoodCache {
 }
 ```
 
-**Never use `DispatchSemaphore` or `NSLock` in modern Swift.** Use `Mutex`
-(iOS 18+) or `OSAllocatedUnfairLock` (iOS 16+) instead. Legacy lock types
-have no `Sendable` conformance and are not designed for structured
-concurrency.
+**Avoid reaching first for `DispatchSemaphore` or `NSLock` in modern Swift.**
+`NSLock` is `Sendable`, but `Mutex` (iOS 18+) and `OSAllocatedUnfairLock`
+(iOS 16+) make the protected state and lock ownership clearer in Swift
+concurrency code. Use `NSLock` only when compatibility or existing API shape
+requires it.
 
 **Never hold a lock across `await`.** This blocks the thread and can deadlock
 the cooperative thread pool.

package/pipeline/skills/shared/external/swift-concurrency-expert/SKILL.md

@@ -40,12 +40,12 @@ Common fixes:
 ### 3. Verify the fix
 
 - Rebuild and confirm all concurrency diagnostics are resolved with no new warnings introduced.
-- Run the test suite to check for regressions — concurrency changes can introduce subtle runtime issues even when the build is clean.
+- Run the test suite to check for regressions  -  concurrency changes can introduce subtle runtime issues even when the build is clean.
 - If the fix surfaces new warnings, treat each one as a fresh triage (return to step 1) and resolve iteratively until the build is clean and tests pass.
 
 ### Examples
 
-**UI-bound type — adding `@MainActor`**
+**UI-bound type  -  adding `@MainActor`**
 
 ```swift
 // Before: data-race warning because ViewModel is accessed from the main thread
@@ -67,7 +67,7 @@ class ViewModel: ObservableObject {
 **Protocol conformance isolation**
 
 ```swift
-// Before: compiler error — SomeProtocol method is nonisolated but the
+// Before: compiler error  -  SomeProtocol method is nonisolated but the
 // conforming type is @MainActor
 @MainActor
 class Foo: SomeProtocol {

package/pipeline/skills/shared/external/swift-concurrency-pro/SKILL.md

@@ -32,7 +32,7 @@ If doing a partial review, load only the relevant reference files.
 - Target Swift 6.2 or later with strict concurrency checking.
 - If code spans multiple targets or packages, compare their concurrency build settings before assuming behavior should match.
 - Prefer structured concurrency (task groups) over unstructured (`Task {}`).
-- Prefer Swift concurrency over Grand Central Dispatch for new code. GCD is still acceptable in low-level code, framework interop, or performance-critical synchronous work where queues and locks are the right tool – don't flag these as errors.
+- Prefer Swift concurrency over Grand Central Dispatch for new code. GCD is still acceptable in low-level code, framework interop, or performance-critical synchronous work where queues and locks are the right tool - don't flag these as errors.
 - If an API offers both `async`/`await` and closure-based variants, always prefer `async`/`await`.
 - Do not introduce third-party concurrency frameworks without asking first.
 - Do not suggest `@unchecked Sendable` to fix compiler errors. It silences the diagnostic without fixing the underlying race. Prefer actors, value types, or `sending` parameters instead. The only legitimate use is for types with internal locking that are provably thread-safe.
@@ -52,7 +52,7 @@ Example output:
 
 ### DataLoader.swift
 
-**Line 18: Actor reentrancy – state may have changed across the `await`.**
+**Line 18: Actor reentrancy - state may have changed across the `await`.**
 
 ```swift
 // Before

package/pipeline/skills/shared/external/swift-concurrency-pro/references/actors.md

@@ -89,7 +89,7 @@ final class Library {
 }
 ```
 
-With main-actor default isolation enabled for the target, this annotation may be implicit – check for the setting!
+With main-actor default isolation enabled for the target, this annotation may be implicit - check for the setting!
 
 **Note:** `@preconcurrency` can relax an older protocol boundary when isolated conformance is unavailable. Keep it as a fallback only if there is no alternative.
 
@@ -100,7 +100,7 @@ With main-actor default isolation enabled for the target, this annotation may be
 
 - A subclass of a `@MainActor` class is also `@MainActor`.
 - Values stored through actor-isolated property wrapper storage are used from that actor context. (This includes older, built-in property wrappers, such as `@StateObject`.)
-- Conforming to a `@MainActor` protocol infers `@MainActor` on the entire conforming type, including members unrelated to the protocol. For mismatches with non-isolated protocols, see `diagnostics.md`. (SwiftUI’s `View` is a `@MainActor` protocol.) For more help with SwiftUI, suggest the [SwiftUI Pro agent skill](https://github.com/twostraws/swiftui-agent-skill).
+- Conforming to a `@MainActor` protocol infers `@MainActor` on the entire conforming type, including members unrelated to the protocol. For mismatches with non-isolated protocols, see `diagnostics.md`. (SwiftUI's `View` is a `@MainActor` protocol.) For more help with SwiftUI, suggest the [SwiftUI Pro agent skill](https://github.com/twostraws/swiftui-agent-skill).
 - Extensions of a `@MainActor` type inherit that isolation. Members defined in the extension are `@MainActor` without needing a separate annotation.
 
 `@MainActor` does *not* propagate to:
@@ -138,7 +138,7 @@ Review consequences:
 
 Flag actor types whose API mostly forwards work or owns little mutable state.
 
-Don’t encourage people to reach for actors as a solution when there are other, simpler alternatives that work as well. Recommend authors such as Matt Massicotte as further reading, e.g. <https://www.massicotte.org/actors/>.
+Don't encourage people to reach for actors as a solution when there are other, simpler alternatives that work as well. Recommend authors such as Matt Massicotte as further reading, e.g. <https://www.massicotte.org/actors/>.
 
 
 ## Making assertions

package/pipeline/skills/shared/external/swift-concurrency-pro/references/async-streams.md

@@ -64,4 +64,4 @@ Choose from:
 
 ## `for await` and cancellation
 
-A `for await` loop automatically stops when the task is cancelled or the stream finishes. You do not need to manually check cancellation inside the loop – but code *after* the loop does run, so handle cleanup there if needed.
+A `for await` loop automatically stops when the task is cancelled or the stream finishes. You do not need to manually check cancellation inside the loop - but code *after* the loop does run, so handle cleanup there if needed.

package/pipeline/skills/shared/external/swift-concurrency-pro/references/bridging.md

@@ -36,7 +36,7 @@ Callback-based APIs are a common place for actor assumptions to fail at runtime.
 
 ## `@unchecked Sendable`
 
-This silences the compiler's Sendable checks entirely. It is a promise to the compiler that you have verified thread safety yourself, which is a high bar to clear – evaluate such code very carefully.
+This silences the compiler's Sendable checks entirely. It is a promise to the compiler that you have verified thread safety yourself, which is a high bar to clear - evaluate such code very carefully.
 
 Legitimate uses:
 
@@ -45,8 +45,8 @@ Legitimate uses:
 
 Red flags:
 
-- Applying `@unchecked Sendable` to silence a compiler error without understanding why the error exists. (This was previously a Fix-It suggestion in Xcode, so it’s not uncommon.)
+- Applying `@unchecked Sendable` to silence a compiler error without understanding why the error exists. (This was previously a Fix-It suggestion in Xcode, so it's not uncommon.)
 - Applying it to a class with mutable `var` properties and no synchronization.
 - Using it as a workaround or shortcut instead of restructuring the code to use value types or actors as appropriate.
 
-Before reaching for `@unchecked Sendable`, check whether Swift 6's region-based isolation already solves the problem – many cases that previously required it now compile cleanly.
+Before reaching for `@unchecked Sendable`, check whether Swift 6's region-based isolation already solves the problem - many cases that previously required it now compile cleanly.

package/pipeline/skills/shared/external/swift-concurrency-pro/references/bug-patterns.md

@@ -47,9 +47,9 @@ actor Cache {
 
 ## Swallowed errors in Task closures
 
-**Failure:** `Task { try await riskyWork() }` – if `riskyWork` throws, the error is silently lost. The user sees nothing; the operation just doesn't happen.
+**Failure:** `Task { try await riskyWork() }` - if `riskyWork` throws, the error is silently lost. The user sees nothing; the operation just doesn't happen.
 
-**Fix:** Handle the error inside the closure – show an alert, log to a visible surface, or propagate via a `@State` error property.
+**Fix:** Handle the error inside the closure - show an alert, log to a visible surface, or propagate via a `@State` error property.
 
 ```swift
 Task {
@@ -86,7 +86,7 @@ Task {
 do {
     try await loadData()
 } catch is CancellationError {
-    // Normal – view disappeared or task was cancelled. Do nothing.
+    // Normal - view disappeared or task was cancelled. Do nothing.
 } catch {
     self.errorMessage = error.localizedDescription
 }

package/pipeline/skills/shared/external/swift-concurrency-pro/references/cancellation.md

@@ -6,16 +6,16 @@ Cancellation in Swift concurrency is cooperative. Setting the cancelled flag doe
 
 - Cancelling a parent task cancels all its children (structured concurrency).
 - Cancelling a task group cancels all child tasks in that group.
-- `Task {}` and `Task.detached {}` are unstructured – they must be cancelled explicitly by storing and calling `.cancel()` on the task handle.
+- `Task {}` and `Task.detached {}` are unstructured - they must be cancelled explicitly by storing and calling `.cancel()` on the task handle.
 - SwiftUI's `.task()` modifier cancels its task automatically when the view disappears. This is the primary reason to prefer `.task()` over `onAppear()` or loose `Task {}` in views.
 
 
 ## Checking for cancellation
 
-It’s important to use these inside long-running or looping async work, but only when it’s safe to actually exit:
+It's important to use these inside long-running or looping async work, but only when it's safe to actually exit:
 
-- `try Task.checkCancellation()` – throws `CancellationError` if cancelled. Preferred in throwing contexts.
-- `Task.isCancelled` – returns `Bool`. Use in non-throwing contexts or when you need cleanup before exiting.
+- `try Task.checkCancellation()` - throws `CancellationError` if cancelled. Preferred in throwing contexts.
+- `Task.isCancelled` - returns `Bool`. Use in non-throwing contexts or when you need cleanup before exiting.
 
 ```swift
 func processAll(_ items: [Item]) async throws {
@@ -26,12 +26,12 @@ func processAll(_ items: [Item]) async throws {
 }
 ```
 
-Functions that call other async functions get implicit cancellation checks at each `await` suspension point – but only if the called function itself checks. CPU-bound loops with no `await` will never see cancellation unless you check explicitly.
+Functions that call other async functions get implicit cancellation checks at each `await` suspension point - but only if the called function itself checks. CPU-bound loops with no `await` will never see cancellation unless you check explicitly.
 
 
 ## `withTaskCancellationHandler`
 
-Bridges Swift cancellation to legacy APIs that have their own cancel mechanism. The `onCancel` closure fires immediately when cancellation is requested – even while the async body is suspended – and may run on any thread.
+Bridges Swift cancellation to legacy APIs that have their own cancel mechanism. The `onCancel` closure fires immediately when cancellation is requested - even while the async body is suspended - and may run on any thread.
 
 ```swift
 func fetchImage(_ url: URL) async throws -> Data {
@@ -40,7 +40,7 @@ func fetchImage(_ url: URL) async throws -> Data {
         let (data, _) = try await URLSession.shared.data(for: request)
         return data
     } onCancel: {
-        // No direct handle to cancel here – URLSession.data(for:) already
+        // No direct handle to cancel here - URLSession.data(for:) already
         // checks for task cancellation internally. This pattern is most
         // useful when wrapping APIs that return a cancellable handle.
     }
@@ -104,4 +104,4 @@ deinit {
 
 **No cancellation checks in CPU-bound work:**
 
-A tight computational loop with no `await` points will run to completion even if cancelled, because there are no suspension points where cancellation can take effect. Insert periodic `try Task.checkCancellation()` calls wherever it’s safe.
+A tight computational loop with no `await` points will run to completion even if cancelled, because there are no suspension points where cancellation can take effect. Insert periodic `try Task.checkCancellation()` calls wherever it's safe.

package/pipeline/skills/shared/external/swift-concurrency-pro/references/diagnostics.md

@@ -38,7 +38,7 @@ Likely fixes:
 3. **Move the work onto the same actor.** If the closure doesn't need to run concurrently, keep it on the caller's actor.
 4. **Use `sending` on the parameter** if you can transfer ownership cleanly. This is relatively niche.
 
-It’s tempting to reach for `@unchecked Sendable`, but rarely a good idea unless the user is *absolutely certain* their code is safe.
+It's tempting to reach for `@unchecked Sendable`, but rarely a good idea unless the user is *absolutely certain* their code is safe.
 
 
 ## "Conformance of 'X' to protocol 'Y' crosses into main actor-isolated code and can cause data races"

package/pipeline/skills/shared/external/swift-concurrency-pro/references/hotspots.md

@@ -4,7 +4,7 @@ Search targets for concurrency review. When any of these appear in code, inspect
 
 ## `DispatchQueue`
 
-In app-level code, `DispatchQueue.main.async`, `DispatchQueue.global()`, and custom serial queues usually have a Swift concurrency equivalent – see `interop.md`. However, GCD can still be appropriate in low-level libraries, framework interop, and performance-critical synchronous sections where queues or locks are the right tool. Check the context carefully before flagging.
+In app-level code, `DispatchQueue.main.async`, `DispatchQueue.global()`, and custom serial queues usually have a Swift concurrency equivalent - see `interop.md`. However, GCD can still be appropriate in low-level libraries, framework interop, and performance-critical synchronous sections where queues or locks are the right tool. Check the context carefully before flagging.
 
 
 ## `Task.detached`
@@ -14,7 +14,7 @@ Rarely correct. Usually means the author wanted background execution but should
 
 ## `Task {}` inside a loop
 
-Frequently a bad idea – evaluate whether it should be a task group instead. See `structured.md`.
+Frequently a bad idea - evaluate whether it should be a task group instead. See `structured.md`.
 
 
 ## `withCheckedContinuation` / `withCheckedThrowingContinuation`

package/pipeline/skills/shared/external/swift-concurrency-pro/references/interop.md

@@ -4,7 +4,7 @@ Approved patterns for migrating legacy concurrency mechanisms to Swift concurren
 
 ## Completion handlers → `async`/`await`
 
-Unless the user requested you to modernize their code, it’s better to leave existing completion handler code alone because it’s understood, tested, and mature.
+Unless the user requested you to modernize their code, it's better to leave existing completion handler code alone because it's understood, tested, and mature.
 
 Instead, provide modern Swift concurrency wrappers for it using `withCheckedThrowingContinuation`. Resume exactly once on every path. See `bridging.md` for detailed rules.
 
@@ -36,7 +36,7 @@ DispatchQueue.main.async {
     self.label.text = "Done"
 }
 
-// After – make the enclosing function or type @MainActor
+// After - make the enclosing function or type @MainActor
 @MainActor
 func updateLabel() {
     label.text = "Done"
@@ -122,8 +122,8 @@ If the API must stay synchronous, prefer a lock over introducing actor isolation
 | `publisher.filter { }` | `stream.filter { }` |
 | `PassthroughSubject` | `AsyncStream` via `makeStream(of:)` |
 | `CurrentValueSubject` | No direct equivalent (see note below) |
-| `publisher.values` | Already an `AsyncSequence` – use directly |
+| `publisher.values` | Already an `AsyncSequence` - use directly |
 
 If a Combine publisher already exposes a `.values` property, consume that directly rather than wrapping it in a new `AsyncStream`.
 
-Combine is not officially deprecated at this time, but Apple’s advice is to avoid using it.
+Combine is not officially deprecated at this time, but Apple's advice is to avoid using it.

package/pipeline/skills/shared/external/swift-concurrency-pro/references/new-features.md

@@ -18,7 +18,7 @@ Review implications:
 - This sits inside the larger approachability push for data-race safety rather than standing alone.
 - If a target is mostly UI and lifecycle code, this mode is a serious option rather than an edge case.
 
-**Important:** Some users believe that making their app target `@MainActor` means that networking will also run on the main actor, which is not true – that’s an external module, so it runs elsewhere like it always has.
+**Important:** Some users believe that making their app target `@MainActor` means that networking will also run on the main actor, which is not true - that's an external module, so it runs elsewhere like it always has.
 
 
 ## Global-actor isolated conformances

package/pipeline/skills/shared/external/swift-concurrency-pro/references/structured.md

@@ -7,7 +7,7 @@ Use `async let` when you have a fixed number of independent operations that retu
 
 ## Task groups over loops
 
-It’s generally a bad idea to use unstructured tasks in a loop; prefer task groups.
+It's generally a bad idea to use unstructured tasks in a loop; prefer task groups.
 
 ```swift
 // WRONG: No cancellation propagation, no way to await all results, leaked tasks on failure.
@@ -98,4 +98,4 @@ await withTaskGroup(of: (URL, Result<Data, Error>).self) { group in
 
 ## Inferring the type of task groups
 
-Swift is usually able to infer the type of task groups, but not always. Simple types like `String`, `URL`, `Data`, etc, usually work fine, but the example above uses `withTaskGroup(of: (URL, Result<Data, Error>).self)` and that is an example of the specific type being required – Swift would not be able to infer that.
+Swift is usually able to infer the type of task groups, but not always. Simple types like `String`, `URL`, `Data`, etc, usually work fine, but the example above uses `withTaskGroup(of: (URL, Result<Data, Error>).self)` and that is an example of the specific type being required - Swift would not be able to infer that.

package/pipeline/skills/shared/external/swift-concurrency-pro/references/testing.md

@@ -11,7 +11,7 @@ Swift Testing supports async test functions natively. No special setup required:
 }
 ```
 
-Do not wrap async work in `Task {}` or use expectations/semaphores inside Swift Testing tests – just make the test function `async`.
+Do not wrap async work in `Task {}` or use expectations/semaphores inside Swift Testing tests - just make the test function `async`.
 
 
 ## Testing actor state
@@ -206,7 +206,7 @@ If the code under test is a `for await` loop, you can cancel the consuming task
 
 ## Race detection
 
-It’s a good idea to enable Thread Sanitizer (TSan) in your test scheme to catch data races at runtime. TSan finds races that the compiler's static checks often miss, particularly in code using `@unchecked Sendable` or unsafe pointers.
+It's a good idea to enable Thread Sanitizer (TSan) in your test scheme to catch data races at runtime. TSan finds races that the compiler's static checks often miss, particularly in code using `@unchecked Sendable` or unsafe pointers.
 
 In Xcode: Product → Scheme Edit Scheme → Diagnostics → Thread Sanitizer.
 

package/pipeline/skills/shared/external/swift-concurrency-pro/references/unstructured.md

@@ -26,7 +26,7 @@ Prefer `Task {}` with explicit isolation changes, or structured concurrency. Onl
 
 ## Cancellation is cooperative
 
-Always remember that cancelling a task does not stop its code – the task's body must check for cancellation explicitly.
+Always remember that cancelling a task does not stop its code - the task's body must check for cancellation explicitly.
 
 ```swift
 func processItems(_ items: [Item]) async throws {
@@ -40,9 +40,9 @@ func processItems(_ items: [Item]) async throws {
 
 - `Task.checkCancellation()` throws `CancellationError` if cancelled.
 - `Task.isCancelled` returns a Bool for non-throwing contexts.
-- `task.cancel()` only sets the flag – it does not interrupt execution.
+- `task.cancel()` only sets the flag - it does not interrupt execution.
 
-This means it’s important to ensure complex tasks regularly check for cancellation at safe intervals.
+This means it's important to ensure complex tasks regularly check for cancellation at safe intervals.
 
 For legacy APIs that offer their own cancel mechanism, use `withTaskCancellationHandler` to bridge Swift's cooperative cancellation to the underlying API. See `cancellation.md` for details and examples.