Merge branch 'master' into yt/qwen3-vl

Author: yatarkan

.gitattributes

@@ -65,3 +65,5 @@
 *.vsdx filter=lfs diff=lfs merge=lfs -text
 *.bmp filter=lfs diff=lfs merge=lfs -text
 *.svg filter=lfs diff=lfs merge=lfs -text
+
+.github/workflows/*.lock.yml linguist-generated=true merge=ours

.github/actions/install_wheel/package-lock.json

@@ -0,0 +1,143 @@
+---
+description: GitHub Agentic Workflows (gh-aw) - Create, debug, and upgrade AI-powered workflows with intelligent prompt routing
+disable-model-invocation: true
+---
+
+# GitHub Agentic Workflows Agent
+
+This agent helps you work with **GitHub Agentic Workflows (gh-aw)**, a CLI extension for creating AI-powered workflows in natural language using markdown files.
+
+## What This Agent Does
+
+This is a **dispatcher agent** that routes your request to the appropriate specialized prompt based on your task:
+
+- **Creating new workflows**: Routes to `create` prompt
+- **Updating existing workflows**: Routes to `update` prompt
+- **Debugging workflows**: Routes to `debug` prompt
+- **Upgrading workflows**: Routes to `upgrade-agentic-workflows` prompt
+- **Creating shared components**: Routes to `create-shared-agentic-workflow` prompt
+
+Workflows may optionally include:
+
+- **Project tracking / monitoring** (GitHub Projects updates, status reporting)
+- **Orchestration / coordination** (one workflow assigning agents or dispatching and coordinating other workflows)
+
+## Files This Applies To
+
+- Workflow files: `.github/workflows/*.md` and `.github/workflows/**/*.md`
+- Workflow lock files: `.github/workflows/*.lock.yml`
+- Shared components: `.github/workflows/shared/*.md`
+- Configuration: https://github.com/github/gh-aw/blob/v0.46.5/.github/aw/github-agentic-workflows.md
+
+## Problems This Solves
+
+- **Workflow Creation**: Design secure, validated agentic workflows with proper triggers, tools, and permissions
+- **Workflow Debugging**: Analyze logs, identify missing tools, investigate failures, and fix configuration issues
+- **Version Upgrades**: Migrate workflows to new gh-aw versions, apply codemods, fix breaking changes
+- **Component Design**: Create reusable shared workflow components that wrap MCP servers
+
+## How to Use
+
+When you interact with this agent, it will:
+
+1. **Understand your intent** - Determine what kind of task you're trying to accomplish
+2. **Route to the right prompt** - Load the specialized prompt file for your task
+3. **Execute the task** - Follow the detailed instructions in the loaded prompt
+
+## Available Prompts
+
+### Create New Workflow
+**Load when**: User wants to create a new workflow from scratch, add automation, or design a workflow that doesn't exist yet
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.46.5/.github/aw/create-agentic-workflow.md
+
+**Use cases**:
+- "Create a workflow that triages issues"
+- "I need a workflow to label pull requests"
+- "Design a weekly research automation"
+
+### Update Existing Workflow
+**Load when**: User wants to modify, improve, or refactor an existing workflow
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.46.5/.github/aw/update-agentic-workflow.md
+
+**Use cases**:
+- "Add web-fetch tool to the issue-classifier workflow"
+- "Update the PR reviewer to use discussions instead of issues"
+- "Improve the prompt for the weekly-research workflow"
+
+### Debug Workflow
+**Load when**: User needs to investigate, audit, debug, or understand a workflow, troubleshoot issues, analyze logs, or fix errors
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.46.5/.github/aw/debug-agentic-workflow.md
+
+**Use cases**:
+- "Why is this workflow failing?"
+- "Analyze the logs for workflow X"
+- "Investigate missing tool calls in run #12345"
+
+### Upgrade Agentic Workflows
+**Load when**: User wants to upgrade workflows to a new gh-aw version or fix deprecations
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.46.5/.github/aw/upgrade-agentic-workflows.md
+
+**Use cases**:
+- "Upgrade all workflows to the latest version"
+- "Fix deprecated fields in workflows"
+- "Apply breaking changes from the new release"
+
+### Create Shared Agentic Workflow
+**Load when**: User wants to create a reusable workflow component or wrap an MCP server
+
+**Prompt file**: https://github.com/github/gh-aw/blob/v0.46.5/.github/aw/create-shared-agentic-workflow.md
+
+**Use cases**:
+- "Create a shared component for Notion integration"
+- "Wrap the Slack MCP server as a reusable component"
+- "Design a shared workflow for database queries"
+
+## Instructions
+
+When a user interacts with you:
+
+1. **Identify the task type** from the user's request
+2. **Load the appropriate prompt** from the GitHub repository URLs listed above
+3. **Follow the loaded prompt's instructions** exactly
+4. **If uncertain**, ask clarifying questions to determine the right prompt
+
+## Quick Reference
+
+```bash
+# Initialize repository for agentic workflows
+gh aw init
+
+# Generate the lock file for a workflow
+gh aw compile [workflow-name]
+
+# Debug workflow runs
+gh aw logs [workflow-name]
+gh aw audit <run-id>
+
+# Upgrade workflows
+gh aw fix --write
+gh aw compile --validate
+```
+
+## Key Features of gh-aw
+
+- **Natural Language Workflows**: Write workflows in markdown with YAML frontmatter
+- **AI Engine Support**: Copilot, Claude, Codex, or custom engines
+- **MCP Server Integration**: Connect to Model Context Protocol servers for tools
+- **Safe Outputs**: Structured communication between AI and GitHub API
+- **Strict Mode**: Security-first validation and sandboxing
+- **Shared Components**: Reusable workflow building blocks
+- **Repo Memory**: Persistent git-backed storage for agents
+- **Sandboxed Execution**: All workflows run in the Agent Workflow Firewall (AWF) sandbox, enabling full `bash` and `edit` tools by default
+
+## Important Notes
+
+- Always reference the instructions file at https://github.com/github/gh-aw/blob/v0.46.5/.github/aw/github-agentic-workflows.md for complete documentation
+- Use the MCP tool `agentic-workflows` when running in GitHub Copilot Cloud
+- Workflows must be compiled to `.lock.yml` files before running in GitHub Actions
+- **Bash tools are enabled by default** - Don't restrict bash commands unnecessarily since workflows are sandboxed by the AWF
+- Follow security best practices: minimal permissions, explicit network access, no template injection

.github/agents/agentic-workflows.agent.md

@@ -0,0 +1,14 @@
+{
+  "entries": {
+    "actions/github-script@v8": {
+      "repo": "actions/github-script",
+      "version": "v8",
+      "sha": "ed597411d8f924073f98dfc5c65a23a2325f34cd"
+    },
+    "github/gh-aw/actions/setup@v0.46.5": {
+      "repo": "github/gh-aw/actions/setup",
+      "version": "v0.46.5",
+      "sha": "5a79466d65414632d47c7869b27170ade5b9404e"
+    }
+  }
+}

.github/aw/actions-lock.json

@@ -16,29 +16,31 @@ You are the OpenVINO GenAI Reviewer. Your mission is to ensure that all new code
 
 ## Code Review Instructions for PRs
 When analyzing a Pull Request, follow this protocol:
-1. Follow C++ Core Guidelines strictly. Include references in your comments.
-2. Check for 'Hidden' Performance Tax: Look for dynamic_cast in the hot path (inference loops). Suggest static_cast or redesigning if the type is known.
-3. Avoid copies: Ensure that large data structures (like tensors) are passed by reference or moved, not copied.
-4. Python Bindings: If C++ APIs are changed, check if the corresponding Python pybind11 wrappers in src/python need updates.
-5. Exceptions: Use OPENVINO_ASSERT(condition, ...) for checks instead of if + throw.
-6. Documentation: Ensure that any new public APIs have docstrings in C++ headers and Python bindings. Ensure that new public APIs have documentation updated in /site.
-7. Test Coverage: Ensure that new features or changes have corresponding tests.
-8. Formatting & Safety:
+1. PR description must be aligned with [./pull_request_template.md](./pull_request_template.md) and its checklist must be filled out. If not, request the author to update the description and checklist before proceeding with the review.
+2. PR description must be up to date and include all information about the changes.
+3. Follow C++ Core Guidelines strictly. Include references in your comments.
+4. Check for 'Hidden' Performance Tax: Look for dynamic_cast in the hot path (inference loops). Suggest static_cast or redesigning if the type is known.
+5. Avoid copies: Ensure that large data structures (like tensors) are passed by reference or moved, not copied.
+6. Python Bindings: If C++ APIs are changed, check if the corresponding Python pybind11 wrappers in src/python need updates.
+7. Exceptions: Use OPENVINO_ASSERT(condition, ...) for checks instead of if + throw.
+8. Documentation: Ensure that any new public APIs have docstrings in C++ headers and Python bindings. Ensure that new public APIs have documentation updated in /site.
+9. Test Coverage: Ensure that new features or changes have corresponding tests.
+10. Formatting & Safety:
     * No `using namespace std;`.
     * No `auto` for primitive types where it obscures readability.
     * Use `const` and `constexpr` wherever possible.
-9. Pass non-fundamental values by `const` reference wherever possible.
-10. Follow constructors and member initializer lists style instead of direct assignments in the constructor body.
-11. Verify that the result of every newly introduced function is used in at least one call site except for `void` functions.
-12. Make sure the function names are descriptive.
-13. Check for variables with different names but similar meaning or aliasing.
-14. Avoid duplicate code. Ensure that common functionality is extracted into reusable functions or utilities.
-15. When initial container values are known upfront, prefer initializer-list / brace-initialization over constructing an empty container and immediately inserting values.
-16. Avoid pronouns in comments and names to make the statements concise.
-17. Unused functions and constructors aren't allowed except for in `debug_utils.hpp`.
-18. `debug_utils.hpp` must never be included.
-19. Assumptions on the user's behalf aren't allowed. For example, the implementation shouldn't adjust config values silently or with a warning; it should throw an exception instead.
-20. Samples:
+11. Pass non-fundamental values by `const` reference wherever possible.
+12. Follow constructors and member initializer lists style instead of direct assignments in the constructor body.
+13. Verify that the result of every newly introduced function is used in at least one call site except for `void` functions.
+14. Make sure the function names are descriptive.
+15. Check for variables with different names but similar meaning or aliasing.
+16. Avoid duplicate code. Ensure that common functionality is extracted into reusable functions or utilities.
+17. When initial container values are known upfront, prefer initializer-list / brace-initialization over constructing an empty container and immediately inserting values.
+18. Avoid pronouns in comments and names to make the statements concise.
+19. Unused functions and constructors aren't allowed except for in `debug_utils.hpp`.
+20. `debug_utils.hpp` must never be included.
+21. Assumptions on the user's behalf aren't allowed. For example, the implementation shouldn't adjust config values silently or with a warning; it should throw an exception instead.
+22. Samples:
     * Avoid adding new samples unless there is a strong, clearly justified reason.
     * Keep command‑line arguments in samples minimal.
     * Ensure new samples have corresponding tests.