Session Resume — pick up where you left off

Absolute rule: a restarted session continues the work, it does not redo it. The source of truth is the PROGRESS.md file at the project root, not the session memory.

When to apply

• At the start of a session on a project that already exists (non-empty folder).
• After a context compaction (automatic summary) — the summary may be incomplete; PROGRESS.md wins.
• When creating a new project: create PROGRESS.md at the very first step.
• When the user says "resume", "continue", "where were we", or types /session-resume.

Procedure on restart

1. Look for PROGRESS.md at the project root (ls PROGRESS.md).
2. If it exists: read it in full BEFORE any other action. Locate the "Current step" and "Remaining" sections.
3. Quickly check that the disk matches (files mentioned are present, last commit if git). Do not redo a full exploration.
4. Tell the user in 2-3 lines: what is done, which step you are resuming. Then continue that step directly.
5. If it does not exist on a non-empty project: rebuild the state from the real files (a code-graph tool for a medium/large repo, otherwise ls -R plus reading the key files), create PROGRESS.md, then continue.

Forbidden after a restart:

• Regenerating a file that already exists and works.
• Re-asking a question already settled in PROGRESS.md ("Decisions" section).
• Reinstalling dependencies already installed, re-running a setup already done.
• Starting from a new plan while ignoring the one in the file.

PROGRESS.md format

# <Project name> — progress

Last updated: YYYY-MM-DD HH:MM

## Goal
One or two sentences: what the project must produce, for whom.

## Current step
A single precise line: what is being done right now, file involved, what is missing to finish it.

## Done
- [x] Step 1 — files: ...
- [x] Step 2 — ...

## Remaining
- [ ] Step 3 — ...
- [ ] Step 4 — ...

## Decisions
- Technical choice / user answer, with the reason. Do not ask again.

## Useful commands
- Run: `...`
- Test: `...`

## Pitfalls hit
- Problem → fix applied.

Updating while working

• Update PROGRESS.md after every significant step (file created, feature working, decision made), not only at the end. A reset can happen at any time.
• Always update the "Current step" line before starting a long step.
• Keep the file short (< 80 lines): it is a logbook, not documentation. Details belong in the README or the specs.
• Date the last update.