Add Sighthound-gated agentic workflow with artifacted scan output

[Copilot]

This adds an agentic workflow that runs Corgea/Sighthound in a dedicated pre-agent job, persists scan output as an artifact, and only activates the agent when findings exist. The workflow keeps detection deterministic and triage conditional.

• Workflow added

  • New workflow: .github/workflows/sighthound-security-scan.md (and compiled .lock.yml).
  • Triggered on pull_request (opened, synchronize, reopened) and workflow_dispatch.

• Separate Sighthound scan job

  • Introduces jobs.sighthound_scan to install and run sighthound before agent execution.
  • Produces structured outputs:
    • findings_detected
    • findings_count
    • artifact_name

• Artifacted results for downstream analysis

  • Writes scan payload and summary under /tmp/gh-aw/agent/sighthound/.
  • Uploads run-scoped artifact (sighthound-results-${{ github.run_id }}) for reproducible triage context.

• Agent execution is findings-gated

  • Top-level workflow if: gates the agent path on:
    • needs.sighthound_scan.outputs.findings_detected == 'true'
  • Agent downloads the scan artifact and performs conditional action:
    • PR context → add_comment
    • non-PR context → create_issue
    • no actionable findings → noop

if: needs.sighthound_scan.outputs.findings_detected == 'true'

jobs:
  sighthound_scan:
    outputs:
      findings_detected: ${{ steps.scan.outputs.findings_detected }}
      findings_count: ${{ steps.scan.outputs.findings_count }}
      artifact_name: ${{ steps.artifact_name.outputs.value }}

[github-actions]

Hey @copilot-swe-agent 👋 — great work adding the Sighthound-gated security scan workflow! The findings-conditional agent execution pattern is a clean approach, and the artifact-backed scan output makes triage reproducible.

One thing that would help push this over the finish line:

• Add workflow tests — the .md workflow spec does not have an accompanying test or validation fixture. Even a basic schema-validation or dry-run test for the compiled .lock.yml would provide confidence that the workflow gates behave correctly under the different trigger paths (pull_request vs workflow_dispatch, findings vs no-findings).

If you would like a hand, you can assign this prompt to your coding agent:

Add tests for the Sighthound-gated agentic workflow introduced in .github/workflows/sighthound-security-scan.md.
Cover the following scenarios:
1. findings_detected == true on a pull_request event → agent job should run and call add_comment.
2. findings_detected == false → agent job should be skipped (if condition is false).
3. non-PR context with findings → agent job should call create_issue.
4. Validate that the compiled .lock.yml matches the spec in the .md file.
Follow the existing test patterns in the repository for workflow specs.

Generated by ✅ Contribution Check · 89.5 AIC · ⌖ 11.5 AIC · ⊞ 6.2K · ◷