vh
ff1f9ca1e8
- #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.
1.2 KiB
[2026-07-13] Resumed-session context-snapshot is IN-MEMORY → lost on a container recreate (agent_not_available on resume). During the #355 re-drive, soong's fresh drive 409'd agent_not_available. Root cause (after ~4 refinements — agent-loss? zombie turn-lock? stale-sessions-hold-agent? → the actual mechanism): get_agent_context_for_session returns the agent snapshot recorded AT SESSION-CREATE, held in-memory; a pre-recreate session resumed on b60/b61 has no snapshot → None → 409. (Compounding: stale 'active' sessions left un-terminated by the old no-terminal bug HOLD the agent, blocking new creates too.) Deploy-grounding was healthy the whole time (registry.resolve("char-rp-reasoning") OK) — the config/grant hypotheses were all red herrings. Fix = a FRESH session (a studio-service restart re-records the snapshot); pre-recreate sessions need retiring. Tracked WT #356. For any run: create a fresh session, never resume a pre-recreate one; agent_not_available on a fresh create = this gap. (Working-style note: I over-relayed the intermediate root-cause churn to the operator — for a peer-owned block being actively diagnosed, hold until it settles.)