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/ankurp/Dollar 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

• 20 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 76% 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 ankurp/Dollar repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ankurp/Dollar.

What it runs against: a local clone of ankurp/Dollar — 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 ankurp/Dollar | 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 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 831 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ankurp/Dollar(\\.git)?\\b" \\
  && ok "origin remote is ankurp/Dollar" \\
  || miss "origin remote is not ankurp/Dollar (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"

# 4. Critical files exist
test -f "Sources/Dollar.swift" \\
  && ok "Sources/Dollar.swift" \\
  || miss "missing critical file: Sources/Dollar.swift"
test -f "Sources/AutoCurry.swift" \\
  && ok "Sources/AutoCurry.swift" \\
  || miss "missing critical file: Sources/AutoCurry.swift"
test -f "Sources/AutoBind.swift" \\
  && ok "Sources/AutoBind.swift" \\
  || miss "missing critical file: Sources/AutoBind.swift"
test -f "Package.swift" \\
  && ok "Package.swift" \\
  || miss "missing critical file: Package.swift"
test -f "Dollar.podspec" \\
  && ok "Dollar.podspec" \\
  || miss "missing critical file: Dollar.podspec"

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

Dollar is a Swift functional programming utility library that provides chainable helper functions for arrays, dictionaries, and objects—similar to Lodash in JavaScript. It offers ~50+ methods like map, filter, reduce, groupBy, and flatten without extending built-in Swift types, maintaining a pure functional approach across iOS/macOS development. Single-package monolith: Sources/ contains three core modules (Dollar.swift, AutoCurry.swift, AutoBind.swift) that implement functional methods. Tests/DollarTests/ holds unit tests. Built as a framework via Dollar.xcodeproj. Companion repo Cent (separate) provides extension-based Swift utilities, keeping Dollar pure-function focused.

Swift developers (iOS/macOS) building data-heavy applications who want to leverage functional programming patterns without writing imperative loops, and who are familiar with Lodash/Underscore.js and expect similar ergonomics in Swift.

Moderately mature and stable. The project has been actively maintained with version 10.0.0 supporting Xcode 15 (Swift 5.1), uses CocoaPods and Swift Package Manager for distribution, includes a test suite (Tests/DollarTests/DollarTests.swift), and CI via Travis CI. However, the GitHub presence and recent commit frequency are not visible in the provided data, so active development status is unclear.

Low-to-moderate risk. It's a single-author project (ankurp) with no visible dependency bloat (99.6% Swift codebase), but relies on manual semantic versioning alignment with Swift/Xcode versions—e.g., version 10 for Swift 5.1, version 7 for Swift 4. Breaking changes are likely when Swift introduces new syntax (noted: $ identifier removed in Swift 4, forcing rename to Dollar). No dependency list visible, reducing supply-chain risk.

Not visible from provided data. No recent PRs, milestones, or commit messages are shown. The README mentions Swift 5.1 support (version 10.0.0) but active work status is unclear.

git clone https://github.com/ankurp/Dollar.git && cd Dollar && swift build (via Swift Package Manager) OR open Dollar.xcodeproj && Cmd+U to run tests in Xcode. For CocoaPods: add 'pod "Dollar"' to Podfile, run pod install, and import Dollar.

Daily commands: xcode: open Dollar.xcodeproj && Cmd+U (runs DollarTests scheme). swift-pm: swift build && swift test. No dev server—it's a library, not an app.

• Sources/Dollar.swift — Main entry point and core utility functions — defines the Dollar namespace and primary functional programming helpers that all consumers depend on.
• Sources/AutoCurry.swift — Implements currying transformation for functions — a fundamental functional programming pattern that enables partial application and chaining throughout the library.
• Sources/AutoBind.swift — Implements function binding and context handling — essential for enabling flexible functional composition patterns in Swift.
• Package.swift — Swift Package Manager manifest — defines dependencies, targets, and module configuration required for compilation and distribution.
• Dollar.podspec — CocoaPods specification — declares the library's public API surface, platforms, and CocoaPods metadata for dependency resolution.
• Tests/DollarTests/DollarTests.swift — Comprehensive test suite covering all public APIs — validates correctness of functional utilities across different input scenarios.

• Dollar.swift (Core Module) (Swift, Sequence/Collection protocols) — Implements all public utility functions (map, filter, reduce, flatten, compact, find, contains, range, merge, etc.) for array and dictionary manipulation.
  • Failure mode: Function logic error results in incorrect transformation or filtering of data; affects all consumers.
• AutoCurry.swift (Swift function types, closures) — Transforms multi-argument functions into curried chains enabling partial application and composition.
  • Failure mode: Incorrect currying logic breaks partial application; composed functions may receive arguments in wrong order or miss context.
• AutoBind.swift (Swift closures, reference capture) — Preserves function context (self reference) during binding, essential for methods and closures with captured state.
  • Failure mode: Lost or incorrect context causes methods to operate on wrong object or lose captured state.
• Test Suite (DollarTests.swift) (XCTest framework) — Validates all public functions across normal inputs, edge cases, and domain examples (CarExample).
  • Failure mode: Incomplete test coverage allows regressions; broken tests hide actual implementation bugs.

• Developer Code → Dollar.swift — Calls functional utility (e.g., Dollar.map(array, transform)) with input data and transformation.
• Dollar.swift → Swift Standard Library (Array/Dictionary) — Applies transformation using native Swift Sequence/Collection methods.
• Developer Code → AutoCurry.swift — Requests curried version of multi-argument function for partial application.
• AutoCurry.swift → Dollar.swift — Wraps original function and returns single-argument closures for chaining.
• Developer Code → AutoBind.swift — Binds function to context (e.g., self reference) to preserve state during composition.
• AutoBind.swift → Dollar.swift — Returns context-aware version of utility function.

Add a new utility function to the Dollar module

1. Define the function signature in Sources/Dollar.swift, typically as a static method or top-level function with clear documentation (Sources/Dollar.swift)
2. Implement the function using Swift's native collection methods and functional composition patterns already established in the file (Sources/Dollar.swift)
3. Add comprehensive test cases covering normal inputs, edge cases, and error conditions in the test file (Tests/DollarTests/DollarTests.swift)
4. Verify the function works with AutoCurry and AutoBind if applicable by testing partial application scenarios (Tests/DollarTests/DollarTests.swift)

Add currying support to a multi-argument function

1. Create a curried wrapper function using the AutoCurry pattern (decompose into single-argument functions) (Sources/AutoCurry.swift)
2. Export the curried version from Dollar.swift alongside or replacing the original function (Sources/Dollar.swift)
3. Test the curried version for partial application and composition in DollarTests (Tests/DollarTests/DollarTests.swift)

Update library for a new Swift version

1. Update the Swift version constraint in .swift-version and Package.swift (Package.swift)
2. Update the CocoaPods specification if new platform versions are supported (Dollar.podspec)
3. Run full test suite via .travis.yml configuration and validate SwiftLint compliance (.travis.yml)
4. Update Xcode project minimum deployment target in project configuration (Dollar.xcodeproj/Configs/Project.xcconfig)

• Swift Language — Primary target language for the library; enables strong type safety and functional programming idioms native to Swift.
• CocoaPods + Swift Package Manager — Dual dependency management approach maximizes adoption across legacy (Pods) and modern (SPM) Swift projects.
• SwiftLint — Enforces consistent code style and prevents common Swift pitfalls without extending built-in types (maintaining Dollar's design principle).
• Travis CI + Hound — Automated validation ensures all contributions maintain functional correctness and style consistency before merge.

• No extension on built-in Swift types (Array, Dictionary, etc.)

  • Why: Avoids polluting global namespace and prevents conflicts with other libraries that extend the same types.
  • Consequence: Functions must be called via Dollar.function() or imported individually; slightly more verbose than lodash/underscore.js but safer in multi-library ecosystems.

• Functional programming helpers only (no data structures)

  • Why: Keeps library lightweight and focused; matches lodash design philosophy.
  • Consequence: Consumers cannot use Dollar for custom data structures; they must use Swift's built-in Array/Dictionary or external libraries.

• Support for Swift 4+ only ($ identifier removed)

  • Why: Swift 4 restricted $ as a valid identifier for stricter syntax; maintains language compliance.
  • Consequence: Requires calling Dollar.function() instead of $.function() (more verbose but language-compliant).

• Does not extend or modify Swift's built-in types (Array, Dictionary, Set, etc.)
• Does not provide custom data structures (trees, linked lists, graphs)
• Does not offer real-time reactive programming (use Combine or RxSwift instead)
• Does not support Linux or non-Apple platforms (Apple platforms only via CocoaPods/SPM)

• Implicit type conversion in generic functions (Low) — Sources/Dollar.swift: Some utility functions rely on implicit type conformance (e.g., Equatable, Comparable) without explicit constraint documentation, making failures at call-time rather than compile-time.
• Missing nil coalescing guards in optional chains — Sources/Dollar.swift: Some functions handling dictionaries may not explicitly handle

Swift version coupling: version selection is tightly tied to Xcode/Swift version (e.g., use 10.0.0 for Swift 5.1, 7.1.0 for Swift 4). The $ identifier is invalid in Swift 4+; must use Dollar instead. No visible API stability guarantee or deprecation policy across major versions. Test suite presence but test coverage depth unknown from file listing.

• Functional Programming / Pure Functions — Dollar's entire design philosophy revolves around pure, side-effect-free functions for data transformation; understanding FP principles is essential to using it effectively
• Method Chaining / Fluent Interface — Dollar enables chainable syntax (e.g., $.map(...).filter(...).reduce(...)); the Chain wrapper type implements this pattern, making it a core ergonomic feature
• Function Currying / Partial Application — AutoCurry.swift implements currying to transform multi-argument functions into sequences of single-argument functions, enabling composition and reuse
• Higher-Order Functions — Dollar's core methods (map, filter, reduce, groupBy) are higher-order functions that accept functions as arguments; this is the foundational pattern across the library
• Generic Programming / Protocol Extensions — Dollar uses Swift generics and protocol extensions to provide type-safe, reusable implementations across Array, Dictionary, and custom types without extending built-ins
• Immutability — Dollar's API favors immutable transformations (returning new collections) over mutations; this prevents side effects and enables safe chaining

• ankurp/Cent — Companion library providing extension-based Swift utilities; Dollar users often pair with Cent for extended built-in type methods
• ReactiveCocoa/ReactiveCocoa — Functional reactive programming framework for Swift; overlaps with Dollar on functional composition but adds time-based signal handling
• pointfreeco/swift-composable-architecture — Modern functional architecture framework emphasizing composition and pure functions; represents a more holistic alternative to Dollar for app-wide state
• ReactiveX/RxSwift — Observable/reactive streams library; complements Dollar for data transformations in async/event-driven contexts
• lodash/lodash — JavaScript predecessor and inspiration; Dollar's API is intentionally similar, making this the reference for feature parity

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 unit tests for AutoBind.swift and AutoCurry.swift

The Sources/ directory contains AutoBind.swift and AutoCurry.swift, but Tests/DollarTests/DollarTests.swift likely has minimal or no coverage for these functional programming features. These are core utilities that deserve dedicated test suites to ensure currying and auto-binding work correctly across Swift versions.

• [ ] Create Tests/DollarTests/AutoBindTests.swift with test cases for auto-binding behavior with different function signatures
• [ ] Create Tests/DollarTests/AutoCurryTests.swift with test cases for curry() function with various arities and argument combinations
• [ ] Add edge case tests (e.g., curry with 0 args, nested currying, type mismatches)
• [ ] Verify tests pass in .travis.yml CI pipeline

Add GitHub Actions workflow to replace/supplement Travis CI

The repo uses .travis.yml for CI, but GitHub Actions is now the standard for GitHub-hosted projects. This provides faster feedback, better integration, and modern Swift toolchain support. The existing .travis.yml suggests the project is not fully modernized.

• [ ] Create .github/workflows/test.yml with matrix strategy for multiple Swift versions (from .swift-version hints)
• [ ] Add steps for: swift build, swift test, and swiftlint validation (see .swiftlint.yml exists)
• [ ] Include CocoaPods validation step using pod lib lint (see Dollar.podspec exists)
• [ ] Test with Swift Package Manager (Package.swift already present)

Complete the truncated README.md documentation for Dictionary and remaining API sections

The README.md ends abruptly at '- [Dictionary](#dict' indicating missing documentation sections. The API Documentation link points to dollarswift.org, but the README should have inline examples for all major function categories to improve discoverability and user onboarding.

• [ ] Expand Dictionary section with min, max, merge, pick, omit examples (reference Sources/Dollar.swift for available functions)
• [ ] Add missing sections: String, Function, Miscellaneous
• [ ] Add 2-3 concrete usage examples for each major function category with before/after code
• [ ] Verify all code examples compile by extracting them into Tests/ReadmeExamplesTests.swift

• Add unit tests for AutoBind.swift and AutoCurry.swift. Currently Tests/DollarTests/DollarTests.swift may not cover all binding/currying edge cases; add tests for partial application with multiple arguments and function composition chains.
• Expand CarExample.swift with additional domain examples (e.g., filtering nested structures, grouping by multiple keys) and add corresponding unit tests to improve documentation through runnable code.
• Document the Chain wrapper type and its interaction with map/filter/reduce in a new sources file or README section; currently unclear how chaining differs from direct method calls, creating onboarding friction.

This is a well-maintained Swift utility library with a strong security posture. No critical vulnerabilities were identified. The codebase follows standard iOS/Swift best practices with linting configuration (.swiftlint.yml) and code review automation (Hound integration). Identified issues are minor: lack of explicit dependency pinning in Package.swift, missing Swift version enforcement, and absence of automated dependency scanning. The library appears to be a pure functional utility library without network calls, database interactions, or external dependencies listed, minimizing attack surface. Recommendations focus on preventive measures rather than addressing active vulnerabilities.

• Low · Missing dependency pinning in Package.swift — Package.swift. The Package.swift file content was not provided for analysis. Without explicit version pinning for dependencies, the build could pull newer versions with potential vulnerabilities or breaking changes. Fix: Specify exact dependency versions or version ranges in Package.swift to ensure reproducible builds. Example: .package(url: "...", from: "1.0.0")
• Low · Swift version not enforced in Package.swift — Package.swift, .swift-version. While .swift-version file exists, best practices recommend explicitly setting swiftLanguageVersions in Package.swift to prevent accidental compilation with incompatible Swift versions. Fix: Add explicit swiftLanguageVersions declaration in Package.swift to ensure consistent Swift version requirements across all build systems.
• Low · No SBOM or dependency audit configuration — Repository root. The repository lacks automated dependency scanning configuration (e.g., Dependabot, automated security audits) to detect known vulnerabilities in transitive dependencies. Fix: Implement automated dependency vulnerability scanning using tools like Dependabot, OWASP Dependency-Check, or similar Swift ecosystem tools.

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.