Update test expectations for roles-to-on-roles codemod

.github/workflows/ai-moderator.md

@@ -1,7 +1,7 @@
 ---
 timeout-minutes: 5
-roles: all
 on:
+  roles: all
   issues:
     types: [opened]
     lock-for-agent: true
@@ -38,6 +38,7 @@ safe-outputs:
     allowed-reasons: [spam]
   threat-detection: false
 ---
+
 # AI Moderator
 
 You are an AI-powered moderation system that automatically detects spam, link spam, and AI-generated content in GitHub issues and comments.
@@ -131,4 +132,4 @@ Based on your analysis:
 - Technical discussions may naturally contain links to resources, documentation, or related issues
 - New contributors may have less polished writing - this doesn't necessarily indicate AI generation
 - Provide clear reasoning for each detection in your analysis
-- Only take action if you have high confidence in the detection
+- Only take action if you have high confidence in the detection

.github/workflows/poem-bot.md

@@ -2,6 +2,9 @@
 description: Generates creative poems on specified themes when invoked with /poem-bot command
 # Custom triggers: command with events filter, workflow_dispatch
 on:
+  roles:
+    - admin
+    - maintainer
   # Command trigger - responds to /poem-bot mentions
   slash_command:
     name: poem-bot
@@ -15,11 +18,6 @@ on:
         required: false
         default: 'technology and automation'
 
-# Restrict to admin/maintainer roles only
-roles:
-  - admin
-  - maintainer
-
 # Minimal permissions - safe-outputs handles write operations
 permissions:
   contents: read

.github/workflows/q.md

@@ -2,6 +2,7 @@
 name: Q
 description: Intelligent assistant that answers questions, analyzes repositories, and can create PRs for workflow optimizations
 on:
+  roles: [admin, maintainer, write]
   slash_command:
     name: q
   reaction: rocket
@@ -11,7 +12,6 @@ permissions:
   issues: read
   pull-requests: read
   discussions: read
-roles: [admin, maintainer, write]
 engine: copilot
 tools:
   agentic-workflows:

.github/workflows/release.md

@@ -2,6 +2,9 @@
 name: Release
 description: Build, test, and release gh-aw extension, then generate and prepend release highlights
 on:
+  roles:
+    - admin
+    - maintainer
   workflow_dispatch:
     inputs:
       release_type:
@@ -17,9 +20,6 @@ permissions:
   pull-requests: read
   actions: read
   issues: read
-roles:
-  - admin
-  - maintainer
 engine: copilot
 strict: false
 timeout-minutes: 20
@@ -509,4 +509,4 @@ safeoutputs/update_release(
 - Reference: `https://github.github.com/gh-aw/reference/`
 - Setup: `https://github.github.com/gh-aw/setup/`
 
-Verify paths exist in `docs_files.txt` before linking.
+Verify paths exist in `docs_files.txt` before linking.

.github/workflows/scout.md

@@ -2,6 +2,7 @@
 name: Scout
 description: Performs deep research investigations using web search to gather and synthesize comprehensive information on any topic
 on:
+  roles: [admin, maintainer, write]
   slash_command:
     name: scout
   workflow_dispatch:
@@ -13,7 +14,6 @@ permissions:
   contents: read
   issues: read
   pull-requests: read
-roles: [admin, maintainer, write]
 engine: claude
 imports:
   - shared/mood.md
@@ -187,4 +187,4 @@ Focus on the most relevant and actionable information. Avoid overwhelming detail
 - **Clarity**: Write for the intended audience (developers working on this repo)
 - **Attribution**: Always cite your sources with proper links
 
-Remember: Your goal is to provide valuable, actionable intelligence that helps resolve the issue or improve the pull request. Make every search count and synthesize information effectively.
+Remember: Your goal is to provide valuable, actionable intelligence that helps resolve the issue or improve the pull request. Make every search count and synthesize information effectively.

docs/src/content/docs/patterns/dispatchops.md

@@ -95,12 +95,12 @@ Deploy to the ${{ github.event.inputs.target_env }} environment.
 Manual workflow execution respects the same security model as other triggers:
 
 - **Repository permissions** - User must have write access or higher to trigger workflows
-- **Role-based access** - Use the `roles:` field to restrict who can run workflows:
+- **Role-based access** - Use the `on.roles` field to restrict who can run workflows:
 
 ```yaml
 on:
   workflow_dispatch:
-roles: [admin, maintainer]
+  roles: [admin, maintainer]
 ```
 
 - **Bot authorization** - Use the `bots:` field to allow specific bot accounts:

docs/src/content/docs/reference/frontmatter-full.md

@@ -3732,22 +3732,6 @@ secret-masking:
   # (optional)
   steps: []
 
-# Repository access roles required to trigger agentic workflows. Defaults to
-# ['admin', 'maintainer', 'write'] for security. Use 'all' to allow any
-# authenticated user (⚠️ security consideration).
-# (optional)
-# This field supports multiple formats (oneOf):
-
-# Option 1: Allow any authenticated user to trigger the workflow (⚠️ disables
-# permission checking entirely - use with caution)
-roles: "all"
-
-# Option 2: List of repository permission levels that can trigger the workflow.
-# Permission checks are automatically applied to potentially unsafe triggers.
-roles: []
-  # Array items: Repository permission level: 'admin' (full access),
-  # 'maintainer'/'maintain' (repository management), 'write' (push access), 'triage'
-  # (issue management)
 
 # Allow list of bot identifiers that can trigger the workflow even if they don't
 # meet the required role permissions. When the actor is in this list, the bot must

docs/src/content/docs/reference/frontmatter.md

@@ -22,7 +22,7 @@ tools:
 
 ## Frontmatter Elements
 
-The frontmatter combines standard GitHub Actions properties (`on`, `permissions`, `run-name`, `runs-on`, `timeout-minutes`, `concurrency`, `env`, `environment`, `container`, `services`, `if`, `steps`, `cache`) with GitHub Agentic Workflows-specific elements (`description`, `source`, `imports`, `engine`, `strict`, `roles`, `features`, `plugins`, `runtimes`, `safe-inputs`, `safe-outputs`, `network`, `tools`).
+The frontmatter combines standard GitHub Actions properties (`on`, `permissions`, `run-name`, `runs-on`, `timeout-minutes`, `concurrency`, `env`, `environment`, `container`, `services`, `if`, `steps`, `cache`) with GitHub Agentic Workflows-specific elements (`description`, `source`, `imports`, `engine`, `strict`, `features`, `plugins`, `runtimes`, `safe-inputs`, `safe-outputs`, `network`, `tools`).
 
 Tool configurations (such as `bash`, `edit`, `github`, `web-fetch`, `web-search`, `playwright`, `cache-memory`, and custom [Model Context Protocol](/gh-aw/reference/glossary/#mcp-model-context-protocol) (MCP) [servers](/gh-aw/reference/glossary/#mcp-server)) are specified under the `tools:` key. Custom inline tools can be defined with the [`safe-inputs:`](/gh-aw/reference/safe-inputs/) (custom tools defined inline) key. See [Tools](/gh-aw/reference/tools/) and [Safe Inputs](/gh-aw/reference/safe-inputs/) for complete documentation.
 
@@ -35,6 +35,7 @@ The `on:` section uses standard GitHub Actions syntax to define workflow trigger
 - `stop-after:` - Automatically disable triggers after a deadline
 - `manual-approval:` - Require manual approval using environment protection rules
 - `forks:` - Configure fork filtering for pull_request triggers
+- `roles:` - Control who can trigger the workflow based on repository permission level
 - `skip-roles:` - Skip workflow execution for specific repository roles
 - `skip-bots:` - Skip workflow execution for specific GitHub actors
 
@@ -211,17 +212,30 @@ The compiler validates workflows have sufficient permissions for their configure
 
 **Strict mode** (`gh aw compile --strict`): Treats under-provisioned permissions as compilation errors. Use for production workflows requiring enhanced security validation.
 
-### Repository Access Roles (`roles:`)
+### Repository Access Roles (`on.roles`)
 
 Controls who can trigger agentic workflows based on repository permission level. Defaults to `[admin, maintainer, write]`.
 
 ```yaml wrap
-roles: [admin, maintainer, write]  # Default
-roles: all                         # Allow any user (⚠️ use with caution)
+on:
+  issues:
+    types: [opened]
+  roles: [admin, maintainer, write]  # Default
+```
+
+```yaml wrap
+on:
+  issues:
+    types: [opened]
+  roles: all  # Allow any user (⚠️ use with caution)
 ```
 
 Available roles: `admin`, `maintainer`, `write`, `read`, `all`. Workflows with unsafe triggers (`push`, `issues`, `pull_request`) automatically enforce permission checks. Failed checks cancel the workflow with a warning.
 
+:::note[Migration from top-level roles]
+The `roles` field was previously a top-level frontmatter field. It has been moved to `on.roles` and top-level `roles` is no longer supported. Use `gh aw fix` to automatically migrate existing workflows.
+:::
+
 ### Bot Filtering (`bots:`)
 
 Configure which GitHub bot accounts can trigger workflows. Useful for allowing specific automation bots while maintaining security controls.
@@ -236,9 +250,9 @@ bots:
 **Behavior**:
 - When specified, only the listed bot accounts can trigger the workflow
 - The bot must be active (installed) on the repository to trigger the workflow
-- Combine with `roles:` for comprehensive access control
+- Combine with `on.roles` for comprehensive access control
 - Applies to all workflow triggers (`pull_request`, `issues`, etc.)
-- When `roles: all` is set, bot filtering is not enforced
+- When `on.roles: all` is set, bot filtering is not enforced
 
 **Common bot names**:
 - `dependabot[bot]` - GitHub Dependabot for dependency updates