jakiboy/revens

1. What this repo is

ReVens is a desktop launcher/catalog for reverse-engineering tools, built as an Electron app with a React renderer. The app itself is not the tooling; it manages a large, JSON-driven inventory of external utilities, downloads, and launch actions.

2. Top-level runtime shape

The application is split into the classic Electron boundary:

- Main process in src/main/* handles windows, app lifecycle, menus, tray, shortcuts, IPC, launching external tools, and AI plumbing.

- Renderer/UI in src/app/* handles the visible launcher experience: tabs, sections, search, settings, downloads, notices, and help/about content.

- Preload (src/main/preload.js) is the bridge between the two.

3. Primary windows and app flow

Startup is centered around src/main.js, which loads the splash screen (src/splash.html / src/main/splash.js) and then the main window (src/main.html). This suggests a staged boot: splash while initializing, then the launcher UI once config and metadata are ready.

4. Renderer subsystem

The renderer is organized around reusable UI components in src/app/components/. The visible app is composed from pieces like header/footer, tabs, sections, search, download, settings, notice, and AI/about panes. This is a catalog-style interface, not a document-driven site or single workflow app.

5. Catalog/data-driven architecture

Most of the launcher content is driven by the files under src/config/:

- items.json is the core package/tool catalog

- sections.json, strings.json, paths.json, and app.json provide grouping, labels, and path/config metadata

- context.txt and prompt.txt support the AI assistant

This means the UI is largely data-driven: the catalog defines what appears, how it is grouped, and what actions are available.

6. External tool boundary

ReVens acts as a manager for external executables. The repository contains the launcher and metadata, but the actual reverse-engineering tools are separate payloads/downloads. That boundary is important for the architecture diagram: the Electron app orchestrates tools, but does not embed their functionality.

7. Launch/download subsystem

The main-process files src/main/launcher.js and src/app/launcher.js indicate a dedicated subsystem for resolving tool paths, starting executables, and likely coordinating downloads or updates. The README’s package-manager focus and “download separately” language reinforce that the app controls acquisition and execution rather than reimplementing tools.

8. AI subsystem

src/main/ai.js and src/app/components/ai.js implement a local AI assistant backed by Ollama. The prompt/context assets in src/config/ show that the assistant is configured from local text resources, with the main process mediating access and the renderer providing the chat UI.

9. System integration

src/main/menu.js, tray.js, shortcut.js, and ipc.js are the app’s integration layer with the OS. These modules handle app-level affordances such as menus, tray icon behavior, hotkeys/shortcuts, and IPC routing between UI and privileged actions.

10. Assets and shell/installer packaging

The repo includes substantial static assets under src/app/assets/ plus installer materials in assets/installer/ using Inno Setup. That indicates a packaged Windows desktop distribution, with branding/splash images, CSS themes, and installer-specific resources separate from application logic.

11. Build and generation pipeline

The repo has a noticeable generation workflow:

- root scripts: init.sh, run.sh, build.sh

- catalog/tooling scripts in scripts/ such as generate.py, update_items.py, fix_items.py, and test helpers

- a README template under scripts/Readme.md.tpl

This points to an architecture where the package catalog and documentation are generated from source data rather than maintained entirely by hand.

12. Operational intent and constraints

The project is Windows-first, Electron-based, and oriented toward security/reversing workflows. Most package entries are legacy third-party tools with their own runtimes, so the app’s key responsibility is metadata management, download orchestration, launch control, and optional AI guidance—not heavy computation itself.