Status:
draft · Version 1.0 · Filed 2026-04-21project.phase (available) and phase-as-of-last-wrap (not stored anywhere). Same for rename.
Solution. Add three nullable columns to the projects table: last_wrapped_phase, last_wrapped_name, last_wrapped_at. Written by prism_wrap on exit, read by prism_wrap on entry for comparison. Null values → no trigger fires (first-ever wrap has nothing to compare against).
Server change. Update _compute_hygiene_triggers in mcp/server.py to take the full project dict alongside recent_deltas. Add phase-advance and rename detection. Update prism_wrap to patch the project row after delta storage but after trigger computation (order matters — write-back must not self-erase the comparison). Patch failure logs warning; does not fail prism_wrap (delta is already stored).
Summary rendering (_render_memory_summary) unchanged. Minor polish: when phase-advance fires, the instruction text names the old→new phase transition explicitly.
Non-goals. Not changing when prism_wrap is called (SPEC-023’s concern). Not adding triggers beyond the three in SPEC-021 §4.4. Not changing the summary format. Not auto-updating Claude Desktop / ChatGPT user-memory fields (paste-based workflow unchanged).
Open questions.
- Q1: Is last_wrapped_at worth the extra column? Lean yes, but cuttable if backend cost is material.
- Q2: Should phase-advance fire on prism_start as well as prism_wrap? Spec §4.4 says wrap-only. Lean: ship wrap-only per SPEC-021, revisit if start-side nudge proves more valuable in practice.
- Q3: Phase rollbacks (Phase 4 → Phase 3) — fire the trigger? Lean: any inequality fires, don’t overfit.
- Q4: Write-back atomicity — gate on delta write succeeding? Lean yes.