If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/duemunk/Async shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• 15 active contributors
• Distributed ownership (top contributor 40% of recent commits)
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live duemunk/Async repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/duemunk/Async.

What it runs against: a local clone of duemunk/Async — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in duemunk/Async | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 789 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of duemunk/Async. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/duemunk/Async.git
#   cd Async
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of duemunk/Async and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "duemunk/Async(\\.git)?\\b" \\
  && ok "origin remote is duemunk/Async" \\
  || miss "origin remote is not duemunk/Async (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 789 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~759d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/duemunk/Async"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Async is a Swift syntactic sugar library that wraps Grand Central Dispatch (GCD) to simplify chaining asynchronous operations across different dispatch queues. Instead of nested DispatchQueue.async closures, it provides a fluent API (e.g., Async.userInitiated { }.main { }.background { }) that reduces indentation and improves readability. It also includes AsyncGroup for parallel task coordination with wait() semantics. Single-framework library structure: core logic lives in the Async.xcodeproj Xcode project; the main source is likely in a Sources/ directory (not fully listed). Example apps are in AsyncPodsExample/ (separate iOS, macOS, and tvOS targets demonstrating usage). Build infrastructure includes Makefile, .travis.yml for CI, and support for CocoaPods, Carthage, and Swift Package Manager (.swiftpm/ directory present).

iOS/macOS/tvOS/watchOS developers using Swift who frequently dispatch work to different QoS queues and want cleaner, more readable asynchronous code without deep callback nesting. Particularly useful for UI-heavy apps that need to coordinate background work with main-thread updates.

This project is no longer maintained (as stated in the README). It targets Swift 5.1 and supports iOS 8.0+, macOS 10.10+, tvOS 9.0+, watchOS 2.0+. The Travis CI badge indicates historical CI setup, but there are no recent commits visible. It is suitable for learning or legacy codebases, but should not be used in new production projects—modern Swift Concurrency (async/await, introduced in Swift 5.5) and structured concurrency are the recommended approach.

Critical risk: the project is explicitly unmaintained and will not receive bug fixes or Swift compatibility updates. No test coverage is evident from the file structure (no Tests directory shown). It has zero external dependencies (uses only Foundation GCD), so supply chain risk is low, but the single-maintainer status and lack of active development mean any issues are unfixed. Swift's modern concurrency model (async/await) has superseded this library's use case, making it obsolete for new code.

Nothing. The project is archived/unmaintained. No active development, PRs, or issues are being addressed. Historical CI (Travis) was set up but is no longer active.

git clone https://github.com/duemunk/Async.git
cd Async
# For Swift Package Manager:
swift build
# For Xcode:
open Async.xcodeproj

Daily commands: Open Async.xcodeproj in Xcode and build the Async scheme, or run swift build in the project root. Run example apps via the AsyncPodsExample folder (separate targets for iOS, macOS, tvOS). No dev server—this is a pure library.

• Async.xcodeproj/project.pbxproj: Xcode project configuration defining build targets, dependencies, and scheme settings for the library and examples.
• .swiftpm/xcode/package.xcworkspace: Swift Package Manager workspace setup, indicating SPM support for the library.
• [AsyncPodsExample/AsyncExample iOS/ViewController.swift](https://github.com/duemunk/Async/blob/master/AsyncPodsExample/AsyncExample iOS/ViewController.swift): iOS example demonstrating real usage of Async.userInitiated { }.main { } chaining patterns.
• .travis.yml: Historical CI configuration (now inactive) showing the build/test pipeline used before maintenance stopped.
• README.md: Documents the library's API, benefits, installation methods (CocoaPods, Carthage, SPM), and the unmaintained status.

The main library source is in the Xcode project; look for Async.swift or equivalent in Sources/ or root. Example app code is in AsyncPodsExample/AsyncExample iOS/ViewController.swift, AsyncPodsExample/AsyncExample OS X/ViewController.swift, etc.—modify these to test library changes. To add features: extend the Async struct with new queue convenience methods, or enhance AsyncGroup with new coordination primitives. Note: This is unmaintained; fork it if you plan to modify.

1. Unmaintained: No fixes for Swift 6+ or future OS versions. 2. No test suite visible: No Tests or test targets in the file list means code quality cannot be verified. 3. Deprecated approach: GCD chaining via this library is obsolete—Swift 5.5+ async/await and structured concurrency are the standard (this library will not support them). 4. QoS semantics: Developers must understand DispatchQueue quality-of-service implications (userInitiated vs. background); misuse can degrade app performance. 5. No error handling: The chaining API has no built-in error propagation (unlike modern async/await try/catch).

• Grand Central Dispatch (GCD) — Async is a wrapper around GCD's DispatchQueue and QoS classes; understanding GCD's queue types (.main, .userInitiated, .background) is essential to using this library correctly.
• Quality of Service (QoS) — Async exposes GCD's QoS levels (userInitiated, background, utility, etc.); choosing the right QoS affects app responsiveness and battery life.
• Fluent Builder / Method Chaining — Async's core design pattern is fluent chaining (.userInitiated { }.main { }) to avoid nesting; understanding this pattern is key to using the library idiomatically.
• Generic Return Types in Swift — Async uses generic Self return types to enable method chaining while preserving type safety; a key Swift pattern for DSL-like APIs.
• Thread Synchronization (group.wait()) — AsyncGroup's wait() blocks the current thread until all dispatched blocks complete; critical for coordinating parallel background tasks before proceeding.
• Structured Concurrency (modern replacement) — Swift 5.5+ async/await and task groups make Async obsolete; learning Async provides context for why structured concurrency was designed to replace GCD-based patterns.

• ReactiveCocoa/ReactiveCocoa — Provides higher-level reactive/functional abstractions (signals, producers) for managing asynchronous operations; more powerful but heavier than Async.
• ReactiveX/RxSwift — Similar intent (manage async work elegantly) but uses observables/operators; RxSwift is actively maintained and widely adopted, making it the modern alternative to Async.
• apple/swift-async-algorithms — Apple's official library for async/await based iteration and task composition; the successor to GCD-based chaining libraries like Async.
• groue/GRDB.swift — Example of a well-maintained Swift library using modern concurrency (async/await); demonstrates the pattern Async users should migrate toward.
• duemunk/Async-history — If it exists, shows the evolution of this library before maintenance stopped; otherwise, the repo itself is the canonical source.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Migrate from Travis CI to GitHub Actions workflow

The repo uses .travis.yml for CI, which is outdated. GitHub Actions is now the standard for GitHub-hosted projects and provides better integration. This will modernize the build pipeline and ensure the project can be tested on current Swift/Xcode versions without relying on external CI services.

• [ ] Create .github/workflows/test.yml with matrix testing for iOS, macOS, tvOS, and watchOS targets
• [ ] Add Swift version matrix (5.1+) to match the README's stated compatibility
• [ ] Remove or deprecate .travis.yml with a note in README
• [ ] Verify tests pass on both Xcode and Swift Package Manager builds
• [ ] Update README badges to reference GitHub Actions status instead of Travis CI

Add comprehensive unit tests for core Async dispatch patterns

The repo has AsyncTests_Info.plist in the Xcode project, but no visible test files in the file structure. Given this is a GCD wrapper library, there should be unit tests covering the main dispatch patterns (async, background queues, main thread, delays, chaining). This ensures reliability and documents expected behavior.

• [ ] Create Tests/AsyncTests.swift with test cases for main queue dispatch
• [ ] Add tests for background queue (default, user-initiated, utility) dispatch patterns
• [ ] Add tests for async chaining/sequential dispatch patterns
• [ ] Add tests for delays and cancellation if supported by the library
• [ ] Ensure tests run on both Xcode project and SPM test target

Create modern Package.swift with explicit module targets and example app reference

While .swiftpm exists, the repo structure suggests it may lack a properly configured Package.swift or it's outdated. Modern Swift packages should explicitly define library and test targets, and optionally reference the example apps. This improves discoverability for SPM users and clarifies the project structure.

• [ ] Review/create Package.swift with explicit .library target for Async
• [ ] Define .executableProduct targets for the three example apps (iOS, macOS, tvOS) if intended for distribution
• [ ] Add proper Swift version requirement (5.1+) and platform minimums matching README
• [ ] Verify SPM can build with swift build and swift test
• [ ] Update README with SPM installation instructions if not present

• Add a comprehensive test suite: create Tests/ directory with XCTestCase files covering Async.main { }, Async.background { }, and multi-chain scenarios (e.g., Async.userInitiated { }.main { }.background { }) to verify execution order and queue dispatch.
• Document AsyncGroup usage with a full example: add sample code to README.md or create AsyncExample_Group.swift showing parallel background tasks, group.wait() blocking, and multiple group.background() calls.
• Migrate to Swift Package Manager as primary build system: move source files into a modern Package.swift structure under Sources/Async/, making the library easier to consume and maintaining CocoaPods/Carthage compatibility via the manifest.

The Async library presents moderate security concerns primarily due to its unmaintained status. While the codebase itself appears to be a straightforward GCD wrapper without obvious injection vulnerabilities, SQL injection, or XSS risks (as it's a low-level async library), the lack of ongoing maintenance is the critical issue. No current security issues were identified in the visible code structure, but the inability to receive security patches for the outdated Swift 5.1 version and any future vulnerabilities discovered represents significant risk for production use. The project should be considered for replacement with actively maintained alternatives.

• High · Unmaintained Project with No Security Updates — Project root / README. The README explicitly states 'This project is no longer maintained.' This means no security patches, bug fixes, or vulnerability updates will be provided. Any security issues discovered in the codebase or its dependencies will remain unfixed. Fix: Consider migrating to a maintained alternative for async/GCD operations, or maintain a fork with security patches if this library is critical to your application.
• Medium · Outdated Swift Version — Package configuration / Swift version requirement. The project targets Swift 5.1, which is significantly outdated. Modern Swift versions (5.9+) include important security improvements, bug fixes, and language features that improve code safety. Fix: Update to the latest stable Swift version and verify compatibility with the codebase.
• Medium · Missing Dependency Lock File Information — Package.swift / Package.resolved. No Package.swift or package resolved file content was provided. Unable to verify if dependencies are pinned to specific versions or if any transitive dependencies have known vulnerabilities. Fix: Ensure all dependencies are pinned to specific secure versions. Use swift package update with care and regularly audit dependencies using tools like swift package describe --type json and vulnerability databases.
• Low · Xcode Project Files in Version Control — Async.xcodeproj/, AsyncPodsExample/AsyncPodsExample.xcodeproj/. Multiple Xcode project files (.pbxproj, workspace configuration files) are tracked in version control. While not directly a security issue, these files can contain sensitive build settings or local paths. Fix: Consider adding .pbxproj files to .gitignore and using workspace or build configuration files instead. Review these files for any hardcoded paths or settings.
• Low · CocoaPods Lockfile Present — AsyncPodsExample/Podfile.lock, AsyncPodsExample/Pods/. Podfile.lock exists in version control under AsyncPodsExample/, which is generally acceptable for reproducible builds. However, the Pods directory itself should be in .gitignore. Fix: Verify that the Pods/ directory is in .gitignore to avoid committing dependency source code. Keep Podfile.lock in version control for reproducible builds.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.