task: Weekly review proposes task new/task close; tracker gains a closing write path

Files changed:
- CHANGES.md
- INSTALL.md
- README.md
- VERSION
- docs/knowledge-and-commitment.md
- instructions/gtd-weekly-review/SKILL.md
- instructions/ingest-large-tree.md
- instructions/wiki-ingest/SKILL.md
- tools/CONTRACT.md
- tools/chemenu/commands/review_cmd.py
- tools/chemenu/commands/task_cmd.py
- tools/chemenu/review.py
- tools/chemenu/tasks/protocol.py
- tools/chemenu/tasks/superproductivity.py
- tools/chemenu/tests/test_review.py
- tools/chemenu/tests/test_superproductivity.py
- tools/chemenu/tests/test_task_cmd.py

docs/knowledge-and-commitment.md

@@ -93,7 +93,7 @@ open right now. Anyone wanting the second reads the tracker, or runs the review.
 
 This pays for itself somewhere unexpected: with the page carrying no task state, an agent has no
 reason to read the task list at all outside the weekly review. That is what keeps the command
-surface as small as it is - one read command and two creation commands - rather than growing a
+surface as small as it is - two read commands and three write commands - rather than growing a
 full CRUD tree over somebody's todo list. The second creation command exists because a single
 name is not always the whole story: a source can carry a piece of durable knowledge and a
 commitment to follow up on it at the same time - a complaint arriving by email is both something
@@ -111,6 +111,15 @@ the ordinary case avoids becomes, there, the expected condition for as long as t
 a failure on the knowledge side afterwards is exactly the ordinary "a source without a page" state
 `lint` already reports.
 
+The write surface stops at *creating* an item and *marking one done* - it never moves a reminder
+and never deletes anything. `task close` sets exactly the field the tracker's own "done" checkbox
+sets, nothing more: reversible, and it leaves a record in the tracker rather than removing the
+item's trace. A command that deleted would take the same shortcut through somebody's task list
+that the whole split above exists to avoid - a write this stack cannot undo, made on behalf of a
+tracker it does not own. `task list` is the one addition on the read side, and it changes nothing
+about the join itself: it exists only because closing an item needs the tracker's own id for it,
+and that id was never worth exposing before there was a write that consumed it.
+
 ## A finished initiative is a state, not a location
 
 Archiving moves nothing. A completed initiative's page stays where it is and changes its `state:`