Upstream Mike PR #254 review

[github-actions]

Automated-Upstream-Mike-Sync: true
Upstream-Risk: high

Promising test-depth capability, but it crosses protected dependency, secrets, provider-key, infrastructure, and operational boundaries.

Mike PR Open-Legal-Products#254

• Outcome: needs-decision
• Capability: ROSS-native mutation testing for critical backend logic plus an on-demand SSE concurrency/completion harness
• Series: testing-21
• Dependencies: Approved mutation-testing packages and lockfile changes, k6 runtime, Owned non-production backend with test authentication and provider configuration
• Prerequisites: Dependency and security review, ROSS-specific mutation baseline using the current node:test suite, Synthetic/non-confidential load-test account and data-cleanup policy, Enforced production-target prohibition, Measured cost, rate-limit, timeout, and false-positive bounds
• Reason: ROSS has matching seams in backend security libraries and the /chat SSE route, but its tests use node:test rather than Vitest, while safe load testing requires protected credentials, provider keys, infrastructure, and operational controls. PR MIKE-04: deploy isolated AWS staging environment Open-Legal-Products/mike#210 is not a dependency because this PR removed that obsolete reference.

Architecture brief

Keep the tools separate and non-gating. Scope mutation testing to current ROSS modules and derive thresholds from repeated ROSS runs. Exercise /chat through an owned isolated environment using synthetic data, least-privilege test credentials, explicit target allowlisting, bounded concurrency/cost, and cleanup evidence; never transplant the upstream workflows wholesale.

Implementation plan

• Approve and pin mutation-testing dependencies through the normal dependency-review process.
• Prototype a runner compatible with ROSS's node:test scripts and record repeated per-module mutation scores, runtime, timeouts, and surviving mutants before setting thresholds.
• Define an owned non-production SSE target contract, credential lifecycle, provider-cost ceiling, rate-limit policy, data cleanup, and a fail-closed production-target guard.
• Build a focused harness that verifies HTTP status, event-stream content type, stream start, terminal [DONE], handled errors, TTFB, and full-stream duration against current /chat behavior.
• Run bounded trials, document reproducibility and false positives, then obtain human approval before adding any workflow or scheduled execution.

Required human action

This is a draft state-only architecture record. Review the brief and implementation plan before any code is attempted.