[agent-issue]: Parity gap with gh-aw — `safe-outputs.threat-detection.prompt` is not supported

[JamesBurnside]

Submission requirements

• Agent-generated issue — drafted by Copilot CLI from direct inspection of this repository and the upstream githubnext/gh-aw sources (file/line references and the gh-aw config surface below were verified, not recalled).
• I reviewed the generated issue and confirm it is being filed directly in githubnext/ado-aw.

Provenance note (please read before triage). This was not generated via .github/agents/ado-aw.agent.md, so the first checkbox is annotated rather than claimed verbatim. That dispatcher routes to the create / update / debug prompts for authoring agentic workflows; it has no path for reporting a gap in the compiler itself. This report is a maintainer-side feature-parity finding about ado-aw's own source, so no workflow-authoring session produced it. Flagging explicitly rather than silently checking the box — if the intake gate is meant to cover compiler issues too, that is worth a template follow-up.

Problem summary

ado-aw does not support safe-outputs.threat-detection.prompt; upstream gh-aw does. Workflow authors cannot add domain-specific guidance to the Detection stage, so threat analysis cannot be tuned to a team's threat model.

In gh-aw, safe-outputs.threat-detection is a config block whose prompt field is documented as "custom instructions appended to default detection prompt" (docs/src/content/docs/reference/threat-detection.md). Sibling extensibility fields in the same block include engine, runs-on, steps, post-steps, and max-ai-credits.

In ado-aw the Detection prompt is fixed at compile time and has no front-matter surface at all:

• src/compile/agentic_pipeline.rs embeds src/data/threat-analysis.md via include_str! and substitutes exactly four markers ({{ source_path }}, {{ agent_name }}, {{ agent_description }}, {{ working_directory }}).
• safe-outputs: accepts only tool names plus the reserved require-approval key (SAFE_OUTPUT_RESERVED_KEYS in src/compile/types.rs), so validate_safe_outputs_keys rejects threat-detection as an unknown key.

Impact. A workflow whose agent legitimately touches sensitive surfaces (dependency manifests, auth code, deployment config) gets the same one-size-fits-all analysis as a docs-only workflow. Authors have two options, both bad: accept the false-positive/false-negative rate, or fork src/data/threat-analysis.md — which is compiler-internal and cannot be overridden per workflow.

This issue is scoped to the parity gap only, not a defect: Detection still fail-closes correctly today.

Reproduction details

Environment: githubnext/ado-aw @ main. Affects all four targets (standalone, 1es, job, stage) — Detection is built by the shared build_detection_job in src/compile/agentic_pipeline.rs, so the gap is target-independent.

Steps:

1. Author a workflow using the gh-aw configuration shape:

   safe-outputs:
     create-pull-request:
     threat-detection:
       prompt: |
         Also flag:
         - unsafe deserialization in the ingest path
         - hardcoded connection strings in *.config

2. Run ado-aw compile.

Observed: Compilation fails. validate_safe_outputs_keys (src/compile/common.rs) treats threat-detection as a safe-output tool name, does not find it in ALL_KNOWN_SAFE_OUTPUTS, and reports it as unknown.

Expected: The key is recognized as section-level configuration, and the supplied text reaches the Detection stage's prompt.

Additional observation (adjacent, surfaced while scoping): build_conclusion_job gates on front_matter.safe_outputs.is_empty() rather than has_any_safe_output_tool(). Any non-tool key under safe-outputs: would therefore emit a Conclusion job for a workflow that declares no safe-output tools. This is already reachable today with a require-approval-only section. Worth folding into triage of this issue or splitting out.

Proposed next step

Triage as a parity feature request against the compiler / front-matter area.

Decisions to make before any work is scoped:

1. Scope of the port. Ship prompt alone, or more of gh-aw's threat-detection block? deny_unknown_fields means a partial port hard-fails on the sibling fields — acceptable, but should be a deliberate choice rather than an omission.
2. Append vs. replace. Upstream appends the custom text verbatim after the rendered template. Replacement would risk dropping the THREAT_DETECTION_RESULT: output contract that evaluate_threat_analysis_step parses.
3. Security review. Operator-supplied text that lands inside the detector's own prompt can weaken the gate. This is the same trust level as the existing description: field, but it should be reviewed and documented rather than assumed equivalent.

Suggested owner: compiler / front-matter area.

Upstream reference: docs/src/content/docs/reference/threat-detection.md in githubnext/gh-aw.