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

instructions/gtd-weekly-review/SKILL.md

@@ -17,14 +17,20 @@ looked at yet.
 
 **Provider-neutral by design.** Nothing below names a task-tracker provider, a file format or an
 API - only the tracker's generic role. That is deliberate: this skill is the one document that
-must read identically in every instance, whichever tracker it runs against. Anything the tracker
-itself must do - add a task, reschedule a reminder, remove an item - is described as an action the
-user takes in their tracker: a deliberate choice, not a gap in `wikitool`'s GTD command surface,
-which also carries `task new` (tracker item only, no page) alongside `review` (read-only) and
-`new project` (page + tracker project creation) - this skill simply does not call it. The
-reasoning behind keeping the tracker and `kb/gtd/` on separate write paths lives in
-`docs/knowledge-and-commitment.md`, which this skill does not repeat - do not reach for a
-tracker-specific tool or API to "just do it faster".
+must read identically in every instance, whichever tracker it runs against.
+
+**What this skill may write to the tracker, and what it may not.** `wikitool`'s GTD command
+surface offers exactly two tracker-side writes - `task new` (create one item) and `task close`
+(mark one item done, never delete it) - alongside `review` (read-only) and `new project` (page +
+tracker project creation). This skill proposes both writes at the specific findings below, always
+after the user confirms the exact call, never on its own initiative - the same posture
+`wiki-ingest` takes toward its own commitment question ("propose one and let the user confirm or
+correct it"). Everything else a tracker item can need - moving a reminder forward, removing an
+item outright - stays the user's own action in their tracker: that is a deliberate line, not a gap
+in the command surface waiting to be filled. Do not reach for a tracker-specific tool or API to
+"just do it faster" for either half. The reasoning behind keeping the tracker and `kb/gtd/` on
+separate write paths, and behind stopping at "create" and "mark done" rather than a fuller CRUD
+surface, lives in `docs/knowledge-and-commitment.md`, which this skill does not repeat.
 
 ## Steps
 
@@ -48,11 +54,11 @@ tracker-specific tool or API to "just do it faster".
 
    | Check | What fired | Options | How to tell them apart |
    |---|---|---|---|
-   | `stalled` | A tracker project has zero open items and its `kb/` page is `state: active` | (a) A next action is genuinely missing - add one in the tracker. (b) The initiative is deliberately paused - `tools/wikitool touch --page "<Title>" --set state=dormant`. (c) It is actually finished or given up on - `--set state=completed` or `--set state=abandoned` | Read the page's `## Ziel` and `## Status` sections and ask the user directly: is there still a next step toward that goal, or did this stop for a reason? A pause that was never decided is (a); a pause that *was* decided is (b), never left as `active` with nothing moving |
-   | `waiting_overdue` | A `WAITING` item's `follow_up_at` is older than the threshold | (a) Follow up now, then move the reminder forward in the tracker. (b) The commitment is no longer needed - remove or close it in the tracker | Did the person the item names actually come through, and is the ask still relevant? If yes but late, (a); if the need has passed, (b) - never leave the same stale date standing unexamined |
+   | `stalled` | A tracker project has zero open items and its `kb/` page is `state: active` | (a) A next action is genuinely missing - propose `tools/wikitool task new --title "<title>" --project "<project>"` with a title the user confirms or corrects, asked as one combined question ("Create '<title>' in project '<project>'?"), then run it once confirmed. (b) The initiative is deliberately paused - `tools/wikitool touch --page "<Title>" --set state=dormant`. (c) It is actually finished or given up on - `--set state=completed` or `--set state=abandoned` | Read the page's `## Ziel` and `## Status` sections and ask the user directly: is there still a next step toward that goal, or did this stop for a reason? A pause that was never decided is (a); a pause that *was* decided is (b), never left as `active` with nothing moving |
+   | `waiting_overdue` | A `WAITING` item's `follow_up_at` is older than the threshold | (a) Follow up now, then move the reminder forward in the tracker - the user's own action, there is no `wikitool` command for it. (b) The commitment is no longer needed - propose `tools/wikitool task close --id "<id>"` (the finding's own `item_id`), asked as one combined question naming the item's title and id, then run it once confirmed | Did the person the item names actually come through, and is the ask still relevant? If yes but late, (a); if the need has passed, (b) - never leave the same stale date standing unexamined |
    | `unpaged_project` | A tracker project has no `kb/` page, past the age threshold | (a) It has grown a memory worth keeping (participants, decisions, context) - `tools/wikitool new project --name "<Name>" --set responsibility=<area>`. (b) It genuinely never needs one - confirm and leave it tracker-only | Ask: would anyone, including the operator in six months, need to know *why* this exists or who is in it? If yes, (a); a project that is fully explained by its own title and task list stays (b) |
    | `no_open_loop` | A `kb/` page is `state: active` but its tracker project is missing or empty | (a) Same three options as `stalled` above. (b) The name diverged - a rename happened on one side only | Before assuming a stall, check whether a *similarly* named tracker project exists. If it does, this is `instructions/page-lifecycle.md`'s rename case (`tools/wikitool rename` for the page, plus renaming the tracker project to match), not a state change - the review reports both directions of a rename so it never has to be inferred silently |
-   | `someday_stale` | A someday/maybe item has not been touched past the threshold | (a) Activate it - give it a page with `tools/wikitool new project` if it is ready to become a committed initiative. (b) Strike it - remove it from the tracker. (c) Leave it - still genuinely "maybe" | Would the user commit to starting this today? If yes, (a). If it no longer belongs on the list at all, (b). If it is still worth keeping but not yet, (c) is a legitimate answer, not inaction - do not force a decision the user is not ready to make |
+   | `someday_stale` | A someday/maybe item has not been touched past the threshold | (a) Activate it - give it a page with `tools/wikitool new project` if it is ready to become a committed initiative. (b) Strike it - propose `tools/wikitool task close --id "<id>"` (the finding's own `item_id`), asked as one combined question naming the item's title and id, then run it once confirmed. (c) Leave it - still genuinely "maybe" | Would the user commit to starting this today? If yes, (a). If it no longer belongs on the list at all, (b). If it is still worth keeping but not yet, (c) is a legitimate answer, not inaction - do not force a decision the user is not ready to make |
 
 3. **Record what was decided or learned on the page - never the task list.** A decision made this
    week (a scope cut, a direction change) goes under `## Entscheidungen`; something that showed
@@ -87,14 +93,12 @@ tracker-specific tool or API to "just do it faster".
 
 ## wikitool commands used
 
-`review`, `touch`, `new project`, `rename` (via `instructions/page-lifecycle.md`, only for the
-rename case), `publish`
+`review`, `touch`, `new project`, `task new`, `task close`, `rename` (via
+`instructions/page-lifecycle.md`, only for the rename case), `publish`
 
-**Deliberately absent:** anything that reaches into the task tracker directly. `wikitool`'s GTD
-surface also includes `task new` (tracker item only, no page -
-`docs/knowledge-and-commitment.md`), but this skill does not use it: every tracker-side action in
-the table above - adding a next action, moving a reminder, removing an item - is something the
-user does in their tracker, not something this skill automates.
+**Absent:** moving a reminder forward, and removing an item outright - both stay the user's own
+action in their tracker. See "What this skill may write to the tracker, and what it may not"
+above for why the line sits exactly there.
 
 ## Output