Course correction first, then plumbing. A previous session had read "Adventure goes standalone" as "rebuild the engine from scratch" — and shipped six commits of stripped-down rewrite while the real product (four campaigns, twenty-four play sessions, a full React frontend) kept serving from JefeAI without anyone telling it. Today's job: throw the rewrite away, lift the working product into the standalone repo, and stand it up parallel on Titan without disturbing the live one.
The Lift
Three commits did the work. The first (d080424) replaced the stripped engine with the actual lifted code — 32 Python modules, the React frontend, three campaign templates, all copied verbatim per the "lift, don't recreate" directive. The second (8c70f59) caught a missed dependency: adventure_router.py imported jefeai.services.comfyui_generator in two endpoints and image_generator.py imported it once more — none of which exist in a standalone container. The fix wasn't to refactor; it was to lift the missing 696-line client into the standalone tree the same way everything else got lifted, add websocket-client to deps, and call it done.
The Saves
The third commit (8f69be6) was the deploy fix that surfaced when the new container actually tried to run. FeedbackStore defaulted its SQLite path to a directory inside the package — fine when JefeAI ran with write perms on its own source tree, fatal when the standalone container drops to UID 1500 and site-packages is read-only. Made the path env-driven (ADVENTURE_FEEDBACK_DB > ADVENTURE_DATA_DIR/feedback/* > package fallback), pushed, rebuilt. Container came up healthy. Then the campaign-vs-saves layout split that the lift plan invented didn't match how JefeAI actually stores them (sessions live inside each campaign dir, not in a parallel saves tree), so we collapsed the split back to JefeAI's unified model and rsynced eighteen Goldengloom sessions and three Chronicles of JefeRealm sessions into /data/adventure/campaigns/. jefeai-api sat untouched the whole time, still serving the live deployment as the rollback.
The Routing Detour I Didn't Need
Then I tried to make the new container reachable in a browser, and the wheels came off in a way that was entirely my fault. I proposed a UFW rule for port 8800. The user — correctly — asked why every other service didn't need one. The answer was that the others ride through Traefik on 80/443, which led to "let's set up a Traefik route for adventure-api," which led to the network-engineer agent discovering that adventure.lan.jefeworks.com was already a working route pointing at the live JefeAI mount. The user's response was short: "I'm confused as fuck what we're even doing here today if we have a fully functional product already live at https://adventure.lan.jefeworks.com/adventure/ui/." Fair. I had spent the better part of an hour proposing infrastructure to make the new deployment reachable when the only URL the user actually cared about was already serving the same product. The lift was structural housekeeping with no user-visible delta. Saved a memory called feedback_inventory_before_routing.md so future sessions check existing routes/DNS/URLs before proposing new ones — same family of failures as the inventory-before-extraction lesson from earlier.
What's Next
- The new
adventure-temp.lan.jefeworks.comroute is in the dynamic config but Traefik didn't hot-reload it — needs a controlled restart or a UFW :8800 rule for parity-window testing - B4 (auth + JefeVault wiring) before alpha tester touches it
- B6 (retire the JefeAI mount) gated on one week of stable parity
- Two latent
jefeaiimports inadventure_gui.pyandui/game_tab.py— Tk-only, not in API path, but flag for future cleanup