Open History to see the last commit
1<!--
2Read CONTRIBUTING.md before opening a PR. Review capacity is limited, and meeting
3the requirements does not guarantee review or merging. Solve one underlying problem.
4The same requirements apply to drafts. Draft status does not defer triage or closure.
5Use a conventional commit title in plain language, such as "fix(web): new threads no longer spike CPU".
6-->
7
8## Problem
9
10<!-- Explain the problem in a sentence or two. Include expected behavior and
11reproduction steps or environment where relevant. -->
12
13## Change
14
15<!-- Explain how this fixes the problem. If it spans components or clients,
16explain why those changes are needed for the same fix. Split independent fixes. -->
17
18## Scope
19
20<!-- We accept bug fixes, not features. Link the issue that shows the bug. For a
21small fix of an obvious bug, say why it needs no issue. If a maintainer asked for
22this PR, link the request. -->
23
24## Verification
25
26<!-- Describe the focused tests or manual checks you ran and the observed results
27for the changed behavior. State anything you could not check. "Tests pass" alone
28is insufficient; broad repo-wide checks are not required.
29
30For UI changes, include clear before/after screenshots. Include a short recording
31when motion, timing, transitions, or interaction details are needed to demonstrate
32the change. Upload evidence to GitHub and embed or link it here. Never commit PR-only assets. -->
33
34<!-- If you used an agent, end with the model and harness that did the work. -->