ratatoskr/persistent-memory.d/2026-07-06-a-fast-no-op-deploy-can-leave-a-stale-contain.md at main

Files

T

vh ff1f9ca1e8 memory: /snapshot — #368 silo test passed; two-tier migration; stores scrubbed

- #368 (user,character) memory silo test DONE + PASSED live (WT b127):
  write-side conjunctive {end_user,agent_self} scoping + read-side cross-
  character isolation both proven end-to-end; betty (throwaway) deleted,
  Sindra intact. Full record in persistent-memory.d/2026-07-18-368-silo-
  test-passed.md. Retired the stale "silo test in progress" in-flight blocks.
- Two-tier migration: split 152 over-threshold dated entries into
  persistent-memory.d/ detail files, leaving one-line pointers in the index
  (startup load ~196KB -> ~53KB; bodies now load on demand).
- Tier-3 stores scrubbed clean (memory 0 / affect 0, provider restarted
  empty); persistent-memory + detail file updated to reflect the scrub.

2026-07-17 21:39:18 -07:00

703 B

Raw Permalink Blame History

[2026-07-06] A fast/"no-op" deploy can leave a STALE container running the old image -- verify the running version, not the deploy status. Personal's b22 deploy (run 8204) "completed" in ~1m (vs ~6m normal): a pull-only deploy racing ahead of the main build, leaving the container on the pre-#348 image. A clean bound mood read stayed neutral DESPITE the persona being declared and the fix being in the code (worldtree-dev proved the b22 derivation is correct). infra-ops force-swapped to the real b22 (run 8211, verified info.version 2.3.0 on 879cefe). Lesson: when engine-proven-correct code produces wrong runtime behavior, suspect the deploy -- check the actual running image version.

703 B Raw Permalink Blame History

703 B

Raw Permalink Blame History