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/zixun/GodEye 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.

AVOID — Looks unmaintained — solo project with stale commits

• MIT licensed
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ No CI workflows 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 zixun/GodEye repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/zixun/GodEye.

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

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "zixun/GodEye(\\.git)?\\b" \\
  && ok "origin remote is zixun/GodEye" \\
  || miss "origin remote is not zixun/GodEye (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 "Core/SystemEye/Classes/System.swift" \\
  && ok "Core/SystemEye/Classes/System.swift" \\
  || miss "missing critical file: Core/SystemEye/Classes/System.swift"
test -f "Core/LeakEye/Classes/LeakEye.swift" \\
  && ok "Core/LeakEye/Classes/LeakEye.swift" \\
  || miss "missing critical file: Core/LeakEye/Classes/LeakEye.swift"
test -f "Core/NetworkEye/Classes/NetworkEye.swift" \\
  && ok "Core/NetworkEye/Classes/NetworkEye.swift" \\
  || miss "missing critical file: Core/NetworkEye/Classes/NetworkEye.swift"
test -f "Core/CrashEye/Classes/CrashEye.swift" \\
  && ok "Core/CrashEye/Classes/CrashEye.swift" \\
  || miss "missing critical file: Core/CrashEye/Classes/CrashEye.swift"
test -f "Core/ANREye/Classes/ANREye.swift" \\
  && ok "Core/ANREye/Classes/ANREye.swift" \\
  || miss "missing critical file: Core/ANREye/Classes/ANREye.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 625 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~595d)"
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/zixun/GodEye"
  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).

GodEye is a comprehensive runtime monitoring framework for iOS apps that automatically captures and displays Logs, Crashes, Network traffic, ANR (Application Not Responding) events, Memory leaks, CPU/RAM usage, FPS, and file system activity through a single line of Swift code. It injects non-invasive monitoring probes into a running app without requiring code modifications, functioning as an in-app debugging dashboard similar to tools like Flipper. Modular monorepo: Core/ directory contains 10 independent monitoring modules (ANREye, CrashEye, LeakEye, NetworkEye, etc.), each with its own Classes/ folder, .h headers, and Info.plist. Core/AppBaseKit provides shared utilities (AppSwizzle.swift, UIKit extensions, file management). Each monitor is designed as a standalone pod that can be integrated selectively.

iOS developers and QA engineers who need real-time runtime diagnostics during development and testing. Specifically engineers building production apps who want to detect memory leaks (LeakEye), ANR hangs (ANREye), crashes (CrashEye), and network issues (NetworkEye) without adding debug logging throughout their codebase.

Actively maintained but niche: the project shows substantial code (~297KB Swift + 25KB Objective-C) and includes 10+ specialized monitoring modules, indicating maturity. However, no visible CI/CD badges or test suite in the file listing, and the README references a Chinese-language book, suggesting the project is primarily community-driven with limited enterprise adoption metrics.

Medium risk: single-language dependency (Swift 4+ required), heavy use of method swizzling (Core/AppBaseKit/Classes/Util/AppSwizzle.swift) which is fragile across iOS versions, and the architecture relies on runtime introspection that Apple discourages. No visible automated testing infrastructure means breakage from iOS SDK updates could go undetected. Last activity status unclear from file listing.

Unable to determine from file listing alone — no visible .git history, CI config, or issue tracker provided. The modular structure suggests ongoing active maintenance of individual modules, but without commit timestamps or PR data, current development status is unclear.

Clone: git clone https://github.com/zixun/GodEye.git. Install: cd GodEye && pod repo update && pod install (standard CocoaPods setup). Integration: add pod 'GodEye' to Podfile or selective pods like pod 'GodEye/ANREye'. Verify: open the generated .xcworkspace in Xcode and run on an iOS 10+ simulator/device.

Daily commands: Development: open GodEye.xcworkspace (post-CocoaPods install), select Example target, build & run on iOS 10+ device. One-line activation in AppDelegate: GodEye.start() (inferred from library purpose). The framework auto-instruments the app on launch — no additional setup needed.

• Core/SystemEye/Classes/System.swift — Main orchestrator for system-level monitoring (CPU, RAM, FPS, Network); entry point for all SystemEye metrics collection.
• Core/LeakEye/Classes/LeakEye.swift — Memory leak detection engine using NSObject runtime swizzling; critical for tracking object lifecycle and detecting dangling references.
• Core/NetworkEye/Classes/NetworkEye.swift — Network monitoring interceptor that hooks URLSession; required to understand how HTTP traffic is captured and logged.
• Core/CrashEye/Classes/CrashEye.swift — Crash handler and exception catcher; foundational for the crash reporting pipeline.
• Core/ANREye/Classes/ANREye.swift — ANR (Application Not Responding) detector using RunLoop monitoring; essential for understanding event loop blockage detection.
• Core/AppBaseKit/Classes/Util/AppSwizzle.swift — Swift wrapper around method swizzling; used across multiple Eyes (Leak, Network, etc.) as a foundational technique.
• Example/GodEye/ViewController.swift — Example integration showing how to initialize all Eyes with one-liner; demonstrates the public API contract.

Add a New System Metric (e.g., Battery Level, Disk I/O)

1. Create a new Swift class in Core/SystemEye/Classes/ following the pattern of CPU.swift or Memory.swift, implementing metric collection from system APIs (Core/SystemEye/Classes/YourMetric.swift)
2. Add a computed property or method to Core/SystemEye/Classes/System.swift that instantiates and queries your metric class (Core/SystemEye/Classes/System.swift)
3. If needed, add a corresponding model or extension in AppBaseKit for UI formatting (e.g., AppBaseKit/Extension/Foundation/String+AppBaseKit.swift) (Core/AppBaseKit/Classes/Extension/Foundation/String+AppBaseKit.swift)

Create a New Eye (e.g., ThermalEye for device temperature monitoring)

1. Create a new directory Core/ThermalEye/Classes/ and implement ThermalEye.swift following the pattern of ANREye.swift or CrashEye.swift with start() and stop() lifecycle methods (Core/ThermalEye/Classes/ThermalEye.swift)
2. Use Core/AppBaseKit/Classes/Util/AppSwizzle.swift or direct API hooking (referencing LeakEye/Monitor/NSObject+Eye.swift) if runtime introspection is needed (Core/AppBaseKit/Classes/Util/AppSwizzle.swift)
3. Create ThermalEye.h header and Info.plist for CocoaPods integration, mimicking Core/ANREye/ANREye.h structure (Core/ThermalEye/ThermalEye.h)
4. Update GodEye.podspec to include the new ThermalEye subspec and test in Example/GodEye/ViewController.swift (GodEye.podspec)

Extend Network Monitoring (e.g., Capture HTTP headers or response bodies)

1. Edit Core/NetworkEye/Classes/URLSession+Eye.swift to add additional fields or callbacks in the URLSessionTaskDelegate interception points (Core/NetworkEye/Classes/URLSession+Eye.swift)
2. Update Core/NetworkEye/Classes/EyeProtocol.swift if you need to change the contract for what data is captured and logged (Core/NetworkEye/Classes/EyeProtocol.swift)
3. Extend Core/Log4G/Classes/LogModel.swift to include new fields (e.g., responseHeaders, requestBody) in the LogModel struct (Core/Log4G/Classes/LogModel.swift)

• Swift with Objective-C runtime interop — Enables safe method swizzling and low-level introspection (swizzle NSObject, URLSession, exception handlers) that is not possible in pure Swift.
• CADisplayLink for FPS monitoring — Provides frame-synchronized timing callbacks tied directly to the display refresh cycle; more accurate than manual timers for frame rate detection.
• Mach kernel APIs (task_info, mach_port) — Provides privileged access to per-process CPU and memory statistics unavailable through public frameworks; required for accurate system metrics.
• URLSession protocol swizzling — Non-invasive way to intercept all HTTP traffic without modifying user code; works transparently with any URLSession-based HTTP client.
• CocoaPods modular architecture — Allows users to include only the Eyes they need (LeakEye, NetworkEye, etc.) as independent subspecs, reducing app footprint and build time.

• Method swizzling for monitoring instead of requiring manual instrumentation

  • Why: Achieves the goal of 'one-liner' initialization; user does not need to manually hook every class or network call.
  • Consequence: Introduces fragile runtime dependencies on Objective-C runtime internals; swizzling can conflict with other libraries doing the same; harder to debug.

• Separate modular Eyes (CrashEye, LeakEye, NetworkEye, etc.) instead of one monolithic monitoring library

  • Why: Allows flexible composition; users include only what they need; cleaner architecture and easier to test/maintain individual components.
  • Consequence: More boilerplate to initialize all Eyes; more files to manage; requires coordination of updates across subspecs.

• Objective-C Mach kernel APIs for CPU/memory instead of higher-level Swift-only APIs

  • Why: Provides accurate, low-overhead metrics that are not available via public Swift Foundation frameworks.
  • Consequence: Code is less portable, more brittle to iOS version changes, and harder for Swift-only

1. Method swizzling conflicts: if the target app already swizzles UIApplication or NSURLSession, GodEye may fail silently or crash. 2) Swift compatibility: the Swift module interfaces require careful ABI stability management; bitcode is incompatible. 3) Private API risk: BSBacktraceLogger.m likely uses Mach APIs and private headers — Apple may reject apps if traces leak framework names in crash reports. 4) Memory overhead: weak-reference tracking (LeakEye) adds ~10-20% memory cost in instrumented apps. 5) No Release config guard: ensure GodEye is only linked in Debug builds via conditional Podfile syntax (pod 'GodEye', :configurations => ['Debug']) or it may bloat or crash production builds.

• Method Swizzling — GodEye injects monitoring into app lifecycle without code changes via runtime method replacement (AppSwizzle.swift); understanding how it works, its brittleness, and iOS restrictions is essential to debug conflicts and understand why hooks may fail.
• Weak References & Retain Cycles — LeakEye detects memory leaks by tracking object lifecycles through weak references (NSObject+Alive.swift); you must understand ARC, weak vs. unowned, and how retain cycles form to interpret leak reports correctly.
• Unix Signals & Mach Exceptions — CrashEye and ANREye intercept SIGSEGV, SIGABRT, and Mach exceptions (BSBacktraceLogger.m); knowing signal handling and how iOS encodes crashes helps you understand why certain crashes are/aren't caught and how to validate fixes.
• Backtrace & Stacktrace Unwinding — All crash/ANR monitoring relies on capturing and parsing stack frames from registers and memory (BSBacktraceLogger.m); understanding frame pointers, DWARF debug info, and symbol resolution is critical for reading and validating GodEye's stack traces.
• Runloop & Thread Monitoring — ANREye detects application hangs by monitoring the main thread runloop (ANREye.swift); understanding how iOS runloop works, why UI updates block it, and how to measure main-thread latency is key to interpreting ANR reports.
• Network Interception via URLSession Swizzling — NetworkEye (referenced in README) captures HTTP requests by hooking URLSession delegates; understanding URLSession lifecycle, delegate protocols, and the timing of network callbacks helps you know what data GodEye can and cannot intercept.
• Apple System Log (ASL) vs. os_log — ASLEye (Core/ASLEye/Classes/ASLEye.swift) monitors NSLog output via the deprecated ASL subsystem; knowing the differences between ASL, os_log, and unified logging helps you understand what logs GodEye can capture on different iOS versions.

• facebook/Flipper — Industry-standard desktop + iOS runtime debugger with similar goals (network, logs, crashes); GodEye is an all-in-one alternative that lives in-app
• plivesey/openswiftui — N/A — not directly related; included for reference pattern only
• CocoaLumberjack/CocoaLumberjack — Mature iOS logging framework that complements GodEye's Log4G module for structured, persistent log output
• firebase/firebase-ios-sdk — Firebase Crashlytics is a complementary cloud crash reporting service for production use alongside GodEye's local crash detection
• realm/realm-swift — In-app database inspector tools (like Realm Studio) pair well with GodEye's file browser for inspecting persisted data during debugging

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 SystemEye metrics collection

The SystemEye module (CPU.swift, Memory.swift, FPS.swift, NetworkFlow.swift, Hardware.swift) lacks visible test coverage. These are critical performance monitoring components that need validation across different device states and iOS versions. Adding unit tests would ensure accuracy of metrics like CPU usage, memory pressure, and FPS calculations.

• [ ] Create Tests/SystemEye/ directory structure
• [ ] Add CPUTests.swift to verify CPU usage calculation accuracy and edge cases
• [ ] Add MemoryTests.swift to test memory usage tracking and pressure states
• [ ] Add FPSTests.swift to validate frame rate detection and CADisplayLink integration
• [ ] Add NetworkFlowTests.swift to test network metrics collection
• [ ] Integrate test suite into CI/CD pipeline (referenced in Dependencies/Config)

Add integration tests for LeakEye detection with NSObject+Eye and ObjectAgent

LeakEye is a complex memory leak detection system (Agent/ObjectAgent.swift, Monitor/NSObject+Eye.swift, Monitor/NSObject+Alive.swift) that uses runtime introspection. Currently there are no visible integration tests validating that memory leaks are correctly identified, and false positives/negatives are avoided. This is critical for a debugging tool.

• [ ] Create Tests/LeakEye/ directory for integration tests
• [ ] Add LeakDetectionTests.swift to verify ObjectAgent correctly tracks object lifecycles
• [ ] Add RetainCycleTests.swift to validate detection of retain cycles with NSObject+Eye
• [ ] Add AliveMonitorTests.swift to test NSObject+Alive monitoring across view controller lifecycles
• [ ] Add test fixtures for common leak patterns (delegate cycles, closure captures, timer leaks)
• [ ] Document expected behavior in Tests/LeakEye/README.md

Add URL session interception tests for NetworkEye compatibility

NetworkEye (URLSession+Eye.swift, EyeProtocol.swift, NetworkEye.swift) patches URLSession to intercept network traffic, but there are no visible tests verifying it correctly captures requests/responses without breaking existing functionality, SSL pinning, or custom URLSessionConfiguration.

• [ ] Create Tests/NetworkEye/ directory
• [ ] Add NetworkInterceptionTests.swift to verify request/response capture for standard HTTP/HTTPS
• [ ] Add URLSessionConfigTests.swift to ensure custom URLSessionConfiguration and delegates aren't broken
• [ ] Add EdgeCaseTests.swift for background sessions, websockets, and streaming responses
• [ ] Add ProtocolTests.swift to validate EyeProtocol implementation across different URL schemes
• [ ] Include tests that verify network logging doesn't interfere with data integrity or performance

• Add unit tests for Core/AppBaseKit/Classes/Extension/{Foundation|UIKit}/ — currently no test files visible; start with simple tests for String+AppBaseKit.swift and UIColor+AppBaseKit.swift extension methods.
• Implement FPS monitor module following ANREye pattern — the README claims FPS monitoring but no Core/FPSEye module is visible; create Core/FPSEye/Classes/FPSEye.swift using CADisplayLink.
• Document the method swizzling rules in Core/AppBaseKit/Classes/Util/AppSwizzle.swift — add inline code comments explaining when swizzles are applied, how to debug conflicts, and which iOS versions are supported.

• High · Runtime Swizzling in AppBaseKit — Core/AppBaseKit/Classes/Util/AppSwizzle.swift. The codebase contains AppSwizzle.swift which implements method swizzling. This technique can introduce runtime vulnerabilities by modifying class methods dynamically, making the code harder to audit and potentially allowing for unexpected behavior changes. Method swizzling is commonly used for hooking but poses risks for security and maintainability. Fix: Minimize or eliminate method swizzling. Use delegation patterns, composition, or protocol-based approaches instead. If swizzling is necessary, implement strict validation and documentation of all swizzled methods.
• High · Network Interception Without Validation — Core/NetworkEye/Classes/URLSession+Eye.swift. The NetworkEye module intercepts URLSession requests (URLSession+Eye.swift) but there is no apparent validation of SSL/TLS certificate pinning or man-in-the-middle (MITM) attack prevention. Network interception without proper security measures can expose sensitive data in transit. Fix: Implement SSL/TLS certificate pinning validation. Use URLSessionDelegate to validate server certificates and reject invalid connections. Ensure all network traffic uses HTTPS with proper certificate validation.
• High · Memory and Leak Monitoring with Weak Reference Risks — Core/LeakEye/Classes/Agent/ObjectAgent.swift, Core/LeakEye/Classes/Monitor/NSObject+Alive.swift. The LeakEye module uses NSObject+Alive.swift and ObjectAgent.swift to monitor object lifecycles. Direct memory introspection and weak reference management can introduce memory safety issues if not handled correctly, potentially causing crashes or undefined behavior. Fix: Thoroughly test memory management under various conditions. Implement proper error handling for weak reference failures. Use Swift's Codable and memory safety features where possible instead of raw memory access.
• Medium · Crash Logging Without Data Sanitization — Core/CrashEye/Classes/CrashEye.swift. The CrashEye module captures crash information including stack traces and system state. If this data is logged or transmitted without proper sanitization, it could leak sensitive information about the application structure, file paths, or user data included in memory. Fix: Sanitize all crash logs before storage or transmission. Remove personally identifiable information (PII), sensitive file paths, and user data. Implement data minimization principles for crash reporting.
• Medium · ANR Detection with Backtrace Logging — Core/ANREye/Classes/Backtrace/BSBacktraceLogger.h, Core/ANREye/Classes/Backtrace/BSBacktraceLogger.m. The ANREye module uses BSBacktraceLogger (Objective-C bridge) to capture backtraces when ANR (Application Not Responding) is detected. C-level backtrace access can be exploited if not properly restricted and the logging mechanism lacks access controls. Fix: Ensure backtrace logging is only active in development/debug builds. Implement proper logging guards and restrict access to backtrace data. Consider using system-provided debugging APIs instead of custom C-level implementations.
• Medium · No Apparent Dependency Pinning — Dependencies/Package file. The provided dependency file is empty. Without explicit dependency version constraints, the project may be vulnerable to supply chain attacks if dependencies are updated to malicious versions or contain unpatched vulnerabilities. Fix: Implement proper dependency management with locked versions. Use CocoaPods podfile.lock, SPM Package.resolved, or Carthage Cartfile.resolved to lock dependency versions. Regularly audit and update dependencies.
• Medium · Logging of Potentially Sensitive Information — Core/Log4G/Classes/Log4G.swift, Core/ASLEye/Classes/ASLEye.swift, Core/NetworkEye/Classes/NetworkEye.swift. The Log4G and ASLEye modules log application information without apparent filtering. Network requests logged via NetworkEye may include headers, parameters, or response bodies containing sensitive data (tokens, credentials, PII). Fix: Implement log filtering to exclude sensitive headers (Authorization, cookies, etc.) and request/response bodies. Use a secure logging format that doesn't expose sensitive data. Consider disabling detailed logging in production builds.
• Low · Extension-based — undefined. undefined Fix: undefined

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.