Clarify fresh-pass workspace semantics in `theme_d3_w9_testing_quality_reproducibility_verification`

[leric]

The task specification and verifier appear to leave an important ambiguity about which files are available in each fresh verification-pass workspace.

Context

In spec_v1.md §6.1, each verification pass is defined as:

1. Create a fresh temporary directory as the pipeline root.
2. Copy all input files from the original pipeline root.
3. Execute all steps within the temporary directory.

The manifest schema separately defines inputs as the step’s input file paths.

However, the round-1 verifier includes pipelines whose commands reference helper scripts that are not declared as inputs:

{
  "command": "sh transform.sh",
  "inputs": ["input.txt"],
  "outputs": ["output.txt"]
}

The test creates transform.sh in the original pipeline root, but it is not listed in inputs. Another test invokes sh gen.sh while declaring no inputs at all.

Why this is ambiguous

An implementation that follows the specification literally can:

• create a fresh pass root;
• copy only the manifest-declared input files;
• execute the command in that fresh root.

Under that interpretation, transform.sh / gen.sh are absent, so the step correctly becomes ERROR with exit code 2. This then cascades into failures for deterministic verification, non-determinism detection, reference matching, policy evaluation, and later cumulative rounds.

Conversely, the verifier expects these helper scripts to be available. That requires an additional, currently unstated rule such as “copy the full original pipeline root” or “copy all command dependencies.”

This is not a request to change the intended functionality; it is a request to make the contract explicit so valid implementations are not penalized for choosing the literal inputs-only interpretation.

Minimal reproduction

With a fresh temporary root that copies only declared inputs:

manifest inputs: ["input.txt"]
command: "sh transform.sh"

the fresh root contains input.txt but not transform.sh, so sh transform.sh fails. The round-1 verifier expects this pipeline to pass.

Observed impact

In my independent runs, both agents failed the same normal-pipeline cases from round 1 with ERROR / exit 2. Their explicit error-message tests largely passed, so the issue is not error wording; it is the missing helper-script availability contract.

The official per-task results also show this task is unusually brittle under binary round scoring: several high-performing agents receive 0/7 rounds while retaining substantial case-level pass rates.