logging: label the perf tick rolling window and emit the interval count

[iceteaSA]

Closes #206. Built to the shape you specced:

toolcall={new:3,window:256,p50_total_ms:…,max_total_ms:…,p50_queue_ms:…,max_queue_ms:…}

• new: first in the group, carrying the already-computed new_tool_calls — it stays the emit gate, it's just no longer discarded after gating
• count → window on both the field and ToolCallPerfSummary
• ring undrained, percentiles unchanged

The group's formatting moved into a small private format_tool_call_summary(new_tool_calls, summary) -> String, called from the emit site. That's what makes the test possible without log capture or waiting for perf_tick_interval() to elapse — perf_tick early-returns on the interval check and mutates process-global PERF, so asserting on it directly would have been either timing-dependent or global-state-dependent. Everything else on the tick line is untouched.

The test is the case you asked for — the one that proves the two fields mean different things:

assert_eq!(format_tool_call_summary(1, summary), "toolcall={new:1,window:1,…max_total_ms:3000…");
assert_eq!(format_tool_call_summary(0, summary), "toolcall={new:0,window:1,…max_total_ms:3000…");

Same 3.0s sample, same window; new: drops to 0 while max_total_ms still reports it. That's the misdiagnosis shape, pinned.

Field rename flagged as you asked: count → window inside the toolcall={} group. Line-prefix consumers are unaffected; anything parsing that group's field names by name will need the rename.

Verification: --lib 2283 passed / 6 skipped · release build clean · cargo fmt --check clean · aft_inspect 0/0/0/0. Red control run independently of the implementer's — swapping new: back to count: in the format string gives left: "toolcall={count:1,window:1,…" against the expected new:1.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Clarifies perf tick logging by emitting the per-interval new tool-call count and labeling the rolling window size as window. This removes ambiguity between interval activity and the rolling sample window and closes #206.

• New Features

  • Add new: to toolcall={} using new_tool_calls (still the emit gate).
  • Rename count to window in toolcall={} and ToolCallPerfSummary.
  • Keep the rolling ring undrained; percentiles unchanged.
  • Extract format_tool_call_summary() and add a unit test to distinguish new vs window.

• Migration

  • Update any log parsers from toolcall.count to toolcall.window.

^{Written for commit 3f7f84e. Summary will update on new commits.}

Greptile Summary

The PR clarifies tool-call performance logging by emitting the interval call count separately from the rolling sample-window size.

• Adds new as the first field in the toolcall={} group.
• Renames the rolling summary field from count to window.
• Extracts tool-call summary formatting into a private helper and tests that interval and rolling-window values can differ.

Confidence Score: 5/5

The PR appears safe to merge, with the intentional logging-field contract change clearly documented and tested.

The interval counter is derived from the existing cumulative tool-call counter at emitted-tick boundaries, while the renamed window field continues to describe the retained rolling sample buffer; no changed-code-triggered failure remains.

Important Files Changed

Filename	Overview
crates/aft/src/logging.rs	Cleanly separates the existing interval counter from the undrained rolling-window size while preserving percentile calculations and emission behavior.

_{Reviews (1): Last reviewed commit: "logging: label the perf tick rolling win..." | Re-trigger Greptile}

[cubic-dev-ai]

No issues found across 1 file

_{Re-trigger cubic}