Add gh-aw agent factory automation suite

[IEvangelist]

Summary

Adopts GitHub Agentic Workflows (gh aw) and a tuned set of workflows from Peli's Agent Factory, covering the categories I want to lean on first: incoming-issue triage, stale-backlog triage, CI failure diagnosis, doc maintenance, and security compliance.

Workflow	Trigger	Effect
issue-triage	issues: [opened, reopened]	Labels, comments, types, and (for obvious spam) closes the issue. Rubric tightened to this repo's actual label set — area-* (or needs-area-label), at-most-one of bug / enhancement / documentation, plus azure / external / good first issue where clearly applicable. Explicitly forbidden to invent labels.
backlog-triage (new)	schedule: weekly on monday + workflow_dispatch	Picks the oldest open issues that have no area label, no needs-area-label, and no type label, and walks at most 10 per run (dispatch input allows up to 25) through the same rubric. Idempotent via a <!-- backlog-triage --> marker comment so we don't re-triage. Aimed at the ~60 stale issues that pre-date this automation.
ci-doctor	workflow_run on ["Aspire Samples CI"] completed on main	Files a [ci-doctor] issue (labels automation, ci) with root-cause analysis when the protected branch breaks.
doc-updater	schedule: weekly on monday + workflow_dispatch	Scope-narrowed: opens a [docs] PR updating only samples/*/README.md files whose corresponding sample folder had material code changes in the last 7 days. Explicitly forbidden to touch the root README.md, CODE_OF_CONDUCT.md, SECURITY.md, LICENSE, or anything outside samples/.
malicious-code-scan	schedule: daily + workflow_dispatch	Reviews the last 3 days of code changes for supply-chain / exfiltration patterns and files Code Scanning alerts (not issues).

A sixth workflow, agentics-maintenance.yml, is auto-generated by gh aw compile because doc-updater uses expires; it sweeps expired draft items on a schedule.

Also in this PR: labeler workflows now actually run

The existing labeler-cache-retention.yml, labeler-predict-issues.yml, and labeler-predict-pulls.yml workflows were imported from the dotnet/issue-labeler onboarding template, including its github.repository_owner == 'dotnet' guard. Since this repo lives under microsoft/, those guards were silently no-opping every scheduled and issues: opened run — the ML labeler hasn't actually been labeling anything here.

This PR flips the three guards from 'dotnet' to 'microsoft' so the existing labeler infrastructure (already trained and pinned by SHA) actually fires. labeler-train.yml and labeler-promote.yml have no such guard and are intentionally left alone.

Known caveats

A few things worth calling out before this gets enabled in earnest:

• set-issue-type may silently no-op. The triage workflows attempt to set a repo-level issue type (Bug/Feature/Task), which depends on whether the parent organization has issue types configured and exposed to this repo. If it isn't, the call fails silently and the agent falls back to a type label (bug / enhancement / documentation). This is intentional and documented in the prompt body.
• ci-doctor only investigates main failures. PR-CI failures are deliberately out of scope: the doctor's job is to alert maintainers when the protected branch breaks, not to comment on every red PR. If we want a per-PR fix-it agent later, pr-fix from the same catalog is a drop-in candidate.
• malicious-code-scan requires Code Scanning to be enabled. Microsoft repos generally have Advanced Security (and therefore Code Scanning) enabled, but if alerts don't appear in the Security tab after the first run, check that before assuming a workflow bug.

Authentication model

Two credential systems. Both must be configured by a maintainer before these workflows can do anything other than fail-fast.

1. AI engine — COPILOT_GITHUB_TOKEN

All Copilot-engine workflows need a fine-grained PAT with Copilot Requests: Read permission, owned by a user with an active Copilot license. GitHub App tokens are not accepted for the engine (gh-aw auth reference).

2. GitHub tools + safe-outputs — ASPIRE_BOT GitHub App

Every write-back operation (labels, comments, issues, PRs, code-scanning alerts) is wired to mint a short-lived, scope-minimized token via actions/create-github-app-token using the new ASPIRE_BOT GitHub App. Two new repo secrets:

• ASPIRE_BOT_APP_ID — App ID (or Client ID) of the ASPIRE_BOT App.
• ASPIRE_BOT_PRIVATE_KEY — PEM-encoded private key for the App.

The ASPIRE_BOT App needs to be installed on this repo with at minimum:

• Contents: Read & write (for doc-updater's PR branch pushes)
• Issues: Read & write (issue-triage, backlog-triage, ci-doctor)
• Pull requests: Read & write (doc-updater)
• Metadata: Read
• Code scanning alerts: Read & write (malicious-code-scan)
• Actions: Read (ci-doctor reading workflow run logs)

Security review

gh aw flagged the following deltas at compile time. I've reviewed each:

New restricted secrets — both intentional, both consumed only by actions/create-github-app-token to mint scoped App tokens:

• ASPIRE_BOT_APP_ID
• ASPIRE_BOT_PRIVATE_KEY

New pinned action (in malicious-code-scan.lock.yml) — required for filing code-scanning alerts:

• github/codeql-action/upload-sarif@e46ed2cbd01164d986452f91f178727624ae40d7 (v4.35.3)

All actions in the generated .lock.yml files are pinned by SHA, and the pin manifest is recorded in .github/aw/actions-lock.json.

How to develop these workflows

The CLI: gh extension install github/gh-aw. Then from the repo root:

gh aw validate                 # schema-check all workflows
gh aw compile                  # regenerate *.lock.yml (commit both .md and .lock.yml)
gh aw status                   # list registered workflows
gh aw run <workflow-name>      # trigger on GitHub Actions
gh aw audit <run-id-or-url>    # download logs and generate a report
gh aw disable|enable <name>    # toggle individual workflows

*.lock.yml files are marked linguist-generated=true merge=ours in .gitattributes. Never hand-edit them; re-run gh aw compile after changing the source .md. The prompt bodies of the .md files are imported at run time via {{#runtime-import ...}}, so prose-only edits don't churn the lock file.

For the index/readme that ships in this PR, see .github/workflows/agentic.md — it mirrors the style of the existing labeler.md.

Why these workflows?

These map to the most-trafficked patterns from the agent factory tour: triage (both new and stale), fault investigation, doc hygiene, security compliance. Other useful agents (daily-repo-status, pr-fix, ChatOps-style assistants, etc.) can be added later via gh aw add githubnext/agentics/<workflow-name> and are intentionally deferred until this baseline is proven.

Marking as draft

I'm leaving this PR as a draft until the three secrets above are configured on the repo — otherwise the workflows will all fail their first scheduled tick. Once secrets are in place, ready for review.