Repository navigation
docs(#4577): the 2026-09-17 reopen wave, measured — 0 to re-close, 3 genuinely live, 41 stale-but-post-close - #4637
Merged
Conversation
…n it may be re-closed The brief was to unwind the wave by recency and re-close what was reopened on stale evidence. Measured per issue, the residue does not partition that way, and the honest answer is that NOTHING here may be closed on the evidence available. DENOMINATOR. Of core's 102 open issues, 51 carry a `reopened` event inside the 07:51:00Z–07:53:59Z burst; all 51 were closed BEFORE 2026-09-17 (50 by rbuergi, 1 by github-actions[bot]). Eight further 2026-09-17 reopens sit outside the burst — one of them by a HUMAN (#1198) — and none was touched. The rest of #4577's ~130 was already unwound by earlier sessions. FIRST AXIS (the authorised close predicate, Plugins#2014: `LastSeen > ClosedAt`): 51 of 51 pass. ZERO have a newest occurrence at or before the close they reverted, so zero qualify for a re-close and zero were closed. The residue is already clean by the only rule that authorises reversing a bot reopen. SECOND AXIS (recency — the predicate that is missing): 3 were seen TODAY, 7 within a week, and 41 had been quiet for 8 to 37.4 days at the moment the bot said "happening again". THAT is the dishonesty in the count, and no proposed predicate reaches it: these faults were seen after their close, and then stopped. THE THREE THAT ARE LIVE — #1549, #2299, #2765 — each have an occurrence on 2026-09-17 (11:11Z, 11:28Z, 14:25Z) reported from `memex-portal-deployment-6c967c7c4c-*`, the running replica, on an image that contains the August fix that closed them. They are the wave's entire signal and they stay open. AWAITING DELIVERY is empty IN THIS WAVE, by construction: the newest close in the population is 2026-09-08, while the portals run afde4ea (09-15) and c84c6c0 (09-12), so every fix that closed a wave issue is in both running images by at least four days. The genuine awaiting-delivery cases today are the two reopened OUTSIDE the wave whose fixes merged 2026-09-16 — #4616 and #4464. A THIRD PREDICATE, stated as inferred: 15 of the 51 have their ONLY post-close evidence within 17 hours of the close and nothing in the weeks since. The likely mechanism is the close racing the roll — a fix closes its issue at MERGE while the old replicas keep emitting until DELIVERY — which would make the right test "seen on an image containing the fix", not "seen after the close". Confirming it needs a pod→image mapping the incident comments do not carry, so it is written up as inferred, not measured. Read-only throughout: no issue in the wave was closed, reopened, commented on or labelled. Method and the full 51-row evidence table are in the page. Green: MeshWeaver.Documentation.Test 562/562 (link integrity + topic map). `dotnet build -c Release -warnaserror` clean (0 Error(s)) on MeshWeaver.Documentation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Sep 17, 2026
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The only noted issue is a minor labeling clarification that does not block approval.
Pull request overview
Adds documentation analyzing the 2026-09-17 issue-reopen wave and links it from the architecture index.
Changes:
- Documents reopen predicates, methodology, and evidence.
- Records the 0/3/41 issue breakdown.
- Adds the analysis to the Architecture index.
File summaries
| File | Description |
|---|---|
src/MeshWeaver.Documentation/Data/Architecture/ReadingARecurrenceReopen.md |
New recurrence-reopen analysis |
src/MeshWeaver.Documentation/Data/Architecture.md |
Adds the architecture index entry |
Review details
Suppressed comments (1)
src/MeshWeaver.Documentation/Data/Architecture/ReadingARecurrenceReopen.md:61
- The bucket labels are internally ambiguous: “seen within 7 days” normally includes the 3 issues “seen today”, but the counts are clearly intended to be mutually exclusive because 3 + 7 + 41 = 51. Readers cannot tell whether the 7 excludes today; label it explicitly as the prior 1–7 days (or “within 7 days, excluding today”) so the reported partition is reproducible.
| bucket | count | what it means |
|---|---|---|
| **seen today**, after the reopen itself | **3** | genuinely live — the fault is happening now |
| seen within 7 days of the reopen | 7 | recently live; quiet for 5–7 days |
| **quiet for 8–37 days** at the reopen | **41** | "again" is a statement about a counter |
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
I wrote that all three are "on an image that contains the August fix that closed the issue", and that a wave issue that recurs "is recurring against its own fix". Checking the artefact that would falsify that — each issue's closing comment — only ONE of the three survives it: - #1549 closed with an explicit verdict: "the defect this issue converged on is fixed and deployed", residual named. A recurrence today IS against a delivered fix. - #2765 closed as "a single transient with no code defect identified, and the retry model worked". No fix exists to recur against — what today's occurrence falsifies is the "single transient" premise (the record now stands at 1,069). - #2299 was closed with NO comment at all and no linked fix. Today's occurrence is the first evidence either way. All three are still live and still stay open; what changes is what each recurrence MEANS, which is the part a reader acts on. The delivery argument is narrowed to what it actually establishes — that no wave issue can be excused as delivery lag — with the separate question of whether a close carried a fix answered per issue. Green: MeshWeaver.Documentation.Test 562/562. `dotnet build -c Release -warnaserror` clean (0 Error(s)) on MeshWeaver.Documentation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… adds them #4577 (~130, written 08:54Z, backlog 43 -> 164) and #4610 (~51, written 15:37Z, backlog 46 -> 97) describe the same 2026-09-17 morning reopen: #4610's window sits INSIDE #4577's, and the backlog figures differ only because re-closing happened in between. A third reading at ~17:30Z finds 102 open and 51 from the burst — matching #4610 exactly, by a different instrument (it counted `updated_at` inside 07:40–08:15Z; this counts `reopened` events). Left unsaid, a reader adds the two tickets and carries ~181 issues of damage into the next burn-down — roughly threefold. The page now names it, which is the whole point of writing the count down. Green: MeshWeaver.Documentation.Test 562/562. `dotnet build -c Release -warnaserror` clean (0 Error(s)) on MeshWeaver.Documentation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The task was to unwind the 2026-09-17 reopen wave by recency and re-close what was reopened on stale evidence. Measured per issue, the residue does not partition that way — and the honest answer is that nothing in the wave may be closed on the evidence available. Zero issues were closed, reopened, commented on or labelled by this change.
Denominator
Of core's 102 open issues, 51 carry a
reopenedevent inside the 07:51:00Z–07:53:59Z burst. All 51 were closed before 2026-09-17 — 50 byrbuergi, 1 bygithub-actions[bot].Eight further 2026-09-17 reopens sit outside the burst (#2387, #4222, Systemorph/MeshWeaver.Plugins#2156, #3712, #1198, #1840, #1561, #1140); #1198 was reopened by a human. None was touched. The remainder of #4577's ~130 had already been unwound by earlier sessions, which is why the residue is 51 and not 130.
First axis — the predicate that authorises a re-close
MeshWeaver.Plugins#2014's rule is
issue.ClosedAt is { } closedAt && incident.LastSeen > closedAt. Taking, per issue, the bot's ownLast seen:from the comment it posted alongside the reopen, and theclosedevent that reopen reverted:0 of 51 qualify, so 0 were re-closed. The residue is already clean by the only rule that authorises reversing a bot reopen — two earlier sessions took the ones that were not.
Hand-verified against the raw API for #1109, #1127 and #2152 (single close, single reopen,
Last seenread from the reopen comment itself).Second axis — recency, which is the missing predicate
Newest occurrence any comment on the issue reports, against the reopen instant:
The oldest is 37.4 days (#1112, #1135: last seen 2026-08-10, reopened 2026-09-17). That is the dishonesty in the count — and no close predicate anyone has proposed reaches it, because these faults were seen after their close and then stopped.
The three that are live, and stay open
Each has an occurrence on 2026-09-17 reported from
memex-portal-deployment-6c967c7c4c-*, the running replica. 🚨 What each close asserted differs, and that decides what the recurrence means — checking each closing comment is what corrected my first draft, which claimed all three recur "against their own fix":They are the wave's entire signal, and only one of the three is evidence that a fix failed.
Awaiting delivery — empty in this wave, by construction
The newest close in the population is 2026-09-08T21:04Z; memex.systemorph.com runs
afde4ea(2026-09-15 21:50Z) and memex.meshweaver.cloud runsc84c6c0(2026-09-12 09:30Z). Every fix that closed a wave issue is in both running images by at least four days, so no wave issue can be excused as delivery lag — which establishes only that if a close carried a fix, that fix is running. Whether a given close carried one at all is a separate question, answered per issue above.The genuine awaiting-delivery cases today are the two reopened outside the wave whose fixes merged 2026-09-16, after both images: #4616 and #4464. Both were closed earlier today with that measurement in their threads. 🚩 If the convention is that delivery debt stays visible as an open issue rather than a closed one, those two are the ones to reopen — they are outside this wave, so I did not.
A third predicate, stated as inferred
15 of the 51 have their ONLY post-close evidence within 17 hours of the close, and nothing in the 8–37 days since: #2152 (+0.0 d), #3466 (+0.0 d), #2171, #2182, #2679, #3051, #2444, #1112, #1135, #1175, #2233, #3647, #2153, #2876, #3126 (+0.7 d).
Measured: the gap and the silence after it. Inferred: that these are old replicas still emitting between the merge that closed the issue and the roll that delivered it. If so the right test is "was it seen on an image containing the fix", not "was it seen after the close" — which would clear these 15 without weakening the rule for the three that are live. Confirming it needs a pod→image mapping the incident comments do not carry.
The honest triple
wrongly reopened and re-closed: 0 · genuinely recurring: 3 (+7 within a week) · awaiting delivery: 0 in the wave (2 outside it) — with 41 reopened on post-close but 8-to-37-day-old evidence, which is the number the bot's second predicate has to remove.
🤖 Generated with Claude Code