March 4, 2026
Stress-Testing the New Architecture
A day of integration testing and targeted fixes following the single-process migration, covering thread safety, installer improvements, and mode router tuning.
Putting the New Architecture Through Its Paces
With the single-process migration complete, today’s focus was on running the new system through realistic usage scenarios and fixing the issues that surfaced. The big architectural changes from the past two days were solid, but integration testing always reveals the gaps that unit tests miss.
The first major issue was in our MemoryStore. While it was designed to be thread-safe, we had a race condition in the sorted-set operations introduced during the Redis purge. Under concurrent load from multiple worker threads hitting the cooldown tracking code simultaneously, we’d occasionally get a KeyError. The fix was straightforward: tightening the lock scope around the affected read-modify-write operations.
We also discovered that the new run.sh startup script wasn’t handling the case where a previous run had crashed mid-dependency-install, leaving the .deps-installed stamp file in place while the venv was in a broken state. We added a simple integrity check—if python can’t be imported from the venv, the stamp is deleted and the install step runs again.
Mode Router Calibration
With action intent detection now live, we spent time calibrating the scoring weights in the mode router. Out of the box, the ACT mode boost was too aggressive, causing Chalie to try to execute things that were phrased as questions or observations with action-adjacent keywords. We pulled the boost back and added a small set of negative signals—phrases like “what if”, “can you explain”, and “how does”—that suppress the ACT mode uplift even when an action keyword is present.
This required updating the intent classifier’s test suite to cover these ambiguous cases, which also flushed out a couple of pre-existing edge cases where REFLECT mode was being under-scored on introspective prompts.
Installer and Onboarding Improvements
The installer saw a few quality-of-life fixes. We improved the detection logic for systems that have Homebrew but where the brew binary isn’t on the PATH at install time—a common situation on fresh macOS setups. We also added a clear, actionable error message when the installer detects that it’s running inside a Docker container, since the installer targets native host setups.
Finally, the Docker image’s startup sequence was updated to match the new run.sh conventions, ensuring that the container entrypoint benefits from the same dependency-stamp optimizations as a native run.
Documentation Pass
We made a first pass at updating the README and inline code comments to reflect the new single-process model. Several comments still referred to Redis queues, the old docker-compose up workflow, and the RQ worker processes—all now gone. Keeping this documentation in sync is important as new contributors will encounter the codebase for the first time.