Remove Fixer workflows #436

Activity

1. github-actions commented on Feb 27, 2026

   

   github-actionsBot

   on Feb 27, 2026 – with GitHub Actions

   Contributor

   More actions

   The repo should not remove fixer workflows in one step; the safest path is a phased migration to a detector-triggered second PR agent, then deprecate fixers pair-by-pair after parity is proven.

   Recommendation

   Keep current fixer workflows for now, add an explicit detector → second-agent PR handoff (opt-in), pilot it on one detector/fixer pair, and only then remove specialized fixers that are redundant.

   Findings

   • The architecture is currently documented as detector/fixer pairs, not detector-only:
     • docs/workflows/gh-agent-workflows.md:70-83 (pair model and current pairs)
     • gh-agent-workflows/README.md:12-19,35-39 (base Scheduled Audit/Fix + “Fixers” section)
   • A generic replacement engine already exists:
     • .github/workflows/gh-aw-scheduled-fix.md:3-4,13,114-124 (generic fixer by issue prefix/label)
   • Existing “second agent” precedent exists for PR failures:
     • .github/workflows/gh-aw-pr-actions-detective.md:78-90 (read-only detective)
     • .github/workflows/gh-aw-pr-actions-fixer.md:82-83,91-95 (separate fixer that can push)
     • gh-agent-workflows/pr-actions-detective/README.md:7-8 and gh-agent-workflows/pr-actions-fixer/README.md:7,23,36-37
   • Removal would touch multiple operational surfaces:
     • scripts/quick-setup.sh:128-142 (--continuous-improvement still includes fixer workflows)
     • scripts/trigger-ci-workflows.sh:28-36 (improvers list includes multiple fixers)
     • .github/workflows/smoke-test-install.yml:51,59,63,68,74,75 (smoke test installs fixer workflows)
     • .github/workflows/trigger-*-fixer.yml files currently present for several fixers
   • Related historical context:
     • Split pr check fix into pr ci detective and pr ci fixer #121 / Add PR CI detective and fixer workflows #123 previously split PR CI detective and fixer.
     • Expand --continuous-improvement workflows, drop pr-ci-fixer #180 removed a duplicate fixer (pr-ci-fixer) but retained the broader detector/fixer model.
     • Add daily fixer agentic workflow for 'Resource not accessible by integration' across long-term branches #424 and Add daily detector agentic workflow for "Resource not accessible by integration" across long-term branches #425 show active investment in detector/fixer-style automation.

   Verification

   I validated current repo behavior and references with existing tooling:

   $ make lint
   ... Validating GitHub Actions workflow files ...
   ... Validating GitHub Actions composite action files ...
   (exited with exit code 0)
   
   $ rg -n "Trigger .* Fixer|IMPROVERS" scripts/trigger-ci-workflows.sh
   28:IMPROVERS=(
   29:  "Trigger Bug Exterminator"
   30:  "Trigger Code Duplication Fixer"
   32:  "Trigger Newbie Contributor Fixer"
   33:  "Trigger Small Problem Fixer"
   
   $ rg -n "code-duplication-fixer|issue-fixer|newbie-contributor-fixer|pr-actions-fixer|scheduled-fix|small-problem-fixer" .github/workflows/smoke-test-install.yml
   51:            code-duplication-fixer
   59:            issue-fixer
   63:            newbie-contributor-fixer
   68:            pr-actions-fixer
   74:            scheduled-fix
   75:            small-problem-fixer

   Detailed Action Plan

   1. Define scope in Remove Fixer workflows #436: which workflows are in-scope for removal (scheduled fixers only vs all “fixer”-named workflows).
   2. Add detector → second-agent handoff using one generic PR agent path first (recommended to build on scheduled-fix semantics in .github/workflows/gh-aw-scheduled-fix.md).
   3. Pilot one pair (e.g., detector issue output -> generic fixer PR) and measure: noop rate, PR quality, reviewer churn, and false positives.
   4. Deprecate pair-by-pair: keep old fixer as compatibility wrapper for one release cycle, then remove.
   5. Update all references in one sweep:
      • docs: gh-agent-workflows/README.md, docs/workflows/gh-agent-workflows.md, pair-specific docs
      • setup: scripts/quick-setup.sh
      • operational scripts: scripts/trigger-ci-workflows.sh
      • smoke/trigger artifacts: .github/workflows/smoke-test-install.yml, trigger-*-fixer.yml
   6. Compile + lint gate before merge: run make compile and make lint and verify no stale fixer references remain.

   Related Items

   Type	Link	Relevance
   Issue	#436	Current request
   Issue	#121	Prior detective/fixer split decision
   PR	#123	Implemented PR CI detective/fixer split
   PR	#180	Removed one duplicate fixer while keeping model
   Issue	#424	Recent request for new fixer workflow
   PR	#425	Recent detector/fixer implementation work
   File	docs/workflows/gh-agent-workflows.md:70-83	Detector/fixer architecture
   File	.github/workflows/gh-aw-scheduled-fix.md	Generic fixer base workflow
   File	scripts/quick-setup.sh:128-142	Installer impact
   File	.github/workflows/smoke-test-install.yml:44-81	CI smoke-test impact

   ---

   What is this? | From workflow: Issue Triage

   Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
2. strawgate commented on Feb 27, 2026

   

   strawgate

   on Feb 27, 2026

   ContributorAuthor

   More actions

   /ai what's the best way to automate the issue -> PR handoff? what will be clean and scalable?

   👀React with 👀1Reacted by github-actions
3. github-actions commented on Feb 27, 2026

   

   github-actionsBot

   on Feb 27, 2026 – with GitHub Actions

   Contributor

   More actions

   tl;dr: the cleanest scalable handoff is a single label-driven PR worker (based on issue-fixer/scheduled-fix) and keep detectors as report-only producers.

   Recommendation

   Use a two-stage contract:

   1. Detector/Triage stage creates or updates an issue and marks it ai:fix-ready only when acceptance criteria are concrete.
   2. PR Worker stage triggers on issues.labeled (ai:fix-ready) and opens one focused draft PR.

   This gives one reusable PR engine, clear gates, and avoids N detector→N fixer coupling.

   Why this is the best fit here

   • You already have detector/fixer architecture documented (docs/workflows/gh-agent-workflows.md:70-73).
   • You already have reusable base workflows intended to pair (gh-agent-workflows/README.md:12-20).
   • scheduled-fix already supports selecting issues by title prefix/label (gh-agent-workflows/scheduled-fix/README.md:36-39).
   • Today issue-triage and issue-fixer are both wired to issues.opened (gh-agent-workflows/issue-triage/example.yml:3-4, gh-agent-workflows/issue-fixer/example.yml:3-4), which is not a true handoff.

   Scalable rollout (minimal churn)

   1. Define a small issue contract for PR eligibility (required fields + ai:fix-ready label).
   2. Add one new trigger workflow for the PR worker on issues.labeled (plus workflow_dispatch for retries).
   3. Keep existing fixers as compatibility wrappers initially; route them through the same worker logic.
   4. After parity, remove specialized fixers pair-by-pair and update setup docs/scripts in one sweep.

   Operational guardrails to keep it clean

   • Concurrency key per issue number (prevents duplicate PR attempts).
   • Idempotency check: if open PR already references that issue, comment and stop.
   • Keep draft PR default, promote to ready only after checks.
   • Restrict auto-handoff to trusted issue sources (existing role/association gates).

   If useful, I can draft the exact issues.labeled trigger YAML and the label/state contract next.

   ---

   What is this? | From workflow: Mention in Issue

   Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
4. strawgate commented on Feb 28, 2026

   

   strawgate

   on Feb 28, 2026

   ContributorAuthor

   More actions

   /ai great idea let's update our detection workflows to have an input for labels to apply to the issue that's created and when let's publish an example of a generic auto-fix workflow which fires from the label and fixes the issue

   👀React with 👀1Reacted by github-actions
5. strawgate

   closed this as not plannedon Mar 24, 2026