[Eval] Qualify Open-Jev 9B/27B on the text reference path and one browser suite #103

Why

Roadmap tracker #54 still has an unchecked model-backend item: Qualify Open-Jev 9B/27B on the text reference path and browser suite through the existing local System One endpoint; record the actual served checkpoint rather than inferring it from the adapter name.

There is no dedicated issue for that work. #88 / PR #101 cover served OneJev multimodal (System One + media), which is a different checkpoint family and path. docs/capabilities.md already records Open-Jev-9B timeout / BLOCKED evidence on Google Flights ticks (Agents 22e685b, Omni 4a79980) and notes Open-Jev-27B-v1.1 did not fit an A40 — that is request-path evidence, not task success or a ticket-router baseline.

Industry context: TypeSafe's System One / Jev stack remains the hosted reference (Introducing System One Models & Jev); local Open-Jev is how self-hosted deployments match that interface without TypeSafe keys. A clean qualification unblocks the Agents capability matrix row and stops people reading adapter names as checkpoint proof.

Proposed scope (one PR of evidence + docs)

1. Pin exact Hugging Face (or Omni worker) revisions for Open-Jev-9B and, if hardware allows, Open-Jev-27B; refuse to claim a size that did not load.
2. Text reference path: run the existing ticket-router (or the public231 / decide probe already in-tree) through the generic Jev HTTP adapter → Omni Open-Jev worker; record accuracy, validity, p50/p95 latency, cost if any, and raw request/response samples under docs/results/.
3. One browser suite slice (prefer a fixture from #13 if ready; otherwise the deterministic local search / Flights shaping path already used for Laya): completion denominator that counts failures and timeouts, decision latency, and failure reasons.
4. Update the Open-Jev row(s) in docs/capabilities.md and tick the matching checkbox on [Tracking] Roadmap: applications, benchmarks, model backends and System1-Omni #54 — mark untested combinations explicitly (e.g. 27B if OOM).

Acceptance criteria

• Every claimed run names Agents SHA, Omni SHA, Open-Jev checkpoint SHA, hardware, and timeout settings.
• Text path has a completion / accuracy number with a clear denominator; browser path states task success or honest failure.
• Capability matrix distinguishes "adapter wired" from "qualified on this checkpoint".
• No claim that OneJev multimodal ([Feat] Add a served OneJev multimodal decision backend (System One + media) #88) or hosted TypeSafe Jev ([Deps] Pin Jev on the direct TypeSafe path (it sends jev-latest) and re-run benchmarks on jev-1.14.0 #93) substitutes for this qualification.

Out of scope

• New decision-model adapter code (use the existing System One HTTP path).
• Multimodal / screenshot Open-Jev (that is [Feat] Add a served OneJev multimodal decision backend (System One + media) #88 / OmniJev / [Feat] Let hosted Jev read screenshots (TypeSafe image input, opt-in) on the browser and desktop pixel-target paths #97).
• Replacing hosted Jev in the README headline table.

References

• Roadmap item (tracker [Tracking] Roadmap: applications, benchmarks, model backends and System1-Omni #54): [Tracking] Roadmap: applications, benchmarks, model backends and System1-Omni #54
• TypeSafe System One / Jev announcement: https://typesafe.ai/blog/introducing-system-one-models-and-jev
• Related: [Feat] Add a served OneJev multimodal decision backend (System One + media) #88 (served OneJev multimodal), [Feat] Integrate and evaluate CLM-v0.1-8B through clm-serve #24 (CLM-serve), [Feat] Integrate and evaluate Julia-1 #25 (Julia-1), capabilities Open-Jev timeout artifact under docs/results/decision-timeout/