fix: tighten stream audit edge guidance

Author: martinfrancois

evals-reference/08-primary-contact-review/criteria.json

@@ -36,7 +36,7 @@
       "name": "Review is concise and focused",
       "category": "maintainability",
       "max_score": 5,
-      "description": "Keeps the review focused on stream ordering and parallelism; brief scan notes or small supporting structure are acceptable if they do not distract from the decision."
+      "description": "Keeps the review focused on stream ordering and parallelism; do not deduct for brief references to the hard-stop scan/checklist or small supporting structure if they do not distract from the decision."
     }
   ],
   "metadata": {

skills/java-streams/SKILL.md

@@ -61,6 +61,8 @@ Keep these rules in view:
 5. Choose collectors by result semantics, and state duplicate-key/null contracts explicitly. When a
    later step needs an expensive check result, carry `element + result` with a baseline-compatible
    holder; use `Map.entry` only on Java 9+ when both values are non-null.
+   For blocking remote checks, also state the concurrency bound, timeout behavior, and error
+   propagation/retry policy instead of leaving those implicit.
 6. Preserve ordering, mutability, and short-circuit behavior. For top-N, sort before `limit`; for
    nullable sort keys, filter or use `Comparator.nullsFirst/nullsLast`; for mutable results, keep a
    mutable collector.

skills/java-streams/references/hard-stops.md

@@ -57,7 +57,8 @@ Use parallel streams only after checking:
 4. The pipeline does not perform blocking IO or remote calls. For Java 24+ blocking per-element
    calls, consider `Gatherers.mapConcurrent` only when the baseline supports it and virtual-thread
    concurrency is the intended design. Preserve element/result association explicitly with
-   a baseline-compatible holder rather than null sentinels or side maps.
+   a baseline-compatible holder rather than null sentinels or side maps. For remote calls, call out
+   the concurrency limit, timeout handling for slow calls, and error propagation/retry policy.
 5. The terminal/collector is safe under parallel execution.
 
 For acceptable CPU-heavy parallel streams, state that the benefit should be measured or benchmarked
@@ -80,4 +81,6 @@ rg -nUP "count\\(\\)\\s*>\\s*0|collect\\([^;]+\\)\\s*\\.\\s*(?:isEmpty|size)\\(|
 ```
 
 For each hit, decide whether it is legitimate for the project Java baseline and behavior. Fix
-stream-quality issues. If a marker remains because it is legitimate, state why.
+stream-quality issues. If a marker remains because it is legitimate, state why. When an audit asks
+for allowed stream markers or allowed usages, also call out plain `count()` when it is the requested
+numeric result rather than a `count() > 0` existence check.