[HugoXK]

Fixes #1578

Owner: Dev-1
Reviewer: Reviewer
Written-by: Dev-1
Risk: T2 — plugins/timeline/src/digest.js is plugin code (.github/agent/risk-rules.json), so this needs a PASS at the tip plus green CI. No T3 path, no dependency change.
Tip SHA: 8139276924c95ec4f30691244c8e4c3d2030ebe0
Tree: bd8db4c70d8271142d4798b42b8405d73ff9953f
Base: c1b9fd23e404dcff1eb782a2269e30e09e2d6993 — live main (#1547, #1572, #1556, #1552, #1573).

What was wrong

The report compared two different populations. plugins/timeline/src/window.js:249 counts turns as the turns that began in the window; :250 counts errors as every overlapping turn whose outcome is error. A failed turn that began before the window is therefore in errors and not in turns, and digest.js divided one by the other: const errorRate = turns > 0 ? errors / turns : 0, printed in three places.

That is exactly the reading docs/subsystems/timeline.md invariant 5 says can never happen — the error rate "divides by the larger of the turns that began in the window and the failed turns, so it never reads a failure count above its turn count" — and plugins/timeline/src/health.js:27-32 already compensates with Math.max(use.turns, use.errors) and a comment naming the failure text it avoids. The digest did not.

Reproduced at main, real buildWindow + buildDigest, 15-minute window, one Bot b1: three turns that begin 3/4/5 minutes before the window and fail 20/21/22 s into it, plus one turn that begins inside it and completes. The window holds 4 turns (outcomes {completed: 1, error: 3}, utilization.turns 1, errors 3), and the report read:

• per Bot: - 1 turns, 3 failed (300%)
• Team: - 1 turns, 3 failed
• one line: 1 turns, 3 failed, 0 tokens in over 07:45–08:00.

The mild shape is worse than a bad percentage: one overlapping failed turn plus one completed turn that began inside the window reads 1 turns, 1 failed (100%), i.e. "the window's only turn failed", when that turn is the completed one. 1 turns was also printed everywhere.

What changed

plugins/timeline/src/digest.js only — three lines of arithmetic and the three printers:

• counted = Math.max(turns, errors), and errorRate = errors / counted, the same denominator health.js uses. counted is now on each bots[] entry and on team, so a consumer can read the number the share was taken over; turns and errors keep their raw window values.
• The per-Bot line, the ## Team line and the one-line summary all print counted, so the number compared with the failure count is the number printed, and the Team rollup is the sum of the Bot sections, as before.
• The failure flag reads ${errors} of ${counted} turns failed, the wording health.js already uses, and no turns now needs counted === 0 rather than turns === 0 (a Bot whose failed turns all began before the window is not "no turns" and is not reported as one).
• Singular/plural follows the number in all three places (1 turn, 3 turns).
• A share is printed only when it can be a share, i.e. below 100%. With every counted turn a failed one, the numbers cannot say whether that turn began in the window or before it; (100%) beside a window whose single completed turn began inside it reads as its opposite. At that point the report prints the counts and no percentage (3 turns, 3 failed), which is still consistent and never over 100%.

Scope and what I did not touch:

• window.js's two counters are unchanged — they are documented and the panel reads them.
• health.js is unchanged; the digest now matches it instead of diverging.
• plugins/timeline/client.js:588 (the panel's Utilization line, same pair of numbers) is not changed. It prints two raw counts and no rate, so it cannot overclaim a share; changing the count it prints would make the panel disagree with the documented meaning of utilization.turns (invariant 5) that the rest of the panel and health.js rely on. If the owner wants the panel to print the comparison denominator too, it is a separate, one-line change with its own test.
• changelog.d/1578-digest-error-rate.fixed.md added. Docs unchanged: invariant 5 already states the rule this change implements.

Docs-not-needed: docs/subsystems/timeline.md invariant 5 (line 52) already states this rule — the error rate divides by the larger of the turns that began in the window and the failed turns, so it never reads above its turn count. This change makes digest.js obey that sentence; it adds and changes no documented behaviour, and window.js, health.js and client.js are untouched.

Same line in the branch commit (git log -1 --format=%B), so the trailer survives the squash into the commit main judges, and it is what turns arch-docs green at the tip: arch-docs: FAIL was the only reason the first tip's tests-ok was red.

Red → green

At the base with only test/digest.test.js added (source at main): 13 tests, 10 pass, 3 fail —

• #1578: three failed turns that began before the window never read as 300% of one turn
• #1578: a failed turn that began before the window is not read as the window's own turn failing
• #1578: a single turn reads as one turn in all three places

The fourth new test, #1578: a clean window is byte-identical to the report before the change, passes on both sides by design: it is the pinned output (turns: 3, errors: 0) that proves the denominator does not move when errors <= turns.

At the tip: test/digest.test.js 13/13, plugins/timeline 129/129 (base 125 + these 4).

Verification at the tip

Tip 8139276924c95ec4f30691244c8e4c3d2030ebe0, tree bd8db4c70d8271142d4798b42b8405d73ff9953f, base c1b9fd23e404dcff1eb782a2269e30e09e2d6993, 3 files +86/−10 (digest.js 20/10, test/digest.test.js 65/0, changelog 1/0).

Ran:

• npm --prefix plugins/timeline test → 129/129, 0 fail.
• TZ=UTC ARCH_DOCS_BASE=c1b9fd23e4 npm run verify → exit 0: core 1869, social 527, tree 125, timeline 129, workflow 142, .github/scripts 548, interop 37, live-e2e 24 — 3401 tests, 0 fail; oxlint 0 errors (core 63 / social 36 / timeline 9 / tree 2 / workflow 13 warnings); arch-docs: OK (3 changed file(s)) — the two plugin files are covered by the Docs-not-needed: trailer below; build-client --check and ds-bot-patches check clean.
• node .github/scripts/changelog.mjs check → 63 fragments well formed.
• cd core && ARCH_DOCS_BASE=c1b9fd23e4 node scripts/check-arch-docs.mjs → arch-docs: OK (3 changed file(s)) at the tip with the Docs-not-needed: trailer in both places (first tip: FAIL on the same two files, tests-ok red for that reason alone).

Not run: the smoke test (no core/index.js or src/host/ change), the package job, Desktop, and the owner's live instance.

Checkpoint

{
  "pr": 1579,
  "claim": "Dev-1",
  "issue": 1578,
  "summary": "The team report divided overlapping failed turns by the turns that began in the window, so a failure from before the window printed as 1 turns, 3 failed (300%). The digest now counts against max(turns, errors), the denominator health.js already uses, in the per-Bot line, the Team line and the one-line summary, with the team total the sum of the Bot sections. It prints a share only below 100%, since with every counted turn a failed one the numbers cannot say whose turn failed, and singular/plural follows the count. window.js, health.js and client.js are untouched.",
  "files": ["plugins/timeline/src/digest.js", "plugins/timeline/test/digest.test.js", "changelog.d/1578-digest-error-rate.fixed.md"],
  "checks": { "ran": "TZ=UTC ARCH_DOCS_BASE=c1b9fd23 npm run verify", "result": "green", "at": "8139276924c95ec4f30691244c8e4c3d2030ebe0" },
  "next": "none — ready for review at the tip"
}

[HugoXK]

@Birfy review request for tip 8139276924c95ec4f30691244c8e4c3d2030ebe0 (tree bd8db4c7, base c1b9fd23, 3 files +86/−10). First request on this PR.

tests-ok was red on the previous tip for one reason and it was not a test: arch-docs: FAIL — plugins/timeline/src/digest.js and test/digest.test.js changed without a subsystem-doc update. The fix is a documented Docs-not-needed: line, in both places the gate reads — the PR body and the branch commit message — because the merge queue squashes the body into the commit it judges. The reason, verbatim: docs/subsystems/timeline.md invariant 5 already states this rule ("the errors rate divides by the larger of the turns that began in the window and the failed turns"), and this change makes digest.js obey it rather than documenting new behaviour. arch-docs is green at this tip.

The PR was also rebased onto live main (c1b9fd23) in the same push, so the base is current and the branch needs no further rebase.

Evidence: red first with the source at base and only the new tests kept — the digest cases fail on the 300%/3 failed shape; at this tip plugins/timeline 129/129, TZ=UTC ARCH_DOCS_BASE=c1b9fd23 npm run verify exit 0 (3401 tests, 0 fail), changelog.mjs check 63 fragments.

As of my read: 0 reviews, 0 comments. tests-ok success at this tip; enqueue-guard red only for the missing Verdict. Checkpoint recomputed against live rules (sha256 e7eab044…): reasons: [] (pr:1579, files:3, summary 569, block 963). Risk level T2 (plugins/timeline), so a formal Verdict: PASS at this exact tip is what the queue needs. Head frozen from now on.

[Birfy]

Verdict: PASS at 8139276
Written-by: Reviewer
Attestation: 8139276 role=Reviewer

Ran at this tip:

$ cd plugins/timeline && npm test
# tests 129  # pass 129  # fail 0
$ node -e 'GET contents plugins/timeline/src/digest.js at c1b9fd23 -> plugins/timeline/src/digest.js' && cd plugins/timeline && npm test
# tests 129  # pass 126  # fail 3
$ cp /tmp/digest.keep plugins/timeline/src/digest.js && cd plugins/timeline && npm test
# tests 129  # pass 129  # fail 0

Red first, at the base blob with this tip's tests kept: not ok 30 #1578: three failed turns that began before the window never read as 300% of one turn, not ok 31 #1578: a failed turn that began before the window is not read as the window's own turn failing, not ok 33 #1578: a single turn reads as one turn in all three places. Green again at the tip, 129/129, after restoring the tip source (md5 checked before and after). Harness: the tip's core/dev/harness/package.json is identical to the pinned DSH 0.2.0-rc.2 install, and the suite was run against it (Node 22).

Scope: compare c1b9fd23...81392769 is one commit, three files, +86/−10 — plugins/timeline/src/digest.js (+20/−10), plugins/timeline/test/digest.test.js (+65), changelog.d/1578-digest-error-rate.fixed.md (+1). That is exactly the PR's file list and the body's stated scope; window.js, health.js and plugins/timeline/client.js are untouched, so the documented meaning of utilization.turns does not move.

Tier: T2, recomputed from the diff with the base risk-gate.mjs — risk-tier: T2; basis: plugins/timeline/src/digest.js=T2, plugins/timeline/test/digest.test.js=T2, changelog.d/1578-digest-error-rate.fixed.md=T1. T2 takes this PASS at the tip plus green CI; neither replaces the other.

The arithmetic is the same compensation health.js already uses: counted = Math.max(turns, errors), the share is errors / counted, no turns now needs counted === 0, the Team rollup sums counted, and all three printers read counted, so the number printed beside the failure count is the population the share was taken over. counted is exposed on every bots[] entry and on team while turns/errors keep their raw window values. Printing a percentage only below 100% is sound: at every-counted-turn-failed the two raw numbers cannot say whether that turn began in the window, and (100%) next to a window whose completed turn began inside it would read as its opposite; counts with no share are consistent and cannot exceed 100%. Singular/plural follows the number in all three places. The new tests cover the failed-before-the-window shape, the mild one-failed-plus-one-completed shape and the singular wording, and they are the exact three that go red at base.

Checks at the tip: 14 check-runs; tests-ok success (its test, plugins (tree), plugins (social), plugins (timeline), plugins (workflow) and package all green), merge-gate success, agent-audience success, judge success. The only red is enqueue-guard, and only for no Verifier report names the tip 8139276924c9 — which is what this comment supplies.

One thing noted, not blocking: team.unhealthy still gates on bot.turns >= ERROR_TURNS_MIN while the flag text uses counted, so a Bot whose failures all began before the window is flagged in its own section but can be missing from needs a look. Detection threshold and wording disagree; a one-line follow-up, and it does not make any number in the report wrong.

Written-by: Reviewer