A Go test that prints (cached) reused an earlier result under the inputs the Go command tracked. That saves time. When a test starts another program, discovers files at runtime, or consults a service, check whether a change in that dependency makes the test run again.
A CI/lock trace can help investigate what the selected backend observed during execution. Source inspection identifies candidate dependencies; an input-change experiment tests the cache rule.
Capture one bounded test
Choose one suspicious test and run it in a private scratch environment with a timeout. Use the tracing options supported by the installed CI/lock version; consult the capture guide and the binary’s help before copying a command from an older post.
For the baseline Go execution, -count=1 explicitly disables reuse of the test result. Keep this measured fresh run distinct from the later experiment that permits caching. See the Go command documentation.
Trace artifacts may contain command arguments, paths, and output. Keep diagnostic traces within the team’s approved storage and access boundaries.
Read the observation before drawing a conclusion
Start with the backend and diagnostics recorded in the envelope. Check subprocess, network, and file observations only within that backend’s supported coverage. An empty observation list may indicate limited visibility rather than an absence of activity.
Repeated compiler or subprocess launches can help explain setup cost. A network observation is a lead to investigate with the source; it may be a local test fixture. A missing record cannot establish that the test was isolated.
Decoding the DSSE payload lets you read it. It does not verify the signature or establish that its producer is trusted.
Challenge the cache key
Remove the option that forces a fresh run and run the same package command twice. Confirm that the second result actually reports (cached).
Change one input the test is supposed to depend on. Run the command again and require the intended test to execute and detect the change. Restore the input, verify that the test passes, and check that an unchanged repeat is cached.
The original engineering note described a schema-inventory test where adding a schema file did not invalidate a cached result. Making the schema package an explicit test dependency corrected that case. Source review and the new-file experiment established the defect; the trace did not discover it.
If an external service or subprocess input remains outside the cache key, use a deterministic fixture or keep the affected test fresh. Preserve the regression assertion while changing its setup. Compare ordinary runs with ordinary runs and traced runs with traced runs: tracing introduces its own cost.
Keep the evidence roles separate
A locally signed diagnostic trace is not automatically the commit-bound test evidence required by a Pushgate policy. The gate checks the evidence and policy for the relevant push. A useful trace does not make an unsafe cache hit a valid result.
Keep the trace, source finding, and invalidation experiment together. Read the evidence trust boundary before using a diagnostic result in an acceptance decision.