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/pNre/ExSwift 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.

WAIT — Stale — last commit 7y ago

• 15 active contributors
• Other licensed
• CI configured
• ⚠ Stale — last commit 7y ago
• ⚠ Concentrated ownership — top contributor handles 65% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No test directory detected

_{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 pNre/ExSwift repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/pNre/ExSwift.

What it runs against: a local clone of pNre/ExSwift — 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 pNre/ExSwift | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 2675 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of pNre/ExSwift. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/pNre/ExSwift.git
#   cd ExSwift
#
# 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 pNre/ExSwift and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other 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 2675 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2645d)"
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/pNre/ExSwift"
  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).

ExSwift is a collection of Swift extensions that augment built-in types (Array, String, Dictionary, Int, Float, Double, Range, NSArray, NSDate) with functional programming utilities and convenience methods. It adds chainable operations like takeWhile(), skipWhile(), difference(), and intersection() to standard Swift types, reducing boilerplate for common data transformations without requiring external dependencies. Flat extension library: source code in ExSwift/ folder contains one file per type extended (Array.swift, String.swift, Dictionary.swift, Int.swift, Float.swift, Double.swift, NSArray.swift, NSDate.swift, Range.swift, Boolean.swift, Character.swift, Sequence.swift). Tests mirror this structure in ExSwiftTests/ with one test file per type (ArrayExtensionsTests.swift, etc.). Xcode projects defined in ExSwift.xcodeproj/ with separate schemes for Mac and iOS targets.

Swift developers (iOS, macOS) building applications circa 2015–2016 who want functional-style collection operations and utility methods on built-in types without pulling in heavy frameworks. Target audience: engineers working on data transformation, filtering, and validation tasks who prefer method chaining over loops.

This is an actively-developed but mature library from the Swift 2 era (repo has 186KB of Swift code and comprehensive test coverage in ExSwiftTests/). It has CI via Travis CI (.travis.yml present) and is distributed via CocoaPods (ExSwift.podspec). However, no recent commit dates are visible in the metadata, suggesting maintenance may be dormant—typical for a pre-Swift 3 library that solved concrete problems but is less critical with modern Swift's expanded standard library.

High risk for new projects: this library targets Swift 2/early Swift 3 era and predates many standard library improvements (e.g., Sequence protocol enhancements in Swift 4+). It explicitly states in the README that Cocoapods integration doesn't work due to Xcode errors, forcing manual submodule + copy installation. No visibility into open issue count, but the lack of recent activity and language drift (Swift has since natively added many of these methods) means you'll face compatibility headaches with current Xcode/Swift versions.

No active development signals visible in provided metadata. The CHANGELOG.md, .travis.yml CI config, and structured test suite suggest this was actively maintained at release, but no PR/issue activity, recent commits, or milestones are mentioned in the file listing. This appears to be a stable, maintenance-mode library.

Clone and add as a submodule: git clone --recursive https://github.com/pNre/ExSwift.git. Then open ExSwift.xcodeproj in Xcode, select the iOS or Mac scheme, and drag the ExSwift/ source folder into your target's file navigator. No package manager install; manual integration only due to the Cocoapods incompatibility noted in the README.

Daily commands: Open ExSwift.xcodeproj in Xcode, select ExSwift-iOS or ExSwift-Mac scheme, press Cmd+U to run the test suite in ExSwiftTests/, or Cmd+B to build the framework. No build scripts, no CLI tools, no runtime server needed.

• ExSwift/Array.swift: Core file containing Array extension methods (first, last, take, takeWhile, skip, skipWhile, difference, intersection, remove, at, get, etc.) — the most feature-rich type in the library.
• ExSwift/String.swift: String extensions for common text operations (length, substring, repetition, etc.) used across iOS/macOS apps.
• ExSwift/Dictionary.swift: Dictionary convenience methods for safe access, merging, filtering, and transformation.
• ExSwiftTests/ArrayExtensionsTests.swift: Comprehensive test suite validating Array extension behavior; reference for test structure when adding new features.
• ExSwift.xcodeproj/xcshareddata/xcschemes: Xcode schemes (ExSwift-iOS.xcscheme, ExSwift-Mac.xcscheme) define build configurations for dual platform support.
• README.md: Official documentation listing all extension methods with signatures and examples; critical reference for API design and usage patterns.
• ExSwift.podspec: Pod specification defining library metadata, version, and dependencies; required for distribution (though Cocoapods integration is broken per README).

To add a new method to a type: edit the corresponding file in ExSwift/ (e.g., ExSwift/Array.swift for Array extensions). Write the extension method, then add a corresponding test in ExSwiftTests/ (e.g., ArrayExtensionsTests.swift). Follow the existing naming pattern (e.g., takeFirst(), skipWhile()). No configuration files to update; just add code and test.

1. Installation is manual only: The README explicitly states Cocoapods integration fails due to Xcode errors—you must use git submodule + drag-and-drop source into Xcode, not pod install. 2. Swift version mismatch: This library targets Swift 2/early Swift 3 and uses now-deprecated patterns (e.g., SequenceOf); many methods are now natively available in Swift 4+ standard library, causing naming conflicts. 3. NSArray/NSDate extensions use ObjC interop: These files bridge to Foundation and may behave unexpectedly with Swift value types. 4. No tvOS/watchOS targets: Despite having Mac/iOS schemes, support for other Apple platforms is absent.

• Extension methods (Swift extensions) — ExSwift is built entirely on Swift's ability to extend types post-hoc without inheritance; understanding open-closed principle via extensions is fundamental to the codebase.
• Functional programming patterns (map, filter, fold) — Methods like takeWhile(), skipWhile(), and the chainable API design expose functional paradigms; core to understanding ExSwift's philosophy.
• Higher-order functions (functions taking/returning closures) — Many ExSwift methods accept condition closures (e.g., takeFirst(condition: (Element) -> Bool)); mastering closures is essential to using the library.
• Generic constraints (Equatable, protocol-based design) — Methods like remove<U: Equatable> and contains<T: Equatable> use Swift generics with protocol constraints; critical for understanding method signatures throughout ExSwift.
• Protocol-oriented programming (Sequence protocol) — ExSwift extends both Array and generic Sequence types; understanding Swift's Sequence protocol hierarchy is needed to know when methods apply.
• Lazy evaluation and sequences — Methods like skipWhile() and takeWhile() can return lazy sequences; understanding when sequences are evaluated vs. deferred impacts performance.

• apple/swift-algorithms — Official Swift Collections package providing many functional operations (takeWhile, drop, etc.) natively; modern replacement for ExSwift on Swift 5.5+.
• ReactiveX/RxSwift — Reactive extensions for Swift offering similar functional chaining patterns but for asynchronous/event-driven code; complements ExSwift for modern reactive apps.
• Alamofire/Alamofire — HTTP networking library often used alongside utility libraries like ExSwift in iOS apps; common dependency pairing for complete app stacks.
• SwiftyJSON/SwiftyJSON — Lightweight JSON parsing library; often paired with ExSwift for data transformation pipelines in API-driven iOS apps.
• raywenderlich/swift-algorithm-club — Educational repo on algorithms and data structures in Swift; ExSwift methods like difference() and intersection() implement patterns documented here.

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.

Add comprehensive test coverage for String.swift extensions

StringExtensionsTests.swift exists but the README shows only partial documentation. String manipulation is a core feature of ExSwift, and given the breadth of standard extensions (case conversion, trimming, splitting, etc.), there are likely edge cases and newer Swift versions not covered by tests. This would catch regressions and validate all documented String methods work correctly.

• [ ] Review all public methods in ExSwift/String.swift
• [ ] Compare against ExSwiftTests/StringExtensionsTests.swift to identify untested methods
• [ ] Add test cases for edge cases: empty strings, Unicode characters, special characters
• [ ] Add tests for each documented String extension in the README

Migrate .travis.yml CI to GitHub Actions workflow

The repo uses .travis.yml for Travis CI, which is outdated infrastructure. GitHub Actions is now the standard for GitHub projects and provides better integration, faster builds, and no external service dependency. This would modernize the project's CI/CD pipeline and ensure better visibility of test results to contributors.

• [ ] Create .github/workflows/test.yml with iOS and macOS test matrices
• [ ] Configure the workflow to run ExSwiftTests target for both platforms (matching .xcschemes)
• [ ] Remove or deprecate .travis.yml with a note in CHANGELOG.md
• [ ] Test the workflow by creating a draft PR and verifying all checks pass

Complete the README documentation for Array extensions with full method signatures and examples

The README snippet cuts off at Array documentation. ExSwift/Array.swift likely contains many extension methods, but contributors and users cannot discover them from the README. A complete API reference for Array (similar to what should exist for other types) would improve discoverability and reduce support burden.

• [ ] Audit all public methods in ExSwift/Array.swift (e.g., takeFirst, drop, etc.)
• [ ] Add a dedicated '## Array' section to README.md with subsections for instance/class methods
• [ ] Include method signature, brief description, and code example for each extension
• [ ] Cross-reference with existing test cases in ExSwiftTests/ArrayExtensionsTests.swift as examples

• Add unit tests for NSDate.swift methods: ExSwiftTests/NSDateExtensionsTests.swift exists but may lack comprehensive coverage for date arithmetic, formatting, and edge cases like leap years.
• Document Range.swift extension methods in README: The Range type has instance and class methods but is mentioned only briefly in the table of contents; add examples to the README wiki or inline.
• Verify Sequence.swift compatibility with Swift 4+: The file exists but SequenceOf is deprecated in Swift 3+; audit and propose modernization (switch to AnySequence or remove if native stdlib suffices).

ExSwift is a utility library with relatively low attack surface as it extends standard Swift types. No critical vulnerabilities detected. Primary concerns are around build infrastructure modernization (dependency management), lack of formal security processes, and absence of security-focused testing practices. The codebase appears to be a straightforward utility library without external dependencies, network calls, or data persistence, which limits exposure. Recommendations focus on improving development practices and supply chain security through modern tooling and explicit security policies.

• Low · Outdated Project Structure and Build Configuration — ExSwift.xcodeproj, Podfile, README.md. The project uses older Xcode project configuration (.pbxproj) without evidence of modern dependency management. The README mentions Cocoapods integration issues and recommends manual submodule/copy approach, which reduces supply chain security visibility and makes dependency tracking difficult. Fix: Migrate to Swift Package Manager (SPM) for modern dependency management. Use version pinning and lock files to ensure reproducible builds. Implement dependency scanning with tools like OWASP Dependency-Check.
• Low · Missing Security Headers and Configuration — .travis.yml, Root directory. No evidence of security configuration files (.travis.yml exists but content not provided). Missing SECURITY.md file for reporting vulnerabilities, no code signing verification, and no certificate pinning strategy visible for any network operations. Fix: Add SECURITY.md file with vulnerability reporting instructions. Implement code signing requirements. Document security best practices for contributors.
• Low · Limited Visibility into Test Coverage and Security Testing — ExSwiftTests/. Test files exist but no evidence of security-focused unit tests, fuzzing, or integration tests. No visible security testing practices documented. Fix: Add security-focused test cases including boundary testing, type safety verification, and memory safety checks. Use tools like SwiftLint and static analysis.

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.