@mmerterden/multi-agent-pipeline 16.18.0 → 16.19.0

package/pipeline/skills/shared/external/macos-spm-app-packaging/references/release.md

@@ -0,0 +1,32 @@
+# Release and notarization notes
+
+## Notarization requirements
+- Install Xcode Command Line Tools (for `xcrun` and `notarytool`).
+- Provide App Store Connect API credentials:
+  - `APP_STORE_CONNECT_API_KEY_P8`
+  - `APP_STORE_CONNECT_KEY_ID`
+  - `APP_STORE_CONNECT_ISSUER_ID`
+- Provide a Developer ID Application identity in `APP_IDENTITY`.
+
+## Sparkle appcast (optional)
+- Install Sparkle tools so `generate_appcast` is on PATH.
+- Provide `SPARKLE_PRIVATE_KEY_FILE` (ed25519 key).
+- The appcast script uses your zip artifact to create an updated `appcast.xml`.
+- Sparkle compares `sparkle:version` (derived from `CFBundleVersion`), so bump `BUILD_NUMBER` for every release.
+
+## Tag and GitHub release (optional)
+Use a versioned git tag and publish a GitHub release with the notarized zip (and appcast if you host it on GitHub Releases).
+
+Example flow:
+```
+git tag v<version>
+git push origin v<version>
+
+gh release create v<version> CodexBar-<version>.zip appcast.xml \
+  --title "AppName <version>" \
+  --notes-file CHANGELOG.md
+```
+
+Notes:
+- If you serve appcast from GitHub Releases or raw URLs, ensure the release is published and assets are accessible (no 404s).
+- Prefer using a curated release notes file rather than dumping the full changelog.

package/pipeline/skills/shared/external/macos-spm-app-packaging/references/scaffold.md

@@ -0,0 +1,79 @@
+# Scaffold a SwiftPM macOS app (no Xcode)
+
+## Steps
+1) Create a repo and initialize SwiftPM:
+```
+mkdir MyApp
+cd MyApp
+swift package init --type executable
+```
+
+2) Update `Package.swift` to target macOS and define an executable target for the app.
+
+3) Create the app entry point under `Sources/MyApp/`.
+- Use SwiftUI if you want a windowed app with minimal AppKit glue.
+- Use AppKit if you want a menu bar or accessory-style app.
+
+4) If you need app resources, add:
+```
+resources: [.process("Resources")]
+```
+and create `Sources/MyApp/Resources/`.
+
+5) Add a `version.env` file (used by packaging templates):
+```
+MARKETING_VERSION=0.1.0
+BUILD_NUMBER=1
+```
+
+6) Copy script templates from `assets/templates/` into your repo (for example, `Scripts/`).
+
+## Minimal Package.swift (example)
+```
+// swift-tools-version: 6.2
+import PackageDescription
+
+let package = Package(
+    name: "MyApp",
+    platforms: [.macOS(.v14)],
+    targets: [
+        .executableTarget(
+            name: "MyApp",
+            path: "Sources/MyApp",
+            resources: [
+                .process("Resources")
+            ])
+    ]
+)
+```
+
+## Minimal SwiftUI entry point (example)
+```
+import SwiftUI
+
+@main
+struct MyApp: App {
+    var body: some Scene {
+        WindowGroup {
+            Text("Hello")
+        }
+    }
+}
+```
+
+## Minimal AppKit entry point (example)
+```
+import AppKit
+
+final class AppDelegate: NSObject, NSApplicationDelegate {
+    func applicationDidFinishLaunching(_ notification: Notification) {
+        // Initialize app state here.
+    }
+}
+
+let app = NSApplication.shared
+let delegate = AppDelegate()
+app.delegate = delegate
+app.setActivationPolicy(.regular)
+app.run()
+```

package/pipeline/skills/shared/external/monorepo-architect/SKILL.md

@@ -20,7 +20,6 @@ Expert in monorepo architecture, build systems, and dependency management at sca
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
 ## Capabilities
 

package/pipeline/skills/shared/external/nodejs-backend-patterns/SKILL.md

@@ -31,8 +31,4 @@ Comprehensive guidance for building scalable, maintainable, and production-ready
 - Clarify goals, constraints, and required inputs.
 - Apply relevant best practices and validate outcomes.
 - Provide actionable steps and verification.
-- If detailed examples are required, open `resources/implementation-playbook.md`.
 
-## Resources
-
-- `resources/implementation-playbook.md` for detailed patterns and examples.

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

@@ -0,0 +1,63 @@
+## Approachable Concurrency (Swift 6.2) - project mode quick guide
+
+Use this reference when the project has opted into the Swift 6.2 approachable
+concurrency settings (default actor isolation / main-actor-by-default).
+
+## Detect the mode
+
+Check Xcode build settings under "Swift Compiler - Concurrency":
+- Swift language version (must be 6.2+).
+- Default actor isolation / Main Actor by default.
+- Strict concurrency checking level (Complete/Targeted/Minimal).
+
+For SwiftPM, inspect Package.swift swiftSettings for the same flags.
+
+## Behavior changes to expect
+
+- Async functions stay on the caller's actor by default; they don't hop to a
+  global concurrent executor unless the implementation chooses to.
+- Main-actor-by-default reduces data race errors for UI-bound code and global
+  state, because mutable state is implicitly protected.
+- Protocol conformances can be isolated (e.g., `extension Foo: @MainActor Bar`).
+
+## How to apply fixes in this mode
+
+- Prefer minimal annotations; let main-actor-by-default do the work when the
+  code is UI-bound.
+- Use isolated conformances instead of forcing `nonisolated` workarounds.
+- Keep global or shared mutable state on the main actor unless there is a clear
+  performance need to offload it.
+
+## When to opt out or offload work
+
+- Use `@concurrent` on async functions that must run on the concurrent pool.
+- Make types or members `nonisolated` only when they are truly thread-safe and
+  used off the main actor.
+- Continue to respect Sendable boundaries when values cross actors or tasks.
+
+## Common pitfalls
+
+- `Task.detached` ignores inherited actor context; avoid it unless you truly
+  need to break isolation.
+- Main-actor-by-default can hide performance issues if CPU-heavy work stays on
+  the main actor; move that work into `@concurrent` async functions.
+
+## Keywords (from source cheat sheet)
+
+| Keyword | What it does |
+| --- | --- |
+| `async` | Function can pause |
+| `await` | Pause here until done |
+| `Task { }` | Start async work, inherits context |
+| `Task.detached { }` | Start async work, no inherited context |
+| `@MainActor` | Runs on main thread |
+| `actor` | Type with isolated mutable state |
+| `nonisolated` | Opts out of actor isolation |
+| `Sendable` | Safe to pass between isolation domains |
+| `@concurrent` | Always run on background (Swift 6.2+) |
+| `async let` | Start parallel work |
+| `TaskGroup` | Dynamic parallel work |
+
+## Source
+
+https://fuckingapproachableswiftconcurrency.com/en/

package/pipeline/skills/shared/external/swift-concurrency-expert/references/swift-6-2-concurrency.md

@@ -0,0 +1,272 @@
+## Concurrent programming updates in Swift 6.2
+
+Concurrent programming is hard because sharing memory between multiple tasks is prone to mistakes that lead to unpredictable behavior.
+
+## Data-race safety
+
+ Data-race safety in Swift 6 prevents these mistakes at compile time, so you can write concurrent code without fear of introducing hard-to-debug runtime bugs. But in many cases, the most natural code to write is prone to data races, leading to compiler errors that you have to address. A class with mutable state, like this `PhotoProcessor` class, is safe as long as you don't access it concurrently.
+
+```swift
+class PhotoProcessor {
+  func extractSticker(data: Data, with id: String?) async -> Sticker? {     }
+}
+
+@MainActor
+final class StickerModel {
+  let photoProcessor = PhotoProcessor()
+
+  func extractSticker(_ item: PhotosPickerItem) async throws -> Sticker? {
+    guard let data = try await item.loadTransferable(type: Data.self) else {
+      return nil
+    }
+
+    // Error: Sending 'self.photoProcessor' risks causing data races
+    // Sending main actor-isolated 'self.photoProcessor' to nonisolated instance method 'extractSticker(data:with:)'
+    // risks causing data races between nonisolated and main actor-isolated uses
+    return await photoProcessor.extractSticker(data: data, with: item.itemIdentifier)
+  }
+}
+```
+
+ It has an async method to extract a `Sticker` by computing the subject of the given image data. But if you try to call `extractSticker` from UI code on the main actor, you'll get an error that the call risks causing data races. This is because there are several places in the language that offload work to the background implicitly, even if you never needed code to run in parallel.
+
+Swift 6.2 changes this philosophy to stay single threaded by default until you choose to introduce concurrency.
+
+```swift
+class PhotoProcessor {
+  func extractSticker(data: Data, with id: String?) async -> Sticker? {     }
+}
+
+@MainActor
+final class StickerModel {
+  let photoProcessor = PhotoProcessor()
+
+  func extractSticker(_ item: PhotosPickerItem) async throws -> Sticker? {
+    guard let data = try await item.loadTransferable(type: Data.self) else {
+      return nil
+    }
+
+    // No longer a data race error in Swift 6.2 because of Approachable Concurrency and default actor isolation
+    return await photoProcessor.extractSticker(data: data, with: item.itemIdentifier)
+  }
+}
+```
+
+The language changes in Swift 6.2 make the most natural code to write data race free by default. This provides a more approachable path to introducing concurrency in a project.
+
+When you choose to introduce concurrency because you want to run code in parallel, data-race safety will protect you.
+
+First, we've made it easier to call async functions on types with mutable state. Instead of eagerly offloading async functions that aren't tied to a specific actor, the function will continue to run on the actor it was called from. This eliminates data races because the values passed into the async function are never sent outside the actor. Async functions can still offload work in their implementation, but clients don't have to worry about their mutable state.
+
+Next, we've made it easier to implement conformances on main actor types. Here I have a protocol called `Exportable`, and I'm trying to implement a conformance for my main actor `StickerModel` class. The export requirement doesn't have actor isolation, so the language assumed that it could be called from off the main actor, and prevented `StickerModel` from using main actor state in its implementation.
+
+```swift
+protocol Exportable {
+  func export()
+}
+
+extension StickerModel: Exportable { // error: Conformance of 'StickerModel' to protocol 'Exportable' crosses into main actor-isolated code and can cause data races
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+Swift 6.2 supports these conformances. A conformance that needs main actor state is called an *isolated* conformance. This is safe because the compiler ensures a main actor conformance is only used on the main actor.
+
+```swift
+// Isolated conformances
+
+protocol Exportable {
+  func export()
+}
+
+extension StickerModel: @MainActor Exportable {
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+ I can create an `ImageExporter` type that adds a `StickerModel` to an array of any `Exportable` items as long as it stays on the main actor.
+
+```swift
+ // Isolated conformances
+
+@MainActor
+struct ImageExporter {
+  var items: [any Exportable]
+
+  mutating func add(_ item: StickerModel) {
+    items.append(item)
+  }
+
+  func exportAll() {
+    for item in items {
+      item.export()
+    }
+  }
+}
+```
+
+But if I allow `ImageExporter` to be used from anywhere, the compiler prevents adding `StickerModel` to the array because it isn't safe to call export on `StickerModel` from outside the main actor.
+
+```swift
+// Isolated conformances
+
+nonisolated
+struct ImageExporter {
+  var items: [any Exportable]
+
+  mutating func add(_ item: StickerModel) {
+    items.append(item) // error: Main actor-isolated conformance of 'StickerModel' to 'Exportable' cannot be used in nonisolated context
+  }
+
+  func exportAll() {
+    for item in items {
+      item.export()
+    }
+  }
+}
+```
+
+With isolated conformances, you only have to solve data race safety issues when the code indicates that it uses the conformance concurrently.
+
+## Global State
+
+Global and static variables are prone to data races because they allow mutable state to be accessed from anywhere.
+
+```swift
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init() // error: Static property 'shared' is not concurrency-safe because non-'Sendable' type 'StickerLibrary' may have shared mutable state
+}
+```
+
+The most common way to protect global state is with the main actor.
+
+```swift
+final class StickerLibrary {
+  @MainActor
+  static let shared: StickerLibrary = .init()
+}
+```
+
+ And it's common to annotate an entire class with the main actor to protect all of its mutable state, especially in a project that doesn't have a lot of concurrent tasks.
+
+```swift
+@MainActor
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init()
+}
+```
+
+You can model a program that's entirely single-threaded by writing `@MainActor` on everything in your project.
+
+```swift
+@MainActor
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init()
+}
+
+@MainActor
+final class StickerModel {
+  let photoProcessor: PhotoProcessor
+
+  var selection: [PhotosPickerItem]
+}
+
+extension StickerModel: @MainActor Exportable {
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+To make it easier to model single-threaded code, we've introduced a mode to infer main actor by default.
+
+```swift
+// Mode to infer main actor by default in Swift 6.2
+
+final class StickerLibrary {
+  static let shared: StickerLibrary = .init()
+}
+
+final class StickerModel {
+  let photoProcessor: PhotoProcessor
+
+  var selection: [PhotosPickerItem]
+}
+
+extension StickerModel: Exportable {
+  func export() {
+    photoProcessor.exportAsPNG()
+  }
+}
+```
+
+ This eliminates data-race safety errors about unsafe global and static variables, calls to other main actor functions like ones from the SDK, and more, because the main actor protects all mutable state by default. It also reduces concurrency annotations in code that's mostly single-threaded. This mode is great for projects that do most of the work on the main actor, and concurrent code is encapsulated within specific types or files. It's opt-in and it's recommended for apps, scripts, and other executable targets.
+
+## Offloading work to the background
+
+Offloading work to the background is still important for performance, such as keeping apps responsive when performing CPU-intensive tasks.
+
+Let's look at the implementation of the `extractSticker` method on `PhotoProcessor`.
+
+```swift
+// Explicitly offloading async work
+
+class PhotoProcessor {
+  var cachedStickers: [String: Sticker]
+
+  func extractSticker(data: Data, with id: String) async -> Sticker {
+      if let sticker = cachedStickers[id] {
+        return sticker
+      }
+
+      let sticker = await Self.extractSubject(from: data)
+      cachedStickers[id] = sticker
+      return sticker
+  }
+
+  // Offload expensive image processing using the @concurrent attribute.
+  @concurrent
+  static func extractSubject(from data: Data) async -> Sticker { }
+}
+```
+
+It first checks whether it already extracted a sticker for an image, so it can return the cached sticker immediately. If the sticker hasn't been cached, it extracts the subject from the image data and creates a new sticker. The `extractSubject` method performs expensive image processing that I don't want to block the main actor or any other actor.
+
+I can offload this work using the `@concurrent` attribute. `@concurrent` ensures that a function always runs on the concurrent thread pool, freeing up the actor to run other tasks at the same time.
+
+### An example
+
+Say you have a function called `process` that you would like to run on a background thread. To call that function on a background thread you need to:
+
+- make sure the structure or class is `nonisolated`
+- add the `@concurrent` attribute to the function you want to run in the background
+- add the keyword `async` to the function if it is not already asynchronous
+- and then add the keyword `await` to any callers
+
+Like this:
+
+```swift
+nonisolated struct PhotoProcessor {
+
+    @concurrent
+    func process(data: Data) async -> ProcessedPhoto? { ... }
+}
+
+// Callers with the added await
+processedPhotos[item.id] = await PhotoProcessor().process(data: data)
+```
+
+
+## Summary
+
+These language changes work together to make concurrency more approachable.
+
+You start by writing code that runs on the main actor by default, where there's no risk of data races. When you start to use async functions, those functions run wherever they're called from. There's still no risk of data races because all of your code still runs on the main actor. When you're ready to embrace concurrency to improve performance, it's easy to offload specific code to the background to run in parallel.
+
+Some of these language changes are opt-in because they require changes in your project to adopt. You can find and enable all of the approachable concurrency language changes under the Swift Compiler - Concurrency section of Xcode build settings. You can also enable these features in a Swift package manifest file using the SwiftSettings API.
+
+ Swift 6.2 includes migration tooling to help you make the necessary code changes automatically. You can learn more about migration tooling at swift.org/migration.

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

@@ -0,0 +1,33 @@
+# SwiftUI Concurrency Tour (Summary)
+
+Context: SwiftUI-focused concurrency overview covering actor isolation, Sendable closures, and how SwiftUI runs work off the main thread.
+
+## Main-actor default in SwiftUI
+
+- `View` is `@MainActor` isolated by default; members and `body` inherit isolation.
+- Swift 6.2 can infer `@MainActor` for all types in a module (new language mode).
+- This default simplifies UI code and aligns with UIKit/AppKit `@MainActor` APIs.
+
+## Where SwiftUI runs code off the main thread
+
+- SwiftUI may evaluate some view logic on background threads for performance.
+- Examples: `Shape` path generation, `Layout` methods, `visualEffect` closures, and `onGeometryChange` closures.
+- These APIs often require `Sendable` closures to reflect their runtime semantics.
+
+## Sendable closures and data-race safety
+
+- Accessing `@MainActor` state from a `Sendable` closure is unsafe and flagged by the compiler.
+- Prefer capturing value copies in the closure capture list (e.g., copy a `Bool`).
+- Avoid sending `self` into a sendable closure just to read a single property.
+
+## Structuring async work with SwiftUI
+
+- SwiftUI action callbacks are synchronous so UI updates (like loading states) can be immediate.
+- Use `Task` to bridge into async contexts; keep async bodies minimal.
+- Use state as the boundary: async work updates model/state; UI reacts synchronously.
+
+## Performance-driven concurrency
+
+- Offload expensive work from the main actor to avoid hitches.
+- Keep time-sensitive UI logic (animations, gesture responses) synchronous.
+- Separate UI code from long-running async work to improve responsiveness and testability.

package/pipeline/skills/shared/external/swiftui-performance-audit/references/code-smells.md

@@ -0,0 +1,150 @@
+# Common code smells and remediation patterns
+
+## Intent
+
+Use this reference during code-first review to map visible SwiftUI patterns to likely runtime costs and safer remediation guidance.
+
+## High-priority smells
+
+### Expensive formatters in `body`
+
+```swift
+var body: some View {
+    let number = NumberFormatter()
+    let measure = MeasurementFormatter()
+    Text(measure.string(from: .init(value: meters, unit: .meters)))
+}
+```
+
+Prefer cached formatters in a model or dedicated helper:
+
+```swift
+final class DistanceFormatter {
+    static let shared = DistanceFormatter()
+    let number = NumberFormatter()
+    let measure = MeasurementFormatter()
+}
+```
+
+### Heavy computed properties
+
+```swift
+var filtered: [Item] {
+    items.filter { $0.isEnabled }
+}
+```
+
+Prefer deriving this once per meaningful input change in a model/helper, or store derived view-owned state only when the view truly owns the transformation lifecycle.
+
+### Sorting or filtering inside `body`
+
+```swift
+List {
+    ForEach(items.sorted(by: sortRule)) { item in
+        Row(item)
+    }
+}
+```
+
+Prefer sorting before render work begins:
+
+```swift
+let sortedItems = items.sorted(by: sortRule)
+```
+
+### Inline filtering inside `ForEach`
+
+```swift
+ForEach(items.filter { $0.isEnabled }) { item in
+    Row(item)
+}
+```
+
+Prefer a prefiltered collection with stable identity.
+
+### Unstable identity
+
+```swift
+ForEach(items, id: \.self) { item in
+    Row(item)
+}
+```
+
+Avoid `id: \.self` for non-stable values or collections that reorder. Use a stable domain identifier.
+
+### Top-level conditional view swapping
+
+```swift
+var content: some View {
+    if isEditing {
+        editingView
+    } else {
+        readOnlyView
+    }
+}
+```
+
+Prefer one stable base view and localize conditions to sections or modifiers. This reduces root identity churn and makes diffing cheaper.
+
+### Image decoding on the main thread
+
+```swift
+Image(uiImage: UIImage(data: data)!)
+```
+
+Prefer decode and downsample work off the main thread, then store the processed image.
+
+## Observation fan-out
+
+### Broad `@Observable` reads on iOS 17+
+
+```swift
+@Observable final class Model {
+    var items: [Item] = []
+}
+
+var body: some View {
+    Row(isFavorite: model.items.contains(item))
+}
+```
+
+If many views read the same broad collection or root model, small changes can fan out into wide invalidation. Prefer narrower derived inputs, smaller observable surfaces, or per-item state closer to the leaf views.
+
+### Broad `ObservableObject` reads on iOS 16 and earlier
+
+```swift
+final class Model: ObservableObject {
+    @Published var items: [Item] = []
+}
+```
+
+The same warning applies to legacy observation. Avoid having many descendants observe a large shared object when they only need one derived field.
+
+## Remediation notes
+
+### `@State` is not a generic cache
+
+Use `@State` for view-owned state and derived values that intentionally belong to the view lifecycle. Do not move arbitrary expensive computation into `@State` unless you also define when and why it updates.
+
+Better alternatives:
+- precompute in the model or store
+- update derived state in response to a specific input change
+- memoize in a dedicated helper
+- preprocess on a background task before rendering
+
+### `equatable()` is conditional guidance
+
+Use `equatable()` only when:
+- equality is cheaper than recomputing the subtree, and
+- the view inputs are value-semantic and stable enough for meaningful equality checks
+
+Do not apply `equatable()` as a blanket fix for all redraws.
+
+## Triage order
+
+When multiple smells appear together, prioritize in this order:
+1. Broad invalidation and observation fan-out
+2. Unstable identity and list churn
+3. Main-thread work during render
+4. Image decode or resize cost
+5. Layout and animation complexity

package/pipeline/skills/shared/external/swiftui-performance-audit/references/demystify-swiftui-performance-wwdc23.md

@@ -0,0 +1,46 @@
+# Demystify SwiftUI Performance (WWDC23) (Summary)
+
+Context: WWDC23 session on building a mental model for SwiftUI performance and triaging hangs/hitches.
+
+## Performance loop
+
+- Measure -> Identify -> Optimize -> Re-measure.
+- Focus on concrete symptoms (slow navigation, broken animations, spinning cursor).
+
+## Dependencies and updates
+
+- Views form a dependency graph; dynamic properties are a frequent source of updates.
+- Use `Self._printChanges()` in debug only to inspect extra dependencies.
+- Eliminate unnecessary dependencies by extracting views or narrowing state.
+- Consider `@Observable` for more granular property tracking.
+
+## Common causes of slow updates
+
+- Expensive view bodies (string interpolation, filtering, formatting).
+- Dynamic property instantiation and state initialization in `body`.
+- Slow identity resolution in lists/tables.
+- Hidden work: bundle lookups, heap allocations, repeated string construction.
+
+## Avoid slow initialization in view bodies
+
+- Don't create heavy models synchronously in view bodies.
+- Use `.task` to fetch async data and keep `init` lightweight.
+
+## Lists and tables identity rules
+
+- Stable identity is critical for performance and animation.
+- Ensure a constant number of views per element in `ForEach`.
+- Avoid inline filtering in `ForEach`; pre-filter and cache collections.
+- Avoid `AnyView` in list rows; it hides identity and increases cost.
+- Flatten nested `ForEach` when possible to reduce overhead.
+
+## Table specifics
+
+- `TableRow` resolves to a single row; row count must be constant.
+- Prefer the streamlined `Table` initializer to enforce constant rows.
+- Use explicit IDs for back deployment when needed.
+
+## Debugging aids
+
+- Use Instruments for hangs and hitches.
+- Use `_printChanges` to validate dependency assumptions during debug.