wassname
0fa250b193
route2 directionality exposed the vector is not load-bearing: hack_anchor force-routes teacher+detector by label (bypassing v_grad), tau calibrated from a live detector, so random==real because labels carried it. Redesign: teacher-off@30, drop force-route, calibrate tau from the A-pairs (no live detector), maybe use the pairset directly vs a rank-1 vector. Decisive test = A5 real(126) vs random(135). Queue snapshot + design notes in docs/REFACTOR_HANDOFF.md. Co-Authored-By: Claudypoo <288921227+claudypoo@users.noreply.github.com>
1.2 KiB
name, description, metadata
| name | description | metadata | ||||||
|---|---|---|---|---|---|---|---|---|
| pueue-negative-priority-gotcha | pueue add with a negative priority must use -o=-N (attached); -o -N silently fails the add. |
|
pueue add -o -1 ... fails: the parser reads -1 as an unknown flag, not the value
of -o, so the add aborts with rc=2 and the job is never queued. The error goes to
stderr; if you only check stdout the failure is silent. Non-negative priorities
(-o 9) work either way, so a batch requeue can drop exactly the negative-priority
jobs and look fine.
Use the attached form for negatives: pueue add -o=-1 -l "..." -w "$PWD" -- cmd.
Why: burned this during the projected_grpo->vgrout module rename requeue (2026-06-05): 11 jobs re-added, the 6 with prio -1/-2 (A4 pair, A5 n=3 seeds) silently failed while the 5 with prio >=0 succeeded. Caught only by counting the re-add IDs.
How to apply: when scripting pueue add, always write -o=<N>, and assert the add
printed "New task added (id ...)" (check rc and stdout), don't assume success. Relates
to the pueue workflow notes in CLAUDE.md (which document -o N but not the negative case).