Memory Turn Closeout
- Before drafting the final response, read the current turn's sanitized SHORT_MEMORY record. Do not wait for Stop to reinject an instruction.
- Compare every requested outcome with task, Plan, Decision, issue, risk, Validation, and Acceptance evidence.
- Choose exactly one status:
completed,needs_user,blocked,cancelled, orsuperseded. - Run
.codex/hooks/memory-runtime.ps1 -Event Closeoutwith conversation ID, turn ID, status, result, evidence, and next action. The runtime delegates to the transaction-safe closeout and migration scripts. - Only
completed,cancelled,superseded, or user-approvedclosed_unresolvedmay move to LONG_MEMORY. - Keep
needs_userandblockedin SHORT_MEMORY with a concrete blocker and next action. Refresh the active summary and requirememory-index.jsonto match the new state,shortlocation, and per-conversation Hash before returning success. - For terminal migration, remove the conversation's detailed records, rollup, and active summary from SHORT only after LONG verification succeeds.
User-visible closeout contract
- Normal path: close out the current turn before submitting the final response; Stop should observe a settled status and pass without a card.
- Fallback path: if Stop finds
received,working, orverifying, it may block once with a short internal-processing message. Complete the existing turn immediately; never re-capture the Prompt. - A Plan approval, status question, or read-only follow-up uses
needs_useronly when the wider active task genuinely awaits user action. Do not manufacture a blocker merely to keep the conversation in SHORT. - The final response must not claim the system was repaired merely because one turn was proactively closed.
Never infer completion from the prompt alone. Never mark unverified work completed.


