Tokenbending

Yes. Examples would make it much more usable because they turn the rule from taste into a decision boundary.

Deterministic Rules With Examples

Use the project's canonical tracking surface as the experiment log. Example: If the project uses GitHub issues, update the issue when a run starts, when a stage completes, when a failure occurs, and when artifacts are uploaded. Example: If the project uses a lab notebook or runs/README.md, append the command, config, result summary, and artifact path there.

Keep changes atomic and reviewable. Example: Commit "add experiment spec" separately from "fix distributed launcher." Example: Do not mix README cleanup, runner code, and generated data into one commit.

Verify before reporting completion. Example: Do not say "uploaded" until the destination lists the expected files. Example: Do not say "training is distributed" until process/GPU state or logs confirm multiple workers.

Do not leave hanging work implicit. Example: If a temporary compatibility endpoint, migration alias, fallback script, manual workaround, unresolved verification, or cleanup step remains, create or link a follow-up issue before calling the work done. Example: Do not write "follow-up: none" when any known duct tape, residual risk, or future cleanup still exists; make the remaining work durable in the project's tracking surface.

Preserve reproducible state before deleting compute resources. Example: Upload configs, logs, checkpoints, summaries, and command history before terminating a pod. Example: If upload fails, keep the machine alive or create a smaller fallback bundle before cleanup.

Do not upload secrets, tokens, caches, or third-party base assets unless explicitly authorized. Example: Upload adapter weights and run logs, but exclude API keys and model cache directories. Example: Preserve a manifest saying which external base model must be re-downloaded instead of copying the full base model.

Clean up costly resources after preservation is verified. Example: Delete an experiment VM after artifact upload is listed and checksummed. Example: Leave unrelated shared infrastructure alone unless the user asked to clean it too.

If the user says stop at first failure, stop at the first substantive failure. Example: A syntax check failure means stop, report it, and do not launch the long run. Example: If stage 2 crashes after stage 1 succeeds, preserve stage 1 outputs and do not proceed to stage 3.

Honor exact named constraints. Example: If the user specifies a particular GPU type, verify the actual GPU model before running. Example: If the user specifies a held-out dataset, do not silently swap in a convenient alternative.

Prefer resumability. Example: Save the exact command line, config, environment notes, logs, and output manifest. Example: Make the artifact bundle sufficient for a new machine to continue from the last valid checkpoint.

Gate paid or long accelerator runs with a full-load profile smoke. Example: Before launching full training on paid GPU/TPU compute, sweep the viable batch, gradient accumulation, packing, compile, checkpointing, and logging settings on a realistic smoke run; record step time, tokens/sec, memory, estimated MFU, and the chosen profile. Example: Do not spend the full run on a low-utilization profile unless the user explicitly accepts the efficiency tradeoff or the controlled experiment forbids changing the profile.

Fuzzy Clarification Rules With Examples

Clarify the exact research question when ambiguous. Example: "Are we testing whether the smaller subsystem alone performs the task, or whether the full system works after replacing that subsystem?" Example: "Is the goal best absolute score, smallest viable subsystem, or a clean comparison to a prior method?"

Clarify fixed variables versus allowed variables. Example: "Should dataset, model, metric, and evaluation mode stay fixed while only the training method changes?" Example: "Can I change batch size and launcher details for stability, or are those part of the controlled experiment?"