Update Board

At an appropriate point in a working session, read the boards and the recent git history, then propose which items should move, be added, or be removed. Present the proposal to the user first. Only after approval, apply the changes. Never move items silently.

Step 1 — Read the current state

Read all three board files:

workspace/boards/tasks.html
workspace/boards/bugs.html
workspace/boards/backlog.html

Also read the recent git log and the current session's history entry (if one exists) to understand what was actually completed.

Step 2 — Propose changes

Present a clear proposal to the user before touching any file. For each proposed change, state the item name, the board, and the action:

• Move to Done — task or bug that was completed this session
• Move to In Progress — task that was started but not finished
• Move to To Do — new task worth adding now
• Remove — item that is no longer relevant
• Add to Backlog — idea or future work surfaced during the session

Also note whether Update Outline should be run — recommend it when new systems, subsystems, or conventions were added that the outline does not yet describe.

Wait for the user to confirm before continuing.

Step 3 — Apply the changes

After the user approves the proposal, edit the board HTML files accordingly. Use the correct colour class for each lane:

• class="green hide-content" — Done (Tasks)
• class="red hide-content" — Critical (Bugs)
• class="yellow hide-content" — In Progress (Tasks) or Visual/UI/UX (Bugs)
• class="blue hide-content" — To Do (Tasks) or MVP (Backlog)
• class="purple hide-content" — Nice To Have (Backlog)
• class="orange hide-content" — To The Moon (Backlog)

Keep the Done lane in Tasks focused — if it grows beyond three or four items, ask the user whether old Done items should be cleared out.