Version. 0.1
Date. 2026-06-27
Status. Standing note (workflow/process) for the Loomworks project. Surfaces whenever a merge changes runtime behaviour and the next step is testing on the dev server.
Origin. 2026-06-27 — the Companion truthfulness fix merged to engine main (41704ef), but Operator testing on loomworks-dev.dunin7.com still showed the pre-fix behaviour. Diagnosis: the dev uvicorn process had not been restarted since the merge (~25 hours stale), so it was running pre-merge code. The deleted prompt line still appeared because prompts are cached in-process at first read (prompt_assets._read, module-level _cache) and only re-read on restart. The fix was correct on main; it simply was not live.
Merging to main does not deploy to the running dev server. After any merge that changes runtime behaviour, the dev engine must be restarted before testing — or the test is against stale code.
A merge updates the files on disk and on main. The running process is a separate thing: it loaded its code (and, critically, its prompts) into memory when it started, and it keeps serving that in-memory version until it is restarted. A merge does not reach into a running process and update it.
So there are two distinct states for any change:
- Merged — the fix is on main, the files are correct, the suite is green.
- Deployed — the running dev process has been restarted and is now serving the merged code.
These are not the same, and the gap between them is invisible: the server looks like it's running, responds normally, and shows the old behaviour. Testing in that window produces false negatives — a correct fix appears not to work.
Prompts are cached in memory at first read. prompt_assets._read() populates a module-level _cache[path] on first access and serves the cached string for the life of the process. A prompt edit on disk (e.g. deleting a line from forget_about_me.md) does not propagate to a running server — the process keeps serving the prompt text it cached at startup. Only a restart clears _cache and re-reads the file.
This means prompt-level fixes (deleting an invented line, changing the Companion's wording) are especially prone to the merged-not-deployed trap: the file is provably clean, yet the old text keeps appearing, which looks like the fix failed or missed a second site. It didn't — it's a cached prompt in a stale process.
After a merge that affects runtime behaviour (engine logic, prompts, responder wording, classification, any served behaviour), restart the dev engine before testing. Then test.
When a just-merged fix appears not to work on dev, check the running process's start time against the merge time before assuming the fix is wrong. If the process predates the merge, it's a deploy gap, not a code gap — restart and re-test before touching the code. A prompt-text change that "didn't take" despite a clean file is almost always a stale cache, not a missed edit.
This is a workflow note, not a code change. It does not call for auto-reload or a deploy pipeline (those are separate decisions — auto-reload on file change would close the gap but has its own tradeoffs for a dev server; out of scope here). The minimal, reliable discipline is: merge → restart dev → test. If the merged-not-deployed gap becomes frequent friction, a dev auto-reload or a one-command "deploy latest main to dev + restart" is worth scoping — but the habit above prevents the false negative regardless.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Standing Note — Merged Is Not Deployed: Restart Dev After a Runtime-Affecting Merge — v0.1 — 2026-06-27 Merging updates main; it does not update a running process. Prompts cache in memory at first read, so prompt edits especially need a restart. After a runtime-affecting merge: restart dev, then test the case the fix targets.