Update Backlog

When to run

• At the end of every working session
• After completing, partially completing, or abandoning a backlog task
• After discovering a new issue or design decision worth tracking

Procedure

1. Identify changes from the session

Review the conversation and extract:

• Tasks that were fully completed → move to ### Done under the correct section, using [x]
• Tasks that were partially completed → keep under the section with [ ], add a note like (in progress — [what remains])
• Tasks that were abandoned or put on hold → keep with [ ], update or add — on hold with a short reason
• New tasks or issues discovered → add under the correct section with [ ]
• New design decisions → these belong in ARCHITECTURE.md, not the backlog; flag them separately for the user

2. Determine the correct section

Each task belongs to one of:

• ## Project-wide — affects the whole project or no specific class/module
• ## ClassName — specific to a class or module

Add a new section if a new class or module was introduced this session.

3. Write the update

Follow the existing format exactly:

- [ ] Task description — optional note
- [x] Completed task description

• One task per line
• No sub-bullets
• Short, imperative phrasing ("Create", "Fix", "Implement", "Change")
• If a task has a dependency or constraint, append it after — (e.g. — on hold, — blocked by X)

4. Present the diff to the user

Before writing, show the user:

• What you are marking as done
• What you are adding
• What you are modifying

Ask for confirmation if anything is ambiguous.

Format reminder

The full structure of BACKLOG.md is:

# Backlog — [project name]

Pending tasks and known issues, grouped by class or module. Update this
file at the end of each session.

---

## Project-wide
...

## ClassName
...

---

## Done

### ClassName
- [x] ...

Preserve all existing content. Only add, tick, or annotate — never delete.