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/ThirtyDegreesRay/OpenHub 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

• 15 active contributors
• GPL-3.0 licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 72% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ 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 ThirtyDegreesRay/OpenHub repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ThirtyDegreesRay/OpenHub.

What it runs against: a local clone of ThirtyDegreesRay/OpenHub — 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 ThirtyDegreesRay/OpenHub | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | 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 ≤ 738 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ThirtyDegreesRay/OpenHub(\\.git)?\\b" \\
  && ok "origin remote is ThirtyDegreesRay/OpenHub" \\
  || miss "origin remote is not ThirtyDegreesRay/OpenHub (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 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 "app/src/main/java/com/thirtydegreesray/openhub/AppApplication.java" \\
  && ok "app/src/main/java/com/thirtydegreesray/openhub/AppApplication.java" \\
  || miss "missing critical file: app/src/main/java/com/thirtydegreesray/openhub/AppApplication.java"
test -f "app/src/main/java/com/thirtydegreesray/openhub/AppConfig.java" \\
  && ok "app/src/main/java/com/thirtydegreesray/openhub/AppConfig.java" \\
  || miss "missing critical file: app/src/main/java/com/thirtydegreesray/openhub/AppConfig.java"
test -f "app/src/main/java/com/thirtydegreesray/openhub/dao/DBOpenHelper.java" \\
  && ok "app/src/main/java/com/thirtydegreesray/openhub/dao/DBOpenHelper.java" \\
  || miss "missing critical file: app/src/main/java/com/thirtydegreesray/openhub/dao/DBOpenHelper.java"
test -f "app/src/main/java/com/thirtydegreesray/openhub/dao/DaoSession.java" \\
  && ok "app/src/main/java/com/thirtydegreesray/openhub/dao/DaoSession.java" \\
  || miss "missing critical file: app/src/main/java/com/thirtydegreesray/openhub/dao/DaoSession.java"
test -f "app/src/main/java/com/thirtydegreesray/openhub/common/AppEventBus.java" \\
  && ok "app/src/main/java/com/thirtydegreesray/openhub/common/AppEventBus.java" \\
  || miss "missing critical file: app/src/main/java/com/thirtydegreesray/openhub/common/AppEventBus.java"

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

OpenHub is a lightweight, open-source Android client for GitHub (API v3) written in Java, designed to be faster and more concise than the official app. It provides offline browsing, multi-account switching, and real-time notifications while supporting 16+ languages and three theme modes (light, dark, AMOLED). The app loads code syntax highlighting via bundled Google Prettify JS libraries (stored in app/src/main/assets/code_prettify/) and handles OAuth authentication without exposing credentials via BuildConfig fields. Standard Android project structure: app/src/main/java/com/thirtydegreesray/openhub/ contains core logic, app/src/main/AndroidManifest.xml defines entry points, app/src/main/assets/ includes external code syntax highlighting libraries. Gradle-based build (build.gradle with novoda build-properties plugin) manages environment-specific secrets. The project uses Proguard obfuscation (proguard-rules.pro) and multi-architecture NDK support (arm64-v8a, x86, x86_64, armeabi-v7a).

Android developers and GitHub power users who want a lightweight, privacy-respecting GitHub mobile client with offline support, trending repository discovery, and multi-account management without relying on the official GitHub app.

Production-ready and actively maintained. The project has a public release track (see VERSION_CODE/VERSION_NAME in build.gradle), is published on Google Play Store and Coolapk, supports Android 5.0+, and includes instrumented test scaffolding (androidTest/). BuildConfig-driven secrets management and signing configuration (OpenHubPublicSign.jks) indicate mature release practices, though commit recency and issue backlog are not visible in provided data.

Moderate risk: Single maintainer (ThirtyDegreesRay) visible in GitHub path suggests potential bus factor. OAuth token storage and API key BuildConfig fields (OPENHUB_CLIENT_ID, OPENHUB_CLIENT_SECRET) must be managed carefully via public.properties/local.properties to avoid credential leaks. The codebase has 1.2M lines of Java, suggesting potential technical debt; JavaScript/CSS asset dependencies (code_prettify with 40+ language loaders) may have security implications if not regularly audited.

Not directly visible from provided file listing, but the mature version numbering (VERSION_CODE, VERSION_NAME in build.gradle) and active Play Store presence suggest ongoing maintenance. The inclusion of bug tracking (BUGLY_ID fields) indicates post-release monitoring infrastructure is in place.

Clone the repository: git clone https://github.com/ThirtyDegreesRay/OpenHub.git && cd OpenHub. Create public.properties and local.properties files with GitHub OAuth credentials (openhub_client_id, openhub_client_secret, bugly_appid, sign_path, store_password, key_alias, key_password). Build with Gradle: ./gradlew assembleDebug or open in Android Studio. For release builds, ensure the keystore file path and passwords match local.properties.

Daily commands: Development: ./gradlew assembleDebug to build debug APK, then push to emulator/device via adb install app/build/outputs/apk/debug/*.apk. For IDE: open in Android Studio, sync Gradle, then Run → Run 'app'. Release: ./gradlew assembleRelease (requires properly configured local.properties with keystore credentials). Tests: ./gradlew connectedAndroidTest (instrumented tests found in app/src/androidTest/).

• app/src/main/java/com/thirtydegreesray/openhub/AppApplication.java — Application entry point; initializes core dependencies, event bus, database, and app-wide configuration
• app/src/main/java/com/thirtydegreesray/openhub/AppConfig.java — Central configuration holder for API endpoints, feature flags, and build-time properties; read by all major components
• app/src/main/java/com/thirtydegreesray/openhub/dao/DBOpenHelper.java — Database initialization and schema management; critical for offline mode and multi-account persistence
• app/src/main/java/com/thirtydegreesray/openhub/dao/DaoSession.java — Generated DAO session providing all database access; backbone of local data layer
• app/src/main/java/com/thirtydegreesray/openhub/common/AppEventBus.java — Event bus for inter-component communication; used throughout for async updates and lifecycle events
• app/build.gradle — Gradle build configuration defining SDK versions, dependencies (Retrofit, Glide, RxJava), and signing configuration

Add Support for a New GitHub API Endpoint

1. Define a new API interface method in the Retrofit service (typically in a service package not fully visible, but follows standard Retrofit pattern) (app/src/main/java/com/thirtydegreesray/openhub)
2. Create a new DAO entity class (e.g., NewEntity.java) following GreenDAO conventions in the dao package (app/src/main/java/com/thirtydegreesray/openhub/dao/AuthUser.java)
3. Run GreenDAO code generation to create corresponding DAO classes and update DaoMaster.java and DaoSession.java (app/src/main/java/com/thirtydegreesray/openhub/dao/DaoMaster.java)
4. Add migrations in DBOpenHelper.onUpgrade() if the new entity requires schema changes (app/src/main/java/com/thirtydegreesray/openhub/dao/DBOpenHelper.java)
5. Create a presenter/viewmodel that fetches from API (via Retrofit) and caches to local DB (via DAO), posting events via AppEventBus (app/src/main/java/com/thirtydegreesray/openhub/common/AppEventBus.java)

Add a New Theme or Accent Color

1. Update AppConfig.java to add new theme or color constants and getters for active theme state (app/src/main/java/com/thirtydegreesray/openhub/AppConfig.java)
2. Define color resources in res/values/colors.xml (not shown, but standard Android pattern) (app/src/main/AndroidManifest.xml)
3. Update theme switching logic in AppApplication.onCreate() or a dedicated ThemeManager to apply colors at runtime (app/src/main/java/com/thirtydegreesray/openhub/AppApplication.java)
4. Persist user preference via AppData.java (using SharedPreferences under the hood) (app/src/main/java/com/thirtydegreesray/openhub/AppData.java)

Implement Offline Mode for a Feature

1. Ensure entity is mapped to a DAO (e.g., LocalRepo.java, LocalUser.java) in the dao package (app/src/main/java/com/thirtydegreesray/openhub/dao/LocalRepo.java)
2. When fetching from API, check cache first: query DAO before making Retrofit call in your presenter/service (app/src/main/java/com/thirtydegreesray/openhub/dao/DaoSession.java)
3. On successful API response, insert/update via DAO: e.g., localRepoDao.insertOrReplace(repo) (app/src/main/java/com/thirtydegreesray/openhub/dao/LocalRepoDao.java)
4. Post update event via AppEventBus to notify UI listeners of data refresh (app/src/main/java/com/thirtydegreesray/openhub/common/AppEventBus.java)

Add Code Syntax Highlighting for a New Language

1. Add corresponding language loader JavaScript file in the code_prettify/loader/ assets folder (e.g., lang-newlang.js) (app/src/main/assets/code_prettify/loader/lang-swift.js)
2. Update language_colors.json to include color metadata for the new language (app/src/main/assets/language_colors.json)
3. In the WebView or code display fragment, ensure run_prettify.js is loaded and dynamically loads the new language plugin (app/src/main/assets/code_prettify/core/run_prettify.js)

• Retrofit + OkHttp — Industry-standard HTTP client for GitHub REST API calls; supports interceptors for authentication and request/response logging
• GreenDAO — Lightweight ORM for SQLite; generates optimized DAO code at compile time; provides fast caching layer without reflection overhead
• EventBus (GreenRobot or Otto) — Decouples UI (Activities/Fragments) from data layer; enables reactive, event-driven architecture without tight coupling
• Glide — Efficient image loading and caching library; handles memory constraints on mobile and supports disk caching for offline access
• Code Prettify (JavaScript) — Lightweight client-side syntax highlighting; avoids server-side processing and works entirely in WebViews for code display

• GreenDAO
  • Why: undefined
  • Consequence: undefined

OAuth credentials (openhub_client_id, openhub_client_secret) must be injected via public.properties or local.properties—missing these will cause BuildConfig field errors and app crashes on GitHub API calls. Signing configuration also requires local.properties (sign_path, store_password, key_alias, key_password); release builds will fail silently without it. The app uses Android 5.0+ (minSdkVersion), so certain AndroidX APIs or features may not work on older devices. Proguard obfuscation in release builds can hide stack traces unless mapping files are kept and uploaded to Bugly for crash reporting. BuildConfigField values are static, so changing credentials requires a full rebuild and reinstall.

• OAuth 2.0 Authorization Code Flow — OpenHub uses GitHub OAuth (OPENHUB_CLIENT_ID, OPENHUB_CLIENT_SECRET in BuildConfig) to authenticate users without storing passwords; understanding this flow is essential for contributing to login/auth features
• ProGuard Code Obfuscation — The project uses app/proguard-rules.pro for release builds to reduce APK size and protect code; misconfigured rules can break reflection-based serialization (e.g., JSON → API models)
• Android Multi-Architecture NDK Support — Build.gradle specifies abiFilters (armeabi-v7a, arm64-v8a, x86, x86_64); understanding ABI selection is crucial for APK size optimization and device compatibility
• Client-Side Code Syntax Highlighting (Google Prettify) — OpenHub bundles 40+ language highlighters in app/src/main/assets/code_prettify/ and loads them at runtime in WebView; this allows offline code viewing without server-side rendering
• Build-Time Secret Injection via BuildConfig — OAuth credentials and API keys are injected at compile-time (buildConfigField in build.gradle) from property files, not hardcoded; this pattern prevents credential exposure in source control
• Android Offline-First Caching Architecture — The app advertises 'Offline mode' and 'Record trace of repositories/users you have viewed'; this requires local persistence layer (likely SQLite/Room) synchronized with GitHub API responses
• Multi-Account Session Management — The README mentions 'Supports multi-account switching'; this requires secure token storage, session isolation, and context switching in the Activity/Fragment layer to avoid credential leaks

• k0shk0sh/FastHub — Alternative lightweight GitHub Android client with similar feature set (offline, multi-account, notifications); direct competitor in the same ecosystem
• pockethub/PocketHub — Predecessor/inspiration GitHub mobile client; open-source Java/Android client that pioneered offline-first design patterns for GitHub browsing
• octokit/octokit.js — Official GitHub API JavaScript wrapper; OpenHub relies on GitHub API v3, and this is the canonical library for understanding API contracts
• google/code-prettify — Source of the bundled syntax highlighting library in app/src/main/assets/code_prettify/; OpenHub includes a snapshot of this project for offline code viewing
• square/retrofit — Likely HTTP client used for GitHub API calls in OpenHub (inferred from Android ecosystem conventions); essential for understanding API integration patterns

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 instrumented tests for GitHub API integration layer

The repo has a placeholder ExampleInstrumentedTest.java but no actual API integration tests. Given that OpenHub is a GitHub client that depends heavily on OAuth authentication and API calls (evidenced by buildConfigField for OPENHUB_CLIENT_ID/SECRET), adding instrumented tests would catch regressions in authentication flows and API response parsing. This is critical for a client app where API changes could break core functionality.

• [ ] Create app/src/androidTest/java/com/thirtydegreesray/openhub/api/ directory structure
• [ ] Add GitHubApiTest.java to test OAuth token handling and API endpoints
• [ ] Add authentication mock tests for login flow validation
• [ ] Reference existing testInstrumentationRunner 'android.support.test.runner.AndroidJUnitRunner' in build.gradle

Implement code signing and release automation via GitHub Actions

The build.gradle shows manual signing configuration with keystore file (app/OpenHubPublicSign.jks) and signing configs that pull from properties files. There's no evidence of CI/CD automation. Adding a GitHub Action for signed APK builds on release tags would streamline the deployment process to Google Play and Coolapk (both mentioned in README), reducing manual steps and human error.

• [ ] Create .github/workflows/build-release.yml for tagged releases
• [ ] Configure signing secrets (store_password, key_pa) in GitHub repository settings
• [ ] Add workflow steps to build signed APK using the existing signingConfigs from build.gradle
• [ ] Integrate GitHub Action to upload releases to GitHub Releases page

Add missing language syntax files for code_prettify asset library

The app bundles code_prettify for markdown/code highlighting (mentioned in README features), but the lang-*.js files appear incomplete. Many common programming languages have loaders but the core prettify implementation is missing critical files. Adding comprehensive language support would improve code preview quality for repositories with less common languages.

• [ ] Audit app/src/main/assets/code_prettify/loader/ against upstream google-code-prettify releases
• [ ] Add missing lang-*.js files for languages like lang-json.js, lang-dockerfile.js, lang-vim.js
• [ ] Verify lang-bash.js and lang-sh.js are present (common in GitHub repos)
• [ ] Update or create app/src/main/assets/code_prettify/README documenting supported languages

• Add unit tests for the Markdown parsing/rendering logic: the file structure shows AndroidManifest.xml declares Markdown support, but there are no visible test files (app/src/test/ or equivalent) for this feature. Create tests in app/src/androidTest/java/com/thirtydegreesray/openhub/ for edge cases like nested code blocks and nested lists.
• Expand language syntax highlighting: the code_prettify loader/ directory has 40+ language files, but missing common languages like Rust (lang-rs.js) and TypeScript (lang-ts.js). Add loaders for these by following the pattern of existing lang-*.js files and update the language detection logic to recognize file extensions.
• Document OAuth setup in README: the build.gradle exposes openhub_client_id and openhub_client_secret as required BuildConfig fields, but README.md does not explain how to obtain GitHub OAuth credentials or where to place them in public.properties/local.properties. Add a 'Getting Started' section with step-by-step OAuth app registration on GitHub.

• Critical · Hardcoded Keystore File in Repository — app/OpenHubPublicSign.jks. The file 'app/OpenHubPublicSign.jks' is a keystore file committed to the repository. This is a critical security risk as keystore files contain private keys used for signing APKs. If this is a real signing key (not a test key), the private key is exposed to anyone with repository access, allowing unauthorized app signing and potential malicious app distribution. Fix: 1. Immediately revoke this keystore and generate a new one. 2. Add *.jks and *.keystore to .gitignore. 3. Remove the file from git history using git-filter-branch or BFG Repo-Cleaner. 4. Store the keystore securely outside the repository (e.g., CI/CD secrets, secure artifact storage). 5. Update build.gradle to reference the keystore from a secure location.
• High · Build Secrets Embedded in Gradle Build Configuration — app/build.gradle (buildConfigField definitions and signingConfigs). The build.gradle file contains references to sensitive credentials (OPENHUB_CLIENT_ID, OPENHUB_CLIENT_SECRET, BUGLY_ID, key_password, storePassword) loaded from property files. While using property files is better than hardcoding, these credentials are still embedded into the APK as BuildConfig fields, making them extractable via reverse engineering. The 'keyPassword' field is truncated in the provided snippet but appears to be handling signing credentials. Fix: 1. Never include API keys or secrets in BuildConfig fields. 2. For API keys needed at runtime, fetch them from a secure backend API. 3. For signing passwords, use CI/CD environment variables or secure vaults that aren't baked into the APK. 4. Use ProGuard/R8 rules to obfuscate sensitive strings. 5. Consider using Android's KeyStore for sensitive data storage. 6. Ensure local.properties is in .gitignore and never committed.
• High · Potential Credential Exposure via Property Files — app/build.gradle (buildProperties configuration). The build system references 'public.properties' and 'local.properties' files for storing sensitive configuration including OAuth credentials (openhub_client_id, openhub_client_secret), API keys (bugly_appid), and signing credentials. If these files are not properly gitignored or if public.properties contains real secrets, they could be exposed. Fix: 1. Ensure local.properties is in .gitignore and never committed. 2. If public.properties contains real secrets, move them to local.properties immediately. 3. Document a template properties file (e.g., local.properties.template) without actual values. 4. Use CI/CD systems to inject secrets at build time rather than storing them in files. 5. For open-source projects, use OAuth to get user-specific tokens rather than embedding app secrets.
• High · Multiple NDK Architecture Support May Increase Attack Surface — app/build.gradle (ndk.abiFilters). The build configuration includes abiFilters for 'armeabi', 'armeabi-v7a', 'arm64-v8a', 'x86', and 'x86_64'. Supporting multiple architectures increases the binary size and potential attack surface. 'armeabi' is deprecated and its inclusion may indicate outdated or less-scrutinized native code. Fix: 1. Remove deprecated 'armeabi' architecture support - use only 'armeabi-v7a' for 32-bit ARM. 2. Audit all native libraries for security vulnerabilities. 3. Consider reducing to only necessary architectures (typically 'armeabi-v7a' and 'arm64-v8a'). 4. Ensure all NDK libraries are compiled with security flags (-fPIE, stack protection, etc.). 5. Regularly update NDK and native dependencies for security patches.
• Medium · Code Prettify HTML/JavaScript Assets May Have XSS Risk — app/src/main/assets/code_prettify/. The application includes extensive code_prettify library assets (HTML/CSS/JavaScript files) in assets. If these are used to display user-generated or untrusted code with WebView, there's a potential for XSS attacks. The presence of multiple language highlighting files and CSS themes suggests code viewing functionality. Fix: 1. If using WebView to display code: enable WebView security restrictions. 2. Implement Content Security Policy (CSP) headers. 3.

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.