docs: stack-dev - Issue-Abschluss als nummerierter Schritt 5, Routing-Blurb rebalanciert (4.3.2, #45)

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/stack-dev/SKILL.md

instructions/dev/stack-dev/SKILL.md

@@ -45,9 +45,10 @@ stack development happens in the origin repo instead (see AGENTS.md's routing li
    [issue-tracking.md](../issue-tracking.md) - open work lives in Gitea issues, one per work
    package, labelled `area/`, `kind/`, `prio/` and `size/`. There is no `TODO.md`. **The body
    of the issue you are working on is this session's plan file:** keep it current as the state
-   moves, not at the end, so an interrupted session leaves a body the next one can resume from.
-   Read it before filing something for later, before editing or closing an issue, or before
-   deciding what to pick up next.
+   moves, so an interrupted session leaves a body the next one can resume from, *and* rewrite it
+   to its final state before closing. Both halves bind; the second is step 5 below. Read it
+   before filing something for later, before editing or closing an issue, or before deciding
+   what to pick up next.
    [testing-conventions.md](../testing-conventions.md) - the suite runs against a deliberately
    empty machine; what the autouse fixture already neutralizes, and what a test still has to
    establish itself. Read it before adding or changing a test.
@@ -104,6 +105,29 @@ stack development happens in the origin repo instead (see AGENTS.md's routing li
    `VERSION` additionally triggers a tagged release. **CI does the tagging** - a session never
    creates a tag, which is what keeps AGENTS.md invariant 5 intact.
 
+5. **Close the issue with a body rewrite, not a comment.** The last act of a session that
+   finished a work package, and the one most easily skipped: by here the change is published and
+   the issue feels done. It is not. The body is the version everyone reads afterwards and nobody
+   revisits, so it is the one place the debt comes due at the worst moment.
+
+   Rewrite it to its final state *first*, then close. The test is what a reader who opens the
+   closed issue tomorrow would conclude:
+
+   - every acceptance criterion ticked, or struck with the reason it was dropped
+   - proposals that were decided read as decided; a "to decide" section has become the decision
+     and its reasoning
+   - nothing left in the present tense about a defect that no longer exists
+   - what was verified is named - which checks ran, which CI run - not a commit hash alone
+
+   Then one short comment naming what changed against the previous state, and nothing else.
+
+   **A closing report in a comment does not satisfy this**, however thorough: it reads as
+   complete to whoever writes it and leaves a body still phrased as open work. Nothing
+   mechanical catches it - `wikitool` does not know this tracker exists and must not learn it,
+   since it ships to instances that have no board - so this step is the only enforcement there
+   is. #44 and #45 both closed exactly this way, the second an hour after the rule was written.
+   [issue-tracking.md](../issue-tracking.md) step 7 has the full shape.
+
 ## Decision points
 
 - **Touches both stack code and wiki content in one session?** Apply this skill's rules to the