Add direct-push alerting and sensitive-change gate

[jeremy]

Summary

• direct-push-alert: Detects commits pushed directly to the default branch (bypassing PR flow) and creates/appends to a tracking issue.
• sensitive-change-gate: Detects PR changes to control-plane paths (workflows, CODEOWNERS, .goreleaser.yaml, release scripts). Runs in shadow mode — posts an informational comment but does not block.

Both are thin callers to reusable workflows in basecamp/.github, pinned to SHA a667bfaa.

Test plan

• Open a PR touching .github/workflows/ — verify shadow comment appears

---

Summary by cubic

Add two GitHub Actions: one alerts on direct pushes to main, and another flags sensitive control‑plane changes in PRs (shadow mode). Improves visibility and nudges contributors to the PR flow without blocking merges.

• New Features
  • direct-push-alert: On push to main, posts to/updates a tracking issue using a reusable workflow in basecamp/.github (pinned to a commit).
  • sensitive-change-gate: On PRs, comments when changes touch workflows, CODEOWNERS, .goreleaser.yaml, or release scripts; runs in shadow mode. Extra paths monitored: scripts/publish-aur.sh, scripts/sync-skills.sh, scripts/manage-release-env.sh.

^{Written for commit bbb5c7c. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 2 files

[Copilot]

Pull request overview

This PR introduces two new GitHub Actions workflow files that act as thin callers to reusable workflows hosted in basecamp/.github, both pinned to a specific commit SHA (a667bfaa…). The direct-push-alert workflow fires on every push to main and creates/appends to a tracking issue when commits bypass the PR flow. The sensitive-change-gate runs on pull_request_target events and posts an informational (shadow-mode) comment when PRs touch control-plane paths.

Changes:

• Added .github/workflows/direct-push-alert.yml — triggers on pushes to main; calls the shared direct-push-alert reusable workflow with issues: write permission.
• Added .github/workflows/sensitive-change-gate.yml — triggers on pull_request_target; calls the shared sensitive-change-gate reusable workflow with extra path patterns for repo-specific scripts.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
.github/workflows/direct-push-alert.yml	New workflow that fires on direct pushes to main and delegates to a pinned reusable workflow to file/update a tracking issue.
.github/workflows/sensitive-change-gate.yml	New workflow that fires on PR events via pull_request_target and calls a pinned reusable workflow to shadow-comment on sensitive path changes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

pull_request_target runs with write permissions in the context of the base branch, which means the called reusable workflow has elevated access even for PRs from forks. Combined with pull-requests: write, if the reusable workflow at basecamp/.github ever checks out or executes code from the PR head branch (e.g. via actions/checkout with ref: ${{ github.event.pull_request.head.sha }}), this creates a significant security risk (arbitrary code execution with write access to the repository).

Before using pull_request_target, verify that the pinned reusable workflow does not check out PR code or execute user-controlled scripts. If it only reads PR metadata via the GitHub API, the risk is lower, but it is still worth confirming explicitly. Adding a comment here explaining why pull_request_target is safe in this context would help future maintainers.

[Copilot]

The permissions key inside a job that uses a reusable workflow (uses:) is not valid GitHub Actions syntax and is silently ignored at runtime. GitHub Actions only honours permissions at the workflow level or within a regular steps-based job. The job-level permissions block here has no effect; the actual permissions that apply to this workflow run come from the top-level permissions block (lines 7–9).

If the intent is to document which permissions are required, a comment would be clearer. If the intent is to actually restrict permissions on the called workflow, those restrictions must be declared in the reusable workflow itself.

Note that the same pattern is already present in .github/workflows/ai-labeler.yml — so this appears to be an established (if ineffective) convention in the repository.

Suggested change

	permissions:
	contents: read
	pull-requests: write
	# Requires permissions:
	# contents: read
	# pull-requests: write

[Copilot]

The permissions key inside a job that uses a reusable workflow (uses:) is not valid GitHub Actions syntax and is silently ignored at runtime. The actual permissions enforced come from the top-level permissions block (lines 7–9). The job-level block here has no effect.

Note that the same pattern is already present in .github/workflows/ai-labeler.yml — so this appears to be an established (if ineffective) convention in the repository.

Suggested change

	permissions:
	contents: read
	issues: write