docs: order the wiki step before the merge, not after it

CLAUDE.md

@@ -10,9 +10,9 @@ The main Claude session acts as the **task manager** and does not implement issu
 2. **Document the final plan on the issue**: Once approved, the plan is posted as a comment on the issue before implementation starts (skip if the issue body already contains the full plan; later decisions go there as comments too).
 3. **Delegate implementation**: After approval, the manager launches a dedicated **development agent**. The agent implements the issue completely on its own branch and opens a PR.
 4. **PR comment handling by the agent**: After opening the PR, the development agent watches it for review comments. New comments are addressed automatically (code changes, reply on the thread), and addressed threads are marked as **resolved**.
-5. **Agent lifetime**: The development agent terminates itself once its PR has been merged (or closed).
+5. **Update the wiki — mandatory, and before the merge is requested.** The wiki is this repo's knowledge base; a change that lands in `main` while the wiki still describes the old state has not been finished, it has been half-finished in a way nothing fails on. The development agent edits the affected pages as part of its issue, so code and documentation are reviewed together. See "The wiki" below for what obliges an edit and what does not.
-6. Only after the PR has been **merged by the user** may work on the next issue begin. The user merges; never merge yourself.
+6. **Agent lifetime**: The development agent terminates itself once its PR has been merged (or closed).
-7. **Update the wiki — mandatory, in the same round of work as the change.** The wiki is this repo's knowledge base; a change that lands in `main` while the wiki still describes the old state has not been finished, it has been half-finished in a way nothing fails on. The development agent edits the affected pages **before** asking for the merge, so code and documentation are reviewed together. See "The wiki" below for what obliges an edit and what does not.
+7. Only after the PR has been **merged by the user** may work on the next issue begin. The user merges; never merge yourself.
 8. **After the merge, verify the linked issue was closed** (auto-close via "Fixes #n"); close it manually if not. Gitea auto-closes on the same keywords, but only for an issue in the same repository — a migrated issue whose number changed is closed by hand. Check in the same step that the wiki edit really landed.
 
 Additional rules for all commits, PRs, issues, and comments: