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/freshOS/Stevia 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

• Last commit 8mo ago
• 11 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 8mo ago
• ⚠ Single-maintainer risk — top contributor 84% 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 freshOS/Stevia repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/freshOS/Stevia.

What it runs against: a local clone of freshOS/Stevia — 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 freshOS/Stevia | 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 | Last commit ≤ 261 days ago | Catches sudden abandonment since generation |

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

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

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

Stevia is a Swift library that replaces verbose NSLayoutConstraint code with a concise, chainable, equation-based syntax for iOS/tvOS autolayout. It generates native NSLayoutConstraints while offering three APIs—visual layout blocks, method chaining, and equation-based expressions—making constraint definition 10-50x more readable. Modular extension-based architecture: Sources/Stevia/ contains ~20 files, each focusing on one constraint category (Stevia+Alignment.swift, Stevia+Size.swift, Stevia+Position.swift, Stevia+Stacks.swift, etc.). LoginExample/ provides a complete working demo comparing native vs. Stevia approaches. Tests/ validate core behavior via BaselineTests.swift and others.

iOS/tvOS developers who write programmatic UI layouts and want to eliminate NSLayoutConstraint boilerplate. Specifically appeals to teams building complex layouts where autolayout readability directly impacts iteration speed and maintenance burden.

Production-ready and actively maintained. The project has comprehensive CI (Swift workflow badge, Bitrise integration), Swift 6 support, supports iOS 8+, won a Hacking with Swift Recommended award, and shows active GitHub contributors. The presence of LoginExample demo and test suite (SteviaTests/) indicates stability.

Low risk for a mature layout library. Single primary maintainer (s4cha), but the codebase is focused and self-contained with minimal external dependencies visible in Package.swift. No obvious breaking changes in CHANGELOG.md pattern. Main risk: iOS constraint API changes could require updates, but that's endemic to autolayout libraries.

Library is in maintenance mode with Swift 6 support confirmed and privacy manifest (PrivacyInfo.xcprivacy) recently added. SwiftLint configuration present (.swiftlint.yml) indicates ongoing code quality focus. No indication of major feature development, but the API is stable and complete.

git clone https://github.com/freshOS/Stevia.git
cd Stevia
swift package resolve
# For Xcode workspace:
open .swiftpm/xcode/package.xcworkspace
# Or run example:
open LoginExample/LoginStevia.xcodeproj

Daily commands: Open .swiftpm/xcode/package.xcworkspace in Xcode to develop the library. For the demo app: open LoginExample/LoginStevia.xcodeproj and run on iOS simulator. Swift workflows in .github/workflows/swift.yml handle automated testing on each commit.

• Sources/Stevia/Stevia+Operators.swift: Implements the equation syntax (==, >=, <=) that makes the equation-based API possible—core innovation of this library
• Sources/Stevia/Stevia+Constraints.swift: Foundation for all constraint generation; contains the core UIView extension methods that activate/deactivate constraints
• Sources/Stevia/Stevia+Hierarchy.swift: Manages view hierarchy and autolayout enabling—required before any constraints can be added
• Sources/Stevia/Stevia+Stacks.swift: Provides stack-based layout composition (horizontal/vertical stacks), a higher-level abstraction over individual constraints
• LoginExample/LoginStevia/LoginViewStevia.swift: Real-world demo showing Stevia syntax vs. native autolayout in LoginViewNative.swift—essential for understanding practical usage
• Package.swift: SPM manifest defining the library's public API surface and Swift version requirements

Start in Sources/Stevia/ where each file is a logical feature set. To add a new constraint type: create Stevia+YourFeature.swift extending UIView or NSLayoutAnchor with a chainable method. The pattern is consistent across all 20 files. Add unit tests in Tests/SteviaTests/ following BaselineTests.swift structure.

No exotic gotchas, but worth noting: (1) translatesAutoresizingMaskIntoConstraints must be set to false—Stevia doesn't do this automatically; use .fill() or explicit constraint methods. (2) The equation syntax creates temporary constraint objects; priority/identifier must be set before the constraint is fully defined. (3) View must be added to hierarchy before constraints are applied; Stevia+Hierarchy.swift handles this but it's easy to forget.

• Fluent/Chainable API — Stevia's entire value proposition depends on chaining constraint calls; understanding fluent interfaces is essential to reading and writing Stevia code idiomatically
• Operator Overloading (Swift Custom Operators) — The equation-based syntax (==, >=, <=) is implemented via custom operator definitions; this is non-trivial Swift and appears throughout Stevia+Operators.swift
• NSLayoutConstraint and Layout Anchors — Stevia is an abstraction layer over Apple's native constraint system; understanding how NSLayoutConstraint, NSLayoutAnchor, and layout priorities work is required to debug or extend Stevia
• Protocol-Oriented Programming (Extensions) — Stevia's architecture is built entirely on Swift extensions—UIView, NSLayoutAnchor, and other core types are extended with constraint methods; this pattern is foundational to the codebase
• View Hierarchy & autoenablesSubviewAutoresizing — Managing view hierarchy order and constraint activation timing is subtle; Stevia+Hierarchy.swift and the .fill() method handle this, but incorrect hierarchy is the #1 runtime bug
• Constraint Priorities & Ambiguity Resolution — Stevia allows setting constraint priorities (via UILayoutPriority); understanding priority resolution is crucial for complex layouts that need flexible vs. rigid constraints
• DSL Design (Domain-Specific Language) — Stevia is a DSL for autolayout; understanding the visual-block syntax, chainable methods, and equation operators as a cohesive language design helps recognize Stevia's scope and limitations

• SnapKit/SnapKit — Industry-standard DSL for autolayout that inspired Stevia; SnapKit uses method chaining while Stevia adds equation-based syntax as an alternative
• freshOS/motion — Sibling library in the freshOS toolkit; provides animation/transition DSLs that integrate with Stevia-laid-out views
• Oleg-E-Bakharev/Anchor — Competing equation-based autolayout library; more algebraic approach vs. Stevia's visual-block and chainable hybrids
• freshOS/Then — Companion library from freshOS for object initialization; often used alongside Stevia for clean view setup code
• Alamofire/Alamofire — Not layout-related, but freshOS projects often pair Stevia UI with Alamofire networking; ecosystem familiarity helpful

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 tests for Stevia+Operators.swift and Stevia+DoubleDash.swift

The test suite has comprehensive coverage for alignment, positioning, and sizing, but there are no dedicated test files for the operator overloading features (Stevia+Operators.swift) and the double-dash syntax (Stevia+DoubleDash.swift). These are core DSL features that deserve explicit test coverage to prevent regressions and document expected behavior.

• [ ] Create Tests/SteviaTests/OperatorsTests.swift to test custom operator behavior for constraint definitions
• [ ] Create Tests/SteviaTests/DoubleDashTests.swift to test the -- syntax for constraint chaining
• [ ] Add tests verifying operator precedence and constraint equality
• [ ] Add tests for edge cases like chaining multiple operators and conflicting constraints

Add unit tests for Stevia+GetConstraint.swift functionality

The GetConstraintsTests.swift file exists but appears minimal. The Stevia+GetConstraint.swift module provides critical functionality for retrieving and managing existing constraints, but this feature lacks comprehensive test coverage for retrieval methods, filtering, and constraint modification scenarios.

• [ ] Expand Tests/SteviaTests/GetConstraintsTests.swift with tests for retrieving constraints by type (width, height, leading, trailing, etc.)
• [ ] Add tests for querying constraints on specific views and their relationships
• [ ] Add tests for constraint removal and replacement scenarios
• [ ] Test edge cases like views with no constraints and constraint conflicts

Add integration tests for Stevia+Stacks.swift with layout verification

While individual layout features have tests, there's no dedicated test file for Stevia+Stacks.swift, which provides stack-based layout functionality. This is a high-value feature that needs verification for proper spacing, distribution, and frame calculations across different view hierarchies.

• [ ] Create Tests/SteviaTests/StacksTests.swift with tests for horizontal and vertical stack layouts
• [ ] Add tests verifying proper spacing between stacked views and margin calculations
• [ ] Add tests for nested stacks and mixed constraint scenarios with stacks
• [ ] Test edge cases like empty stacks, single-view stacks, and dynamic content changes

• Add comprehensive tests for Stevia+Percentage.swift—only BaselineTests.swift exists and percentage-based sizing is a powerful feature that lacks coverage.
• Expand LoginExample to show all three APIs (visual, chainable, equation) side-by-side with clear before/after comparisons and performance notes.
• Document the relationship between UIView extensions and NSLayoutAnchor extensions in code comments—new contributors confuse which API to use for different constraint types.

The Stevia codebase demonstrates good security posture. As a lightweight Swift UI framework, it has minimal attack surface. No hardcoded credentials, SQL injection risks, or infrastructure vulnerabilities were identified. Recommendations focus on dependency management verification and ensuring example code remains credential-free. The codebase follows good practices with CI/CD workflows, code organization, and proper documentation.

• Low · Missing Package.resolved Lockfile Details — Package.resolved. The Package.resolved file is present but its contents were not provided for analysis. This file should be reviewed to ensure all dependencies are pinned to specific versions and that no vulnerable versions are in use. Fix: Verify all dependencies in Package.resolved are up-to-date and free from known vulnerabilities. Use swift package update cautiously and review changes.
• Low · Swift Lint Configuration Present — .swiftlint.yml. The .swiftlint.yml file is present but its contents were not provided. Code style enforcement is good practice, but security-specific linting rules should be configured. Fix: Ensure .swiftlint.yml includes rules to detect common Swift security issues (e.g., force unwrapping, hardcoded credentials patterns).
• Low · Example Application Credentials Risk — LoginExample/LoginStevia/. The LoginExample directory contains a demo application. While demo code typically doesn't require strict security, ensure no real credentials or API keys are committed in example code. Fix: Audit LoginExample for any hardcoded credentials, API keys, or sensitive data. Use environment variables or configuration files for any sensitive values.

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.