Wrap Up

Session Wrap-Up

A session-end workflow in phases, not a single parallel check. Run them in order:

1. Preflight — confirm the repo and capture the branch.
2. Gather (read-only checks 1 to 6) — collect status; write nothing.
3. Report — deliver one consolidated status checklist.
4. Commit and push (gated, autonomous) — record side-effects, then commit pending work.
5. Optional follow-ups (opt-in, batched into one prompt) — skill and learning loops.
6. Continuation handoff (automatic, gated on open work) — write the prompt that starts the next session.

Report-only mode. If Ane invokes /wrap-up report, /wrap-up --report-only, or asks for status only, run phases 1 to 3 then STOP. Do not write, commit, or run any follow-up, and do not write a handoff.

Date. Use the current date from the session environment. Never guess it.

Phase 1 — Preflight

The thread is now closed. From this point, park every new question, explainer request and follow-up ask in the Phase 6 handoff rather than answering it in-session. Say so in one line when it happens: Parked for the next session: <ask>. Ane can override by repeating the ask, and then you answer it. Reason (2026-07-30 /improve-system Run 4): across five consecutive logged sessions the thread itself closed at 190k–227k and the whole overage came from post-decision Q&A, one extra check, and the wrap-up loops. Closing costs about 50k; answering new asks inside the close-out is what doubles it.

Run git rev-parse --git-dir 2>/dev/null. If it fails (not a git repository), skip the git, harness, and commit sections. Run only checks 3 and 4, deliver a short report, and end with:

ℹ️  Not a git repo — git, harness, and commit checks skipped.

Otherwise capture the branch once: git branch --show-current. Hold it as the expected branch for the branch guard in Phase 4, and show it in the report header.

Capture every repo the session wrote to, not only the working directory. Before moving to Phase 2, list the repos this session actually touched: the working directory, plus any other repo a file was written or committed to. Hold that set as the repo set, and run check 1, the Phase 4 gates, and the commit against each repo in it, labelling each block with its repo name in the report. git status reads the current directory only, so a session that produced its deliverables in a project repo and then wrapped up from the work folder reports a clean tree while real work sits exposed somewhere else. Evidence (2026-08-01, it-demo-followup-and-system-synthesis): the whole session's output landed in 1. Ane's PROJECTS/AI in IPPF EN 2026/MY MEL AI SYSTEM DEMO, including Ane's hand-edited canonical .docx sitting untracked and one file the agent had written that existed nowhere else; the work folder repo was clean and would have reported "safe to close" on its own. A repo with no remote is not a defect to fix. The three local-only repos guarding 1. Ane's PROJECTS exist to survive OneDrive reverts, so report no remote by design, skip the push, and never offer to add an origin.

A read-only probe into another repo in the set can be blocked, and the block is usually pointing at cheaper evidence. The edit-preservation guard judges a command on the folders it names, so git -C <other-repo> config --get ... is refused when that repo holds one of Ane's hand-edited artefacts, even though the command writes nothing. Do NOT reach for --accept to satisfy a status read: the guard is correct that the artefacts changed, and clearing a block to produce a report line spends Ane's protection on bookkeeping. Ask instead what already proves the fact. A harness check that went green this session over exactly that condition is stronger evidence than re-reading the file by hand, because it was computed rather than eyeballed. Evidence (2026-09-10): a wrap-up read of Antwerphouse's user.email, confirming that a deliberate temporary revert had been restored, was blocked on two hand-edited .docx files in that repo; check_git_identity_by_content had already asserted the same condition and was green, so the check was the answer and the read was never needed. Where nothing already asserts it, isolate the probe in its own command: the blocked call that day was batched with the desktop-sync and handoff-status checks and took both down with it.

Resume check — never run a full wrap-up twice. If a wrap-up already ran in this session and stopped at the Phase 4 harness gate, this invocation is a RESUME, not a fresh close-out. Say Resuming wrap-up at the harness gate. then run ONLY: the harness (Phase 2 check 2), the Phase 4 gates, commit and push, and Phase 6. Skip Phases 2 and 3 otherwise, and skip Phase 5 unless Ane asks for it. Their findings have not changed, and re-deriving them is the largest avoidable cost in the close-out: the 2026-07-28 local-analyst-mirror-freshness-check row logged two wrap-up passes plus the cost-log reconciliation, which almost exactly doubled the session spend. A resume is one harness run and a commit, not a second session review.

Phase 2 — Gather (read-only checks)

1. Git status Run git status --short. For unpushed commits, run git log --oneline "@{u}.." 2>/dev/null. If the branch has no upstream (git rev-parse @{u} fails), say so explicitly: nothing is pushed yet, and the push step will set -u. Do not report "all pushed" when there is no upstream. Report uncommitted files (count + list), unpushed commits (count + list), and the current branch. If both are clean, state that clearly.

Committed and pushed is not the same as landed. git status and @{u}.. both measure against the branch you happen to be on, so a session whose work sits on a feature branch reports nothing uncommitted, all pushed while the branch that actually gets consumed still holds the old content. This matters whenever the session's purpose is what some other surface reads: a mirror, a published default branch, npx skills add (which installs from the default branch, not from yours), a deploy, or a release. So when the session's work was meant to change what a remote publishes, verify against origin/<default-branch> rather than the local checkout, and state in the report which branch you checked. Evidence (2026-08-03, github-migration-runbook-and-preflight-cleanup): two repos were on a wave0-skill-fixes branch; every cleanup commit reported success while origin/main still carried all 25 files the session had removed and the personal project name in 5 more. Both repos read clean at wrap-up. Had the IPPF mirror run that day it would have copied everything the session existed to remove. Cheap check, two lines: git ls-tree -r --name-only origin/main -- <path-that-should-be-gone> | wc -l and git rev-list --left-right --count origin/main...HEAD.