[HugoXK]

Timeline: token spend per Bot, from the activity feed

#357 and #401 want cost visible: the timeline showed models and durations but not how many tokens each Bot spent. The feed's turn.end now carries tokens (the counts a turn's model calls reported, summed from its assistant/message usage, each floored and capped — counts only, never text), the timeline records them and timeline/window carries usage per Bot (calls, input, output, cacheRead, cacheWrite). Read-only; absent when the adapter reports no usage.

Ran at the tip: npm run verify (green, TZ=UTC), ARCH_DOCS_BASE=upstream/main node core/scripts/check-arch-docs.mjs. Not run: smoke, Desktop, real-model steward.

[Birfy]

Review (Birfy, 2026-10-20 20:07 Asia/Shanghai): FAIL

Tip SHA: b157f8f
Ran:

• npm --prefix plugins/timeline test (TZ=UTC) → pass (95/95)
• node --import ./test/harness-resolve.mjs --test test/flybot-feed.test.js (core/) → pass (14/14)
• node scripts/ds-bot-patches.mjs check → pass
• npm --prefix core run lint (oxlint + arch-docs) → pass
• CI tests-ok at this tip → green
  Not run:
• full core suite locally (CI ran it at this tip), smoke, Desktop
  Verdict: FAIL

Findings:

1. Second, divergent token counter (design: simplicity/consistency). FlyBot already has a per-Bot token ledger, core/src/host/usage.js, which feeds the Usage page. It counts per billed attempt the way DSH's tokenUsage projection does: it reads assistant/attempt (retried, billed attempts), falls back to the stream usage chunk, and attributes forks and group Sessions to their Bot. This PR sums only assistant/message data.usage in the feed. So retries and stream-only usage are dropped, and the timeline's per-Bot tokens will disagree with the Usage page for the same Bot and period. Please take per-Bot totals from the existing ledger (or reuse foldCalls/tokensOf), not a second fold in flybot-feed.js.
2. usage[].calls counts turns that reported usage, not model calls (the comment and the issue say calls). Rename it to turns or count the calls.
3. window.js fold() keeps record.tk as-is (only typeof === 'object'), while every other trace field is re-cleaned on read (cleanCode, cleanLabel). Run it through cleanTokens there as well.
4. TurnEnded.tokens in flybot.d.ts declares all four keys required, but zero/absent keys are omitted. Make them optional.

#536 is also a new feature the owner has not confirmed (needs-human), so this is held regardless. This is not merge authority.

[Birfy]

@HugoXK Owner decision (2026-10-20 21:09 Asia/Shanghai): accepted with a change. Required: take token numbers from the existing Usage ledger instead of computing a separate count, so per-Bot spend matches the Usage page.

[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 b157f8fcd6f98ccf29264089177a0fec08d431fb (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):

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

Token counts are numbers only (never text), floored and capped at 1e9 per field, summed per turn; turn.end stays absent when the adapter reported none. The patches/ds-bot/files/ mirror carries the same change, and both subsystem docs are updated.

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.