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/typelift/Swiftz 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

• 12 active contributors
• BSD-3-Clause licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 4y ago
• ⚠ Concentrated ownership — top contributor handles 79% of recent commits

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

What it runs against: a local clone of typelift/Swiftz — 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 typelift/Swiftz | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-3-Clause | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1440 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-3-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-3-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-3-Clause" \\
  || miss "license drift — was BSD-3-Clause 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"

# 4. Critical files exist
test -f "Sources/Swiftz/Functor.swift" \\
  && ok "Sources/Swiftz/Functor.swift" \\
  || miss "missing critical file: Sources/Swiftz/Functor.swift"
test -f "Sources/Swiftz/Monad.swift" \\
  && ok "Sources/Swiftz/Monad.swift" \\
  || miss "missing critical file: Sources/Swiftz/Monad.swift"
test -f "Sources/Swiftz/Applicative.swift" \\
  && ok "Sources/Swiftz/Applicative.swift" \\
  || miss "missing critical file: Sources/Swiftz/Applicative.swift"
test -f "Sources/Swiftz/Kinds.swift" \\
  && ok "Sources/Swiftz/Kinds.swift" \\
  || miss "missing critical file: Sources/Swiftz/Kinds.swift"
test -f "Sources/Swiftz/List.swift" \\
  && ok "Sources/Swiftz/List.swift" \\
  || miss "missing critical file: Sources/Swiftz/List.swift"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1440 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1410d)"
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/typelift/Swiftz"
  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).

Swiftz is a comprehensive Swift library that brings functional programming abstractions to iOS and macOS development. It implements typeclasses (Functor, Monad, Arrow, Semigroup, Monoid), functional data structures (List, NonEmptyList, HList, Either, Reader, Writer, State), and functional combinators that mirror Haskell's Prelude and Scalaz's designs—enabling developers to write declarative, type-safe functional code in Swift. Modular typeclass hierarchy: Sources/Swiftz/ contains ~50 focused files organized by abstraction level. Base typeclasses (Functor.swift, Monad.swift, Semigroup.swift) sit at the foundation. Data structures (List.swift, Either.swift, Reader.swift, State.swift, Writer.swift) implement these typeclasses. Extensions on stdlib types (ArrayExt.swift, OptionalExt.swift, DictionaryExt.swift, StringExt.swift) add FP methods. High-level composites (Arrow.swift, HList.swift, Curry.swift) layer on top.

Swift developers (iOS/macOS) who want to apply functional programming paradigms—specifically those familiar with Haskell, Scala, or OCaml and seeking equivalent abstractions in Swift. Contributors are typically advanced developers comfortable with category theory concepts like Functors, Monads, and Arrows.

Moderately mature but historical. The repo has significant scope (264KB of Swift code), uses modern tooling (Carthage, CocoaPods, Travis CI in .travis.yml), and implements well-established FP patterns. However, the last visible activity and commit recency are not shown in the provided data—Swift's language evolution (particularly with Result and async/await) may have outpaced parts of this library. No test files are visible in the top 60, which is a yellow flag.

Moderate risk: (1) No test suite visible in the provided file list suggests coverage gaps. (2) Single-maintainer risk is typical of open-source FP libraries. (3) Swift's standard library has absorbed many functional features (Optional, Result, async/await) since Swiftz was created, potentially reducing need for this library. (4) Dependencies on external functional concepts mean breaking changes in Swift versions could ripple through multiple abstraction layers.

Activity is not detailed in provided data. Check .travis.yml for CI setup and Cartfile for active dependencies. The presence of both Package.swift and Swiftz.podspec suggests maintained multi-platform distribution, but commit history is not visible.

git clone https://github.com/typelift/Swiftz.git
cd Swiftz
carthage update --platform iOS,macOS
# Or with CocoaPods:
pod install

See .swift-version for the required Swift version.

Daily commands: This is a library, not an executable. Add to your project via Carthage (Cartfile) or CocoaPods (Swiftz.podspec), then import Swiftz in Swift files. CI runs via Travis (see .travis.yml). No local dev server.

• Sources/Swiftz/Functor.swift — Defines the foundational Functor protocol that most functional abstractions in the library extend.
• Sources/Swiftz/Monad.swift — Core monad abstraction enabling monadic composition patterns used throughout the library.
• Sources/Swiftz/Applicative.swift — Applicative functor protocol bridging functors and monads; essential for understanding lifting and application patterns.
• Sources/Swiftz/Kinds.swift — Type-level abstractions and kind system that enable higher-kinded programming patterns in Swift.
• Sources/Swiftz/List.swift — Functional linked-list data structure providing monadic operations; demonstrates core library idioms.
• Sources/Swiftz/Reader.swift — Reader monad implementation showcasing dependency injection and environment-passing patterns.
• Package.swift — Swift Package Manager configuration defining build targets, dependencies, and library structure.

Add a new Functional Data Structure (Monad)

1. Create new file Sources/Swiftz/MyMonad.swift with struct/class inheriting from Monad protocol (Sources/Swiftz/MyMonad.swift)
2. Implement required Monad methods: pure (static), flatMap, and inherited Functor.map (Sources/Swiftz/MyMonad.swift)
3. Create corresponding test file Tests/SwiftzTests/MyMonadSpec.swift with monad law verification (left identity, right identity, associativity) (Tests/SwiftzTests/MyMonadSpec.swift)
4. Export the new type in Sources/Swiftz/Swiftz.h header or ensure it's discoverable via package (Sources/Swiftz/Swiftz.h)

Add Functional Operations to Swift Built-In Type

1. Edit or create Sources/Swiftz/[Type]Ext.swift (e.g., StringExt.swift) with extension on Swift's native type (Sources/Swiftz/ArrayExt.swift)
2. Implement functional methods leveraging existing typeclasses (Functor, Foldable, Monoid) for composability (Sources/Swiftz/ArrayExt.swift)
3. Add conformance to library protocols (e.g., extension Array: Functor) if applicable (Sources/Swiftz/ArrayExt.swift)
4. Create test file Tests/SwiftzTests/[Type]ExtSpec.swift validating new operations (Tests/SwiftzTests/ArrayExtSpec.swift)

Add a new Typeclass/Abstraction

1. Create Sources/Swiftz/MyTypeclass.swift defining protocol with required methods and type constraints (Sources/Swiftz/MyTypeclass.swift)
2. Reference existing similar typeclasses (Functor, Applicative, Monad in Sources/Swiftz/) as models for design patterns (Sources/Swiftz/Functor.swift)
3. Implement conformances in concrete data structures (List, Identity, Either) by extending them with your typeclass (Sources/Swiftz/List.swift)
4. Write law-based tests in Tests/SwiftzTests/MyTypeclassSpec.swift (e.g., associativity, identity, composition laws) (Tests/SwiftzTests/MyTypeclassSpec.swift)

Extend Existing Typeclass with New Implementation

1. Identify target typeclass file (e.g., Sources/Swiftz/Monad.swift) and data structure needing conformance (Sources/Swiftz/Monad.swift)
2. Add extension block to data structure (e.g., Sources/Swiftz/List.swift) implementing required typeclass methods (Sources/Swiftz/List.swift)
3. Test conformance in existing spec file (e.g., Tests/SwiftzTests/ListSpec.swift) or create new spec if needed (Tests/SwiftzTests/ListSpec.swift)
4. Verify implementation satisfies typeclass laws (composition, identity) documented in the protocol (Sources/Swiftz/Monad.swift)

(1) Swiftz makes heavy use of protocol-based generics; Swift compiler errors can be cryptic—read error messages carefully from the bottom up. (2) No visible test suite in top 60 files suggests you may need to write integration tests yourself. (3) HList.swift uses advanced generics that may hit Swift compiler limitations in older versions—check .swift-version strictly. (4) Extensions on stdlib types (OptionalExt, ArrayExt) add unprefixed methods; namespace collisions with other FP libraries are possible. (5) Arrow and higher typeclass code requires understanding of composition semantics—not immediately intuitive.

• Typeclass (Protocol-based abstraction) — The entire library is built on typeclasses (Functor, Monad, Arrow, Semigroup); understanding this pattern is mandatory to use Swiftz effectively
• Functor, Applicative, Monad hierarchy — These three typeclasses form the backbone of functional composition in Swiftz; every data structure implements them in sequence
• Arrow (Category theory abstraction) — Arrows generalize functions and enable composable, reusable computations; critical for advanced Swiftz patterns
• Semigroup and Monoid — Enable principled reductions and concatenations without explicit loops; core pattern for functional aggregations shown in README
• Currying (Partial application) — Swiftz.Curry provides currying utilities essential for composing multi-argument functions in functional style
• Reader, Writer, State monads — These monadic data structures encapsulate side effects and mutable state in pure functions; foundational for composable I/O and stateful computations
• Heterogeneous Lists (HList) — HList.swift enables type-safe lists of mixed types; demonstrates Swift's advanced type system and enables generic programming patterns not possible with homogeneous arrays

• typelift/Swiftx — Lightweight companion library; Swiftz is explicitly a superset of Swiftx with simpler primitives for incremental adoption
• ReactiveX/RxSwift — Reactive/streaming alternative to functional composition; many Swiftz patterns (Functor, Monad) apply to RxSwift Observables
• pointfreeco/swift-composable-architecture — Modern TCA framework uses functional composition patterns that Swiftz pioneered; demonstrates applied functional architecture in Swift
• scalaz/scalaz — Swiftz's primary inspiration—Scala FP library that shows how Haskell patterns translate to JVM languages (informational for learning)
• apple/swift-package-manager — Swiftz uses SPM (Package.swift); understanding SPM is required for building and distributing this library

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 Monad, Applicative, and Functor protocols

The Tests/SwiftzTests directory has only a few spec files (ArrayExtSpec, ArrowExtSpec, DictionaryExtSpec, EitherSpec) but Sources/Swiftz contains 40+ modules including core abstractions like Monad.swift, Applicative.swift, Functor.swift, and Comonad.swift. These foundational typeclass implementations lack corresponding test files, making it difficult to verify law compliance (monad laws, functor laws, applicative laws) and catch regressions.

• [ ] Create Tests/SwiftzTests/MonadSpec.swift with tests for monad laws (left identity, right identity, associativity)
• [ ] Create Tests/SwiftzTests/ApplicativeSpec.swift with applicative functor law tests
• [ ] Create Tests/SwiftzTests/FunctorSpec.swift with functor law tests (identity, composition)
• [ ] Create Tests/SwiftzTests/ComonadSpec.swift with comonad law tests
• [ ] Ensure Reader.swift, Writer.swift, State.swift implementations are tested against their respective laws

Add GitHub Actions workflow to replace Travis CI and test multiple Swift versions

.travis.yml exists but is outdated for modern Swift development. The repo has .swift-version file and multiple platform schemes (iOS, tvOS, watchOS) defined in Swiftz.xcodeproj, but no modern CI. GitHub Actions would provide faster feedback, better Swift version matrix testing, and native GitHub integration. Travis CI is no longer recommended for new projects.

• [ ] Create .github/workflows/swift.yml with matrix strategy for Swift versions (5.3, 5.4, 5.5, 5.6+)
• [ ] Add job to build Swiftz.xcodeproj for macOS platform with xcodebuild
• [ ] Add job to run Tests/LinuxMain.swift on Linux runners for cross-platform verification
• [ ] Add separate jobs for iOS, tvOS, and watchOS platform schemes to verify multi-platform support
• [ ] Update README.md badge to reference GitHub Actions instead of Travis CI

Add integration tests for concrete data structures (List, NonEmptyList, Stream, HList)

Sources/Swiftz contains sophisticated data structures (List.swift, NonEmptyList.swift, Stream.swift, HList.swift) but Tests/SwiftzTests directory has no corresponding spec files for them. These are non-trivial implementations that need validation of correctness, performance characteristics, and proper Functor/Monad/Foldable instance behavior.

• [ ] Create Tests/SwiftzTests/ListSpec.swift testing List construction, traversal, Monad operations, and Foldable instance
• [ ] Create Tests/SwiftzTests/NonEmptyListSpec.swift validating the non-empty invariant and its operations
• [ ] Create Tests/SwiftzTests/StreamSpec.swift for lazy evaluation correctness and infinite stream handling
• [ ] Create Tests/SwiftzTests/HListSpec.swift for heterogeneous list type-safety and operations
• [ ] Add property-based tests using QuickCheck-style generators where applicable

• Add comprehensive unit tests for Sources/Swiftz/List.swift operations (map, filter, reduce, cycle, take, drop)—tests directory appears absent or underpopulated
• Document the typeclass hierarchy with a visual diagram or ASCII chart in README, mapping Functor → Applicative → Monad → Arrow relationships
• Create a 'Getting Started' guide with runnable Swift Playground examples for each major abstraction (List, Either, Reader, Writer, State) in Sources/

The Swiftz codebase demonstrates a reasonable security posture for a functional programming library. It is a pure Swift library without obvious injection vulnerabilities, hardcoded secrets, or exposed infrastructure. Key recommendations include: (1) auditing and updating the Swift version specification and dependencies, (2) ensuring CI/CD configurations don't contain secrets, (3) implementing regular dependency vulnerability scanning, and (4) verifying the integrity of git submodules and external dependencies. The library's nature as a utility/library rather than a server application reduces certain attack surfaces. No critical vulnerabilities were identified from the visible file structure.

• Medium · Outdated Swift Version Specification — .swift-version. The .swift-version file is present but its content is not visible. This file typically specifies a Swift version that may be outdated. Using outdated Swift versions can expose the codebase to known security vulnerabilities and compiler issues that have been patched in newer versions. Fix: Review and update .swift-version to specify the latest stable Swift version. Ensure all dependencies and CI/CD pipelines use this updated version.
• Low · Travis CI Configuration Visible — .travis.yml. The .travis.yml file is present in the repository. While this is a standard CI configuration file, it may expose sensitive information about the build process or infrastructure details if not properly reviewed. Fix: Audit .travis.yml to ensure no secrets, API keys, or sensitive credentials are hardcoded. Use Travis CI environment variables for sensitive data.
• Low · Cartfile Dependency Management — Cartfile, Cartfile.resolved, Cartfile.private. The repository uses Carthage for dependency management (Cartfile, Cartfile.resolved present). Without visibility into these files, there's a risk of outdated or vulnerable dependencies being used. Fix: Regularly audit dependencies using tools like carthage outdated. Implement dependency scanning in CI/CD pipeline. Pin to specific secure versions and review changelogs for security patches.
• Low · Git Submodules Configuration — .gitmodules. The presence of .gitmodules indicates use of git submodules. Submodules can pose security risks if the referenced repositories are compromised or become unavailable. Fix: Audit all submodule references to ensure they point to trusted sources. Use HTTPS URLs instead of SSH/git protocol. Regularly update submodules and verify their integrity.

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.