Skip to content

Harden skill evaluation and repository controls#5

Merged
dd3ok merged 1 commit into
mainfrom
codex/best-practice-hardening
Jul 10, 2026
Merged

Harden skill evaluation and repository controls#5
dd3ok merged 1 commit into
mainfrom
codex/best-practice-hardening

Conversation

@dd3ok

@dd3ok dd3ok commented Jul 10, 2026

Copy link
Copy Markdown
Owner

Summary

  • refine runtime routing, idempotency, review-only, handoff, delegation, authorization, and evidence boundaries
  • add a provider-neutral trigger evaluation harness with paired trials, bounded protocol I/O, provenance, and cross-platform process cleanup
  • harden CI, Python support, dependency updates, contribution guidance, and security reporting

Verification

  • python scripts/verify_all.py (77 tests; POSIX-only test skipped on Windows)
  • Ubuntu WSL / Python 3.14: all 24 evaluator tests passed
  • source, .agents, and .claude packages pass quick_validate.py
  • python -m ruff check scripts tests
  • python -m py_compile ...
  • gh skill publish --dry-run . from skills/
  • 18 trigger cases x 2 variants protocol smoke passed with fake telemetry left null

Checklist

  • Source-first skill edits were made under skills/boring-backend/.
  • Mirrors under .agents/skills/boring-backend/ and .claude/skills/boring-backend/ are synchronized.
  • Tests were added or updated, and python scripts/verify_all.py passes.
  • Evaluation inputs and tooling remain outside the runtime skill package.
  • No secrets, credentials, tokens, or sensitive report data are included.

@dd3ok dd3ok force-pushed the codex/best-practice-hardening branch from 4d897a3 to 0b6498d Compare July 10, 2026 08:14
@dd3ok dd3ok merged commit 26d2747 into main Jul 10, 2026
4 checks passed
@dd3ok dd3ok deleted the codex/best-practice-hardening branch July 10, 2026 08:16

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Code Review

This pull request introduces a provider-neutral skill activation evaluation harness (run_skill_eval.py) with corresponding tests, and updates the repository's documentation, workflows, and verification scripts to support this protocol. It also refines the semantic rules and guard catalogs for the boring-backend skill. Feedback on these changes suggests wrapping path operations in command_file_hashes with a try-except OSError block to prevent crashes on Windows when processing arguments with invalid filename characters. Additionally, it is recommended to make the evaluation harness more resilient by recording individual trial failures rather than aborting the entire run upon a timeout or non-zero exit code.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Comment thread scripts/run_skill_eval.py
Comment on lines +383 to +403
def command_file_hashes(command: list[str]) -> list[dict[str, Any]]:
files = []
for index, argument in enumerate(command):
candidate = Path(argument).expanduser()
if not candidate.is_absolute():
candidate = ROOT / candidate
if not candidate.is_file() and index == 0:
executable = shutil.which(argument)
if executable is not None:
candidate = Path(executable)
if candidate.is_file():
resolved = candidate.resolve()
files.append(
{
"argument_index": index,
"argument": argument,
"path": str(resolved),
"sha256": hash_file(resolved),
}
)
return files

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

high

On Windows, Path(argument).expanduser() and candidate.is_file() can raise an OSError if the argument contains characters that are invalid in Windows filenames (such as <, >, |, *, ?). Since command can contain arbitrary arguments passed to the runner (including query strings, JSON payloads, or other non-path strings), this can cause the evaluation to crash on Windows. Wrapping the path operations in a try...except OSError: block will make the file hashing robust and cross-platform.

def command_file_hashes(command: list[str]) -> list[dict[str, Any]]:
    files = []
    for index, argument in enumerate(command):
        try:
            candidate = Path(argument).expanduser()
            if not candidate.is_absolute():
                candidate = ROOT / candidate
            if not candidate.is_file() and index == 0:
                executable = shutil.which(argument)
                if executable is not None:
                    candidate = Path(executable)
            if candidate.is_file():
                resolved = candidate.resolve()
                files.append(
                    {
                        "argument_index": index,
                        "argument": argument,
                        "path": str(resolved),
                        "sha256": hash_file(resolved),
                    }
                )
        except OSError:
            continue
    return files

Comment thread scripts/run_skill_eval.py
Comment on lines +1007 to +1021
if completed.timed_out:
cleanup = (
f"; cleanup best effort: {'; '.join(completed.cleanup_errors)}"
if completed.cleanup_errors
else ""
)
raise EvalError(f"runner timed out for {run_id}{detail}{cleanup}")
if completed.cleanup_errors:
raise EvalError(
f"runner cleanup failed for {run_id}: {'; '.join(completed.cleanup_errors)}"
)
if completed.returncode != 0:
raise EvalError(
f"runner exited {completed.returncode} for {run_id}{detail}"
)

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

medium

Aborting the entire evaluation run on the first timeout or non-zero exit code of an adapter makes the harness highly fragile. Transient network issues or timeouts are common when calling LLM providers. Consider recording the failure for the specific trial in results.jsonl (e.g., with a failed status or null response) and continuing the evaluation loop so that a single transient issue does not discard the results of the entire suite.

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.

1 participant