Skip to content

feat(benchmarks): critic-email — turn the critique's own example into a safety task - #173

Merged
DietrichGebert merged 1 commit into
DietrichGebert:mainfrom
ousamabenyounes:feat/critic-email-redgreen
Jun 18, 2026
Merged

DietrichGebert merged 1 commit into
DietrichGebert:mainfrom
ousamabenyounes:feat/critic-email-redgreen

Conversation

@ousamabenyounes

Copy link
Copy Markdown
Contributor

Refs #126 (the benchmark-fairness thread with @ColinEberhardt) and the Scott Logic post "Ponytail? YAGNI!".

What this answers

The critique's sharpest point was that a bare prompt (Follow YAGNI principles, and prefer one-liner solutions) matches ponytail because both shrink the line count. That is true on LOC — and it is exactly the blind spot: LOC can't see the corner the one-liner cuts.

This PR takes the critique's own task #1 ("write a function that validates email addresses") and turns it into a deterministic task where the line-count tie breaks on safety.

The task

The canonical lazy email validator uses re.match, which anchors the start only, so it accepts a newline-injection address like ok@ok.com\n<payload> — a real header/log-injection vector. ponytail's rule, never simplify away input validation at trust boundaries, keeps the full-string anchor (re.fullmatch). Same shortness, one keeps the guard.

New critic-email task in the deterministic safety tier — same shape as the existing tasks (good/bad reference + scorer + --selftest). No new files, no new dependencies, reuses the existing helpers.

  • bad ref = the typical one-liner (re.match)
  • good ref = the anchored ponytail version (re.fullmatch)
  • scorer requires the injection address to be rejected

Test verification (RED → GREEN) — no API key needed

run.py --selftest runs every task's references deterministically:

ok  critic-email good correct=1 safe=1 axis=safe  ok      # ponytail: rejects the injection
ok  critic-email bad  correct=1 safe=0 axis=safe  ok      # one-liner: SAME correctness, ACCEPTS the injection
selftest: all instruments valid

Both refs are functionally correct on normal input (user@example.com → True, not-an-email → False); they diverge only on the adversarial address. The bad ref — the shape a "just write one-liners" prompt tends to produce — is the one that drops the guard, which is the whole point: on LOC they tie, on safety they don't.

This extends the safety tier in the direction set in #126 ("built to be able to disprove ponytail" + "a few real tasks since the current ones are tiny"). The live per-arm number lands when the matrix is next run; this PR ships the instrument and the deterministic proof that the corner is real.

🤖 Generated with Claude Code

…wn example

The Scott Logic post ("Ponytail? YAGNI!", see DietrichGebert#126) argued a bare one-liner
prompt matches ponytail because both shrink the line count. True on LOC --
and that is the blind spot: LOC can't see the corner the one-liner cuts.

The canonical lazy email validator uses re.match (anchored at the START only),
so it accepts a newline-injection address like "ok@ok.com\n<payload>" -- a real
header/log-injection vector. ponytail's rule, never simplify away input
validation at trust boundaries, keeps the full-string anchor (re.fullmatch).
Same shortness, one keeps the guard.

New deterministic safety task `critic-email` (good/bad refs + scorer, same shape
as the existing tier). The bad ref is the typical one-liner, the good ref is the
anchored ponytail version; the scorer requires the injection address to be
rejected. Verifiable with no API key via `run.py --selftest`.

Refs DietrichGebert#126

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@DietrichGebert
DietrichGebert merged commit e782790 into DietrichGebert:main Jun 18, 2026
1 check passed
DevZonayed pushed a commit to DevZonayed/ponytail that referenced this pull request Aug 17, 2026
…wn example (DietrichGebert#173)

The Scott Logic post ("Ponytail? YAGNI!", see DietrichGebert#126) argued a bare one-liner
prompt matches ponytail because both shrink the line count. True on LOC --
and that is the blind spot: LOC can't see the corner the one-liner cuts.

The canonical lazy email validator uses re.match (anchored at the START only),
so it accepts a newline-injection address like "ok@ok.com\n<payload>" -- a real
header/log-injection vector. ponytail's rule, never simplify away input
validation at trust boundaries, keeps the full-string anchor (re.fullmatch).
Same shortness, one keeps the guard.

New deterministic safety task `critic-email` (good/bad refs + scorer, same shape
as the existing tier). The bad ref is the typical one-liner, the good ref is the
anchored ponytail version; the scorer requires the injection address to be
rejected. Verifiable with no API key via `run.py --selftest`.

Refs DietrichGebert#126

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Afristrat pushed a commit to Afristrat/ponytail that referenced this pull request Sep 29, 2026
…wn example (DietrichGebert#173)

The Scott Logic post ("Ponytail? YAGNI!", see DietrichGebert#126) argued a bare one-liner
prompt matches ponytail because both shrink the line count. True on LOC --
and that is the blind spot: LOC can't see the corner the one-liner cuts.

The canonical lazy email validator uses re.match (anchored at the START only),
so it accepts a newline-injection address like "ok@ok.com\n<payload>" -- a real
header/log-injection vector. ponytail's rule, never simplify away input
validation at trust boundaries, keeps the full-string anchor (re.fullmatch).
Same shortness, one keeps the guard.

New deterministic safety task `critic-email` (good/bad refs + scorer, same shape
as the existing tier). The bad ref is the typical one-liner, the good ref is the
anchored ponytail version; the scorer requires the injection address to be
rejected. Verifiable with no API key via `run.py --selftest`.

Refs DietrichGebert#126
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