RSI Anything - Moses Yebei

The Problem

Developers need a repeatable loop that turns predictions from a world‑model into real improvements. Existing tools either stop at a single “generate‑evaluate” cycle or require domain‑specific plumbing. RSI‑Anything offers a unified workflow that can be plugged into code repair, GUI automation, lab planning, and more, without rewriting the selection and learning logic for each domain.

What This Does

The core library lives in src/rsi_anything.

__main__.py launches the package as a CLI.
cli.py exposes a click command set that delegates to domain modules.
workflow/ implements the generic Propose → Predict → Select → Evaluate → Learn → Retain cycle and is exercised by the domain tasks in src/rsi_anything/tasks.

Domain‑specific logic is separated into subpackages:

tasks/code_repair – candidate generation, execution simulation, and test‑based feedback.
tasks/gui – MiniWoB++ interactions, UI state serialization, and browser automation.

Both use the same workflow.runner to orchestrate their steps. The GUI entry point is tasks/gui/src/rsi_anything_gui/__main__.py, which loads a bundled MiniWoB HTML bundle from tasks/gui/src/rsi_anything_gui/assets/miniwob_html.

How It Is Wired

Entry – python -m rsi_anything imports src/rsi_anything/__main__.py.
__main__ calls cli.main(), defined in src/rsi_anything/cli.py.
cli parses a subcommand (e.g., code-repair or gui) and imports the corresponding task module.
The task module calls workflow.runner.run(task_config).
runner reads a JSON config from configs (e.g., configs/code_repair/default.json) and constructs a Workflow instance (workflow/config.py).
The Workflow executes the pipeline by calling task.propose(), task.predict(), task.select(), task.evaluate(), and task.learn().
Each step touches the filesystem only for logging or artifact storage; no external database or network is invoked unless a domain task explicitly does so (e.g., tasks/gui/src/rsi_anything_gui/aggregate.py writes a JSON summary).

The workflow module is the single hub; any change to the selection logic propagates to all domains. This tight coupling makes the pipeline powerful but also a critical maintenance point.

How To Use It

Setup

git clone https://github.com/moses-y/RSI-Anything
cd RSI-Anything
pip install -e .

The root pyproject.toml pulls JEPA-Anything and the core dependencies. Domain‑specific requirements are in tasks/code_repair/requirements.txt and tasks/gui/requirements.txt.

Configuration Edit JSON files in the configs directory. For code repair, start with configs/code_repair/default.json. No environment variables are required for the minimal launch.

Running

# Run the default code‑repair pipeline
python -m rsi_anything code-repair

# Launch the GUI demo
python -m rsi_anything gui

The CLI will print progress and write artifacts to the artifacts folder under the current working directory.

Real‑World Use

A research lab can use RSI‑Anything to iteratively improve a reaction‑optimization policy. The lab writes a custom tasks/reaction_optimization.py that defines the state, actions, and reward. It then supplies a config (configs/reaction_optimization.json). The framework will generate candidate protocols, predict yields using a world model, select promising protocols, run them in a reactor simulator, learn from the results, and retain the improved policy for the next round.

Code Health & Issues

Low – Dependencies declared without a lockfile (pyproject.toml has no poetry.lock or Pipfile.lock). Reproducibility may suffer.
Medium – No Dockerfile; deployment requires manual setup of the Python environment.
Low – CI defined in .github/workflows/* but only covers code‑repair and GUI tests; no end‑to‑end integration test for the full pipeline.

The repository contains 85 test files, but many domain modules lack unit tests (e.g., GUI interactions). Documentation is extensive but scattered across docs/ and tasks/gui/docs/.

The Bottom Line

RSI‑Anything offers a clean, reusable workflow that unifies prediction‑guided decision making across domains. Its Pythonic structure and CLI make it approachable, while the tight coupling in workflow/runner demands careful change management. The absence of a lockfile and a Docker image limits reproducibility out of the box, but the modular design allows targeted domain extensions. Researchers and developers looking for a common framework to iterate on complex tasks will find this repo a solid foundation.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

570 files

HTML140
Python100
JavaScript68
JSON37
Markdown31
CSS17

ReactDjango

Module dependencies

The 10 most depended-upon modules of 154, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0__src_rsi_anything_gui_common["common"] n1_rc_rsi_anything_gui_settings["settings"] n2__rsi_anything_gui_experiment["experiment"] n3_src_rsi_anything_gui_gui_env["gui_env"] n4_c_rsi_anything_gui_gui_world["gui_world"] n5_n_src_suzuki_inference_prior["prior"] n6_rsi_anything_gui_orchestrate["orchestrate"] n7_rc_suzuki_inference_selector["selector"] n8_rsi_anything_workflow_config["config"] n9__rsi_anything_workflow_types["types"] n0__src_rsi_anything_gui_common --> n1_rc_rsi_anything_gui_settings n2__rsi_anything_gui_experiment --> n0__src_rsi_anything_gui_common n2__rsi_anything_gui_experiment --> n3_src_rsi_anything_gui_gui_env n3_src_rsi_anything_gui_gui_env --> n0__src_rsi_anything_gui_common n3_src_rsi_anything_gui_gui_env --> n1_rc_rsi_anything_gui_settings n4_c_rsi_anything_gui_gui_world --> n0__src_rsi_anything_gui_common n6_rsi_anything_gui_orchestrate --> n1_rc_rsi_anything_gui_settings n6_rsi_anything_gui_orchestrate --> n0__src_rsi_anything_gui_common n7_rc_suzuki_inference_selector --> n5_n_src_suzuki_inference_prior

Dependencies

1 of 7 declared dependencies are a major version behind. Resolved 7 of 7 against the registry.

Package	Declared	Latest	Behind
`transformers`	==4.57.3	5.15.0	1 major

Findings

LowDependencies declared without a lockfile - non-reproducible builds pyproject.toml

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium3

low1

Upgrade the pinned dependency carrying a published advisoryhigh17 occurrences

torch@2.9.1 CVE-2026-24747 (high) +3 more; transformers@4.57.3 CVE-2026-4372 (high) +10 more; accelerate@1.12.0 CVE-2026-69112 (medium) +1 more

The pinned version is the one that installs, so a published advisory against it describes this deployment rather than a hypothetical one, and the advisory is also a public description of how to exploit it.

Fix: Upgrade to the fixed version named in the advisory, then commit the lockfile.

Commit a lockfile beside the manifesthigh

pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Enable Dependabot or Renovatemedium

7 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/code-repair.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow3 occurrences

.github/workflows/code-repair.yml

3 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.