Enforce No Fallbacks
Core Rule
Do not add fallback code to make a failure disappear. Preserve the failure, find the reason, and fix the reason.
Treat this as a default engineering constraint for local Mac work, remote server work, SSH sessions, and SLURM jobs.
Forbidden By Default
Avoid adding or keeping patterns that hide problems:
- Broad
try/except blocks that continue after an unexpected error.
except Exception: pass, empty outputs, synthetic data, cached plots, or placeholder results after a failed computation.- Silent import fallbacks, alternate libraries, alternate file paths, alternate interpreters, alternate TeX engines, or alternate plotting backends.
- Default values used only because a config key, data column, environment variable, or dependency is missing.
- Switching from a required server, node, queue, or SLURM workflow to local/login-node execution because submission failed.
- Changing scientific parameters, data cuts, units, or physical models to make a run complete without explaining the underlying failure.
Failure Workflow
When something fails:
- Reproduce the exact command or code path that failed.
- Keep the original traceback, stderr, job log, or compiler log visible.
- Inspect the real cause: interpreter, package versions, paths, permissions, environment variables, config files, input data schema, scheduler resources, or node-specific state.
- Fix the root cause directly.
- Add or update a focused test/check when the failure could recur.
- Report what failed, why it failed, and what changed.
Cross-Environment Rules
Apply the same rule on local Mac and on servers.
- On local Mac: verify the active shell,
$PATH, Python/Conda/uv environment, TeX installation, filesystem path, and permissions before changing code.
- On remote servers: verify SSH host, working directory, project environment, modules, permissions, storage mount, and scheduler context.
- On SLURM clusters: inspect submission output, allocation, node logs, stdout/stderr, exit code, walltime, memory, CPU count, and environment activation. If a job must run on a compute node, do not move it to the login node as a workaround.
Allowed Exceptions
A fallback is allowed only when the user explicitly asks for graceful degradation, or when an existing product requirement already defines it.
Even then, make it observable and testable:
- Name the failure condition precisely.
- Log or surface the fallback path clearly.
- Keep the original error available.
- Add a test that proves both the normal path and fallback path behave as intended.
- Avoid changing scientific meaning or hiding missing data.
Review Behavior
When reviewing existing code, flag fallback paths that could hide broken environments, missing data, failed jobs, failed imports, or physically invalid results. Recommend root-cause fixes instead of additional fallback layers.
1---2name: enforce-no-fallbacks3description: Use when writing, running, testing, debugging, reviewing, or modifying code, scripts, TeX, plots, local/remote commands, or SLURM jobs where failures must surface clearly instead of being hidden by fallbacks, guessed paths, or silent degradation.4---56# Enforce No Fallbacks78## Core Rule910Do not add fallback code to make a failure disappear. Preserve the failure, find the reason, and fix the reason.1112Treat this as a default engineering constraint for local Mac work, remote server work, SSH sessions, and SLURM jobs.1314## Forbidden By Default1516Avoid adding or keeping patterns that hide problems:1718- Broad `try/except` blocks that continue after an unexpected error.19- `except Exception: pass`, empty outputs, synthetic data, cached plots, or placeholder results after a failed computation.20- Silent import fallbacks, alternate libraries, alternate file paths, alternate interpreters, alternate TeX engines, or alternate plotting backends.21- Default values used only because a config key, data column, environment variable, or dependency is missing.22- Switching from a required server, node, queue, or SLURM workflow to local/login-node execution because submission failed.23- Changing scientific parameters, data cuts, units, or physical models to make a run complete without explaining the underlying failure.2425## Failure Workflow2627When something fails:28291. Reproduce the exact command or code path that failed.302. Keep the original traceback, stderr, job log, or compiler log visible.313. Inspect the real cause: interpreter, package versions, paths, permissions, environment variables, config files, input data schema, scheduler resources, or node-specific state.324. Fix the root cause directly.335. Add or update a focused test/check when the failure could recur.346. Report what failed, why it failed, and what changed.3536## Cross-Environment Rules3738Apply the same rule on local Mac and on servers.3940- On local Mac: verify the active shell, `$PATH`, Python/Conda/uv environment, TeX installation, filesystem path, and permissions before changing code.41- On remote servers: verify SSH host, working directory, project environment, modules, permissions, storage mount, and scheduler context.42- On SLURM clusters: inspect submission output, allocation, node logs, stdout/stderr, exit code, walltime, memory, CPU count, and environment activation. If a job must run on a compute node, do not move it to the login node as a workaround.4344## Allowed Exceptions4546A fallback is allowed only when the user explicitly asks for graceful degradation, or when an existing product requirement already defines it.4748Even then, make it observable and testable:4950- Name the failure condition precisely.51- Log or surface the fallback path clearly.52- Keep the original error available.53- Add a test that proves both the normal path and fallback path behave as intended.54- Avoid changing scientific meaning or hiding missing data.5556## Review Behavior5758When reviewing existing code, flag fallback paths that could hide broken environments, missing data, failed jobs, failed imports, or physically invalid results. Recommend root-cause fixes instead of additional fallback layers.
SOYONAOC