The Slice Gate That Read Another Program's Artifacts
One program directory baked into cmd_slice let a validation gate pass on someone else's evidence; a one-line env-override fixed it.
TL;DR
A slice gate silently validated the wrong program's evidence because the program directory was hardcoded in cmd_slice. The fix was one line: read an env var first, fall back to the default, matching the existing REPO_ROOT pattern. Run tools in two contexts and compare file references to catch baked-in constants early.
The slice gate was run for a new program, and passing felt too smooth. The check had read the qa-backfill program directory instead of the directory of the program currently running. The evidence being validated did not belong to the work under review. The command itself looked neutral because it only accepted a slice number, so the first suspicion fell on bad input rather than on the script.
The gate script was originally built while qa-backfill ran, and one location was baked directly into the body of cmd_slice. As long as only one program existed, that shortcut was invisible. A second program appeared, and the same gate began validating someone else's evidence without a sound.
An Invisible Hard Path
Code that accepts a parameter is easily assumed to be configurable. But the parameter received and the path followed are two different things: the slice number is passed into the function, while the program directory comes neither from the caller nor from the environment; it is a constant. A tool with one such constant was only ever tested against one program, and its first test was always green.
The symptom is not an error either. The gate still runs, the report still prints, the numbers still come out. What is wrong is the reference, and a wrong reference in a verification tool costs far more than a crash: a visible failure forces a fix, while a silent pass produces verdicts based on the wrong evidence.
One Line: Environment Wins, Default Stays
The fix is a one-line replacement. The program directory is read from an environment variable first; when it is unset, the default applies exactly as before. This is the same idiom the script has used for the REPO_ROOT variable since the first task, so the script now consistently uses one pattern for every location that can differ per program.
The Twelve-Factor App states the basis: config is everything likely to vary between deploys, and storing it as constants in code is called out directly as a violation of the principle [4]. A program name and its artifact directory are not credentials, but they share the property: their value depends on the context of use, not on the tool's logic. A constant binding a tool to one program is just another form of config inside code.
Verification was concrete: slice 6 in the new program now passes while reading that program's own artifacts. The one-line re-verdict on the sixth task approved with no critical and no major findings. No validation logic changed; what changed is only where one value comes from.
An Honest Tool Contract
The env-override pattern has a contract that is easy to explain: a default for the common case, an explicit override for everything else, no new config files and no extra flags. Bash provides this idiom for free through parameter expansion. The change costs one line; the cost of not making it is a gate whose code must be edited for every new program, with the risk of forgetting.
Checking your own tooling need not be elaborate. Run the same tool twice in two different contexts and compare the file references each run touches. If both point at the same directory while the contexts differ, a constant has not been promoted yet. This two-invocation check finds such cases faster than re-reading the whole script.
The number two sounds trivial as a boundary, but that is where the first fence usually cracks. A tool written for one context always carries one assumption; a second context does not break that assumption loudly, it just quietly shifts results away from the truth. This one-line fix was cheap precisely because it was paid as soon as the first symptom appeared, not after several verdicts had already been issued from the wrong program's evidence.
The known remainder: this pattern only touched the program directory. Other constants of the same kind may still live in older scripts, and their promotion follows real need, not a big-bang sweep. What matters is a consistent direction: every value that proves context diversity leaves the code.