Partially addresses #222 by adding SubprocessError.executionContext, representing a snapshot of the executable, arguments, environment, and working directory configured at the time the error was thrown, along with values resolved at spawn time.

Design

A new public ExecutionContext struct contains properties representing the supplied inputs and their resolved values. Resolution happens at spawn time rather than when the error is inspected, so the resolved values reflect what the child actually received; the state from which they derive can change over the parent's lifetime. A few resolved values are purposefully absent or adjusted:

• resolvedExecutable is nil on Windows when the executable is given by name: CreateProcessW() performs the search internally and does not report the path it used, and Subprocess does not issue a separate post-spawn lookup to recover it. Path-based executables report a path on all platforms.
• resolvedEnvironment is nil for environments given as raw bytes (no faithful String representation), and on Windows may include a PATH entry that Subprocess adds so the child can locate its DLLs.
• resolvedWorkingDirectory is the configured directory when one is set, and otherwise the parent's working directory captured at spawn.

The context is attached in Configuration.run(). A failure during spawn is caught there with the configured inputs only, since no resolved values exist yet; any error surfacing after a successful spawn propagates back through the same function and is caught with the resolved context. Every error that leaves a run() call passes through one of these two points, so StandardInputWriter, SubprocessOutputSequence, and the collected output types need no awareness of ExecutionContext. Only SubprocessError is wrapped, so an error thrown from the caller's own body closure propagates unchanged. executionContext is nil only for errors observed outside a run() call, such as Execution-level process monitoring.

Testing

Nine existing tests in IntegrationTests that asserted on SubprocessError equality have been updated to directly assert on the relevant properties, since the addition of executionContext caused the type-level comparison to fail.

ProcessMonitoringTests.testInvalidProcessIdentifier() has been extended to verify that Execution-level errors carry no executionContext.

Future directions

#222 also requests including the exit code/signal and captured standard input/output on the error. Both involve scoping and design questions distinct from the snapshot (for example, whether the captured streams should be included verbatim or truncated). I'll address these in follow-up PRs.