ragops 2.2.0__tar.gz → 2.4.0__tar.gz

{ragops-2.2.0 → ragops-2.4.0}/.github/ISSUE_TEMPLATE/bug.yml

@@ -10,7 +10,7 @@ body:
     id: version
     attributes:
       label: RAGOps version or commit
-      placeholder: v2.1.0 or commit SHA
+      placeholder: v2.4.0 or commit SHA
     validations:
       required: true
   - type: textarea

{ragops-2.2.0 → ragops-2.4.0}/.github/workflows/ragops-gate.yml

@@ -12,7 +12,7 @@ on:
         description: RAGOps Git revision or tag to install
         required: false
         type: string
-        default: "v2.1.0"
+        default: "v2.4.0"
       scenario:
         description: Caller-relative scenario JSON path
         required: true

{ragops-2.2.0 → ragops-2.4.0}/CHANGELOG.md

@@ -4,6 +4,33 @@ All notable changes follow Keep a Changelog. This project uses Semantic Versioni
 
 ## [Unreleased]
 
+## [2.4.0] - 2026-07-13
+
+### Changed
+
+- Reframed the public adoption experience around the five-minute path from
+  installation to an explainable PASS/BLOCK release decision.
+- Rebuilt the showcase hero as a responsive, interactive developer proof with
+  copyable commands and recorded portable evidence.
+- Rewrote getting-started, demo, portfolio, presentation, video, CV/LinkedIn,
+  and GitHub launch materials with one evidence-safe product narrative.
+- Replaced the primary README visual with a screenshot captured from the real
+  implementation and refreshed design-QA evidence.
+
+## [2.3.0] - 2026-07-13
+
+### Added
+
+- `ragops --version` for installed-package and support diagnostics.
+- Clean-wheel installation smoke testing in the local release verification lane.
+
+### Changed
+
+- Local artifact checksum verification is dependency-free and portable across
+  supported operating systems.
+- Public documentation, roadmap, release evidence, and integration examples now
+  identify the current stable release consistently.
+
 ## [2.2.0] - 2026-07-13
 
 ### Added

{ragops-2.2.0 → ragops-2.4.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ragops
-Version: 2.2.0
+Version: 2.4.0
 Summary: Evaluation and red-team release gates for RAG and agent systems
 Project-URL: Homepage, https://github.com/thangldw/ragops
 Project-URL: Documentation, https://github.com/thangldw/ragops#readme
@@ -31,7 +31,7 @@ Description-Content-Type: text/markdown
 
 # RAGOps
 
-**Evaluation and red-team release gates for RAG and agent systems.**
+**From install to an explainable RAG release decision in five minutes.**
 
 [![CI](https://github.com/thangldw/ragops/actions/workflows/ci.yml/badge.svg)](https://github.com/thangldw/ragops/actions/workflows/ci.yml)
 [![PyPI](https://img.shields.io/pypi/v/ragops.svg)](https://pypi.org/project/ragops/)
@@ -45,7 +45,7 @@ optional.
 
 <p align="center">
   <a href="https://thangldw.github.io/ragops/">
-    <img src="docs/demo/screenshots/ragops-release-screen.jpg" alt="RAGOps product screen showing a recorded blocked regression and local release evidence" width="100%">
+    <img src="docs/demo/screenshots/ragops-adoption-hero.png" alt="RAGOps five-minute proof showing terminal commands, a passing baseline, and a blocked candidate with portable release evidence" width="100%">
   </a>
 </p>
 
@@ -57,6 +57,16 @@ optional.
   <a href="docs/evaluation/benchmark-report-v0.2.md"><strong>Benchmark evidence</strong></a>
 </p>
 
+## The release question RAGOps answers
+
+Your RAG or agent already runs. A prompt, retriever, embedding model, dataset,
+or evaluator changes. **Is the candidate still good enough to release?**
+
+RAGOps compares the candidate with an accepted baseline, applies versioned
+quality and operational policy, and returns `PASS` or `BLOCK` with evidence.
+It evaluates your system; it does not replace LangChain, LlamaIndex, your model,
+or your retrieval stack.
+
 ## What RAGOps does
 
 - Evaluates citations, groundedness, retrieval, latency, cost, and custom metrics.
@@ -80,21 +90,12 @@ returns a decision with named reasons rather than an isolated dashboard score.
 
 ## Five-minute proof
 
-Clone the repository and generate a complete, credential-free release bundle:
+Install the stable CLI and generate a complete credential-free release bundle:
 
 ```bash
-git clone https://github.com/thangldw/ragops.git
-cd ragops
 python -m venv .venv
 source .venv/bin/activate
-pip install -e .
-ragops demo --output ragops-demo
-```
-
-For the latest published stable CLI without cloning the repository:
-
-```bash
-pip install ragops==2.1.0
+pip install ragops==2.4.0
 ragops demo --output ragops-demo
 ```
 
@@ -135,8 +136,8 @@ injection, abstention, and consequential actions. These synthetic results
 validate the harness and architecture comparison; they do not establish
 Japanese semantic quality, customer adoption, or production ROI.
 
-The repository currently validates its core, adapters, reference deployment,
-showcase, and demo paths with 138 automated tests.
+The v2.4.0 release validation passed 144 automated tests. This is repository
+quality evidence, not a customer-adoption or production-security claim.
 
 <p align="center">
   <img src="docs/demo/infographics/evidence-stack.svg" alt="RAGOps evidence stack combining quality, safety, operational budgets, and regression comparison into a release decision" width="100%">
@@ -149,7 +150,7 @@ showcase, and demo paths with 138 automated tests.
 | <img src="docs/demo/screenshots/ragops-release-screen.jpg" alt="RAGOps desktop release-decision screen" width="640"> | <img src="docs/demo/screenshots/ragops-limitations-screen.jpg" alt="RAGOps known-limitations and rollout-recommendation screen" width="640"> |
 
 <p align="center">
-  <img src="docs/demo/screenshots/ragops-mobile-screen.jpg" alt="RAGOps responsive mobile product screen" width="320">
+  <img src="docs/demo/screenshots/ragops-adoption-mobile.png" alt="RAGOps responsive mobile five-minute proof with copyable commands" width="320">
 </p>
 
 The screens show the public reference experience and recorded synthetic

{ragops-2.2.0 → ragops-2.4.0}/README.md

@@ -1,6 +1,6 @@
 # RAGOps
 
-**Evaluation and red-team release gates for RAG and agent systems.**
+**From install to an explainable RAG release decision in five minutes.**
 
 [![CI](https://github.com/thangldw/ragops/actions/workflows/ci.yml/badge.svg)](https://github.com/thangldw/ragops/actions/workflows/ci.yml)
 [![PyPI](https://img.shields.io/pypi/v/ragops.svg)](https://pypi.org/project/ragops/)
@@ -14,7 +14,7 @@ optional.
 
 <p align="center">
   <a href="https://thangldw.github.io/ragops/">
-    <img src="docs/demo/screenshots/ragops-release-screen.jpg" alt="RAGOps product screen showing a recorded blocked regression and local release evidence" width="100%">
+    <img src="docs/demo/screenshots/ragops-adoption-hero.png" alt="RAGOps five-minute proof showing terminal commands, a passing baseline, and a blocked candidate with portable release evidence" width="100%">
   </a>
 </p>
 
@@ -26,6 +26,16 @@ optional.
   <a href="docs/evaluation/benchmark-report-v0.2.md"><strong>Benchmark evidence</strong></a>
 </p>
 
+## The release question RAGOps answers
+
+Your RAG or agent already runs. A prompt, retriever, embedding model, dataset,
+or evaluator changes. **Is the candidate still good enough to release?**
+
+RAGOps compares the candidate with an accepted baseline, applies versioned
+quality and operational policy, and returns `PASS` or `BLOCK` with evidence.
+It evaluates your system; it does not replace LangChain, LlamaIndex, your model,
+or your retrieval stack.
+
 ## What RAGOps does
 
 - Evaluates citations, groundedness, retrieval, latency, cost, and custom metrics.
@@ -49,21 +59,12 @@ returns a decision with named reasons rather than an isolated dashboard score.
 
 ## Five-minute proof
 
-Clone the repository and generate a complete, credential-free release bundle:
+Install the stable CLI and generate a complete credential-free release bundle:
 
 ```bash
-git clone https://github.com/thangldw/ragops.git
-cd ragops
 python -m venv .venv
 source .venv/bin/activate
-pip install -e .
-ragops demo --output ragops-demo
-```
-
-For the latest published stable CLI without cloning the repository:
-
-```bash
-pip install ragops==2.1.0
+pip install ragops==2.4.0
 ragops demo --output ragops-demo
 ```
 
@@ -104,8 +105,8 @@ injection, abstention, and consequential actions. These synthetic results
 validate the harness and architecture comparison; they do not establish
 Japanese semantic quality, customer adoption, or production ROI.
 
-The repository currently validates its core, adapters, reference deployment,
-showcase, and demo paths with 138 automated tests.
+The v2.4.0 release validation passed 144 automated tests. This is repository
+quality evidence, not a customer-adoption or production-security claim.
 
 <p align="center">
   <img src="docs/demo/infographics/evidence-stack.svg" alt="RAGOps evidence stack combining quality, safety, operational budgets, and regression comparison into a release decision" width="100%">
@@ -118,7 +119,7 @@ showcase, and demo paths with 138 automated tests.
 | <img src="docs/demo/screenshots/ragops-release-screen.jpg" alt="RAGOps desktop release-decision screen" width="640"> | <img src="docs/demo/screenshots/ragops-limitations-screen.jpg" alt="RAGOps known-limitations and rollout-recommendation screen" width="640"> |
 
 <p align="center">
-  <img src="docs/demo/screenshots/ragops-mobile-screen.jpg" alt="RAGOps responsive mobile product screen" width="320">
+  <img src="docs/demo/screenshots/ragops-adoption-mobile.png" alt="RAGOps responsive mobile five-minute proof with copyable commands" width="320">
 </p>
 
 The screens show the public reference experience and recorded synthetic

ragops-2.4.0/design-qa.md

@@ -0,0 +1,56 @@
+# Adoption refresh design QA
+
+- Source visual truth: `docs/design-audit/adoption-refresh/source-option-3.png`
+- Desktop implementation: `docs/design-audit/adoption-refresh/implementation-desktop.png`
+- Mobile implementation: `docs/design-audit/adoption-refresh/implementation-mobile.png`
+- Full-view comparison: `docs/design-audit/adoption-refresh/comparison-desktop.png`
+- Desktop viewport/state: 1440×1024, initial hero
+- Mobile viewport/state: 390×844, initial hero
+
+## Findings
+
+No actionable P0, P1, or P2 differences remain.
+
+- Fonts and typography: implementation preserves the target's editorial sans +
+  monospace pairing, large three-line headline, blue emphasis, and readable code.
+- Spacing and layout rhythm: two-column desktop proportions, left proof sequence,
+  right release report, CTA row, and evidence strip match the target hierarchy.
+- Colors and tokens: graphite background, restrained blue, mint PASS, and warm
+  red BLOCK remain semantic and high contrast.
+- Image quality and asset fidelity: the selected raster mock is retained only as
+  design truth; public screenshots are browser captures from the real HTML/CSS.
+  No visual asset was replaced with placeholder or improvised icon art.
+- Copy and content: version is intentionally updated from the selected v2.3.0
+  concept to the v2.4.0 release candidate. Metrics are recorded repository
+  evidence and limitations remain explicit.
+
+## Primary interactions tested
+
+- Copy-command primary CTA resolves uniquely and executes.
+- Navigation and GitHub links are real anchors.
+- Desktop and 390px mobile layouts have no horizontal overflow.
+- Browser console contained no errors during the desktop interaction test.
+
+## Focused-region evidence
+
+The full-view comparison keeps headline, proof terminal, PASS/BLOCK panels,
+reason deltas, and CTA text legible at the same desktop viewport, so a separate
+crop was not required. The mobile capture separately verifies text wrapping,
+command readability, button width, and responsive navigation behavior.
+
+## Comparison history
+
+1. Initial desktop capture matched the selected information hierarchy but used
+   v2.3.0 evidence.
+2. Documentation and implementation were aligned to the v2.4.0 release
+   candidate, then desktop and mobile screenshots were recaptured.
+3. Final comparison found only intentional content simplification: the
+   implementation uses three named regressions rather than invented aggregate
+   scores from the mock.
+
+## Follow-up polish
+
+- P3: after observed traffic exists, test whether “copy commands” or “view live
+  report” produces higher five-minute-demo activation.
+
+final result: passed

ragops-2.4.0/docs/architecture/adr/0020-local-release-integrity.md

@@ -0,0 +1,17 @@
+# ADR 0020: Verify local release integrity before publication
+
+Status: Accepted for owner review
+
+## Decision
+
+The quota-independent release lane must install its newly built wheel in a fresh
+virtual environment before publication. SHA-256 verification is implemented in
+dependency-free Python rather than delegating to platform-specific `shasum` or
+`sha256sum` commands. The installed CLI exposes its package version.
+
+## Consequences
+
+Local releases catch missing-package and metadata errors before tags are pushed,
+and PyPI promotion works consistently on macOS, Linux, and Windows. Verification
+takes slightly longer because it creates an isolated environment. This does not
+replace the supported-Python matrix when GitHub Actions capacity returns.

{ragops-2.2.0 → ragops-2.4.0}/docs/demo/cv-linkedin-copy.md

@@ -15,15 +15,16 @@ not customer production adoption.
   candidate with 25-point citation coverage/precision regressions. The fixture
   validates harness behavior, not Japanese semantic quality.
 - Published architecture decisions, threat model, rollout plan, executive
-  go/no-go recommendation, reproducible reports, and 138 automated tests.
+  go/no-go recommendation, reproducible reports, and a v2.4.0 release validated
+  by 144 automated tests.
 
 ## LinkedIn project description
 
-RAGOps demonstrates my Forward Deployed Engineering approach: start with a
-synthetic Japanese-question workflow fixture, define measurable release
-criteria, build a production-shaped reference system, test regressions and
-safety, and make an honest rollout decision. The repository and case study are
-public; the fixture is not evidence of Japanese semantic quality.
+RAGOps is the provider-independent evidence layer between an AI change and a
+release decision. It evaluates recorded RAG/agent output, applies versioned
+quality and operational policy, and produces an explainable PASS or BLOCK report
+locally. The public synthetic fixture validates the harness—not customer
+adoption, production security, or Japanese semantic quality.
 
 Repository: https://github.com/thangldw/ragops
 Case study: https://thangldw.github.io/projects/ragops/

ragops-2.4.0/docs/demo/portfolio-case-study.md

@@ -0,0 +1,45 @@
+# RAGOps portfolio case study
+
+## From AI change to defensible release decision
+
+RAG and agent teams can ship a prompt, retriever, embedding, or dataset change
+quickly. The harder problem is deciding whether the candidate is still good
+enough to release. Quality scores, operational budgets, citations, and review
+notes often live in separate tools with no accepted baseline.
+
+I built RAGOps as the provider-independent evidence layer between an AI change
+and a release. It consumes recorded responses, portable traces, and optional
+external evaluator metrics; applies versioned absolute and regression policy;
+then emits an explainable `PASS` or `BLOCK` decision in JSON, Markdown, or HTML.
+
+## Five-minute proof
+
+```bash
+pip install ragops==2.4.0
+ragops demo --output ragops-demo
+```
+
+The generated report shows an accepted baseline passing and an intentionally
+regressed candidate blocked with named reasons. No model API is required.
+
+## Evidence
+
+- Dependency-free Python 3.11+ evaluation core.
+- 30-case synthetic release-gate fixture across nine failure families.
+- Graph+ACL reference agent whose lexical-only candidate records 25-point
+  citation coverage and precision regressions.
+- Portable Ragas, DeepEval, Langfuse, and internal-judge metric envelope.
+- Build-once GitHub/PyPI releases with byte-identical artifacts, SBOM, and
+  checksums; v2.4.0 release validation passed 144 tests.
+
+## Product boundary
+
+RAGOps evaluates an existing RAG or agent. It does not replace orchestration,
+retrieval, generation, model observability, or human review. Synthetic evidence
+validates the harness, not semantic correctness, production security, customer
+adoption, or ROI.
+
+## Current recommendation
+
+Use v2.4.0 for offline evaluation and customer discovery. Convert real failures
+into reviewed regression fixtures before expanding into hosted collaboration.

ragops-2.4.0/docs/demo/presentation-outline.md

@@ -0,0 +1,35 @@
+# Ten-minute presentation outline
+
+## 1. Release question — 60 seconds
+
+“We changed the RAG system. Is the candidate still good enough to release?”
+Show why isolated scores and manual review do not create a defensible baseline.
+
+## 2. Product thesis — 60 seconds
+
+RAGOps is a provider-independent release-policy and evidence layer for existing
+RAG and agents—not another orchestration framework.
+
+## 3. Five-minute path — 90 seconds
+
+Show install → demo → PASS baseline → BLOCK candidate → portable report.
+
+## 4. Live evidence — 180 seconds
+
+Run `ragops demo`, open the HTML report, and trace one aggregate regression to
+its case, citations, metric delta, and versioned policy rule.
+
+## 5. Extensibility — 90 seconds
+
+Map portable responses/traces and Ragas, DeepEval, Langfuse, or internal scores
+into the same gate. Keep provider semantics outside the dependency-free core.
+
+## 6. Trust boundary — 90 seconds
+
+Separate recorded synthetic evidence from production claims. Explain local-first
+execution, exact artifact promotion, known limits, and why hosted 3.0 requires
+real customer demand and operations.
+
+## 7. Close — 30 seconds
+
+“Evaluate with evidence. Release with a reason.”

ragops-2.4.0/docs/demo/video-script.md

@@ -0,0 +1,30 @@
+# 60-second adoption video script
+
+## 0:00–0:10 — The change
+
+Show a prompt/retriever/model change and ask: “Is this candidate still safe
+enough and useful enough to release?”
+
+## 0:10–0:22 — Install and run
+
+```text
+pip install ragops==2.4.0
+ragops demo --output ragops-demo
+```
+
+Say: “No model API. No hosted dependency. Five minutes to reviewable evidence.”
+
+## 0:22–0:38 — Decision
+
+Open the report. Baseline is `PASS`; candidate is `BLOCK`. Highlight named
+citation, groundedness, latency, or cost gates rather than an opaque score.
+
+## 0:38–0:50 — Fit your stack
+
+Show portable responses/traces and optional metrics from Ragas, DeepEval,
+Langfuse, or an internal judge entering the same versioned policy.
+
+## 0:50–1:00 — Honest close
+
+“RAGOps evaluates the system you already have. Synthetic fixtures validate the
+harness; your reviewed production evidence decides what ships.”

ragops-2.4.0/docs/demo/walkthrough.md

@@ -0,0 +1,46 @@
+# Five-minute demo walkthrough
+
+Audience: an engineer who already operates a RAG or agent system and needs a
+repeatable release decision.
+
+## Minute 0–1: state the release question
+
+“The system already works. We changed a prompt, retriever, embedding model, or
+dataset. Is the candidate still good enough to release?”
+
+RAGOps sits outside the application. It consumes recorded evidence and applies
+the same versioned policy to baseline and candidate.
+
+## Minute 1–2: run the proof
+
+```bash
+pip install ragops==2.4.0
+ragops demo --output ragops-demo
+```
+
+Explain that process success and release decision are separate: the command
+returns successfully because it reproduced the expected blocked regression.
+
+## Minute 2–3: inspect PASS and BLOCK
+
+Open `ragops-demo/release-report.html`.
+
+- Baseline: `PASS`, because it satisfies the frozen scenario and thresholds.
+- Candidate: `BLOCK`, with named metric and case-level reasons.
+- Evidence: portable JSON, Markdown, HTML, scenario, baseline, and candidate.
+
+## Minute 3–4: trace one failure
+
+Follow one aggregate regression to its case, answer, citations, metric delta,
+and policy rule. Emphasize evidence lineage rather than a single dashboard score.
+
+## Minute 4–5: map to the adopter's stack
+
+Replace the demo responses with recorded application output or JSONL traces.
+Keep model, retriever, and orchestration choices outside RAGOps. Import optional
+Ragas, DeepEval, Langfuse, or internal-judge metrics through the portable metric
+envelope when those tools already exist.
+
+Close honestly: lexical groundedness is not semantic entailment, synthetic
+fixtures are not customer evidence, and the local control plane is not hosted
+production infrastructure.

ragops-2.4.0/docs/design-audit/adoption-refresh/compare.html

@@ -0,0 +1,4 @@
+<!doctype html>
+<html lang="en"><head><meta charset="utf-8"><title>RAGOps adoption refresh QA</title>
+<style>body{margin:0;background:#05070b;color:#fff;font:14px system-ui}.grid{display:grid;grid-template-columns:1fr 1fr;gap:12px;padding:12px}.panel{min-width:0}.label{padding:8px 0;color:#9ba8bb}img{display:block;width:100%;height:auto;border:1px solid #28354a}</style></head>
+<body><div class="grid"><div class="panel"><div class="label">Selected visual target</div><img src="source-option-3.png" alt="Selected option 3"></div><div class="panel"><div class="label">Rendered implementation</div><img src="implementation-desktop.png" alt="Rendered implementation"></div></div></body></html>

ragops-2.4.0/docs/design-audit/v2.3/audit.md

@@ -0,0 +1,20 @@
+# v2.3 workbench product-flow audit
+
+## Flow
+
+1. **Evaluation input — healthy.** API key is explicitly tab-local; scenario and
+   response fixtures are prefilled and labeled.
+2. **Release decision — healthy empty state.** Before evaluation the UI says
+   “Waiting for a run” and “Not evaluated”; it does not display stale PASS data.
+3. **Experiment history — healthy with setup guidance.** The run limit is labeled
+   and the page explains the `RAGOPS_STORE` requirement.
+
+## Highest-impact follow-up
+
+No release-blocking redesign is justified. A future usability study should test
+whether adopters prefer file upload over large JSON textareas; screenshots alone
+cannot establish this. Keyboard behavior, screen-reader announcements, focus
+movement after evaluation, and color contrast require dedicated accessibility
+testing and are not claimed here.
+
+![Workbench desktop](01-workbench-desktop.png)

{ragops-2.2.0 → ragops-2.4.0}/docs/engineering/github-pr-gate.md

@@ -22,7 +22,7 @@ jobs:
   release-gate:
     uses: thangldw/ragops/.github/workflows/ragops-gate.yml@main
     with:
-      ragops-version: v2.1.0
+      ragops-version: v2.4.0
       scenario: evals/scenario.json
       baseline: evals/baseline.json
       candidate: evals/candidate.json

{ragops-2.2.0 → ragops-2.4.0}/docs/engineering/gitlab-ci-gate.md

@@ -19,7 +19,7 @@ Set these repository-relative variables:
 
 ```yaml
 variables:
-  RAGOPS_VERSION: "2.1.0"
+  RAGOPS_VERSION: "2.4.0"
   RAGOPS_SCENARIO: "evaluation/scenario.json"
   RAGOPS_BASELINE: "evaluation/baseline.json"
   RAGOPS_CANDIDATE: "evaluation/candidate.json"

{ragops-2.2.0 → ragops-2.4.0}/docs/engineering/pypi-publishing.md

@@ -9,10 +9,10 @@ PyPI API token and publishes only an existing tag whose `vX.Y.Z` value matches
 
 - Project: [ragops on PyPI](https://pypi.org/project/ragops/)
 - First Trusted Publishing release: `1.6.0`
-- Current verified release: `2.1.0`
+- Current verified release: `2.3.0`
 - GitHub environment: `pypi`
 - Publisher: `thangldw/ragops`, workflow `publish-pypi.yml`
-- Verification: 2.1.0 wheel and sdist present; clean install and
+- Verification: 2.3.0 wheel and sdist present; clean install and
   credential-free proposal-review demo pass
 
 ## One-time owner setup
@@ -32,7 +32,7 @@ GitHub's current OIDC guidance is linked from the
 ## Publish an accepted tag
 
 1. Open **Actions → Publish package to PyPI → Run workflow**.
-2. Enter an existing tag such as `v2.1.0`.
+2. Enter an existing tag such as `v2.3.0`.
 3. Approve the `pypi` environment when protection rules require it.
 4. After success, install in a clean environment and compare the installed
    version and wheel hash with the GitHub Release asset.

{ragops-2.2.0 → ragops-2.4.0}/docs/examples/gitlab-ci-ragops.yml

@@ -2,7 +2,7 @@ ragops_release_gate:
   stage: test
   image: python:3.12-slim
   variables:
-    RAGOPS_VERSION: "2.1.0"
+    RAGOPS_VERSION: "2.4.0"
     RAGOPS_SCENARIO: "scenarios/japanese_troubleshooting/benchmark-v0.2.json"
     RAGOPS_BASELINE: "scenarios/japanese_troubleshooting/benchmark-baseline.json"
     RAGOPS_CANDIDATE: "scenarios/japanese_troubleshooting/benchmark-regressed.json"