[dustinbyrne]

Summary

Add shared SDK performance reports to pull requests, so reviewers can see how a change affects flag evaluation, event capture, CPU time, allocations and memory usage.

The report starts with changes worth reviewing, uses readable test names and time/size units, and keeps all measurements under View all results. A change is flagged when the median differs by at least 5% and all six paired measurements agree on direction. This is an informational noise filter, not a performance merge gate.

Implementation

• Keep the result schema, comparison logic, renderer and reusable publishing workflow together in this repository. SDK repositories own their native benchmarks.
• Support both serial results and workload shards, preserving each runner's measurement context.
• Publish one updated comment per SDK/PR, with a link to the reporting run's full diagnostics.
• Run benchmarks with read-only permissions and publish separately, so PR code never receives comment-write permissions. Verify the source run, PR, revisions and artifacts before updating a comment; reject stale results.
• Document the common 20-workload specification and SDK integration contract.

SDK integrations: Node, Python, .NET, and Ruby.

Validation

• 377 reporting tests and five workflow contract tests passed, including fork discovery, artifact validation, stale-run protection and comment rendering.
• Ruff, Black and Actionlint passed, with the documented Actionlint exception for GitHub's queue: max syntax.
• Actual SDK CI results validated through the shared reporter, including sharded collection and explicit failure handling.
• Fresh read-only code and security reviews found no concrete issues; the security pass was static, not a substitute for code-owner approval.

Rollout

Automatic comments activate once the SDK caller workflows land on their default branches. After this PR is squash-merged, follow up by repinning the shared action and SDK callers to commits on main.

Agent context

Autonomy: Human-driven (agent-assisted).

Implemented with Pi and independently reviewed by fresh read-only agents.

[turnipdabeets]

[question] The trust boundary looks solid to me: workflow_run only, no PR checkout, scoped token, artifacts validated against the API. One gap on the fork side, inline.

[turnipdabeets]

[question] Thanks for the fork fix: the owner/branch lookup still requires the exact head SHA and repos, and the tests now reproduce the real empty response. One thing from the new comment rendering, inline.

[turnipdabeets]

Both fixes check out: fork PRs resolve through the owner/branch lookup with the same identity checks, and the diagnostics link now points at the publishing run. 377 tests pass on 2a6111d. One follow-up on the pin, inline.