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/roberthein/TinyConstraints 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 2y ago

• 17 active contributors
• MIT licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 72% of recent commits
• ⚠ No CI workflows detected
• ⚠ 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 roberthein/TinyConstraints repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/roberthein/TinyConstraints.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "roberthein/TinyConstraints(\\.git)?\\b" \\
  && ok "origin remote is roberthein/TinyConstraints" \\
  || miss "origin remote is not roberthein/TinyConstraints (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 "TinyConstraints/Classes/TinyConstraints.swift" \\
  && ok "TinyConstraints/Classes/TinyConstraints.swift" \\
  || miss "missing critical file: TinyConstraints/Classes/TinyConstraints.swift"
test -f "TinyConstraints/Classes/Constrainable.swift" \\
  && ok "TinyConstraints/Classes/Constrainable.swift" \\
  || miss "missing critical file: TinyConstraints/Classes/Constrainable.swift"
test -f "TinyConstraints/Classes/Constraints.swift" \\
  && ok "TinyConstraints/Classes/Constraints.swift" \\
  || miss "missing critical file: TinyConstraints/Classes/Constraints.swift"
test -f "TinyConstraints/Classes/Abstraction.swift" \\
  && ok "TinyConstraints/Classes/Abstraction.swift" \\
  || miss "missing critical file: TinyConstraints/Classes/Abstraction.swift"
test -f "TinyConstraints/Classes/Stack.swift" \\
  && ok "TinyConstraints/Classes/Stack.swift" \\
  || miss "missing critical file: TinyConstraints/Classes/Stack.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 784 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~754d)"
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/roberthein/TinyConstraints"
  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).

TinyConstraints is a lightweight Swift wrapper that provides syntactic sugar over iOS Auto Layout's NSLayoutConstraint API, reducing boilerplate code by 80-90%. Instead of writing 4+ lines of NSLayoutConstraint calls, you write single-line methods like view.edgesToSuperview() or view.center(in: superview). It's pure Swift 5 with zero runtime overhead—constraints are created identically but expressed more readably. Simple framework structure: TinyConstraints/Classes/ contains three core files—Constrainable.swift (main protocol adding methods to UIView/NSView), Constraints.swift (constraint creation logic), and Abstraction.swift (helper types). Example/ is a standalone Xcode project demonstrating all API patterns. No monorepo complexity; this is a single-purpose library.

iOS/Swift developers building UIKit apps who find Apple's Auto Layout API verbose. Specifically: junior developers learning constraints who get frustrated with NSLayoutConstraint boilerplate, and experienced developers who want to ship layout code faster without dropping down to Storyboards or SwiftUI.

This is a stable, production-ready library. The single-digit pod spec version, comprehensive example app in Example/, and the fact that constraint methods cover all common use cases (edges, center, sizing, stacking) indicate mature design. However, commits appear infrequent—last activity not visible in file structure, suggesting maintenance mode rather than active development. No test suite visible in file list is a minor concern.

Low risk for core functionality: TinyConstraints is a thin DSL layer over Apple's stable NSLayoutConstraint, so it inherits iOS's layout stability. Single-maintainer project (roberthein) with no visible CI/testing infrastructure increases risk of unreviewed changes. The library has no external dependencies (only uses UIKit), eliminating supply-chain risk. Main risk: if the maintainer becomes unavailable, bug fixes may stall.

Activity level is unclear from the file structure alone (no git log visible), but the presence of Swift Package Manager support (Package.swift), CocoaPods (TinyConstraints.podspec), and Carthage (Example/Cartfile) suggests the library was actively maintained through multiple dependency manager eras. Recent updates likely focus on Swift 5 compatibility maintenance rather than feature additions.

Clone and open the example: git clone https://github.com/roberthein/TinyConstraints.git && cd TinyConstraints/Example && open TinyConstraints.xcodeproj. To use in your own project: add to Podfile pod 'TinyConstraints', run pod install, then import TinyConstraints in your view controller.

Daily commands: This is a library, not an executable. To see it in action: cd Example && pod install && open TinyConstraints.xcodeproj, then run the app scheme on a simulator. Example app contains ExampleViewController.swift and demo views (DemoView.swift, GradientView.swift, MetricView.swift) showing all constraint patterns.

• TinyConstraints/Classes/TinyConstraints.swift — Core API entry point defining the main fluent interface for creating Auto Layout constraints with minimal syntax.
• TinyConstraints/Classes/Constrainable.swift — Protocol defining the constraint-building interface that all constrainable objects must implement.
• TinyConstraints/Classes/Constraints.swift — Generic constraint builder handling dimension, position, and relationship constraints with priority and identifier support.
• TinyConstraints/Classes/Abstraction.swift — Abstraction layer providing unified access to layout anchors across UIView, NSView, and other constrainable types.
• TinyConstraints/Classes/Stack.swift — Stack view convenience methods enabling single-line constraint creation for vertically/horizontally stacked views.
• TinyConstraints/Classes/TinyEdgeInsets.swift — Custom inset type supporting negative values for margin manipulation in edge constraint operations.

• TinyConstraints public API (Swift protocol extensions, @discardableResult attributes) — Top-level methods (width, height, edges, etc.) on Constrainable extension; handles method chaining and DSL entry points
  • Failure mode: Constraint conflicts when overconstrained or conflicting anchor combinations used; no compile-time validation
• Constraints<T> builder (Swift generics, NSLayoutConstraint, NSLayoutPriority) — Generic class managing constraint configuration lifecycle: creation → priority setting → identifier assignment → activation
  • Failure mode: Activation failure if view hierarchy invalid or translatesAutoresizingMaskIntoConstraints not disabled
• Abstraction layer (Swift enums, conditional compilation, NSLayoutAnchor subtypes) — LayoutProxy enum abstracting anchor access differences between platforms (iOS, macOS, tvOS) and view types
  • Failure mode: Anchor mismatch crashes if abstraction maps anchor to wrong type (UIView.leadingAnchor vs incompatible anchor type)
• Stack layout helpers (Swift variadic functions, array composition) — vStack/hStack functions composing multiple dimension + position constraints for rapid vertical/horizontal layouts
  • Failure mode: Over-constrained views if spacing + explicit dimension constraints both applied

• Developer code → TinyConstraints API (e.g., view.width(100)) — Fluent method call with dimension constant, relation, and optional priority
• TinyConstraints API → Constraints<NSLayoutDimension> builder — undefined

Add a new dimension constraint method

1. Open TinyConstraints/Classes/TinyConstraints.swift and locate an existing dimension method like width() (TinyConstraints/Classes/TinyConstraints.swift)
2. Add a new @discardableResult method that calls makeConstraint() with the appropriate anchor and returns Constraints<NSLayoutDimension> (TinyConstraints/Classes/TinyConstraints.swift)
3. Ensure the method is added as an extension on Constrainable protocol so it applies to UIView and NSView (TinyConstraints/Classes/TinyConstraints.swift)

Add a new edge constraint variant

1. Open TinyConstraints/Classes/TinyConstraints.swift and find the edgesToSuperview() or edges() method family (TinyConstraints/Classes/TinyConstraints.swift)
2. Create a new method that calls edgesTo() or edgeToSuperview() with a custom TinyEdgeInsets parameter (TinyConstraints/Classes/TinyConstraints.swift)
3. Return an array of Constraints to allow chained priority or identifier customization (TinyConstraints/Classes/TinyConstraints.swift)

Add support for a new platform (e.g., watchOS)

1. Update TinyConstraints/Classes/Abstraction.swift to add the new platform's anchor type handling (TinyConstraints/Classes/Abstraction.swift)
2. Modify TinyConstraints/Classes/Constrainable.swift protocol if platform-specific behavior is needed (TinyConstraints/Classes/Constrainable.swift)
3. Update TinyConstraints.podspec and Package.swift to declare platform support (TinyConstraints.podspec)

Create a new stacking layout helper

1. Open TinyConstraints/Classes/Stack.swift where vStack() and hStack() are defined (TinyConstraints/Classes/Stack.swift)
2. Add a new function taking an array of Constrainable objects and spacing parameter (TinyConstraints/Classes/Stack.swift)
3. Implement the layout logic using existing constraint methods and return an array of active Constraints (TinyConstraints/Classes/Stack.swift)

• Swift 5 & Protocol Extensions — Enables fluent API design through Constrainable protocol extensions without subclassing UIView/NSView, maintaining full Auto Layout compatibility
• Generic Constraints<T> class — Type-safe constraint builder supporting NSLayoutDimension, NSLayoutXAxisAnchor, NSLayoutYAxisAnchor without code duplication
• CocoaPods + SPM dual support — Maximizes adoption across iOS/macOS projects using either package manager; zero external dependencies ensure library simplicity

• Constraints active by default (no explicit activate() call)

  • Why: Reduces boilerplate and matches user expectations; easier API
  • Consequence: Developers must explicitly deactivate if they need deferred activation, adding complexity for advanced use cases

• Automatic translatesAutoresizingMaskIntoConstraints = false

  • Why: Prevents common runtime errors and reduces mistake surface area
  • Consequence: May interfere if developer intentionally wants mask-based + constraint-based layout mixing

• TinyEdgeInsets with signed CGFloat instead of CGEdgeInsets

  • Why: Supports negative insets for outward margins/padding, more expressive
  • Consequence: Breaks symmetry with UIKit's unsigned inset types; potential for misuse with negative values

• Does not provide visual layout debugging or constraint violation diagnostics
• Does not support animation or dynamic constraint updates beyond native Auto Layout
• Does not handle view controller lifecycle or safe area constraints beyond standard anchor support
• Not a layout engine replacement; purely syntactic sugar over native NSLayoutConstraint

No surprises in this simple library. One minor gotcha: translatesAutoresizingMaskIntoConstraints is automatically set to false by TinyConstraints, so if you mix TinyConstraints calls with manual NSLayoutConstraint code, ensure you're not setting it back to true. The library supports both UIView (iOS/tvOS) and NSView (macOS) via protocol extension, but platform differences aren't documented in the README.

• Protocol-Oriented Programming (POP) with Extensions — TinyConstraints uses a Constrainable protocol extended onto UIView/NSView—understanding how Swift extensions on protocols let you add methods without subclassing is key to grasping this codebase's elegance
• Operator Overloading (DSL Design) — The EdgeInsets syntax .top(10) + .left(10) works via overloaded + operator in Abstraction.swift; understanding operator overloading helps you extend the DSL or debug unexpected binding behavior
• NSLayoutAnchor API (Modern Auto Layout) — TinyConstraints wraps NSLayoutAnchor (topAnchor, leadingAnchor, etc.) introduced in iOS 9; knowing the anchor hierarchy (LayoutAnchor → XAxisAnchor/YAxisAnchor) explains why some constraint types are grouped together
• Typealiases for API Clarity — TinyConstraints defines Constraint = NSLayoutConstraint and Constraints = [NSLayoutConstraint] for shorter return types; this pattern reduces visual clutter while maintaining type safety
• Auto Layout Priorities and Relations — The library exposes NSLayoutConstraint.Relation (.equal, .lessThanOrEqual, .greaterThanOrEqual) and UILayoutPriority (.required, .high, .low); understanding priority systems prevents layout conflicts
• View Hierarchy and Superview Constraints — Methods like edgesToSuperview() only work when a view has a superview; understanding UIView hierarchy and why translatesAutoresizingMaskIntoConstraints matters is critical for debugging layout issues

• SnapKit/SnapKit — Similar DSL-based constraint library (more feature-rich, actively maintained); TinyConstraints is the lightweight alternative
• PureLayout/PureLayout — Older Objective-C-based Auto Layout wrapper; TinyConstraints is its Swift successor with simpler API
• realm/realm-swift — Different library, but also a single-purpose Swift framework maintained by a core team; example of stable, dependency-free iOS SDK design
• apple/swift-algorithms — Official Swift standard library companion; demonstrates protocol-oriented API design pattern used by TinyConstraints' Constrainable protocol

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 TinyConstraints core API

The repo has no visible test files despite being a mature library with complex constraint logic. TinyConstraints.swift, Constraints.swift, and Stack.swift contain core functionality that needs validation across different constraint scenarios (edges, dimensions, stacking, priorities). This is critical for a layout library where regressions affect UI across dependent projects.

• [ ] Create Tests directory with XCTest targets matching TinyConstraints.xcodeproj
• [ ] Add unit tests for TinyConstraints.swift methods (center, edges, size constraints with various configurations)
• [ ] Add unit tests for Constraints.swift to verify constraint activation, priorities, and constant modifications
• [ ] Add unit tests for Stack.swift to verify horizontal/vertical stacking with spacing and distribution
• [ ] Add unit tests for TinyEdgeInsets.swift edge case handling
• [ ] Integrate test execution into build scheme (TinyConstraints.xcscheme)

Add GitHub Actions CI workflow for Swift package validation

The repo supports multiple package managers (CocoaPods, Carthage, SPM via Package.swift) but has no visible CI/CD pipeline. There's no mechanism to validate that changes work across iOS versions or that the Swift Package Manager configuration remains valid. This risks breaking dependent projects.

• [ ] Create .github/workflows/ci.yml with matrix testing for iOS 12+ (minimum supported version should be verified in podspec)
• [ ] Add Swift build verification step: swift build
• [ ] Add CocoaPods validation: pod lib lint TinyConstraints.podspec
• [ ] Add unit test execution for the XCTest targets created above
• [ ] Configure workflow to run on: pull_request, push to main branches

Document API usage for TinyConstraints+superview.swift with code examples

The README shows basic examples but doesn't demonstrate the superview-specific constraints (TinyConstraints+superview.swift file exists but no docs). The library advertises 'Constrain directly to the superview' as a feature, but concrete usage examples are missing. This creates friction for new users trying to use a key selling point.

• [ ] Add 'Superview Constraints' section to README.md with before/after comparison
• [ ] Document convenience methods from TinyConstraints+superview.swift with code samples (e.g., edges(to:), width/height relative to superview)
• [ ] Add section for TinyEdgeInsets usage with examples for inset-based constraints
• [ ] Include example for setting constraint priorities during superview attachment
• [ ] Reference Example/TinyConstraints/Sources code (e.g., DemoView.swift, MetricView.swift) as real-world usage patterns

• Add unit tests for Constraints.swift: The library has no test suite visible. Add XCTest cases to verify that view.width(100) produces an NSLayoutConstraint with the correct attribute, constant, and relation. Start in TinyConstraints.xcodeproj by creating a TinyConstraintsTests target.
• Document the DSL syntax for EdgeInsets: The Abstraction.swift file defines operator overloads like .top(10) + .left(10), but the README only shows .edgesToSuperview(insets: .top(10) + .left(10)) as an example. Add a section to README.md showing all EdgeInsets combinations and why they're useful (e.g., .all(8), .vertical(10)).
• Add examples for constraint priorities and relations: Example/TinyConstraints/Sources/ shows basic usage but ExampleViewController.swift lacks demonstrations of priority: .high and relation: .equalOrLess parameters. Add a demo view (e.g., PriorityDemoView.swift) showing competing constraints with different priorities to illustrate real layout conflicts.

TinyConstraints is a Swift library for Auto Layout constraints with minimal security surface. No critical vulnerabilities detected. The codebase is a UI framework with no network, database, or authentication components. Minor recommendations focus on dependency management and code signing practices.

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.