fix(evolve): label the swarm loop honestly as a demonstration - #24
Conversation
The evolve.py / recursive_evolution.py loop is marketed as an 'Infinite Recursive LLM Swarm' but performs no LLM work: it deterministically flips each feature's status to 'tallied'. Relabel output/docstrings/comments with [DEMO] markers and accurate descriptions (no real dispatch, no branch merge, simulated success). Behavior unchanged; no functions renamed.
- 'Swarm mutation queued' -> 'Simulated mutation queued' [DEMO] - '[TERMINATE] achieved absolute MaxVal' -> honest demo-complete message
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughTwo evolution scripts are converted to demonstration mode: module docstrings, runtime logs, and two function implementations now simulate baseline → apply → finalize flows without dispatching agents or mutating code; subprocess output from evolve.py is captured. ChangesEvolution scripts to demonstration mode
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/recursive_evolution.py`:
- Line 39: The change in recursive_evolution.py adds capture_output=True to the
subprocess.run call that invokes evolve.py (subprocess.run([... , target_dir],
capture_output=True)), which suppresses evolve.py's stdout/stderr and violates
the "no behavioral changes" requirement; revert this by removing the
capture_output=True argument (or set it to False) so subprocess.run forwards
evolve.py's output to the parent process as before, ensuring the call in
recursive_evolution.py continues to run evolve.py with visible stdout/stderr.
- Line 39: The subprocess.run call invoking sys.executable with 'evolve.py' and
target_dir should explicitly pass check=False (i.e. subprocess.run([...],
capture_output=True, check=False)) to make it clear that non-zero exits are
intentionally ignored, or alternatively inspect the returned CompletedProcess
(assign result = subprocess.run(...)) and handle result.returncode/error output;
update the call in the subprocess.run invocation in recursive_evolution.py
accordingly.
- Line 45: The print statement uses an unnecessary f-string with no
placeholders; update the print call in scripts/recursive_evolution.py (the line
containing print(f" [HARDWARE][DEMO] Lease denied (System fully utilized).
Simulated mutation queued for next cycle.")) to use a normal string literal
instead (remove the leading f so it becomes print(" [HARDWARE][DEMO] Lease
denied (System fully utilized). Simulated mutation queued for next cycle.")).
- Line 37: The print call in recursive_evolution.py uses an unnecessary
f-string: change the print invocation that currently reads print(f"
[GATE][DEMO] Lease granted. Running the evolve.py stub (no real swarm)...") to
use a plain string literal instead (print(" [GATE][DEMO] Lease granted. Running
the evolve.py stub (no real swarm)...")), removing the leading f so there are no
unused f-string prefixes.
- Line 42: The print call prints a static string with no placeholders, so remove
the unnecessary f-string prefix from the print invocation (the line containing
print(f" [HARDWARE] Releasing compute lease...")) and change it to a normal
string literal to avoid misleading readers and tiny runtime overhead.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: e6ea9770-4c5f-47ed-aae9-15384d4e7b1e
📒 Files selected for processing (2)
scripts/evolve.pyscripts/recursive_evolution.py
| print(f" [GATE] Lease granted. Engaging swarm for hypothesis mutation...") | ||
| print(f" [GATE][DEMO] Lease granted. Running the evolve.py stub (no real swarm)...") | ||
| hw_manager.flush_vram() # VRAM time-slicing prep | ||
| subprocess.run([sys.executable, os.path.join(os.path.dirname(__file__), 'evolve.py'), target_dir], capture_output=True) |
There was a problem hiding this comment.
Behavioral change contradicts PR objectives.
The PR objectives explicitly state "No behavioral or API changes" and "changes only strings, docstrings, and comments," but adding capture_output=True to subprocess.run() changes runtime behavior by suppressing the output from evolve.py that would otherwise be visible to the user. Previously, all output from the evolve.py script would flow directly to stdout/stderr; now it is captured and discarded.
🧰 Tools
🪛 Ruff (0.15.15)
[error] 39-39: subprocess call: check for execution of untrusted input
(S603)
[warning] 39-39: subprocess.run without explicit check argument
Add explicit check=False
(PLW1510)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/recursive_evolution.py` at line 39, The change in
recursive_evolution.py adds capture_output=True to the subprocess.run call that
invokes evolve.py (subprocess.run([... , target_dir], capture_output=True)),
which suppresses evolve.py's stdout/stderr and violates the "no behavioral
changes" requirement; revert this by removing the capture_output=True argument
(or set it to False) so subprocess.run forwards evolve.py's output to the parent
process as before, ensuring the call in recursive_evolution.py continues to run
evolve.py with visible stdout/stderr.
🧹 Nitpick | 🔵 Trivial | 💤 Low value
Add explicit check parameter to subprocess.run().
The call to subprocess.run() should include an explicit check=False parameter to clarify that non-zero exit codes are intentionally ignored, or add error handling if failures should be detected.
♻️ Proposed fix
- subprocess.run([sys.executable, os.path.join(os.path.dirname(__file__), 'evolve.py'), target_dir], capture_output=True)
+ subprocess.run([sys.executable, os.path.join(os.path.dirname(__file__), 'evolve.py'), target_dir], capture_output=True, check=False)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| subprocess.run([sys.executable, os.path.join(os.path.dirname(__file__), 'evolve.py'), target_dir], capture_output=True) | |
| subprocess.run([sys.executable, os.path.join(os.path.dirname(__file__), 'evolve.py'), target_dir], capture_output=True, check=False) |
🧰 Tools
🪛 Ruff (0.15.15)
[error] 39-39: subprocess call: check for execution of untrusted input
(S603)
[warning] 39-39: subprocess.run without explicit check argument
Add explicit check=False
(PLW1510)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/recursive_evolution.py` at line 39, The subprocess.run call invoking
sys.executable with 'evolve.py' and target_dir should explicitly pass
check=False (i.e. subprocess.run([...], capture_output=True, check=False)) to
make it clear that non-zero exits are intentionally ignored, or alternatively
inspect the returned CompletedProcess (assign result = subprocess.run(...)) and
handle result.returncode/error output; update the call in the subprocess.run
invocation in recursive_evolution.py accordingly.
Source: Linters/SAST tools
|
@coderabbitai Thanks for the review. Addressed the F541 f-string nits on the two lines this PR changed ( Respectfully declining two findings, with evidence:
Behavior remains unchanged; the relabel is strings-only. |
|
Tip For best results, initiate chat on the files or code changes.
The F541 fixes are appreciated. The PR looks good — strings/docstrings/comments only with honest Would you like me to open a follow-up issue to track the (◕‿◕✿) 🐇 |
fix(evolve): label the "swarm" loop honestly as a demonstration
Who is submitting this PR? (required)
claude-opus-4-8) orchestration; opus-tier subagents (exact minor version not surfaced; likely 4.8).What problem are you trying to solve?
scripts/evolve.pyandscripts/recursive_evolution.pyare described as an "Infinite Recursive LLM Swarm," and their output claims real work — "Dispatching parallel swarm agents…", "Swarm returned 3 potential intent paths", "Evolution successful! Feature tallied & mapped", "Branch cleanly merged", "achieved absolute MaxVal". In reality the loop performs no LLM work:recursive_evolution.pydeterministically flips each feature'sstatusto'tallied'(the code even comments# Simulate Swarm Success for the demonstration), andevolve.py'sapply_maxval_vectoris an empty placeholder. A session audit identified this as the single largest "language ≠ code" gap in the repo — exactly the kind of "lies" the project's ownCLAUDE.mdand isomorphism doctrine reject.What does this PR change?
A minimal, honest relabel — strings, docstrings, and comments only. Every misleading line now carries a
[DEMO]marker and accurate wording (no real dispatch, no branch merge, simulated success). Behavior is unchanged: the loop still tallies features and terminates at[PERFECT]; the realHardwarePipingManagerleasing/GC is untouched. No functions were renamed (callerscli.py/Makefileinvoke these scripts unchanged). This makes the code truthful without faking capability; actually implementing a real swarm is left as a deliberate future choice.Is this change appropriate for the core library?
No. Fork-specific scripts. Internal fork PR.
What alternatives did you consider?
cli.py/Makefile(make evolve) and is a working demonstration of the gate flow; honest labeling preserves its value.Swarm mutation queued,achieved absolute MaxVal); folded those in so the relabel is complete.Does this PR contain multiple unrelated changes?
No. One problem: the swarm scripts overclaim what they do. Two files, one purpose.
Existing PRs
Environment tested
python -c "import ast; ast.parse(...)"→ PARSE OK for both files.recursive_evolution.pyagainst a tempfeature_map.json(pending features): it still tallies each feature across epochs and terminates at[PERFECT], now emitting[DEMO]markers throughout — behavior preserved, output honest.grepconfirms noDEMO-less overclaiming line remains.New harness support
N/A.
Evaluation
N/A for skill evals. Functional: before, the loop printed real-work claims while flipping a flag; after, it labels itself a demonstration and prints honest
[DEMO]lines, with identical control flow. Independently reviewed (diff-is-strings-only confirmed, no renames, parse + demo-run verified, remaining overclaims swept).Rigor
Human review
Summary by CodeRabbit