switch to upstream compiler, rename workflows, update fragments#312
switch to upstream compiler, rename workflows, update fragments#312
Conversation
📝 WalkthroughWalkthroughBulk updates to GitHub Actions configurations: added multiple new workflows, parameterized and propagated AI model inputs via COPILOT_MODEL, extended safe-outputs schemas (draft/repo/missing_data), bumped gh-aw setup action to v0.48.1 in lockfiles, renamed many workflows, and adjusted artifact/ref handling and PR base-branch fallbacks. Changes
Sequence Diagram(s)mermaid Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Requesting changes: the new CI trigger helper currently masks workflow dispatch failures and can report success when dispatches fail.
What is this? | From workflow: PR Review
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/gh-aw-release-update.lock.yml (1)
704-730:⚠️ Potential issue | 🟡 Minor
missing_datatool has no required fields — agent can invoke it with zero arguments.Both the MCP inputSchema (
"required": [], line 726) and the validation schema (norequired: trueanywhere, lines 771-795) allow an emptymissing_datacall. This is inconsistent withmissing_tool, which enforces"required": ["reason"]. An agent could emit amissing_datarecord with no context, making it impossible to act on.🛡️ Suggested fix in source
.mdfile- "required": [], + "required": ["reason"],And in the validation schema:
"reason": { "type": "string", "sanitize": true, + "required": true, "maxLength": 256 }Based on learnings, changes must be applied to the source
.mdfile.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/gh-aw-release-update.lock.yml around lines 704 - 730, The "missing_data" tool's schema allows empty invocation; update the tool definition for missing_data so it requires the key information (make "reason" required, consistent with missing_tool) by adding "reason" to the inputSchema "required" array and mirror that requirement in the validation schema for the missing_data type so the validator enforces the presence of reason (and any other required fields you choose like data_type or context if desired) before accepting a missing_data record.
🧹 Nitpick comments (2)
.github/workflows/gh-aw-flaky-test-investigator.lock.yml (1)
794-820:missing_datatool: no required fields.The
missing_datatool schema has"required": [](line 816), and accordingly the validation schema (lines 858–882) marks no field asrequired: true. This means an agent could callmissing_datawith an empty object. If a minimum ofreasonordata_typewas intended (similar tomissing_toolwhich requiresreason), this would need to be fixed in the source.mdfile. If the flexibility is intentional, this is fine as-is.Also applies to: 858-882
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/gh-aw-flaky-test-investigator.lock.yml around lines 794 - 820, The missing_data tool currently has an empty required array in its inputSchema which allows calls with an empty object; update the missing_data tool definition so its inputSchema.required includes the minimum expected fields (e.g., add "reason" or ["reason","data_type"] similar to how missing_tool requires "reason"), update the corresponding validation schema to mark those fields required, and regenerate any derived schema/artifacts so the validator enforces that missing_data cannot be invoked without the chosen required fields; look for the "missing_data" tool block and its "inputSchema" / "required" entries to make the change..github/workflows/gh-aw-issue-fixer.lock.yml (1)
793-796:missing_dataaccepts calls with zero arguments.The
"required": []in the tool input schema and norequired: truemarkers invalidation.jsonmean an agent can callmissing_datawith an empty object. Contrast withmissing_tool, which enforces"required": ["reason"]. Consider requiring at leastreasonto avoid uninformative empty reports.This originates from the source
.mdfragments — a change to themissing_datatool definition there would be the correct fix.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/gh-aw-issue-fixer.lock.yml around lines 793 - 796, The missing_data tool currently allows empty calls because its JSON schema has "required": [] and validation.json lacks required fields; update the tool definition for missing_data to require a reason (e.g., set "required": ["reason"] in the tool input schema for missing_data), mirror that constraint in validation.json (add required: true for the reason field), and update the originating .md fragment that defines missing_data so the generated schema enforces a non-empty reason similar to missing_tool's "required": ["reason"].
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/downstream-users.lock.yml:
- Around line 744-756: The "repo" validation rule is unreachable because the
create_pull_request inputSchema has "additionalProperties": false and does not
declare "repo"; update the source fragment that generates the schema
(safe-output-create-pr.md) to add a "repo" property under inputSchema.properties
with the same shape used in the lock (type: string, maxLength: 256), ensuring
the generated inputSchema for create_pull_request includes "repo" so the
downstream-users.lock.yml rule becomes reachable; alternatively, if cross-repo
PRs are not supported, remove the "repo" rule from the lock generation to keep
schemas consistent.
In @.github/workflows/gh-aw-flaky-test-investigator.lock.yml:
- Around line 67-71: The workflow default model value "gpt-5.3-codex" is not
available via the public API; update the model default under the "model:" key
(replace the current default value "gpt-5.3-codex") to an API-accessible model
such as "gpt-4" or "gpt-3.5-turbo" so the GitHub Actions run can authenticate
and call the OpenAI API successfully.
In @.github/workflows/gh-aw-issue-fixer.lock.yml:
- Around line 814-817: Add an inline clarifying note to the "repo" schema entry
in validation.json (the "repo" object used by add_comment and
create_pull_request) to indicate it is an optional, infrastructure-injected
field for cross-repo routing and not supplied by the agent; update the "repo"
object to include a human-readable annotation such as a "description" or
"$comment" (e.g., "Infrastructure-injected field for cross-repo routing. Not
exposed in inputSchema.") so future maintainers won't treat it as an accidental
omission.
In @.github/workflows/gh-aw-release-update.lock.yml:
- Around line 559-563: The workflow currently injects `${{ inputs.model }}`
directly into the github-script JavaScript string (see keys
engine_id/engine_name/model/agent_version), which risks template/JS injection;
instead pass the model via an environment variable (e.g., set env.MODEL: ${{
inputs.model }} in the step) and read it in the script with process.env.MODEL,
updating the step that uses "github-script" to remove direct `${{ inputs.model
}}` interpolation; make this change in the source .md that generates this
workflow rather than editing the generated .yml.
---
Outside diff comments:
In @.github/workflows/gh-aw-release-update.lock.yml:
- Around line 704-730: The "missing_data" tool's schema allows empty invocation;
update the tool definition for missing_data so it requires the key information
(make "reason" required, consistent with missing_tool) by adding "reason" to the
inputSchema "required" array and mirror that requirement in the validation
schema for the missing_data type so the validator enforces the presence of
reason (and any other required fields you choose like data_type or context if
desired) before accepting a missing_data record.
---
Duplicate comments:
In @.github/workflows/downstream-users.md:
- Around line 18-20: The "cron" schedule line under the schedule block is
intentionally written in natural language ("weekly on Monday around 10:00")
because the GH CLI compile step translates that into a valid 5-field cron in
downstream-users.lock.yml (see the compiled cron "4 9 * * 1" with the friendly
format comment), so no code change is required; leave the schedule and
workflow_dispatch entries as-is and rely on the compile step to produce the
concrete cron.
---
Nitpick comments:
In @.github/workflows/gh-aw-flaky-test-investigator.lock.yml:
- Around line 794-820: The missing_data tool currently has an empty required
array in its inputSchema which allows calls with an empty object; update the
missing_data tool definition so its inputSchema.required includes the minimum
expected fields (e.g., add "reason" or ["reason","data_type"] similar to how
missing_tool requires "reason"), update the corresponding validation schema to
mark those fields required, and regenerate any derived schema/artifacts so the
validator enforces that missing_data cannot be invoked without the chosen
required fields; look for the "missing_data" tool block and its "inputSchema" /
"required" entries to make the change.
In @.github/workflows/gh-aw-issue-fixer.lock.yml:
- Around line 793-796: The missing_data tool currently allows empty calls
because its JSON schema has "required": [] and validation.json lacks required
fields; update the tool definition for missing_data to require a reason (e.g.,
set "required": ["reason"] in the tool input schema for missing_data), mirror
that constraint in validation.json (add required: true for the reason field),
and update the originating .md fragment that defines missing_data so the
generated schema enforces a non-empty reason similar to missing_tool's
"required": ["reason"].
| "draft": { | ||
| "type": "boolean" | ||
| }, | ||
| "labels": { | ||
| "type": "array", | ||
| "itemType": "string", | ||
| "itemSanitize": true, | ||
| "itemMaxLength": 128 | ||
| }, | ||
| "repo": { | ||
| "type": "string", | ||
| "maxLength": 256 | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for "repo" in markdown source fragments
find .github -name "*.md" -type f | head -20Repository: elastic/ai-github-actions
Length of output: 980
🏁 Script executed:
#!/bin/bash
# Search for repo field in relevant source files
rg -n "\"repo\"" --type md .github/ -C 3Repository: elastic/ai-github-actions
Length of output: 483
🏁 Script executed:
#!/bin/bash
# Examine the specific lines in the lock file to confirm the schema structure
head -n 660 .github/workflows/downstream-users.lock.yml | tail -n 50Repository: elastic/ai-github-actions
Length of output: 3084
🏁 Script executed:
#!/bin/bash
# Check lines 744-756 of the lock file to confirm validation.json contains "repo"
sed -n '744,756p' .github/workflows/downstream-users.lock.ymlRepository: elastic/ai-github-actions
Length of output: 467
🏁 Script executed:
#!/bin/bash
# Find the source fragment for safe outputs / create_pull_request
fd "safe.*output.*create.*pr" --type f .github/Repository: elastic/ai-github-actions
Length of output: 127
🏁 Script executed:
#!/bin/bash
# Search for any fragment files with create_pull_request or create-pr in name
fd -e md . .github/workflows/gh-aw-fragments/ | xargs rg -l "create_pull_request|create-pr|create.*pull.*request" 2>/dev/nullRepository: elastic/ai-github-actions
Length of output: 357
🏁 Script executed:
#!/bin/bash
# Examine the source fragment
cat .github/workflows/gh-aw-fragments/safe-output-create-pr.mdRepository: elastic/ai-github-actions
Length of output: 2251
repo validation rule is unreachable — agent cannot provide this field.
The inputSchema for create_pull_request (lines 622–654) has "additionalProperties": false and does not include a repo property. The validation rule at lines 753–756 therefore cannot be triggered: any tool call including repo would be rejected at the schema level first.
The source fragment .github/workflows/gh-aw-fragments/safe-output-create-pr.md does not define repo either. Either remove the validation rule from the lock file, or add repo to both the inputSchema.properties and the source fragment if cross-repo PR support is intended.
Since this is auto-generated, the fix belongs in the source fragment, not in downstream-users.lock.yml.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/downstream-users.lock.yml around lines 744 - 756, The
"repo" validation rule is unreachable because the create_pull_request
inputSchema has "additionalProperties": false and does not declare "repo";
update the source fragment that generates the schema (safe-output-create-pr.md)
to add a "repo" property under inputSchema.properties with the same shape used
in the lock (type: string, maxLength: 256), ensuring the generated inputSchema
for create_pull_request includes "repo" so the downstream-users.lock.yml rule
becomes reachable; alternatively, if cross-repo PRs are not supported, remove
the "repo" rule from the lock generation to keep schemas consistent.
| model: | ||
| default: gpt-5.3-codex | ||
| description: AI model to use | ||
| required: false | ||
| type: string |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
gpt-5.3-codex model OpenAI availability
💡 Result:
As of February 21, 2026, GPT‑5.3‑Codex is available to paid ChatGPT subscribers via Codex—i.e., in the Codex app, web, CLI, and IDE extension. OpenAI says they are “working to safely enable API access soon,” meaning it is not generally available in the API yet. [1]
Related: GPT‑5.3‑Codex‑Spark is rolling out as a research preview for ChatGPT Pro users in Codex surfaces, with limited API availability only to a small set of design partners (not broad public API access). [2]
Sources:
[1] OpenAI — “Introducing GPT‑5.3‑Codex” (Feb 5, 2026)
[2] OpenAI — “Introducing GPT‑5.3‑Codex‑Spark” (Feb 12, 2026)
Replace gpt-5.3-codex with an available API model.
The gpt-5.3-codex model does exist as of February 2026, but it is not available via the general API—it's currently limited to Codex app/web/CLI/IDE extension access for paid subscribers, with API access still in development. GitHub workflows require API access, so this default will cause the workflow to fail at runtime. Use an available OpenAI API model (e.g., gpt-4, gpt-3.5-turbo) instead.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/gh-aw-flaky-test-investigator.lock.yml around lines 67 -
71, The workflow default model value "gpt-5.3-codex" is not available via the
public API; update the model default under the "model:" key (replace the current
default value "gpt-5.3-codex") to an API-accessible model such as "gpt-4" or
"gpt-3.5-turbo" so the GitHub Actions run can authenticate and call the OpenAI
API successfully.
| "repo": { | ||
| "type": "string", | ||
| "maxLength": 256 | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/gh-aw-issue-fixer.lock.yml | sed -n '810,820p'Repository: elastic/ai-github-actions
Length of output: 441
🏁 Script executed:
cat -n .github/workflows/gh-aw-issue-fixer.lock.yml | sed -n '840,850p'Repository: elastic/ai-github-actions
Length of output: 498
🏁 Script executed:
# Search for the tool schemas to understand inputSchema structure
cat -n .github/workflows/gh-aw-issue-fixer.lock.yml | sed -n '700,850p' | grep -A 5 -B 5 "additionalProperties"Repository: elastic/ai-github-actions
Length of output: 2515
🏁 Script executed:
# Search for safe_output or repo injection in the codebase
rg -i "safe.output|repo.*inject" --type=js --type=ts -g '*.lock.yml' --type=json | head -20Repository: elastic/ai-github-actions
Length of output: 217
🏁 Script executed:
# Find the inputSchema for add_comment tool
cat -n .github/workflows/gh-aw-issue-fixer.lock.yml | sed -n '790,825p'Repository: elastic/ai-github-actions
Length of output: 1394
🏁 Script executed:
# Find the inputSchema for create_pull_request tool
cat -n .github/workflows/gh-aw-issue-fixer.lock.yml | sed -n '720,760p'Repository: elastic/ai-github-actions
Length of output: 2703
🏁 Script executed:
# Search for repo injection or validation context in the entire codebase
rg -n "repo.*inject|safe.output|validation.*repo" --type=js --type=ts --type=json -i | head -30Repository: elastic/ai-github-actions
Length of output: 51
🏁 Script executed:
# Look for where validation.json is used or how repo field is handled
rg -n '"repo"' .github/workflows/gh-aw-issue-fixer.lock.yml | head -20Repository: elastic/ai-github-actions
Length of output: 128
🏁 Script executed:
# Find add_comment tool definition
cat -n .github/workflows/gh-aw-issue-fixer.lock.yml | grep -B 30 '"name": "add_comment"' | head -40Repository: elastic/ai-github-actions
Length of output: 3671
🏁 Script executed:
# Find create_pull_request tool definition
cat -n .github/workflows/gh-aw-issue-fixer.lock.yml | grep -B 30 '"name": "create_pull_request"' | head -40Repository: elastic/ai-github-actions
Length of output: 1874
🏁 Script executed:
# Search entire codebase for where validation.json is used and repo is injected
rg -n "validation.json|repo" --type=js --type=ts -A 3 -B 3 | grep -A 5 -B 5 "repo\|validation" | head -50Repository: elastic/ai-github-actions
Length of output: 217
🏁 Script executed:
# Look for safeoutputs directory and its implementations
find . -type f -name "*safeoutput*" -o -name "*validation*" | grep -v ".git" | grep -v "node_modules"Repository: elastic/ai-github-actions
Length of output: 117
🏁 Script executed:
cat ./scripts/gh-aw-safe-outputs-validation-rules.mdRepository: elastic/ai-github-actions
Length of output: 11335
🏁 Script executed:
# Search for where repo field is actually processed or injected
rg -n "repo" -A 3 -B 3 --type=js --type=ts | head -60Repository: elastic/ai-github-actions
Length of output: 217
🏁 Script executed:
# Look for safeoutputs validation code or handler
fd "safeoutput" -t fRepository: elastic/ai-github-actions
Length of output: 51
🏁 Script executed:
# Look for context around the repo field definitions and any comments
cat -n .github/workflows/gh-aw-issue-fixer.lock.yml | sed -n '800,880p'Repository: elastic/ai-github-actions
Length of output: 3093
🏁 Script executed:
# Search for any comments or documentation about repo field
rg -n "repo|defaultTargetRepo|allowedRepos" .github/workflows/gh-aw-issue-fixer.lock.yml | head -20Repository: elastic/ai-github-actions
Length of output: 2334
🏁 Script executed:
# Check if repo appears in other validation entries
cat -n .github/workflows/gh-aw-issue-fixer.lock.yml | sed -n '800,950p' | grep -A 3 -B 3 '"repo"'Repository: elastic/ai-github-actions
Length of output: 592
Add a clarifying comment explaining that repo is an optional infrastructure-injected field.
The repo field appears in validation.json for both add_comment (lines 814–817) and create_pull_request (lines 844–847), but neither tool's inputSchema exposes it (both declare additionalProperties: false). This is intentional—repo is an optional, infrastructure-injected field used for cross-repository routing, not supplied by the agent. Without an inline comment, future maintainers may flag this as an oversight. Consider adding a brief note like:
"repo": {
"type": "string",
"maxLength": 256,
"comment": "Infrastructure-injected field for cross-repo routing. Not exposed in inputSchema."
}
Also applies to: 844–847
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/gh-aw-issue-fixer.lock.yml around lines 814 - 817, Add an
inline clarifying note to the "repo" schema entry in validation.json (the "repo"
object used by add_comment and create_pull_request) to indicate it is an
optional, infrastructure-injected field for cross-repo routing and not supplied
by the agent; update the "repo" object to include a human-readable annotation
such as a "description" or "$comment" (e.g., "Infrastructure-injected field for
cross-repo routing. Not exposed in inputSchema.") so future maintainers won't
treat it as an accidental omission.
| engine_id: "copilot", | ||
| engine_name: "GitHub Copilot CLI", | ||
| model: "gpt-5.2-codex", | ||
| model: "${{ inputs.model }}", | ||
| version: "", | ||
| agent_version: "0.0.412", |
There was a problem hiding this comment.
${{ inputs.model }} interpolated directly into a github-script JavaScript string — template injection risk.
GitHub Actions evaluates ${{ }} expressions textually before passing the script to Node. If inputs.model ever contains " or other JS-special characters (e.g., from a misconfigured caller that forwards user input), it can break or inject into the script. The safe pattern is to pass the value through an environment variable and read process.env.MODEL in the script.
🛡️ Proposed safe-env fix (apply to the source .md file)
- name: Generate agentic run info
id: generate_aw_info
uses: actions/github-script@...
+ env:
+ GH_AW_INPUT_MODEL: ${{ inputs.model }}
with:
script: |
const fs = require('fs');
const awInfo = {
engine_id: "copilot",
engine_name: "GitHub Copilot CLI",
- model: "${{ inputs.model }}",
+ model: process.env.GH_AW_INPUT_MODEL,Based on learnings, changes to this generated file must be made in the corresponding source .md file rather than directly here.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| engine_id: "copilot", | |
| engine_name: "GitHub Copilot CLI", | |
| model: "gpt-5.2-codex", | |
| model: "${{ inputs.model }}", | |
| version: "", | |
| agent_version: "0.0.412", | |
| engine_id: "copilot", | |
| engine_name: "GitHub Copilot CLI", | |
| model: process.env.GH_AW_INPUT_MODEL, | |
| version: "", | |
| agent_version: "0.0.412", |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/gh-aw-release-update.lock.yml around lines 559 - 563, The
workflow currently injects `${{ inputs.model }}` directly into the github-script
JavaScript string (see keys engine_id/engine_name/model/agent_version), which
risks template/JS injection; instead pass the model via an environment variable
(e.g., set env.MODEL: ${{ inputs.model }} in the step) and read it in the script
with process.env.MODEL, updating the step that uses "github-script" to remove
direct `${{ inputs.model }}` interpolation; make this change in the source .md
that generates this workflow rather than editing the generated .yml.
Summary
This PR switches workflow compilation to the upstream
github/gh-awtoolchain, renames and re-groups GitHub Agent workflows, adds reusable scheduled audit/fix base workflows, and refreshes generated workflow lock files plus docs to match.Key changes
1) Switch to upstream compiler/runtime
MakefileGH_AW_VERSIONbumped tov0.48.1.setup-gh-awnow installsgithub.com/github/gh-aw/cmd/gh-aw@v0.48.1(instead of cloning a fork/branch).compilenow depends onsyncand usesgh-aw compile --action-mode release --action-tag $(GH_AW_VERSION)..github/workflows/agentics-maintenance.ymlgithub/gh-aw/actions/setup@v0.48.1..github/aw/actions-lock.json2) Workflow renames and taxonomy cleanup
A broad rename pass aligns workflow names with clearer detector/fixer terminology and current conventions, including:
pr-ci-detective->pr-actions-detectivepr-ci-fixer->pr-actions-fixerdocs-drift->docs-patroldocs-drift-external->docs-patrol-externaldocs-new-contributor-review->newbie-contributor-patroldocs-new-contributor-review-external->newbie-contributor-patrol-externalbreaking-change-detect->breaking-change-detectorsemantic-function-clustering->code-duplication-detectorflaky-test-triage->flaky-test-investigatorissue-triage-pr->issue-fixertest-improvement->test-improvergh-aw-prefix (for example:upgrade-check,workflow-patrol,downstream-users).Related trigger workflow files were renamed/updated under
.github/workflows/trigger-*.yml, with obsolete triggers removed and new ones added (for example,trigger-text-auditor.ymlandtrigger-newbie-contributor-fixer.yml).3) New base and specialized workflows
Added base reusable workflows:
gh-agent-workflows/scheduled-audit/gh-agent-workflows/scheduled-fix/.github/workflows/gh-aw-scheduled-audit.{md,lock.yml}.github/workflows/gh-aw-scheduled-fix.{md,lock.yml}Added/expanded specialized workflows:
code-duplication-fixernewbie-contributor-fixertext-auditor.github/workflows/trigger-text-auditor.yml4) Shared fragments and automation scripts
.github/workflows/gh-aw-fragments/:scheduled-report.md->scheduled-audit.mdscheduled-fix.mdscripts/trigger-ci-workflows.shdetectors,improvers,monitors), plus--listand--dry-run.scripts/dogfood.shEXCLUDED_WORKFLOWSfor the new workflow set.scripts/quick-setup.sh5) Compatibility lockfile symlinks
Added backward-compatibility symlinks for legacy lockfile names:
.github/workflows/gh-aw-breaking-change-detect.lock.yml->gh-aw-breaking-change-detector.lock.yml.github/workflows/gh-aw-docs-drift.lock.yml->gh-aw-docs-patrol.lock.yml.github/workflows/gh-aw-pr-ci-detective.lock.yml->gh-aw-pr-actions-detective.lock.yml.github/workflows/gh-aw-test-improvement.lock.yml->gh-aw-test-improver.lock.yml6) CI/workflow maintenance updates
.github/workflows/smoke-test-install.ymlgh-awCLI viago install github.com/github/gh-aw/cmd/gh-aw@v0.48.1..github/workflows/gh-aw-*.mdentrypoints during install tests..github/workflows/release.yml"$GITHUB_OUTPUT") to satisfy linting/actionlint checks.Makefilelint-workflowsnow targets trigger/internal workflow files directly instead of broadly scanning all.github/workflowsexamples.7) Documentation refresh
Updated docs to match the new model and names:
gh-agent-workflows/README.mdgh-agent-workflows/DEVELOPING.mddocs/upgrading.md(new)docs/workflows/gh-agent-workflows.mddocs/workflows/gh-agent-workflows/bugs.md(new)docs/workflows/gh-agent-workflows/code-duplication.md(new)docs/workflows/gh-agent-workflows/docs-patrol-overview.md(new)docs/workflows/gh-agent-workflows/newbie-contributor.md(new)docs/workflows/gh-agent-workflows/text-quality.md(new)mkdocs.ymlnavigation reorganized into:DEVELOPING.mdanddocs/developing.mdupdated for internal-vs-published naming conventions.Most
.lock.ymlupdates are generated outputs from the compiler/tooling and renamed workflow shims.