If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Orange-OpenSource/hurl shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 7 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 55% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Orange-OpenSource/hurl repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Orange-OpenSource/hurl.

What it runs against: a local clone of Orange-OpenSource/hurl — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Orange-OpenSource/hurl | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Orange-OpenSource/hurl. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Orange-OpenSource/hurl.git
#   cd hurl
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Orange-OpenSource/hurl and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Orange-OpenSource/hurl(\\.git)?\\b" \\
  && ok "origin remote is Orange-OpenSource/hurl" \\
  || miss "origin remote is not Orange-OpenSource/hurl (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Orange-OpenSource/hurl"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Hurl is a command-line HTTP client and testing framework that executes HTTP requests defined in a plain-text declarative format (.hurl files), with built-in support for request chaining, response assertions (XPath/JSONPath queries), and header/body validation. It replaces curl + jq + test scripts with a single unified tool for both API data fetching and functional HTTP testing. Monorepo structure: three Cargo workspace members under packages/ (hurl = CLI binary, hurlfmt = formatter, hurl_core = shared parser/executor library). Supporting infrastructure: .github/workflows/ contains 8+ CI/CD flows (test.yml, coverage.yml, package.yml, release.yml), bin/check/ has modular Bash validation scripts, and .cargo/config.toml sets release optimizations (LTO, single codegen-unit, symbol stripping).

API developers, QA engineers, and DevOps professionals who need to write reproducible HTTP request chains and automated API tests without learning scripting languages—particularly teams testing REST, GraphQL, SOAP, and XML/JSON APIs at scale.

Production-ready and actively developed. The project has comprehensive CI/CD pipelines (.github/workflows/), Cargo workspace structure across 3 packages (hurl, hurlfmt, hurl_core), ~2.3M LOC in Rust with strict lint rules (deny warnings, clippy checks), and regular release automation. The RELEASING.md and extensive shell test scripts (bin/check/) indicate mature release practices.

Low risk for core stability—Orange is an active maintainer (evident from the Orange-OpenSource org), with strong test coverage infrastructure (.github/workflows/coverage.yml) and multi-platform packaging (NSIS, Dockerfile). Risk factors: heavy Rust ecosystem dependency chain (visible in Cargo.lock's size), and breaking changes possible in pre-1.0 versions if applicable. Monitor CHANGELOG.md for major version migrations.

Active development visible through: release automation (release.yml, update-branch-version.yml, update-crates.yml), continuous packaging across platforms (extra-package.yml generates installers), and code quality enforcement (check.yml runs clippy, coverage, hurlfmt validation). CHANGELOG.md and CONTRIBUTING.md indicate regular feature merges and community contribution processes.

git clone https://github.com/Orange-OpenSource/hurl.git
cd hurl
cargo build --release
./target/release/hurl --version

Daily commands:

cargo run --release -- <file.hurl>              # Run a Hurl file
cargo run -p hurlfmt -- <file.hurl>             # Format a Hurl file
cargo test                                        # Run all tests
bin/check/clippy.sh                              # Lint check
bin/check/coverage.sh                            # Coverage report

• packages/hurl_core/src: Parser, AST, and core execution engine—this is where HTTP request/response processing and assertion evaluation happens
• packages/hurl/src/main.rs: CLI entry point defining command-line interface, argument parsing, and request orchestration
• packages/hurlfmt/src: Hurl file formatter/pretty-printer—handles syntax highlighting and code style enforcement
• .github/workflows/test.yml: Multi-platform test matrix (Linux/macOS/Windows) that validates all Rust code, integration tests, and compatibility checks
• Cargo.toml: Workspace configuration defining the three interdependent packages and release-level optimizations (LTO, symbol stripping)
• CHANGELOG.md: Documents all feature additions, breaking changes, and fixes—essential for understanding what versions introduced what
• CONTRIBUTING.md: Developer contribution guidelines, code style, testing requirements, and PR review process

1. Parser changes: src/ in packages/hurl_core/ (grammar, AST definitions). 2) CLI behavior: packages/hurl/src/main.rs and subcommand handlers. 3) Assertions/queries: look for XPath/JSONPath evaluation in hurl_core/src/. 4) Tests: integration tests live in .github/workflows/test.yml and bin/check/; unit tests colocated with source files. 5) Formatter: packages/hurlfmt/src/ for output formatting.

1. Workspace members must compile together: changing hurl_core breaks hurl and hurlfmt—test cargo build --workspace. 2) Lints are enforced as deny: wildcard imports, empty struct brackets, missing semicolons will fail CI (see [workspace.lints] in Cargo.toml). 3) Release builds are heavily optimized: LTO + single codegen-unit means local debug builds compile much faster than release builds used in CI. 4) Tests split across multiple locations: unit tests in src/, integration tests in .github/workflows/test.yml, and shell-based checks in bin/check/ (run all three). 5) Platform-specific behavior: NSIS for Windows, shell scripts for Unix—test on target OS before merging.

• Declarative HTTP Testing — Hurl's core strength—defining requests and assertions as data (the .hurl format) rather than code eliminates boilerplate and makes tests readable by non-programmers
• Request Chaining with Variable Capture — Hurl's [Captures] section extracts values from one response (e.g., CSRF token) and injects them into subsequent requests—essential for testing stateful workflows
• XPath and JSONPath Query Languages — Hurl uses these two query languages to extract and assert values in HTML/XML and JSON responses respectively—learners must understand selector syntax
• Predicate-based Assertions — Hurl assertions (e.g., jsonpath '$.status' == 'RUNNING', matches /regex/) are composable predicates—enables declarative test logic without if/then branching
• AST-based Request Compilation — Hurl parses .hurl files into an Abstract Syntax Tree (in hurl_core) before execution—understanding the AST structure is key for extending parser and evaluator
• Link Time Optimization (LTO) in Rust — Cargo.toml enables LTO for release builds ([profile.release] lto=true)—this dramatically improves binary size and speed but requires understanding Rust compilation stages
• Workspace-level Lint Rules — All Hurl packages share strict [workspace.lints] rules (deny wildcard imports, require semicolons) enforced at CI time—contributors must follow or fail CI

• postmanlabs/postman-cli — Alternative HTTP testing CLI with similar request chaining, but Postman-specific; Hurl is format-agnostic
• jqlang/jq — JSON query language that Hurl depends on conceptually for assertion evaluation—Hurl is testing-first while jq is transformation-first
• httpie/httpie — User-friendly curl replacement; Hurl extends this idea with test assertions and request chaining in declarative format
• cucumber/cucumber — BDD testing framework; Hurl's plain-text format philosophy aligns with Cucumber's Gherkin, but Hurl is HTTP-specific
• Orange-OpenSource/opal — Another Orange open-source project; potential shared CI/CD tooling or organizational patterns

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add Zizmor security audit integration to CI/CD pipeline

The repo has a zizmor.sh check script (bin/check/zizmor.sh) but no corresponding GitHub Actions workflow to run it automatically on PRs/commits. Zizmor is a security linter for GitHub Actions workflows, which is critical given the extensive .github/workflows directory with multiple automation scripts. Adding this to the CI pipeline would catch security vulnerabilities in workflow files before they're merged.

• [ ] Review bin/check/zizmor.sh to understand current implementation and dependencies
• [ ] Check .github/workflows/check.yml to see how other checks are orchestrated
• [ ] Create a new workflow file .github/workflows/security-audit.yml that runs zizmor on all files in .github/workflows/
• [ ] Ensure it runs on pull_request and push events to main branches
• [ ] Test locally that zizmor properly validates the existing workflow files
• [ ] Update CONTRIBUTING.md to document running zizmor locally

Add comprehensive integration tests for .cargo/config.toml settings validation

The repo has aggressive Rust compiler/linter settings in Cargo.toml (LTO, panic=abort, strip, clippy lints set to 'deny'). There's no dedicated test or validation that these settings are correctly applied across all workspace members (hurl, hurlfmt, hurl_core). A new test suite should verify these profiles actually build correctly and that the deny-level lints are enforced.

• [ ] Create a new test file packages/hurl_core/tests/cargo_config_validation.rs
• [ ] Add a test that attempts to compile with intentional code that violates the denied clippy lints (wildcard-imports, empty_structs_with_brackets, etc.)
• [ ] Verify that LTO compilation produces valid binaries in bin/check/compatibility.sh
• [ ] Add a check in bin/check/ad_hoc.sh to validate all workspace members compile with the release profile settings
• [ ] Document the rationale for each aggressive setting in a new doc file docs/build-configuration.md

Create automated changelog validation workflow and template standardization

The repo has CHANGELOG.md and RELEASING.md files, but no GitHub Actions workflow to validate that PRs include appropriate changelog entries following a consistent format. This prevents incomplete changelogs from being merged and ensures consistency across releases. Currently bin/check/changelog.sh exists but isn't integrated into the CI pipeline.

• [ ] Review bin/check/changelog.sh to understand current validation logic
• [ ] Create .github/workflows/validate-changelog.yml that runs on pull_request events
• [ ] Configure the workflow to fail if CHANGELOG.md wasn't modified (with exceptions for docs-only or chore PRs via labels)
• [ ] Add a PR template in .github/PULL_REQUEST_TEMPLATE.md that reminds contributors to update CHANGELOG.md with specific sections (Added, Fixed, Changed, etc.)
• [ ] Update CONTRIBUTING.md with the changelog format requirements and examples
• [ ] Test that the workflow correctly identifies and validates changelog entries

• Add XPath function coverage tests: packages/hurl_core/src/ likely lacks exhaustive tests for XPath string(), count(), normalize-space() functions—write tests for each function with edge cases
• Extend JSONPath assertion examples in docs/: README.md shows basic jsonpath usage but missing examples for complex nested paths, filters, and recursive descent—add runnable .hurl examples
• Implement --quiet flag for hurlfmt: packages/hurlfmt/src/ could add a suppression mode for non-error output—useful in CI pipelines where formatting checks shouldn't be verbose

Hurl project demonstrates reasonable security practices with aggressive linting enforcement, LTO optimization, and basic secrets scanning infrastructure. However, security concerns exist around binary stripping limiting post-incident analysis, lack of visible automated dependency vulnerability scanning, and potential secrets exposure in workflow scripts. The codebase lacks visible infrastructure-as-code security controls and explicit security policy documentation. Recommend implementing automated dependency scanning, documenting security exception processes, and establishing formal secure development practices.

• Medium · Potential Secrets Exposure via Workflow Files — .github/workflows/. GitHub Actions workflow files (.github/workflows/) may contain hardcoded secrets, API keys, or credentials in environment variables or shell scripts. The presence of multiple shell scripts in workflow configuration (bin/shared.functions.sh, etc.) increases the risk of accidental credential exposure. Fix: Audit all workflow files and shell scripts for hardcoded secrets. Use GitHub Secrets for sensitive values and ensure they are never logged. Implement pre-commit hooks to detect secrets.
• Medium · Aggressive Security Linting Without Documentation — Cargo.toml - [workspace.lints.clippy]. The Cargo.toml enforces strict clippy linting rules with 'deny' level (wildcard-imports, manual_string_new, empty_structs_with_brackets, semicolon_if_nothing_returned). While beneficial for code quality, lack of documented rationale or exceptions mechanism may cause development friction and potential bypasses. Fix: Document the security rationale for each lint rule. Establish a formal exception process for cases where strict compliance is infeasible. Consider using #[allow] attributes with justification comments.
• Medium · Strip Binary Symbols in Release Builds — Cargo.toml - [profile.release] strip = true. The release profile has 'strip = true' enabled, which removes debugging symbols. While this reduces binary size, it may hinder security investigation, crash analysis, and vulnerability assessment post-deployment. Stripped binaries are harder to debug and analyze for vulnerabilities. Fix: Consider generating separate debug symbols or maintaining a symbol server. Ensure crash reporting mechanisms are in place. Document the rationale for symbol stripping in security policies.
• Low · Dependency Management Best Practices — Cargo.lock and CI/CD pipeline. No evidence of lock file safety practices or automated dependency vulnerability scanning (e.g., cargo-audit, dependabot configuration) in the visible file structure. The Cargo.lock exists but scanning mechanisms are not visible. Fix: Integrate cargo-audit into CI/CD pipelines. Enable Dependabot for automatic security updates. Regularly audit dependencies with 'cargo audit' and establish a policy for addressing vulnerabilities.
• Low · Gitleaks Configuration Present — .github/workflows/config/gitleaks.toml. Gitleaks configuration file exists (.github/workflows/config/gitleaks.toml), indicating awareness of secrets scanning. However, without seeing the actual rules, the effectiveness cannot be determined. Configuration may have gaps. Fix: Verify gitleaks.toml includes comprehensive patterns for secrets detection. Ensure gitleaks is run on all PRs and branches. Review and update patterns regularly based on organizational standards.
• Low · Panic Abort in Production — Cargo.toml - [profile.release] panic = abort. Release profile uses 'panic = abort' which terminates immediately on panic. This can mask security-relevant error conditions and prevent graceful error handling in security-critical paths. Fix: Evaluate critical paths for proper error handling before panic. Consider using panic hooks for logging. Implement structured error handling for security-sensitive operations instead of relying on panics.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.