Reviewing a fail-closed parser of a recorded compile command: resolve relative file lists against the tool cwd, and require the tool to be the first token

When code scans a recorded build command (e.g. an EDA tool rebuild script) for options that change semantics, and must return unknown rather than a false empty list, test these beyond the obvious spellings: (1) relative -f/option-file paths: the recorded script runs in the tool original working directory, but the output database often lives in a subdirectory when -o has a path (-o out/bin puts the db in out/). Resolving relative paths against the db folder reads the wrong file if a same-named one exists there, which gives a silent empty result. Derive cwd from the -o directory component or fail closed. (2) Locating the command by the first token whose basename equals the tool name skips options before it when a wrapper script passes args and later the tool path. Require it to be argv[0] after env/VAR= assignments, or scan all tokens. (3) Substring word matching on option names also matches plain file arguments (parameters_pkg.sv): restrict matching to tokens starting with - or +. Separately, in UI trust marking keyed by the instance a step touches, check what the driver summary actually puts in driver.instance: for an input-port hop it was the child itself, so the parent where the connection is evaluated was never checked. Unit tests built from hand-written step objects missed it; probe with the engine real step shape.