StigAnalysisP5GenerateAnalyzerRunPlanTask

Generates the v4 PhASAR run-plan: one aggregate cfg for every (analysisKind × sinkASIL) combination, flat in the task's output directory.

v4 semantics

The v4 schema (see stig-docs/.../user-guide/analysis-pipeline.md) runs the analyzer twice per ASIL for elements that carry sinks at that ASIL:

• cascading-faults pass — sources at ASIL strictly below sinkASIL. Answers the safety question "did low-integrity data influence a higher-integrity sink?".

• data-and-control-flow pass — sources at sinkASIL or above. Answers the design question "what's the natural flow within this safety level?".

A pass is only emitted if its source set is non-empty: if every source is at QM and every sink is at B, only the cascading-faults cfg materializes (1 cfg). The typical activity has sources at multiple ASILs and sinks at a single ASIL → 2 cfgs.

Filesystem layout

Everything sits flat in outputDir. No more 3-axis nesting (the pre-v4 <analysisType>/<depth>/<mergeMode>/<slug> tree is gone — pass identity is encoded in the filename + carried in the run-plan JSON as typed fields).

<outputDir>/
  data-and-control-flow-B.json        ← cfg (analyzer's --config=)
  data-and-control-flow-B.endpoints.json  ← ASIL sidecar (P7 reads)
  cascading-faults-B.json
  cascading-faults-B.endpoints.json

Run-plan JSON

Each entry has analysisKind/sinkASIL/sourceASILs/sinkSelection as typed fields — downstream consumers (P6 runner, P7 diagram task) read those rather than inferring from filesystem paths. CLI args plumb the same values into --analysis-kind, --sink-asil, --source-asils.