What would you like to be added?
Close the engineering-safety gaps in the Java SDK modules (packages/sdk-java/managed-agent-server, packages/sdk-java/runtime-broker):
- Static analysis in CI: add SpotBugs (and/or Error Prone) to the Maven build, plus an OWASP dependency-check (or equivalent) gate. Today the only automated check is Checkstyle.
- Load/budget tests for the endpoints a hot tenant actually exercises: session list pages (query-count budgets), event-stream fan-out (per-event DB calls should not scale with subscribers), message materialization (snapshot rewrite cost vs session length), and lease-renewal behavior under a slow-DB fault injection. These would have caught the amplification findings from the 2026-10-02 audit before code review had to.
Why is this needed?
The modules already carry >24k lines of tests against ~35k lines of production code, yet the audit still found lock-scoped quadratic writes, N+1 endpoints, and infinite retry loops — the test suite proves behavior, but nothing proves resource shape. The class of bugs these guards catch is exactly the class manual review keeps missing under time pressure, which is how the current technical debt accumulated.
Additional context
Related audit issues: broker authentication design, DB amplification, retry terminal states, runtime-broker robustness, unbounded growth. Suggested acceptance: mvn verify fails on new SpotBugs high-confidence warnings and on dependency CVEs above a chosen threshold; each listed endpoint gains one budget test that fails when its query count or latency exceeds the pinned envelope.
中文
希望添加什么？
补齐 Java SDK 模块（packages/sdk-java/managed-agent-server、packages/sdk-java/runtime-broker）的工程护栏缺口：
- CI 静态分析：在 Maven 构建中加入 SpotBugs（和/或 Error Prone），并加 OWASP dependency-check（或等效）门禁。目前唯一的自动化检查是 Checkstyle。
- 热点租户真实触达端点的负载/预算测试：会话列表分页（查询数预算）、事件流扇出（每事件 DB 调用不应随订阅者数增长）、消息物化（快照重写成本对会话长度）、慢 DB 故障注入下的租约续约行为。这类测试能在代码评审之前抓住 2026-10-02 审计发现的放大问题。
为什么需要？
这两个模块已有超过 2.4 万行测试对着约 3.5 万行生产代码，但审计仍找到了锁内平方写入、N+1 端点和无限重试环——现有测试证明行为，但没有任何东西证明资源形状。这类护栏抓的正是赶工评审中最容易漏的那类缺陷，也是当前技术债的成因。
附注
相关审计 issue：broker 认证设计、DB 放大、重试终态、runtime-broker 健壮性、无界增长。建议验收标准：mvn verify 对新增 SpotBugs 高置信告警与超过阈值的依赖 CVE 失败；上述每个端点各增一个预算测试，查询数或时延超出钉住的包络即失败。
What would you like to be added?
Close the engineering-safety gaps in the Java SDK modules (
packages/sdk-java/managed-agent-server,packages/sdk-java/runtime-broker):Why is this needed?
The modules already carry >24k lines of tests against ~35k lines of production code, yet the audit still found lock-scoped quadratic writes, N+1 endpoints, and infinite retry loops — the test suite proves behavior, but nothing proves resource shape. The class of bugs these guards catch is exactly the class manual review keeps missing under time pressure, which is how the current technical debt accumulated.
Additional context
Related audit issues: broker authentication design, DB amplification, retry terminal states, runtime-broker robustness, unbounded growth. Suggested acceptance:
mvn verifyfails on new SpotBugs high-confidence warnings and on dependency CVEs above a chosen threshold; each listed endpoint gains one budget test that fails when its query count or latency exceeds the pinned envelope.中文
希望添加什么？
补齐 Java SDK 模块（
packages/sdk-java/managed-agent-server、packages/sdk-java/runtime-broker）的工程护栏缺口：为什么需要？
这两个模块已有超过 2.4 万行测试对着约 3.5 万行生产代码，但审计仍找到了锁内平方写入、N+1 端点和无限重试环——现有测试证明行为，但没有任何东西证明资源形状。这类护栏抓的正是赶工评审中最容易漏的那类缺陷，也是当前技术债的成因。
附注
相关审计 issue：broker 认证设计、DB 放大、重试终态、runtime-broker 健壮性、无界增长。建议验收标准：
mvn verify对新增 SpotBugs 高置信告警与超过阈值的依赖 CVE 失败；上述每个端点各增一个预算测试，查询数或时延超出钉住的包络即失败。