PIMiner CLAUDE.md

PIMiner — project-level instructions for Claude Code

Entry points & utility commands → ORCHESTRATION.md

How to launch runs (training and test) and housekeeping commands (reset strategy library, etc.) live in ORCHESTRATION.md — read it when the user asks to dispatch a run or issue a utility command. It is intentionally NOT in this file: CLAUDE.md is auto-loaded into and re-read every turn by every session (including attacker sessions that only run next/write/submit), so launch/maintenance procedure is kept out to minimize per-turn token overhead. Quick map: edit experiments/<name>.yaml (train: + test: lists) → python piminer_plan.py experiments/<name>.yaml builds the plan files → piminer_train_parallel.sh / piminer_test_parallel.sh run them. Full slot grammar + worked examples: USAGE.md.

Run-to-completion mandate

Do not pause to ask intermediate questions about time, cost, or whether to keep going during a multi-step run. The user has explicitly chosen to spend whatever time the run requires. When in doubt about the cost or duration, default to continuing until the work is finished, the run hits a real error, or the user explicitly says stop.

Hard threshold: never ask "should I continue / is this OK to keep running?" for any task whose expected total wall time is under 2 days. This applies before launching (don't pre-confirm a 10-hour batch) and during execution (don't pause partway to re-confirm). 10 hours, 24 hours, 36 hours — all well inside the threshold; just run it. Asking creates exactly the failure mode we keep seeing: the batch dies waiting for an answer, partial state is left on disk, and the run has to be restarted from scratch. The only mid-run interrupts allowed are the two legitimate reasons listed below. If a task is expected to exceed 2 days, surface that estimate once up-front before launching — and only then.

In practice this means:

• iterative attack runs (/step, sample-major or batched): when starting, drive every sample through every iter to its terminal status (hit / miss / exhausted) without checking in mid-run. Do not summarise hit-rate-so-far and ask "should I continue?" — that pattern is forbidden. Hit-rate plateaus, slow per-iter wall time, "diminishing returns" intuitions, and "this will take ~N more hours" estimates are not reasons to stop or to ask.
• Long file edits / refactors / migrations: same shape. Plan up front, then execute end-to-end. If the work splits naturally into phases, complete each phase before reporting; don't ask "want me to do the next phase?" between phases.
• Background tasks (run_in_background: true Bash, agents): kick them off, do other useful work while they run, and proceed when their notification fires. Do not poll-and-pause.