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/EhPanda-Team/EhPanda 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 the board

• Last commit 5w ago
• 6 active contributors
• Distributed ownership (top contributor 45% of recent commits)
• MIT licensed
• CI configured
• Tests present

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

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "EhPanda-Team/EhPanda(\\.git)?\\b" \\
  && ok "origin remote is EhPanda-Team/EhPanda" \\
  || miss "origin remote is not EhPanda-Team/EhPanda (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "EhPanda/App/EhPandaApp.swift" \\
  && ok "EhPanda/App/EhPandaApp.swift" \\
  || miss "missing critical file: EhPanda/App/EhPandaApp.swift"
test -f "EhPanda.xcodeproj/project.pbxproj" \\
  && ok "EhPanda.xcodeproj/project.pbxproj" \\
  || miss "missing critical file: EhPanda.xcodeproj/project.pbxproj"
test -f ".swiftlint.yml" \\
  && ok ".swiftlint.yml" \\
  || miss "missing critical file: .swiftlint.yml"
test -f ".github/workflows/deploy.yml" \\
  && ok ".github/workflows/deploy.yml" \\
  || miss "missing critical file: .github/workflows/deploy.yml"
test -f "EhPanda/App/Assets.xcassets/Category/Colors" \\
  && ok "EhPanda/App/Assets.xcassets/Category/Colors" \\
  || miss "missing critical file: EhPanda/App/Assets.xcassets/Category/Colors"

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

EhPanda is an unofficial iOS app for browsing E-Hentai galleries, built entirely in SwiftUI with The Composable Architecture (TCA) state management. It provides a native mobile experience to the E-Hentai platform with search, filtering, gallery viewing, and history tracking capabilities. Standard iOS Xcode project structure (EhPanda.xcodeproj/) using SwiftUI for UI and TCA for unidirectional state management. Assets organized in EhPanda/App/Assets.xcassets with localization bundles for each supported language (.lproj directories). Likely domain-driven features split across TCA Stores with View and Reducer separation per TCA conventions, though specific feature folders not visible in top 60 files.

iOS developers learning TCA and SwiftUI best practices, E-Hentai community members seeking a native iOS client, and contributors interested in building production-grade Swift apps with advanced state management patterns.

Actively maintained with established CI/CD pipelines (GitHub Actions for testing, pre-release, and deployment workflows visible in .github/workflows/), published releases available on the project website (ehpanda.app), and support for iOS 16.0+. The project has multilingual support (6+ languages) and professional distribution infrastructure (AltStore.json config), indicating production-ready status with ongoing development.

Single-language ecosystem (Swift-only, 1.18M lines) means dependency on Apple's ecosystem stability; no visible Package.resolved details in the provided structure limits visibility into dependency health. The app directly integrates with E-Hentai's undocumented API (unofficial nature), risking breakage if E-Hentai changes backend. No explicit test coverage files mentioned in the top 60 structure is a concern for maintenance.

Project maintains active GitHub Actions workflows for CI (test.yml), automated dependency updates (dependencies.yml), and versioned deployments (deploy.yml for releases and deploy-pre-release.yml for preview builds). SwiftLint configuration present (.swiftlint.yml) indicates code quality tooling is enforced, and multilingual translation contributions are actively solicited in the README.

Clone the repository: git clone https://github.com/EhPanda-Team/EhPanda.git && cd EhPanda. Open the project: open EhPanda.xcodeproj. Build via Xcode (iOS 16.0+ required) or use xcodebuild from CLI: xcodebuild build -scheme EhPanda -configuration Debug. Distribute via AltStore.json or TestFlight for testing.

Daily commands: Build and run from Xcode (Product > Scheme: EhPanda > Run), or command line: xcodebuild build-for-testing -scheme EhPanda && xcodebuild test-without-building -scheme EhPanda. Simulator or physical device (iOS 16.0+) required.

• EhPanda/App/EhPandaApp.swift — App entry point and root TCA store initialization; every contributor must understand the app lifecycle and store structure
• EhPanda.xcodeproj/project.pbxproj — Xcode project configuration defining all build targets, dependencies, and resource bundles; required for build consistency
• .swiftlint.yml — SwiftLint configuration enforcing code style standards across the codebase; must be observed in all pull requests
• .github/workflows/deploy.yml — Production release workflow and CI/CD pipeline; defines the official build and distribution process
• EhPanda/App/Assets.xcassets/Category/Colors — Category color definitions for E-Hentai and ExHentai content types; central design system asset used throughout UI

Add a new content category color scheme

1. Create a new colorset directory under Assets.xcassets/Category/Colors/{Platform}/ (e.g., E-Hentai or ExHentai) (EhPanda/App/Assets.xcassets/Category/Colors/E-Hentai/)
2. Add Contents.json with color definitions for light and dark appearances (EhPanda/App/Assets.xcassets/Category/Colors/E-Hentai/Doujinshi.colorset/Contents.json)
3. Reference the new color in UI views via SwiftUI color literals or asset catalog lookups (EhPanda/App/Assets.xcassets/Category/Colors)

Modify the app's build configuration or dependencies

1. Edit the main Xcode project to add or update build settings and target dependencies (EhPanda.xcodeproj/project.pbxproj)
2. Update Swift Package Manager resolved dependencies to lock new versions (EhPanda.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved)
3. Verify the build scheme includes the new configuration and run tests via the CI/CD workflow (.github/workflows/test.yml)

Enforce new code style rules across the codebase

1. Update SwiftLint configuration with new rule definitions or thresholds (.swiftlint.yml)
2. Run SwiftLint locally to validate all files comply with the new rules (EhPanda/App)
3. Commit and push; CI/CD will automatically check all pull requests against the updated rules (.github/workflows/test.yml)

Configure a new release pipeline (stable, beta, or AltStore)

1. Define a new or edit an existing GitHub Actions workflow for your release channel (.github/workflows/deploy.yml)
2. For AltStore sideload distribution, update the JSON manifest (AltStore.json)
3. Ensure the workflow is triggered on the correct branch or tag and publishes to the intended platform (.github/workflows)

• SwiftUI — Modern, declarative iOS UI framework providing native performance, state binding, and iOS 16+ feature access
• The Composable Architecture (TCA) — Scalable, testable state management with composable reducers, effects, and side-effect isolation; reduces view logic complexity
• Swift Package Manager — Native dependency management integrated into Xcode; enables reproducible builds and version locking
• GitHub Actions — Native CI/CD for iOS builds, automated testing, and release distribution without external service dependencies
• HTML Parsing (via Network client) — E-Hentai does not expose a public API; HTML scraping is the only method to fetch gallery metadata and images

• HTML scraping instead of official API

  • Why: E-Hentai/ExHentai do not provide a public API; scraping is the only viable data source
  • Consequence: App is fragile to site HTML structure changes; requires maintenance if the site layout updates

• Unofficial app status

  • Why: No partnership with E-Hentai; enables rapid feature development and user control without legal constraints
  • Consequence: Cannot be distributed on the official iOS App Store; requires sideloading via AltStore or similar

• SwiftUI-only UI (iOS 16+)

  • Why: Simplifies codebase and leverages modern SwiftUI APIs; reduces legacy code and improves maintainability
  • Consequence: Minimum iOS/iPadOS requirement is 16.0; older devices are not supported

• TCA for all state management

  • Why: Enforces unidirectional data flow and testability; scales well as feature count grows
  • Consequence: Steeper learning curve for new contributors unfamiliar with TCA; more boilerplate than simpler alternatives

• Does not support iOS versions below 16.0
• Does not distribute via Apple App Store (sideload-only)
• Does not provide an official public API or SDK
• Does not implement user authentication beyond E-Hentai session cookies
• Does not support offline reading (requires live network connection to E-Hentai servers)
• Does not implement DRM or content protection beyond platform security

E-Hentai API is undocumented and unofficial—network endpoints and response formats are reverse-engineered and may break without warning. iOS 16.0+ minimum requirement is strict (no fallback for older iOS); verify target deployment version in build settings. Multilingual support requires updating 6+ .lproj directories in sync when adding UI strings, or translations will be incomplete. AltStore distribution requires user device management and signing configuration outside standard App Store review process. No visible keychain or sensitive credential storage strategy in top 60 files—verify secure storage for authentication tokens if E-Hentai login is implemented.

• The Composable Architecture (TCA) — TCA is the architectural foundation of this entire app—understanding State, Action, Reducer, and Effect is mandatory for contributing to any feature
• Unidirectional Data Flow — TCA enforces strict unidirectional data flow (View → Action → Reducer → State); essential for predicting how state changes propagate and for debugging side effects
• SwiftUI @State, @StateObject, and Property Wrappers — SwiftUI's reactive property system manages UI binding to TCA State; understanding reactivity is critical for building responsive views without manual refresh logic
• GitHub Actions CI/CD Workflows — EhPanda automates testing, building, and releasing via workflows in .github/workflows/; understanding YAML pipeline syntax is essential for maintaining or extending CI
• Swift Package Manager (SPM) — Dependencies are managed via SPM (visible in Package.resolved); understanding how SPM resolves versions and locks dependencies prevents integration issues
• iOS Localization (.lproj bundles) — EhPanda supports 6+ languages via .lproj directories; understanding how iOS loads localized strings and assets is required for multilingual feature work
• Reverse-Engineering Undocumented APIs — The E-Hentai API is unofficial and undocumented; contributors must infer endpoint behavior from network logs and handle breaking changes gracefully

• pointfreeco/swift-composable-architecture — The canonical TCA library this entire project is built upon; essential for understanding state management patterns used throughout EhPanda
• realm/realm-swift — Likely persistence layer for caching gallery metadata and history if used in EhPanda; a common iOS persistence pattern alongside TCA
• Alamofire/Alamofire — Popular Swift networking library frequently paired with TCA apps for simplified HTTP requests; potential dependency for E-Hentai API calls
• SwiftGen/SwiftGen — Code generation tool for Assets.xcassets and localization strings (.lproj); common companion tool for managing the large asset set visible in EhPanda
• realm/realm-studio — Database inspection tool for debugging Realm-based persistence if EhPanda uses Realm for caching; useful for contributors troubleshooting data issues

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 TCA reducers and effects

The repo uses TCA (The Composable Architecture) but there's no visible test.yml workflow content or test files in the structure. With a SwiftUI+TCA architecture handling E-Hentai data fetching, authentication, and gallery management, reducer logic and async effects need coverage. This is critical for an unofficial API client to catch regressions.

• [ ] Create Tests/ directory structure mirroring EhPanda/ for test targets
• [ ] Add unit tests for core reducers (likely in EhPanda/App) covering state mutations and effects
• [ ] Implement TestStore assertions for async network effects (gallery loading, authentication)
• [ ] Update .github/workflows/test.yml to run Swift tests with code coverage thresholds
• [ ] Document test patterns in CONTRIBUTING.md for new contributors

Implement SwiftLint rule enforcement in CI with comment feedback

The repo has .swiftlint.yml configuration but no GitHub Action to enforce it on PRs with inline comments. This is especially important for a community project to maintain code quality consistency. The config exists but isn't being validated automatically.

• [ ] Create .github/workflows/swiftlint.yml that runs on pull_request events
• [ ] Use norio-nomura/action-swiftlint to analyze changes and post inline comments
• [ ] Configure to fail CI if violations exceed severity threshold (from .swiftlint.yml)
• [ ] Add SwiftLint setup instructions to CONTRIBUTING.md
• [ ] Reference the workflow in any contributor guidelines

Add localization testing and validation workflow for translations

The README explicitly requests translations and mentions App Strings in [{lang}.lproj], but there's no CI workflow to validate that translation files are complete and properly formatted. Missing translation keys between locales causes runtime crashes or untranslated UI text.

• [ ] Create .github/workflows/localization.yml that validates .lproj directories
• [ ] Add a Swift script (Scripts/validate_localization.swift) to check all Localizable.strings files have matching keys across all language variants
• [ ] Detect missing or deprecated translation keys and report them as CI failures
• [ ] Ensure consistency in translation file format (proper escaping, line endings)
• [ ] Document the localization structure and validation process in CONTRIBUTING.md

• Add unit tests for TCA Reducers (no test files visible in top 60): Create Tests/ directory and add XCTest targets for State/Action/Reducer logic, ensuring each feature's state mutations are covered. Start with a simple feature Reducer with 2-3 test cases.
• Improve code documentation: Add doc comments to public TCA Stores and Views following Apple's markup style. Start with EhPanda/App main entry points visible in the structure, then expand to feature modules. This aids contributors unfamiliar with TCA patterns.
• Expand SwiftLint rules in .swiftlint.yml: Review current configuration and add stricter rules for code style (e.g., force_unwrap, todo, complexity thresholds) documented in SwiftLint docs. This prevents common pitfalls and unifies team standards.

EhPanda is an unofficial E-Hentai iOS client with moderate security concerns. Primary risks include: (1) Lack of complete dependency analysis for Swift packages, (2) Potential sensitive data in AltStore configuration, (3) Limited visibility into CI/CD security practices, and (4) Inability to perform full source code analysis. The project demonstrates good security hygiene with SwiftLint configuration and GitHub Actions workflow setup, but security implementation details cannot be verified from the provided file structure alone. The unofficial nature of the application presents inherent risks related to API stability and terms of service compliance. Recommend implementing automated security scanning, secrets detection in CI/CD, and comprehensive code review processes before production use.

• Medium · Unofficial Third-Party Application — Repository root - README.md, App configuration. EhPanda is an unofficial client for E-Hentai. Unofficial applications may lack proper security audits, API stability guarantees, and may violate terms of service. This increases risks of account compromise, data exposure, or service disruption. Fix: Implement robust error handling for API changes, use official APIs where available, maintain transparent security practices, and regularly audit dependencies. Consider obtaining explicit permission from E-Hentai operators.
• Medium · Incomplete Dependency Analysis — EhPanda.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved. The Package.resolved file is referenced but not provided for analysis. Swift Package Manager dependencies cannot be fully audited. Transitive dependencies may contain known vulnerabilities. Fix: Run 'swift package diagnose' and use tools like SwiftSec or Snyk to audit all direct and transitive dependencies. Implement automated dependency scanning in CI/CD pipeline (as referenced in .github/workflows).
• Medium · Potential Sensitive Data in AltStore Configuration — AltStore.json (repository root). AltStore.json file is present in the repository root. This file may contain sensitive configuration, signing certificates, or API keys if not properly managed. Fix: Verify AltStore.json does not contain secrets or credentials. Add to .gitignore if it contains sensitive data. Use environment variables or secure configuration management for deployment credentials.
• Low · Code Quality Tool Configuration — .swiftlint.yml. .swiftlint.yml is configured but cannot be fully analyzed without the complete file content. SwiftLint rules may not be sufficiently strict for security-focused linting. Fix: Enable security-focused SwiftLint rules: force_try, force_cast, force_unwrap. Add custom rules for hardcoded URLs, API keys, and sensitive data patterns.
• Low · GitHub Workflows Not Fully Analyzed — .github/workflows/deploy.yml, deploy-pre-release.yml, test.yml, dependencies.yml. CI/CD workflows exist (.github/workflows) but content was not provided for analysis. Workflows may lack security scanning, SBOM generation, or artifact signing. Fix: Implement security checks in CI/CD: SAST scanning, dependency vulnerability scanning, code signing verification, and automated release notes. Review secrets management in workflow files.
• Low · Missing CODEOWNERS Security Policy — .github/CODEOWNERS. CODEOWNERS file exists but content is not visible. Code review process for security-critical components cannot be verified. Fix: Ensure CODEOWNERS includes security reviewers for critical components (networking, authentication, data persistence). Require code review before merging security-related changes.
• Low · Incomplete Source Code Analysis — EhPanda/App/ (all Swift files). Source code in EhPanda/App directory structure is visible but file contents not provided. Actual vulnerability patterns (SQLi, XSS, insecure storage, hardcoded credentials) cannot be detected. Fix: Perform source code review focused on: API endpoint validation, network security (TLS pinning), local data encryption, authentication token handling, and WebView usage.

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.