Skip to content

test: add code agent eval framework with 4 functional test cases#216

Closed
mysticgohan1 wants to merge 1 commit into
fullsend-ai:mainfrom
mysticgohan1:test/code-eval-edge-cases
Closed

test: add code agent eval framework with 4 functional test cases#216
mysticgohan1 wants to merge 1 commit into
fullsend-ai:mainfrom
mysticgohan1:test/code-eval-edge-cases

Conversation

@mysticgohan1

Copy link
Copy Markdown

Summary

Adds the code agent eval framework and four functional test cases covering distinct patterns observed in the 30-issue benchmark:

Case Pattern Language Budget Planted Bug
001-sort-direction Trivial bug fix Python $5 / 50 turns sorted() missing reverse=True
002-docs-guidance Docs-only edit Go repo $3 / 30 turns Missing AGENTS.md section
003-extract-shared Multi-file refactor Python $6 / 60 turns Duplicated format_error() with err/exc typo
004-shell-validation Shell script gap Bash $4 / 40 turns deploy.sh missing env var validation

Infrastructure

  • eval/code/eval.yaml: 5 judges (pr_created, code_quality LLM judge, forbidden_labels, max_turns, max_cost)
  • eval/scripts/capture-code-output.sh: after-each hook to capture PR state
  • eval/scripts/setup-fixture.sh: added optional fixture.labels support (backward-compatible)
  • eval/scripts/run-fullsend.sh: exports REPO_FULL_NAME + ISSUE_NUMBER for code agent (backward-compatible)

Verification

  • eval/lint-cases.sh code passes
  • eval/lint-cases.sh triage and eval/lint-cases.sh review still pass (no regressions)
  • Each case has verified fail-before/pass-after behavior for its planted bug

Test plan

  • eval/lint-cases.sh code passes
  • Triage and review evals unaffected (eval/lint-cases.sh triage, eval/lint-cases.sh review)
  • Case 001: pytest shows 1 failure (test_highest_priority_first), fix is reverse=True
  • Case 002: make check-docs fails (missing section), fix is adding ## Error Handling
  • Case 003: pytest shows 3 failures (webhook NameError), fix is extracting shared errors.py
  • Case 004: test_missing_vars.sh shows 1 failure (deploy.sh), fix is adding validation loop

🤖 Generated with Claude Code

Add eval infrastructure for the code agent pipeline (issue → fix → PR)
and four test cases exercising different patterns:

- 001-sort-direction: trivial Python bug fix (baseline)
- 002-docs-guidance: docs-only AGENTS.md edit (Go repo)
- 003-extract-shared: multi-file refactor with planted bug (Python)
- 004-shell-validation: shell script env var validation gap

Infrastructure: eval.yaml with 5 judges (pr_created, code_quality,
forbidden_labels, max_turns, max_cost), capture-code-output.sh hook,
label support in setup-fixture.sh, env var export in run-fullsend.sh.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: guy oron <goron@redhat.com>
@mysticgohan1
mysticgohan1 requested a review from a team as a code owner July 16, 2026 16:02
@github-actions github-actions Bot closed this Jul 16, 2026
@github-actions

Copy link
Copy Markdown

Thank you for your interest in contributing, @mysticgohan1.

This project uses a vouch system for first-time contributors. Before submitting a pull request, you need to be vouched by a maintainer.

To get vouched:

  1. Open a Vouch Request discussion on the main fullsend repo.
  2. Describe what you want to change and why.
  3. Write in your own words — do not have an AI generate the request.
  4. A maintainer will comment /vouch if approved.
  5. Once vouched, open a new PR (preferred) or reopen this one.

See CONTRIBUTING.md for details.

@github-actions

Copy link
Copy Markdown

Functional tests did not run

Functional tests run automatically for org/repo members and collaborators on pull requests.

For other contributors, a maintainer must add the ok-to-test label after the latest push.

@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Add code-agent eval harness and 4 functional edge-case fixtures

🧪 Tests ✨ Enhancement ⚙️ Configuration changes 🕐 40+ Minutes

Grey Divider

AI Description

• Introduce a code-agent evaluation harness with budgets and post-run judges.
• Add four functional fixture repos covering bugfix, docs-only, refactor, and shell validation
 patterns.
• Enhance fixture setup and capture hooks to propagate labels/env and archive PR diffs.
Diagram

graph TD
  H["code cases"] --> B[["setup-fixture.sh"]] --> C{{"GitHub ephemeral repo"}}
  H --> D[["run-fullsend.sh"]] --> E(["Code agent"]) --> C
  A["eval/code/eval.yaml"] --> B
  A --> D
  A --> F[["capture-code-output.sh"]] --> G[("output/pr-state.json")]
  subgraph Legend
    direction LR
    _cfg["Config"] ~~~ _sh[["Script"]] ~~~ _ext{{"External"]}} ~~~ _out[("Captured output")]
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Template/generator for cases
  • ➕ Reduces repetitive repo scaffolding (Makefiles/README/boilerplate) across cases
  • ➕ Makes it easier to add many more cases consistently (naming, budgets, annotations)
  • ➖ Adds upfront tooling complexity (templating, rendering, validation)
  • ➖ Harder to review generated fixtures without careful source-of-truth discipline
2. Single monorepo fixture with per-case branches
  • ➕ Less duplication of repo skeleton across cases
  • ➕ Can share common test harness/CI setup for fixtures
  • ➖ Branch management complexity in harness setup/teardown
  • ➖ Less realistic for agents that must handle diverse repo shapes/languages

Recommendation: The PR’s approach (self-contained case directories with embedded repos + a small amount of harness scripting) is appropriate for early-stage eval development: it’s straightforward to understand, easy to run locally, and minimizes extra tooling. If case count grows substantially, consider introducing a case generator to keep fixture maintenance manageable.

Files changed (39) +1066 / -1 · 4 not counted

Documentation (5) +108 / -0
README.mdDocument fixture repo usage and testing +22/-0

Document fixture repo usage and testing

• Adds a brief README describing the task manager library and how to run its tests.

eval/code/cases/001-sort-direction/repo/README.md

AGENTS.mdAdd baseline contribution guidelines missing Error Handling section +29/-0

Add baseline contribution guidelines missing Error Handling section

• Introduces the guidelines document that intentionally lacks the requested Error Handling section. This is the target file for the agent’s docs-only change.

eval/code/cases/002-docs-guidance/repo/AGENTS.md

README.mdDocument Go fixture repo basics +18/-0

Document Go fixture repo basics

• Adds a brief README for running tests/lint and pointing to AGENTS.md.

eval/code/cases/002-docs-guidance/repo/README.md

README.mdDocument formatter fixture repo layout +14/-0

Document formatter fixture repo layout

• Adds a short README describing the API/webhook modules and how to run tests.

eval/code/cases/003-extract-shared/repo/README.md

README.mdDocument deploy toolkit fixture repo and required env vars +25/-0

Document deploy toolkit fixture repo and required env vars

• Adds README describing scripts, required variables, and how to run tests/lint.

eval/code/cases/004-shell-validation/repo/README.md

Other (34) +958 / -1
annotations.yamlDefine expectations and budgets for sort-direction bug case +41/-0

Define expectations and budgets for sort-direction bug case

• Adds judging rubric and constraints for a trivial Python sort-order bug. Declares forbidden labels plus max_turns/max_cost for the case.

eval/code/cases/001-sort-direction/annotations.yaml

input.yamlAdd GitHub issue fixture for sort-order bug +40/-0

Add GitHub issue fixture for sort-order bug

• Defines the issue title/body and initial labels used to seed the evaluation run. Includes concrete reproduction steps and expected behavior.

eval/code/cases/001-sort-direction/input.yaml

MakefileProvide test/lint entrypoints for fixture repo +7/-0

Provide test/lint entrypoints for fixture repo

• Adds simple targets to run pytest and a minimal syntax lint for the fixture repository.

eval/code/cases/001-sort-direction/repo/Makefile

__init__.pyCreate tasks package for fixture repo not counted

Create tasks package for fixture repo

• Adds an empty package initializer to support imports in the fixture codebase.

eval/code/cases/001-sort-direction/repo/tasks/init.py

manager.pyIntroduce intentionally-buggy task priority sorter +18/-0

Introduce intentionally-buggy task priority sorter

• Implements task helpers, with get_tasks_by_priority() sorting ascending despite docstring expecting descending. This planted bug drives the evaluation.

eval/code/cases/001-sort-direction/repo/tasks/manager.py

__init__.pyCreate tests package for fixture repo not counted

Create tests package for fixture repo

• Adds an empty test package initializer for pytest discovery/import behavior.

eval/code/cases/001-sort-direction/repo/tests/init.py

test_manager.pyAdd pytest coverage that exposes the sort bug +49/-0

Add pytest coverage that exposes the sort bug

• Adds tests asserting highest-priority comes first and basic helper behavior. The test_highest_priority_first test is designed to fail pre-fix.

eval/code/cases/001-sort-direction/repo/tests/test_manager.py

annotations.yamlDefine docs-only expectations for AGENTS.md guidance case +40/-0

Define docs-only expectations for AGENTS.md guidance case

• Adds rubric requiring insertion of an "## Error Handling" section and forbids touching Go source files. Declares turn/cost budgets and forbidden labels.

eval/code/cases/002-docs-guidance/annotations.yaml

input.yamlAdd GitHub issue fixture requesting AGENTS.md error-handling section +27/-0

Add GitHub issue fixture requesting AGENTS.md error-handling section

• Defines a docs-only enhancement issue with explicit content requirements and constraints. Seeds fixture labels indicating documentation work.

eval/code/cases/002-docs-guidance/input.yaml

MakefileAdd check-docs gate for AGENTS.md structure +14/-0

Add check-docs gate for AGENTS.md structure

• Adds make targets for go test, gofmt lint, and a grep-based docs check that fails until the required section/topics exist.

eval/code/cases/002-docs-guidance/repo/Makefile

main.goAdd minimal HTTP server entrypoint for Go fixture repo +26/-0

Add minimal HTTP server entrypoint for Go fixture repo

• Provides a tiny runnable service to make the repo realistic, though the eval case requires no Go code changes.

eval/code/cases/002-docs-guidance/repo/cmd/server/main.go

go.modDefine Go module for fixture repo +3/-0

Define Go module for fixture repo

• Adds go.mod to make the fixture repository buildable/testable.

eval/code/cases/002-docs-guidance/repo/go.mod

notify.goAdd minimal notification service implementation +30/-0

Add minimal notification service implementation

• Implements a small service with basic validation and state tracking, used by the server and tests.

eval/code/cases/002-docs-guidance/repo/internal/notify/notify.go

notify_test.goAdd unit tests for notification service fixture +30/-0

Add unit tests for notification service fixture

• Adds basic tests for success and error cases, ensuring the fixture repo has a normal test baseline.

eval/code/cases/002-docs-guidance/repo/internal/notify/notify_test.go

annotations.yamlDefine multi-file refactor expectations for shared error formatter case +40/-0

Define multi-file refactor expectations for shared error formatter case

• Adds rubric requiring extraction of format_error() into formatters/errors.py and removal of duplicates. The planted webhook bug must be fixed via the shared implementation.

eval/code/cases/003-extract-shared/annotations.yaml

input.yamlAdd GitHub issue fixture describing duplicated format_error() bug/refactor +31/-0

Add GitHub issue fixture describing duplicated format_error() bug/refactor

• Defines the refactor request, including the variable-name bug in webhook_handler and strict constraints on scope/signature.

eval/code/cases/003-extract-shared/input.yaml

MakefileProvide test/lint entrypoints for formatter fixture repo +8/-0

Provide test/lint entrypoints for formatter fixture repo

• Adds pytest and basic py_compile lint targets for the two handler modules.

eval/code/cases/003-extract-shared/repo/Makefile

__init__.pyCreate formatters package for fixture repo not counted

Create formatters package for fixture repo

• Adds an empty initializer to support package imports during the refactor case.

eval/code/cases/003-extract-shared/repo/formatters/init.py

api_handler.pyAdd API handler with local format_error implementation +23/-0

Add API handler with local format_error implementation

• Implements API request validation and returns structured errors using a local format_error(). This duplication is intended to be extracted during evaluation.

eval/code/cases/003-extract-shared/repo/formatters/api_handler.py

webhook_handler.pyAdd webhook handler with intentionally broken format_error +26/-0

Add webhook handler with intentionally broken format_error

• Implements webhook processing and includes a planted NameError/incorrect return by referencing err instead of exc. Tests are designed to fail until the shared extraction fixes this.

eval/code/cases/003-extract-shared/repo/formatters/webhook_handler.py

__init__.pyCreate tests package for fixture repo not counted

Create tests package for fixture repo

• Adds an empty test package initializer for import behavior consistency.

eval/code/cases/003-extract-shared/repo/tests/init.py

test_api_handler.pyAdd API handler tests that validate error formatting contract +31/-0

Add API handler tests that validate error formatting contract

• Adds tests for valid/invalid request scenarios and basic error shape assertions.

eval/code/cases/003-extract-shared/repo/tests/test_api_handler.py

test_webhook_handler.pyAdd failing webhook tests that expose format_error bug +29/-0

Add failing webhook tests that expose format_error bug

• Adds tests for webhook behavior and a specific assertion on the error message. The error formatting test fails before the refactor/bugfix.

eval/code/cases/003-extract-shared/repo/tests/test_webhook_handler.py

annotations.yamlDefine shell-script validation expectations for deploy.sh case +41/-0

Define shell-script validation expectations for deploy.sh case

• Adds rubric requiring DEPLOY_TARGET validation early in deploy.sh and consistency with setup.sh’s pattern. Declares budgets and forbidden labels.

eval/code/cases/004-shell-validation/annotations.yaml

input.yamlAdd GitHub issue fixture for missing DEPLOY_TARGET validation +38/-0

Add GitHub issue fixture for missing DEPLOY_TARGET validation

• Defines the bug report with current cryptic rsync failure and desired explicit validation behavior, referencing setup.sh as the pattern.

eval/code/cases/004-shell-validation/input.yaml

MakefileAdd shell fixture repo test/lint targets +7/-0

Add shell fixture repo test/lint targets

• Adds targets to run a missing-var validation test and shellcheck over scripts.

eval/code/cases/004-shell-validation/repo/Makefile

deploy.shAdd deploy script lacking required env var validation (planted gap) +9/-0

Add deploy script lacking required env var validation (planted gap)

• Implements a simple deploy flow that interpolates DEPLOY_TARGET without validating it, intentionally producing confusing failures when unset.

eval/code/cases/004-shell-validation/repo/scripts/deploy.sh

rollback.shProvide rollback script with required env var validation pattern +14/-0

Provide rollback script with required env var validation pattern

• Implements a validation loop for required env vars and a rollback rsync call; serves as a style reference for the deploy fix.

eval/code/cases/004-shell-validation/repo/scripts/rollback.sh

setup.shProvide setup script with required env var validation pattern +15/-0

Provide setup script with required env var validation pattern

• Implements a top-of-file validation loop for BUILD_DIR/APP_NAME and prepares build artifacts directory; referenced by the issue as the desired pattern.

eval/code/cases/004-shell-validation/repo/scripts/setup.sh

test_missing_vars.shAdd functional shell test to ensure scripts fail with clear messages +53/-0

Add functional shell test to ensure scripts fail with clear messages

• Adds a harness that unsets required vars and asserts non-zero exit plus mention of the missing variable name in output.

eval/code/cases/004-shell-validation/repo/tests/test_missing_vars.sh

eval.yamlAdd code-eval configuration with hooks, runner, and 5 judges +188/-0

Add code-eval configuration with hooks, runner, and 5 judges

• Introduces a case-mode eval definition including setup/teardown hooks, fullsend runner invocation, output schema, and judges for PR creation, code quality, forbidden labels, max turns, and max cost.

eval/code/eval.yaml

capture-code-output.shCapture created PR metadata and diff for code-quality judging +59/-0

Capture created PR metadata and diff for code-quality judging

• Adds an after-each hook that locates the PR on the ephemeral repo, captures PR fields and full diff via gh, and writes output/pr-state.json for downstream judges.

eval/scripts/capture-code-output.sh

run-fullsend.shExport repo/issue env vars for issue fixtures and agent runtime +8/-1

Export repo/issue env vars for issue fixtures and agent runtime

• Extends issue fixture handling to write REPO_FULL_NAME and ISSUE_NUMBER into the agent env file, and exports them in the runner environment for backward-compatible agent consumption.

eval/scripts/run-fullsend.sh

setup-fixture.shAdd optional fixture.labels support when creating GitHub issues +13/-0

Add optional fixture.labels support when creating GitHub issues

• Enhances issue fixture creation to read fixture.labels from input.yaml, ensure labels exist in the ephemeral repo, and apply them to the created issue. Behavior is backward-compatible when labels are not provided.

eval/scripts/setup-fixture.sh

@qodo-code-review

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📜 Skill insights (3)

Context used
✅ Compliance rules (platform): 55 rules
✅ Skills: 4 invoked
  code-review
  code-implementation
  pr-review
  docs-review

Grey Divider


Action required

1. DEPLOY_TARGET not validated 📜 Skill insight ⛨ Security
Description
deploy.sh proceeds to run rsync even when DEPLOY_TARGET is unset/empty, which is a fail-open
validation gate and can cause unintended behavior. The script should explicitly reject missing
configuration before performing deployment actions.
Code

eval/code/cases/004-shell-validation/repo/scripts/deploy.sh[R3-8]

+set -eo pipefail
+
+BUILD_DIR="${BUILD_DIR:-./build}"
+
+echo "Deploying to ${DEPLOY_TARGET:-}..."
+rsync -avz --delete "${BUILD_DIR}/artifacts/" "${DEPLOY_TARGET:-}:/app/"
Relevance

⭐⭐⭐ High

Team repeatedly accepts fail-closed validation gates in scripts/workflows (PR90, PR94).

PR-#90
PR-#94

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The compliance rule requires validation/auth gates to fail-closed when controlling config is absent
or empty. The added deploy.sh code uses DEPLOY_TARGET with a default empty value and continues
to execute rsync without any preflight validation.

eval/code/cases/004-shell-validation/repo/scripts/deploy.sh[3-8]
Skill: pr-review

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`eval/code/cases/004-shell-validation/repo/scripts/deploy.sh` uses `${DEPLOY_TARGET:-}` and does not validate that `DEPLOY_TARGET` is set/non-empty before running deployment logic, so the script can proceed in a permissive (fail-open) way when configuration is absent.

## Issue Context
Other scripts in the same case (e.g., `setup.sh` / `rollback.sh`) already follow a strict env-var validation pattern.

## Fix Focus Areas
- eval/code/cases/004-shell-validation/repo/scripts/deploy.sh[1-9]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. No linked issue reference 📜 Skill insight § Compliance
Description
This PR introduces a substantial new eval framework and multiple test case fixtures but does not
link to an authorizing issue in the PR description. For non-trivial changes, explicit issue
authorization is required.
Code

eval/code/eval.yaml[R1-10]

+name: code-eval
+description: Functional test of the fullsend code agent pipeline
+
+skill: code
+
+execution:
+  mode: case
+  timeout: 2400  # 40 min — agent timeout is 35 min, plus setup/teardown
+  parallelism: 2
+  env:
Relevance

⭐⭐ Medium

Prior asks to link/justify protected changes show mixed/partial adoption (PR25, PR184).

PR-#25
PR-#184

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The checklist requires a linked issue for non-trivial changes; this PR adds a large new evaluation
config and associated framework/cases but provides no linked issue in the PR description to
authorize the work.

eval/code/eval.yaml[1-10]
Skill: pr-review

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Non-trivial PRs must link to an authorizing issue (e.g., "Fixes #123" / "Refs #123"), but the PR description contains no linked issue reference.

## Issue Context
The diff adds a full new eval (`eval/code/eval.yaml`) and multiple new case repositories, indicating a non-trivial scope.

## Fix Focus Areas
- eval/code/eval.yaml[1-10]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Wrong PR captured 🐞 Bug ≡ Correctness
Description
eval/scripts/capture-code-output.sh selects the first PR returned by gh pr list without verifying
it is the PR created for the fixture issue, so when multiple PRs exist it may capture an unrelated
diff and mis-score the case.
Code

eval/scripts/capture-code-output.sh[R24-28]

+# Find PRs on the ephemeral repo. The post-script creates a PR whose
+# body contains "Closes #<FIXTURE_NUMBER>".
+PR_JSON=$(gh pr list --repo "$EPHEMERAL_REPO" --state all \
+  --json number,title,state,body,headRefName,baseRefName,additions,deletions,changedFiles,labels \
+  --jq '.[0]' 2>/dev/null || echo "null")
Relevance

⭐⭐ Medium

No precedent found for correct-PR selection in capture hook; only general eval reliability work
(PR205).

PR-#205

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The capture hook documents the Closes #<FIXTURE_NUMBER> association but does not enforce it, while
the post-code script deterministically injects that marker into the PR body, so filtering is both
intended and possible.

eval/scripts/capture-code-output.sh[24-34]
scripts/post-code.sh[513-518]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`capture-code-output.sh` claims it finds the PR whose body contains `Closes #<FIXTURE_NUMBER>`, but it actually captures `.[0]` from `gh pr list` with no association check. If multiple PRs exist (retries, multiple agent PRs, etc.), judges may evaluate the wrong PR diff.

### Issue Context
The post-script always includes `Closes #${ISSUE_NUMBER}` in the PR body, so the capture hook can reliably filter on that marker.

### Fix Focus Areas
- eval/scripts/capture-code-output.sh[24-34]

### Implementation notes
- Fetch the PR list and select the first PR whose `.body` contains `Closes #${FIXTURE_NUMBER}` (case-insensitive is fine).
- If no match is found, write `{error: "No PR found matching fixture"}` (optionally include fixture number and list size) and exit 0 like today.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

4. Label setup failures hidden 🐞 Bug ☼ Reliability
Description
eval/scripts/setup-fixture.sh suppresses errors when creating and applying fixture labels, so a
fixture can silently miss its intended labels and change agent behavior / label-based evaluation
expectations without failing setup.
Code

eval/scripts/setup-fixture.sh[R108-118]

+    # Apply fixture labels if declared in input.yaml.
+    LABEL_COUNT=$(yq -r '.fixture.labels // [] | length' "$INPUT")
+    if [[ "$LABEL_COUNT" -gt 0 ]]; then
+      for i in $(seq 0 $((LABEL_COUNT - 1))); do
+        label=$(yq -r ".fixture.labels[$i]" "$INPUT")
+        gh label create "$label" --repo "$EPHEMERAL_REPO" --force 2>/dev/null || true
+      done
+      LABELS_CSV=$(yq -r '.fixture.labels | join(",")' "$INPUT")
+      gh issue edit "$FIXTURE_NUMBER" --repo "$EPHEMERAL_REPO" \
+        --add-label "$LABELS_CSV" 2>/dev/null || true
+      echo "Applied labels: $LABELS_CSV"
Relevance

⭐⭐⭐ High

Team trends toward failing closed vs suppressing automation errors (accepted in PR184, PR94).

PR-#184
PR-#94

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The new labels feature is used by cases, but setup-fixture currently treats label creation/edit as
best-effort and hides failures, which can silently produce an incorrect fixture state.

eval/scripts/setup-fixture.sh[108-119]
eval/code/cases/002-docs-guidance/input.yaml[25-27]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Fixture label creation and label application both redirect stderr and `|| true`, so label failures are silent and setup continues. That can invalidate a case (labels in input.yaml aren’t actually present) while still producing outputs.

### Issue Context
Cases now declare `fixture.labels` in input.yaml, so labels are part of the test fixture contract.

### Fix Focus Areas
- eval/scripts/setup-fixture.sh[108-118]

### Implementation notes
- Remove `2>/dev/null || true` for label creation/application, or at minimum:
 - emit a warning to stderr and exit non-zero if applying labels fails.
 - optionally verify labels were applied by reading back `gh issue view --json labels` and checking expected names.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


5. Incorrect ISSUE_NUMBER exported 🐞 Bug ☼ Reliability
Description
eval/scripts/run-fullsend.sh exports ISSUE_NUMBER=${FIXTURE_NUMBER} for every fixture type, so PR
fixtures will incorrectly receive ISSUE_NUMBER set to the PR number, which conflicts with code-skill
scripts that validate ISSUE_NUMBER against GITHUB_ISSUE_URL.
Code

eval/scripts/run-fullsend.sh[R73-75]

+export REPO_FULL_NAME="${EPHEMERAL_REPO}"
+export ISSUE_NUMBER="${FIXTURE_NUMBER}"
+
Relevance

⭐⭐ Medium

No historical evidence on ISSUE_NUMBER export semantics; closest context is run-fullsend
introduction (PR31).

PR-#31

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The code skill’s validation requires ISSUE_NUMBER to correspond to a GitHub issue URL/number pair,
but run-fullsend exports ISSUE_NUMBER even when the fixture is a PR, bypassing the
fixture-type-specific env semantics established just above.

eval/scripts/run-fullsend.sh[54-65]
eval/scripts/run-fullsend.sh[73-75]
scripts/pre-code.sh[7-41]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`run-fullsend.sh` now unconditionally exports `ISSUE_NUMBER` (and `REPO_FULL_NAME`) after the fixture-type switch. For non-issue fixtures this can introduce semantically wrong inputs (e.g., PR number in ISSUE_NUMBER).

### Issue Context
The code skill’s pre-script enforces that `ISSUE_NUMBER` is a positive integer and matches `GITHUB_ISSUE_URL`. Exporting `ISSUE_NUMBER` in PR contexts is a compatibility hazard and can confuse downstream logic that keys off `ISSUE_NUMBER`.

### Fix Focus Areas
- eval/scripts/run-fullsend.sh[54-65]
- eval/scripts/run-fullsend.sh[73-75]

### Implementation notes
- Move the exports into the `case "$FIXTURE_TYPE"` block:
 - `issue) export REPO_FULL_NAME=...; export ISSUE_NUMBER=...;;`
 - `pull_request) export REPO_FULL_NAME=...; export PR_NUMBER=...; unset ISSUE_NUMBER;;`
- Keep writing the env-file as you do today; just make exported vars consistent with fixture type.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


6. Docs check incomplete 🐞 Bug ≡ Correctness
Description
In case 002, make check-docs only validates the Error Handling heading plus exception/traceback
keywords, so it can pass even if the required logging-before-reraise or structured API error
guidance is missing.
Code

eval/code/cases/002-docs-guidance/repo/Makefile[R9-14]

+check-docs:
+	@echo "Checking AGENTS.md structure..."
+	@grep -q "## Error Handling" AGENTS.md && echo "PASS: Error Handling section found" || (echo "FAIL: Missing '## Error Handling' section" && exit 1)
+	@grep -q "specific exception" AGENTS.md && echo "PASS: Specific exceptions topic found" || (echo "FAIL: Missing specific exceptions guidance" && exit 1)
+	@grep -q "traceback\|stacktrace\|stack trace" AGENTS.md && echo "PASS: Traceback topic found" || (echo "FAIL: Missing traceback guidance" && exit 1)
+	@echo "All docs checks passed"
Relevance

⭐⭐ Medium

No historical evidence on doc-check completeness; team does tighten validations elsewhere (PR90,
PR94).

PR-#90
PR-#94

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The fixture’s rubric requires four topics, but the Makefile only enforces two of them, allowing
incomplete docs changes to pass make check-docs.

eval/code/cases/002-docs-guidance/annotations.yaml[15-20]
eval/code/cases/002-docs-guidance/input.yaml[12-20]
eval/code/cases/002-docs-guidance/repo/Makefile[9-14]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The case requires 4 specific topics in the new AGENTS.md section, but the repo’s `check-docs` target only checks for 2 of them (plus the heading). This weakens the fixture’s self-verification.

### Issue Context
Both the issue text and annotations list the required topics; `check-docs` should reflect that contract.

### Fix Focus Areas
- eval/code/cases/002-docs-guidance/repo/Makefile[9-14]
- eval/code/cases/002-docs-guidance/input.yaml[12-20]
- eval/code/cases/002-docs-guidance/annotations.yaml[15-20]

### Implementation notes
- Add grep checks for:
 - logging before re-raising (e.g., `logger.error` / `log` / `re-raise` wording)
 - structured API errors (e.g., `structured` + `error response`, `JSON`, etc.)
- (Optional) also assert placement: Error Handling appears after `## Code Style` and before `## Testing`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

7. Agent prompt in eval.yaml 📜 Skill insight ⛨ Security
Description
The new eval configuration embeds role/instruction-style prompt text (e.g., "You are evaluating...")
in a config value, matching prohibited agent-instruction patterns. This increases risk of
prompt-injection style artifacts being carried in-repo as executable/configured content.
Code

eval/code/eval.yaml[R96-123]

+    prompt: |
+      You are evaluating a code agent's work on a GitHub issue. The agent
+      was given an issue filed against a small repository, and ran a full
+      implementation pipeline: it read the issue and source code, identified
+      what needed to change, implemented the fix or feature, and committed
+      to a feature branch. A post-script then pushed the branch and
+      created a PR.
+
+      Here is the captured state of the PR the agent created, including
+      the full diff:
+      {{ outputs }}
+
+      Here is what the test case author expects from a good implementation:
+      {{ annotations }}
+
+      Evaluate the quality of the implementation on a 1-5 scale:
+
+      1 = Wrong change or fundamentally misunderstood the issue
+      2 = Change addresses the symptom but not the root cause, or
+          introduces new issues
+      3 = Adequate — correct change, but sloppy (unnecessary edits, extra
+          files modified, poor placement or formatting)
+      4 = Good — correct minimal change, clean diff, meets expectations
+      5 = Excellent — minimal correct change, clean commit message
+          referencing the issue, no scope creep, nothing extraneous
+
+      Use the code_expectations field in the annotations as your rubric.
+      Respond with just a number 1-5.
Relevance

⭐ Low

Repo already includes instruction-style prompts in eval YAML (PR31, PR148); not treated as
prohibited.

PR-#31
PR-#148

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The rule disallows agent-instruction patterns in config values. The added
judges.code_quality.prompt block contains explicit role/instruction phrasing ("You are
evaluating...", "Respond with...") which matches the failure criteria style.

eval/code/eval.yaml[96-123]
Skill: code-review

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`eval/code/eval.yaml` introduces a long instruction-style prompt in a YAML config value (`judges[].prompt`), which matches the prohibited "agent instruction patterns" category.

## Issue Context
The rule forbids system-prompt fragments / role-play instructions in comments, string literals, or config values.

## Fix Focus Areas
- eval/code/eval.yaml[91-123]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

@@ -0,0 +1,9 @@
#!/usr/bin/env bash
# Deploy script — pushes build artifacts to the target server.
set -eo pipefail

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. deploy_target not validated 📜 Skill insight ⛨ Security

deploy.sh proceeds to run rsync even when DEPLOY_TARGET is unset/empty, which is a fail-open
validation gate and can cause unintended behavior. The script should explicitly reject missing
configuration before performing deployment actions.
Agent Prompt
## Issue description
`eval/code/cases/004-shell-validation/repo/scripts/deploy.sh` uses `${DEPLOY_TARGET:-}` and does not validate that `DEPLOY_TARGET` is set/non-empty before running deployment logic, so the script can proceed in a permissive (fail-open) way when configuration is absent.

## Issue Context
Other scripts in the same case (e.g., `setup.sh` / `rollback.sh`) already follow a strict env-var validation pattern.

## Fix Focus Areas
- eval/code/cases/004-shell-validation/repo/scripts/deploy.sh[1-9]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread eval/code/eval.yaml
@@ -0,0 +1,188 @@
name: code-eval

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

3. No linked issue reference 📜 Skill insight § Compliance

This PR introduces a substantial new eval framework and multiple test case fixtures but does not
link to an authorizing issue in the PR description. For non-trivial changes, explicit issue
authorization is required.
Agent Prompt
## Issue description
Non-trivial PRs must link to an authorizing issue (e.g., "Fixes #123" / "Refs #123"), but the PR description contains no linked issue reference.

## Issue Context
The diff adds a full new eval (`eval/code/eval.yaml`) and multiple new case repositories, indicating a non-trivial scope.

## Fix Focus Areas
- eval/code/eval.yaml[1-10]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

mkdir -p "$OUTPUT_DIR"
PR_STATE_FILE="${OUTPUT_DIR}/pr-state.json"

# Find PRs on the ephemeral repo. The post-script creates a PR whose

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

4. Wrong pr captured 🐞 Bug ≡ Correctness

eval/scripts/capture-code-output.sh selects the first PR returned by gh pr list without verifying
it is the PR created for the fixture issue, so when multiple PRs exist it may capture an unrelated
diff and mis-score the case.
Agent Prompt
### Issue description
`capture-code-output.sh` claims it finds the PR whose body contains `Closes #<FIXTURE_NUMBER>`, but it actually captures `.[0]` from `gh pr list` with no association check. If multiple PRs exist (retries, multiple agent PRs, etc.), judges may evaluate the wrong PR diff.

### Issue Context
The post-script always includes `Closes #${ISSUE_NUMBER}` in the PR body, so the capture hook can reliably filter on that marker.

### Fix Focus Areas
- eval/scripts/capture-code-output.sh[24-34]

### Implementation notes
- Fetch the PR list and select the first PR whose `.body` contains `Closes #${FIXTURE_NUMBER}` (case-insensitive is fine).
- If no match is found, write `{error: "No PR found matching fixture"}` (optionally include fixture number and list size) and exit 0 like today.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[[ -n "${GOOGLE_APPLICATION_CREDENTIALS:-}" ]] && echo "GOOGLE_APPLICATION_CREDENTIALS=${GOOGLE_APPLICATION_CREDENTIALS}"
} > "$ENV_FILE"

export REPO_FULL_NAME="${EPHEMERAL_REPO}"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

5. Incorrect issue_number exported 🐞 Bug ☼ Reliability

eval/scripts/run-fullsend.sh exports ISSUE_NUMBER=${FIXTURE_NUMBER} for every fixture type, so PR
fixtures will incorrectly receive ISSUE_NUMBER set to the PR number, which conflicts with code-skill
scripts that validate ISSUE_NUMBER against GITHUB_ISSUE_URL.
Agent Prompt
### Issue description
`run-fullsend.sh` now unconditionally exports `ISSUE_NUMBER` (and `REPO_FULL_NAME`) after the fixture-type switch. For non-issue fixtures this can introduce semantically wrong inputs (e.g., PR number in ISSUE_NUMBER).

### Issue Context
The code skill’s pre-script enforces that `ISSUE_NUMBER` is a positive integer and matches `GITHUB_ISSUE_URL`. Exporting `ISSUE_NUMBER` in PR contexts is a compatibility hazard and can confuse downstream logic that keys off `ISSUE_NUMBER`.

### Fix Focus Areas
- eval/scripts/run-fullsend.sh[54-65]
- eval/scripts/run-fullsend.sh[73-75]

### Implementation notes
- Move the exports into the `case "$FIXTURE_TYPE"` block:
  - `issue) export REPO_FULL_NAME=...; export ISSUE_NUMBER=...;;`
  - `pull_request) export REPO_FULL_NAME=...; export PR_NUMBER=...; unset ISSUE_NUMBER;;`
- Keep writing the env-file as you do today; just make exported vars consistent with fixture type.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

FIXTURE_NUMBER="${FIXTURE_URL##*/}"
echo "Created issue: $FIXTURE_URL"

# Apply fixture labels if declared in input.yaml.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

6. Label setup failures hidden 🐞 Bug ☼ Reliability

eval/scripts/setup-fixture.sh suppresses errors when creating and applying fixture labels, so a
fixture can silently miss its intended labels and change agent behavior / label-based evaluation
expectations without failing setup.
Agent Prompt
### Issue description
Fixture label creation and label application both redirect stderr and `|| true`, so label failures are silent and setup continues. That can invalidate a case (labels in input.yaml aren’t actually present) while still producing outputs.

### Issue Context
Cases now declare `fixture.labels` in input.yaml, so labels are part of the test fixture contract.

### Fix Focus Areas
- eval/scripts/setup-fixture.sh[108-118]

### Implementation notes
- Remove `2>/dev/null || true` for label creation/application, or at minimum:
  - emit a warning to stderr and exit non-zero if applying labels fails.
  - optionally verify labels were applied by reading back `gh issue view --json labels` and checking expected names.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

lint:
gofmt -l .

check-docs:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

7. Docs check incomplete 🐞 Bug ≡ Correctness

In case 002, make check-docs only validates the Error Handling heading plus exception/traceback
keywords, so it can pass even if the required logging-before-reraise or structured API error
guidance is missing.
Agent Prompt
### Issue description
The case requires 4 specific topics in the new AGENTS.md section, but the repo’s `check-docs` target only checks for 2 of them (plus the heading). This weakens the fixture’s self-verification.

### Issue Context
Both the issue text and annotations list the required topics; `check-docs` should reflect that contract.

### Fix Focus Areas
- eval/code/cases/002-docs-guidance/repo/Makefile[9-14]
- eval/code/cases/002-docs-guidance/input.yaml[12-20]
- eval/code/cases/002-docs-guidance/annotations.yaml[15-20]

### Implementation notes
- Add grep checks for:
  - logging before re-raising (e.g., `logger.error` / `log` / `re-raise` wording)
  - structured API errors (e.g., `structured` + `error response`, `JSON`, etc.)
- (Optional) also assert placement: Error Handling appears after `## Code Style` and before `## Testing`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants