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

What it runs against: a local clone of DeclarativeHub/Bond — 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 DeclarativeHub/Bond | 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 ≤ 1482 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "DeclarativeHub/Bond(\\.git)?\\b" \\
  && ok "origin remote is DeclarativeHub/Bond" \\
  || miss "origin remote is not DeclarativeHub/Bond (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/Bond/Bond.swift" \\
  && ok "Sources/Bond/Bond.swift" \\
  || miss "missing critical file: Sources/Bond/Bond.swift"
test -f "Package.swift" \\
  && ok "Package.swift" \\
  || miss "missing critical file: Package.swift"
test -f "Sources/Bond/Data Structures/Array2D.swift" \\
  && ok "Sources/Bond/Data Structures/Array2D.swift" \\
  || miss "missing critical file: Sources/Bond/Data Structures/Array2D.swift"
test -f "Sources/Bond/UIKit/UITableView.swift" \\
  && ok "Sources/Bond/UIKit/UITableView.swift" \\
  || miss "missing critical file: Sources/Bond/UIKit/UITableView.swift"
test -f "Sources/Bond/Data Sources/SectionedDataSourceChangesetConvertible.swift" \\
  && ok "Sources/Bond/Data Sources/SectionedDataSourceChangesetConvertible.swift" \\
  || miss "missing critical file: Sources/Bond/Data Sources/SectionedDataSourceChangesetConvertible.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 1482 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1452d)"
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/DeclarativeHub/Bond"
  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).

Bond is a Swift binding framework that implements reactive data binding and observable properties, allowing automatic propagation of state changes between UI components and data models without boilerplate. It bridges reactive programming (via ReactiveKit) with imperative Swift code, enabling one-line bindings like textField.reactive.text.bind(to: label) while supporting transformation pipelines and reactive data sources for collections. Framework structure: core binding logic lives in the main Bond package (Swift Package Manager at Package.swift), extensions for third-party libraries (Realm) in Extensions/, platform-specific schemes for iOS/macOS/tvOS in Bond.xcodeproj/xcshareddata/xcschemes/, and runnable examples in Playground-iOS.playground/ and Bond-App/. Key documentation in Documentation/ covers Bindings.md, ObservableCollections.md, and DataSourceSignals.md.

iOS/macOS/tvOS developers building data-driven UIs who want type-safe, declarative state management without KVO boilerplate or reactive framework complexity. Specifically architects using the Binder Architecture pattern (https://github.com/DeclarativeHub/TheBinderArchitecture).

Production-ready and actively maintained—Bond 7 is released with migration guides in Documentation/Migration.md, CI runs on Travis (.travis.yml), and the codebase shows 480KB of well-organized Swift code. However, last activity is not visible in provided data; check git log and GitHub releases for recency confirmation.

Low risk for a mature library: depends on ReactiveKit (a sibling framework under DeclarativeHub control), but single maintainer (srdanrasic per README badge) is a concentration risk. The reactive programming model carries a moderate learning curve for imperative teams unfamiliar with functional transformations.

Bond 7 has been released—see Documentation/Migration.md for what changed. Active development includes support for observable collections (ObservableArray/ObservableArray2D evident in playground pages) and reactive UIKit proxies (reactive.text, reactive.controlEvents patterns shown in README). No specific PR data in file list; check GitHub Issues and recent commits for current work.

git clone https://github.com/DeclarativeHub/Bond.git
cd Bond
open Bond.xcworkspace  # Opens Xcode workspace
# Or use Swift Package Manager:
swift package resolve

Then explore Playground-iOS.playground/Pages/ to see binding examples in action.

Daily commands: Open Bond.xcworkspace in Xcode and build the Bond-iOS scheme, or use swift build. Run Playground-iOS.playground in Xcode to interactively explore binding examples (Key Value Observing.xcplaygroundpage, Observable Collections.xcplaygroundpage, etc.). Bond-App/ target provides a minimal sample app.

• Sources/Bond/Bond.swift — Core binding framework entry point that defines the primary API for creating and managing bindings between objects.
• Package.swift — Swift Package Manager manifest defining dependencies (ReactiveKit) and platform targets; essential for build configuration.
• Sources/Bond/Data Structures/Array2D.swift — Foundation for observable 2D collections used throughout the framework for table and collection view bindings.
• Sources/Bond/UIKit/UITableView.swift — Critical UIKit binding layer that demonstrates how Bond integrates reactive bindings with standard iOS UI components.
• Sources/Bond/Data Sources/SectionedDataSourceChangesetConvertible.swift — Key data source abstraction that enables sectioned collection bindings and changeset-based UI updates.
• Sources/BNDProtocolProxyBase/include/BNDProtocolProxyBase.h — Objective-C protocol proxy foundation enabling dynamic delegate binding, a unique Bond capability for reactive delegation.
• Documentation/Bindings.md — Comprehensive guide to the binding concept and patterns that underpin all Bond functionality.

Add a new UIKit control binding

1. Create a new file in Sources/Bond/UIKit/ named after the control (e.g., UISwitch.swift) (Sources/Bond/UIKit/UISwitch.swift)
2. Define reactive properties using the Bond pattern, typically wrapping event signals to observable properties (Sources/Bond/UIKit/UISwitch.swift)
3. Implement binding operators that connect observable values to the control's state using Bond's bind operator (Sources/Bond/UIKit/UISwitch.swift)
4. Follow the pattern established in Sources/Bond/UIKit/UIControl.swift for consistent API surface (Sources/Bond/UIKit/UIControl.swift)

Add a new observable collection type

1. Define the collection structure in Sources/Bond/Data Structures/ (e.g., Array3D.swift) extending standard Swift collection protocols (Sources/Bond/Data Structures/Array2D.swift)
2. Create a corresponding data source protocol in Sources/Bond/Data Sources/ conforming to ChangesetConvertible pattern (Sources/Bond/Data Sources/SectionedDataSourceChangesetConvertible.swift)
3. Implement binding adapters in UIKit and AppKit layers to connect the collection to table/collection views (Sources/Bond/UIKit/UITableView.swift)
4. Add a playground example demonstrating usage patterns (follow Playground-iOS.playground structure) (Playground-iOS.playground/Pages/UITableView+ObservableArray.xcplaygroundpage/Contents.swift)

Add AppKit bindings for a new control

1. Create a new file in Sources/Bond/AppKit/ named after the control (e.g., NSButton.swift already exists as a reference) (Sources/Bond/AppKit/NSButton.swift)
2. Follow the AppKit binding patterns from existing controls, using NSControl as the base for most bindings (Sources/Bond/AppKit/NSControl.swift)
3. Implement target-action and notification-based observable properties since AppKit lacks combine-like primitives (Sources/Bond/AppKit/NSControl.swift)
4. Add corresponding macOS playground example in Playground-macOS.playground to demonstrate usage (Playground-macOS.playground/Pages/NSTableView Bindings.xcplaygroundpage/Contents.swift)

Add a reactive data source for complex layouts

1. Define a new changeset-convertible protocol in Sources/Bond/Data Sources/ following the pattern of SectionedDataSourceChangesetConvertible (Sources/Bond/Data Sources/SectionedDataSourceChangesetConvertible.swift)
2. Implement the data source delegate methods in UIKit layer (e.g., Sources/Bond/UIKit/UITableView+DataSource.swift) (Sources/Bond/UIKit/UITableView+DataSource.swift)
3. Create the observable collection data structure in Sources/Bond/Data Structures/ that the data source consumes (Sources/Bond/Data Structures/Array2D.swift)
4. Add documentation to Documentation/ explaining the new data source pattern and add a playground example (Documentation/DataSourceSignals.md)

• Swift + SwiftUI/UIKit/AppKit — Bond is a Swift binding framework designed to work across Apple platforms with type-safe syntax; multi-platform support (iOS, macOS, tvOS) requires control bindings for each framework
• ReactiveKit dependency — ReactiveKit provides the underlying reactive signal/observable infrastructure; Bond bridges the gap between ReactiveKit's purely reactive model and imperative UI paradigms
• Objective-C Protocol Proxies (BNDProtocolProxyBase) — Enables dynamic reactive delegates without manual conformance; allows interception of delegate method calls at runtime for reactive observation patterns
• Changeset-based diffing — Efficient batch UI updates through minimal row/section changes rather than full reloads; critical for performance with large observable collections
• Generic Data Structures (Array2D, TreeArray) — Type-safe representation of complex data layouts (sectioned, hierarchical); enables compile-time correctness for collection binding code

• Framework built on top of ReactiveKit rather than SwiftUI Combine
  • Why: Bond was created before Combine existed; provides more flexible reactive primitives and multi-platform support before SwiftUI was available
  • Consequence: Developers must learn ReactiveKit semantics; adds a dependency layer

1. ReactiveKit dependency not vendored: Bond requires ReactiveKit (a separate framework under DeclarativeHub). Ensure it's properly resolved via CocoaPods (Bond.podspec) or SPM (Package.swift) before building. 2. KVO limitations on Swift properties: Bindings via .reactive proxy only work on Objective-C runtime-visible properties (e.g., @objc dynamic vars or UIKit properties). Plain Swift properties don't support KVO without special annotation. 3. Playground execution: Playground-iOS.playground requires iOS scheme; running against tvOS scheme will fail silently. 4. .swift-version file: Specifies minimum Swift version; check this if you encounter compilation errors with older Swift toolchains.

• Reactive Binding / One-way Binding — Core concept in Bond: establishing a unidirectional propagation of state changes (e.g., textField.reactive.text → label.reactive.text). Understanding binding direction prevents subtle bugs in two-way scenarios.
• Observable / ReactiveX Pattern — Bond's entire API is built on Observables from ReactiveKit. Understanding subscribe, map, and flatMap operators is essential to building complex bindings and transformation pipelines.
• Key-Value Observing (KVO) — Bond leverages Objective-C KVO under the hood for detecting property changes on UIKit components. Knowing KVO limitations (requires Objective-C runtime, @dynamic/@objc declaration) explains why some Swift properties cannot be bound.
• Functional Reactive Programming (FRP) / Functional Composition — Bond encourages composing bindings with functional operators (map, filter, flatMap). Understanding function composition and immutability patterns is necessary to avoid common reactive mistakes.
• Observable Collections / Reactive Data Sources — Bond extends Observable to collections (ObservableArray, ObservableArray2D) to enable automatic UITableView/UICollectionView updates when data changes. This pattern eliminates manual data source delegation boilerplate.
• Protocol Proxies / Dynamic Proxy Pattern — Bond's .reactive property is a proxy object that wraps UIKit components and exposes reactive properties without modifying the original class. This pattern decouples binding logic from UIKit internals.
• Memory Cycle / Strong Reference Cycle Prevention in Reactive Chains — Binding chains can create retain cycles if closures capture self strongly. Bond and ReactiveKit use weak captures and disposable patterns to prevent memory leaks in long-lived observable subscriptions.

• DeclarativeHub/ReactiveKit — Direct dependency of Bond; provides the Observable protocol and reactive operators (map, flatMap, bind) that Bond wraps for UI binding.
• ReactiveCocoa/ReactiveCocoa — Alternative reactive binding framework for Objective-C/Swift; heavier but more mature ecosystem with wider community adoption.
• RxSwift/RxSwift — Another reactive Swift framework offering similar Observable/binding patterns; RxSwift is more widely used but larger surface area than Bond.
• DeclarativeHub/TheBinderArchitecture — Reference architecture explicitly designed around Bond; shows production patterns for organizing app state and UI binding with this framework.
• realm/realm-swift — Database library with Bond integration example in Extensions/Bond+Realm.swift; relevant for developers binding Realm model changes to UI.

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 unit tests for ObservableCollections with differential updates

The repo has extensive playground documentation (Playground-iOS.playground/Pages/UITableView+Signal+Diff.xcplaygroundpage) demonstrating differential/diff-based updates for observable collections, but there's no evidence of corresponding unit tests in the codebase. This is a critical feature for performance optimization when binding to UITableView/UICollectionView. Adding comprehensive unit tests would ensure correctness of insertion, deletion, and move operations.

• [ ] Create Tests/ObservableCollectionDiffTests.swift with test cases for differential updates
• [ ] Add tests for edge cases: empty collections, single element, duplicate elements, reordering scenarios
• [ ] Verify tests cover both ObservableArray and ObservableArray2D as shown in playground pages
• [ ] Ensure tests validate that diff operations correctly identify insertions, deletions, and moves

Add GitHub Actions CI workflow to replace .travis.yml

The repo uses Travis CI (.travis.yml) which is dated infrastructure. Modern Swift/iOS projects use GitHub Actions for better integration, faster builds, and matrix testing across multiple Swift versions and platforms. This would improve contributor experience and CI reliability.

• [ ] Create .github/workflows/swift-build.yml with matrix jobs for iOS, macOS, and tvOS platforms
• [ ] Add Swift version matrix testing (reference .swift-version file for baseline)
• [ ] Configure jobs to run pod install (Bond.podspec present) and execute both unit tests and playground validation
• [ ] Add workflow for SPM package resolution (Package.swift present for SwiftPM support)

Add missing test coverage documentation for ProtocolProxies feature

Documentation/ProtocolProxies.md exists describing a significant framework feature, but there's no evidence of corresponding unit tests or example code. This advanced feature (reactive protocol implementations) needs validation tests to ensure it works across different protocol scenarios and edge cases.

• [ ] Create Tests/ProtocolProxiesTests.swift with test cases for basic protocol binding scenarios
• [ ] Add tests for delegate pattern implementation (UITableViewDelegate, UICollectionViewDelegate proxies)
• [ ] Test optional protocol method handling and property observation through proxies
• [ ] Add integration tests combining ProtocolProxies with ObservableCollections (validate with UITableView example)

• Add reactive binding example for UISwitch state + UILabel feedback: README shows textField → label binding but not toggle controls; adding a UISwitch.reactive.isOn example to Playground-iOS.playground/Pages/ would clarify boolean bindings for newcomers.
• Document reactive proxy naming conventions and what 'reactive' returns: README jumps into textField.reactive.text syntax without explaining that .reactive is a namespace returning Observable<T> wrappers. A new section in Documentation/Bindings.md clarifying this pattern would reduce confusion.
• Create a minimal 'Getting Started' example in Bond-App/: Bond-App/ exists but is not described in README or Documentation/; a step-by-step example (e.g., 'build a login form with email validation using bindings') would lower the barrier for new users.

Bond is a well-structured Swift binding framework with generally secure architecture. The primary concerns are: (1) inability to fully assess dependency security without Package.swift content, (2) inclusion of Objective-C code requiring additional security review for memory safety, and (3) standard development configuration files in version control. The framework's reactive/declarative design is inherently safer than imperative patterns. No evidence of hardcoded secrets, SQL injection risks, or XSS vulnerabilities was found. Recommend comprehensive dependency auditing, Objective-C security review, and modernization of CI/CD infrastructure.

• Medium · Missing dependency verification file — Package.swift, Package.resolved. The Package.resolved file exists but Package.swift content was not provided for analysis. Without reviewing the Swift package manifest, it's impossible to verify if all dependencies are properly pinned to secure versions and whether known vulnerable packages are in use. Fix: Ensure Package.swift specifies exact versions for all dependencies. Review Package.resolved to verify no known vulnerable versions are locked. Use swift package update cautiously and audit changelog for security fixes.
• Medium · Objective-C code without security review — Sources/BNDProtocolProxyBase/BNDProtocolProxyBase.m, Sources/BNDProtocolProxyBase/include/BNDProtocolProxyBase.h. The codebase includes Objective-C source code (BNDProtocolProxyBase.m and .h files) which may have different security considerations than Swift. Memory management, buffer overflows, and unsafe operations are more likely in Objective-C. Fix: Conduct thorough security review of Objective-C code, particularly for memory safety issues. Use Address Sanitizer and Memory Sanitizer during testing. Consider gradual migration to pure Swift if possible.
• Low · Build configuration files in version control — Bond.xcodeproj/project.pbxproj, Bond.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings. XCode project configuration files (.pbxproj, workspace settings, scheme files) are committed to version control. These can expose development environment details and build paths. Fix: Review .gitignore to ensure sensitive build configurations are excluded. Consider using .gitignore to exclude generated build artifacts and local development settings.
• Low · Missing input validation documentation — Sources/Bond/. As a binding framework, Bond processes external data through reactive streams and bindings. Without visible input validation patterns in the file structure, there may be risk of malformed data propagation. Fix: Document and implement input validation at binding entry points. Validate data types and ranges before propagating through observables. Add type safety checks for reactive transformations.
• Low · Deprecated CI/CD configuration — .travis.yml. The .travis.yml file indicates use of Travis CI, which may be outdated. CI/CD security is critical for catching vulnerabilities early. Fix: Migrate to modern CI/CD platforms (GitHub Actions, GitLab CI). Enable branch protection rules and require security scanning. Implement SAST/dependency scanning in CI pipeline.

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.