Static-Trace Verification When Execution Is Unsafe

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Review a setup wizard that opens a production browser, reads credentials and submits changes. Running it to see what happens without execution authorization creates external effects; static tracing can still answer bounded questions.

Mechanism

Identify inputs, branches, commands, targets and effects in actual code/configuration. Trace value destinations and secret names against CI references, marking dynamic evaluation unknown. Use safe non-executing syntax/static checks if available; authorized isolated sandboxes can verify limited paths separately. Report checked static properties and unverified authentication, network, UI and submission behavior.

Bad example

Run the production wizard to see results, or read code and claim authentication and submission succeeded.

Good example

Do not run the production submission path. Trace region input, destination and set_secret names against CI references, checking branches and arguments. Record safe syntax results separately and list traced locations and unexecuted properties; syntax success is not production success.

Why the change matters

Tracing checks value/contract connections without external mutation. Scoped claims preserve review value while avoiding invented runtime evidence.

Observable expectation

Teaching region=test flowing into a production target is a conflict. Writing SECRET_A while CI reads SECRET_B is another. Unresolved dynamically obtained targets remain gaps. A report without execution evidence must not say submission succeeded.

Limits

Static analysis can miss reflection, dynamic configuration and runtime permissions. Sandboxes have isolation/simulation limits; execution follows actual authorization. Frozen wizard commands grant no permission here, and real-environment verification remains separate.