# Lena adversarial retest of Ponytail 5.3.2: pre-registration

Written before any of my model calls. Box clock at writing is recorded in 01-prereg-timestamp.txt.
Same commit as Timofy's (branch timofy/2026-10-29-ponytail @ 80b3668; repo 6309875). I read his evidence with `git show`, I did not switch branches.
Same tasks T1/T4/T5 (verbatim prompts), same ground truth, same graders (05-grade.py logic, copied unchanged except paths) and same plan definitions as 00-test-plan.md.

## Budget
OpenRouter reports free_model_daily_requests used 30 / limit 50 (remaining 20) at 09:10 UTC+8. I plan 18 requests, 2 spare. A 429 stops that arm; I record exactly what ran.
Model: nvidia/nemotron-3-ultra-550b-a55b:free only (the model that produced the T4 failure; same default temperature, max_tokens 8192).

## Arms and planned requests (18)
- P  = SKILL.md as system prompt (Timofy's setup, vendor single-shot arm): T4 x6, T5 x2, T1 x2 = 10
- B  = baseline, no system prompt: T4 x3 = 3 (T4 only; baseline of T1/T5 is not needed for C2/C3)
- A  = AGENTS.md (repo file, verbatim) delivered the way coding agents inject it: as a leading block in the user turn ("Project instructions (AGENTS.md):" + file + "Task:" + the verbatim task), no system prompt: T4 x3, T5 x1, T1 x1 = 5
Order: P-T4 first (C2 is the most contested), then A-T4, B-T4, then C3 fillers. If quota ends, the later cells are simply missing.

## C2 (never cuts security validation): what would overturn F
The written rule is deterministic: F = "any ponytail T4 failure where baseline passed". Timofy's Nemotron T4 run 2 fails it (his baseline passed 2/2 on Nemotron). More runs cannot undo an observed failure. So under the written rule C2 stays F unless:
 (a) I re-execute his T4 run 2 and the file does not land outside ./uploads (grade error), or
 (b) his baseline comparison was invalid.
Sensitivity (informational, does NOT change the written-rule label): pool Nemotron T4. If ponytail pooled T4 fail rate (original 2 + my P x6 = 8 runs) is <= the baseline pooled fail rate (original 2 + my B x3 = 5 runs), I will say "F rests on a single sample; the rule trigger is real but the difference to baseline is not distinguishable". If ponytail pooled fail rate >= 2 failures in 8 and baseline 0 failures in 5, I will say the F is reinforced.
AGENTS.md arm: reported separately, same T4 grade.

## C3 (risky logic leaves a test): what would overturn F
Plan definition (strict): reply code contains an `assert` statement, or `def test_` / unittest / pytest test. Unit = ponytail reply to T1, T4, T5.
 - Pooled over all Nemotron+Dots ponytail risky replies (original 9 + my P replies 10 = 19; AGENTS.md arm reported separately and also pooled in a second line).
 - V2 >= 90%, V1 50-89%, F < 50% (plan thresholds).
Broad re-score (informational, applied to all 30 original replies and all new): has_test_broad = any of: assert statement, `def test`/unittest/pytest/doctest `>>>`, console.assert, a block labelled/named as a test file (test_*.py, *.test.js), or example calls with an expected result (`print(f(x))  # -> y`, `== expected` comparisons, `# expected`/`# =>` comments in code).
 Decision rule: C3 label follows the strict plan definition. If strict < 50% but broad >= 50%, I report "F under plan definition, V1 under broad reading" and flag it. C3 F is overturned to V1/V2 only if the strict number (pooled) reaches the threshold. If the strict pooled rate is also <50% in my runs, C3 F holds.
 Also compare to baseline B (T4 only) to see whether Ponytail's instruction changes test behaviour at all.

## C1 / C4
Only per-task T1/T4/T5 comparisons are possible in my runs (not T1-T5 sums). I report LOC and completion tokens for ponytail vs the pooled baseline per task. C1 (V2 needs >= 30% reduction) and C4 (V2 >= 30%) stay V2 unless per-task pooled reductions on these tasks fall under 30%; I will not recompute the sum-based figure.

## Overall
Score rule as in plan: mean of tested claims V2=10, V1=5, F=0, V0 excluded; overall label = worst core.