[HugoXK]

Timeline: list the requests waiting longest

#469 wants a "waiting too long" signal. The timeline window flagged waiting requests per edge but never listed them, so a stuck Bot-to-Bot handoff was easy to miss. timeline/window now carries stuck: the open requests, sorted by waited time, worst first (up to 20), each with its ids, role and waitedMs. Read-only, ids only.

Ran at the tip: npm run verify (green, TZ=UTC), node scripts/lint-plugins.mjs timeline (0 errors). Not run: smoke, Desktop, real-model steward.

[Birfy]

Review (Birfy, 2026-10-20 20:07 Asia/Shanghai): PASS (code) — held for the owner's confirmation of #534

Tip SHA: d423209
Ran:

• npm --prefix plugins/timeline test (TZ=UTC) → pass (94/94)
• node scripts/lint-plugins.mjs → pass
• CI tests-ok at this tip → green
  Not run:
• core suite / smoke / Desktop — plugin-only change, CI ran the full suite at this tip
  Verdict: PASS

Findings (non-blocking, for the owner's decision):

1. stuck is built from the window's exchanges, so an open request sent before the window start is not listed. A "waiting longest" list can miss the oldest stuck handoff. Consider scanning open requests in the whole trace, or say it is per window.
2. waitedMs is measured to now even when a past window (to < now) is viewed. That's honest for an open request, but worth a line in the doc.
3. Nothing in the panel reads stuck yet, so for now it's payload only. This is different from the Remind about approvals waiting 15 min, switch each notification kind, one notification per chat #492 approval reminder (approvals, not Bot-to-Bot requests).

#534 is a new feature the owner has not confirmed yet, so this is not merged regardless of tier. It shares the same window.js return line / doc row as #531/#537/#539. This is not merge authority.

[Birfy]

@HugoXK Owner decision (2026-10-20 21:09 Asia/Shanghai): accepted. Required change: also show the waiting-longest (stuck) list in the dashboard/panel, not only in timeline/window.

[Birfy]

Waiting for approval. tests-ok is green at the tip and the PR is mergeable, so it is labeled awaiting-approval.

It needs (1) the owner's approval through the GitHub UI (a chat reply does not count) and (2) a review PASS at the exact tip SHA; any new commit voids both.

Automation does not merge T2/T3 by itself and does not approve on the owner's behalf.

[Birfy]

PASS — tip d42320935879be7e9b82cd02db5d105aa904482c (Maintainer review, acting as Birfy)

Design check: no change to Bot authorization, to the approval path (still a UI button only) or to user-facing English text; the new surface is read-only and part of the existing answer.

Local evidence: I applied this PR's diff to my local main snapshot and ran the touched tests there (TZ=UTC), plus node scripts/ds-bot-patches.mjs check (with the new files staged, as a commit would):

• plugins/timeline: node --import ./test/resolve.mjs --test test/window.test.js → 22/22 pass
• node scripts/ds-bot-patches.mjs check → ok

stuck keeps only open handoffs, sorts worst-first, caps at 20, and waitedMs is floored at 0.

Not run locally: the full npm run verify in one shot (this box has a 2 GiB memory cap, so I run the steps one at a time), the smoke test, Desktop, and the real-model steward.

CI: tests-ok is green at the tip SHA above (GitHub Actions ran the full suite there).

Tier: T2/T3, so this PASS does not approve the PR: the owner still has to approve it through the GitHub UI, and any new commit voids both the approval and this PASS. Not merged by automation.

[Birfy]

Verdict: PASS at 77725ec

Tip SHA: 77725ec6be0183901e98062116e56b5f45943e5e
The tip moved (rebased onto current main); the PASS at d4232093 is void. Read the whole new diff: plugins/timeline/src/window.js (+9 -1, a `stuck` list of open waits inside the existing timeline/window answer), test/window.test.js (+8), one docs/subsystems/timeline.md row, one changelog fragment. Nothing else changed.
Design: read-only and additive — `stuck` is another field of the same answer, worst-first, capped at 20, waitedMs floored at 0, ids/labels from the existing cleaners; no new endpoint, no config, no user-facing string, no new approval path.
TDD: the new test reads `win.stuck`, which does not exist at the base window.js — 0 pass / 1 fail with only window.js reverted, and it passes with the change.
Ran at the tip: CI tests-ok green at this SHA (test, plugins tree/social/timeline, package all success). On a copy of current main with this diff applied: plugins/timeline 96/96 (TZ=UTC), changelog.mjs check OK.
Not run: one-shot npm run verify (2 GiB OOM), core suite, smoke, Desktop.

Tier: T2. Awaiting the owner's click in the GitHub UI plus this PASS at the tip. Any new commit voids this PASS. Note: #531/#535/#539 all touch the same return line in window.js and the same docs row, so after one of them merges the other two will need a rebase, not a new PASS at a stale tip.

[Birfy]

Do not approve this tip — it no longer merges. #531 landed on main (03bfc468) and it changed the same line of plugins/timeline/src/window.js (return { … usage }) and the same docs/subsystems/timeline.md table row this branch edits, so the PR is now dirty against main: a local 3-way merge conflicts in window.js, window.test.js and timeline.md.

The PASS at 77725ec6 stays valid for the content, but a PASS is only half the gate — the other half is a mergeable tip. Please merge main into the branch (or rebase) and push; I will re-review the new tip and post a fresh PASS there. Merging main in is the fix; no code change is needed.

(Same for #539 and #568: all three carry a row of the same timeline doc table, so after #531 only one of them can merge without a rebase. #568 has the same note.)

[Birfy]

Verdict: PASS at c13ba07

Reviewed again at this tip: the branch was rebased onto main 33fb55ed, so the previous PASS (77725ec6) is void.
Diff (4 files, +19 -2): `plugins/timeline/src/window.js` adds `stuck` (open request arrows with `waiting`, worst first, capped at 20, `waitedMs` floored at 0) to the window it already builds; the new test in `plugins/timeline/test/window.test.js`; the `window.js` row of `docs/subsystems/timeline.md` now reads "...per-Bot outcomes and recent failures (#471) and the open requests waiting longest (#469)" — the rebase kept #531's wording; new `changelog.d/timeline-stuck.added.md`.
The rebase carried no behaviour change: the only difference from the version I reviewed at 77725ec6 is the docs row, which now sits on #531's line.
Ran at the tip: CI tests-ok green (test, plugins tree/social/timeline, package, Node 24). On a copy of this PR's own base with the whole diff applied: `ds-bot-patches.mjs check` OK (10 patches, core == ds-bot + patches), `check-arch-docs.mjs` OK (4 files), `changelog.mjs check` OK (12 fragments), plugins/timeline 97/97, `scripts/lint-plugins.mjs timeline` 0 errors / 8 warnings, TZ=UTC.
TDD: with only `window.js` at the base commit, the new "stuck" test fails and the rest of window.test.js 23/24 pass; all 97 pass with the change.
Conflicts: with #539 (both edit the same return line of `window.js`, the same `timeline.md` row and the same test file) and with #568 (`timeline.md`). Clean with main, #566, #572, #574, #578, #580. Only one of the timeline trio (#535, #539, #568) can land per cycle; whoever does not land needs a rebase and a fresh PASS.

Not run: one-shot npm run verify (2 GiB OOM), full core suite, smoke, Desktop, a real model call.
Merge matrix (local 3-way merges against main 33fb55e and against every other open PR): see the lines above; every claim is measured, not assumed.
Tier: T2 (plugins/**, core/src/host/**, core/types/**). The owner's own click in the GitHub UI is the approval and this PASS must sit on the tip; I do not approve or merge it myself. Any new commit voids this PASS.

[Birfy]

One precision on the PASS above: I could not byte-diff the pre-rebase branch (the force-push removed the old commit), so "the only difference is the docs row" is my reading of the source hunks against my review notes for the old tip, not a diff I could run. What is verified at the new tip is everything else in the PASS: the full check set, the plugin test suite and the red-without-fix run were all redone here.

[Birfy]

Superseded by #586 (one combined timeline change, at main 33fb55ed).

The maintenance round merged this PR's change, its test and its docs wording into #586 together with #535 and #568, because all three edit the same window.js return line and the same timeline.md row: the owner then gets one PASS and one click instead of one merge plus two rebases. Your authorship is recorded in #586's body and in this thread; nothing of your work is dropped.

Closing this PR as superseded. Thank you for the original — the tests and the docs row came through unchanged.