stack-close: wait for CI via the authenticated Gitea connection, with timings and a give-up point

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

instructions/dev/stack-close/SKILL.md

@@ -71,6 +71,23 @@ and a fresh subagent starts without the session's context).
    `instructions/dev/issue-tracking.md` steps 2-3 and 7 have the full shape; this is that
    procedure, run at the point this skill exists to guarantee it actually gets run.
 
+   **Close only once CI on the published commit is green, and wait for it this way.** The
+   push-triggered runs take about **4 minutes**; a push that moved `VERSION` to a suffix-free
+   release adds about **1 minute** for the release job. So:
+
+   - Read the runs for the published commit's SHA through the authenticated Gitea connection
+     `ENVIRONMENT.md` lists (the Gitea MCP's `actions_run_read`, `list_runs`), right after
+     `publish`, to get their ids. **Never anonymously via `curl`:** Gitea answers the Actions
+     API with `401 token is required` even for this public repo.
+   - Check again after about 4 minutes (5 with a release job), then once a minute.
+   - **Give up after 15 minutes** and hand the open runs to the user by id and link, rather than
+     waiting on.
+   - Any shell loop that polls instead must **end on the first non-2xx status or missing field**
+     and print the raw response. A loop that treats an error as "not finished yet" never ends;
+     that happened in the #139 close-out.
+
+   A red run is not closed over: report it, and the package stays open until it is fixed.
+
    **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, which is why this is a step - and now a whole skill - rather than a habit. #44 and