ci(gh-aw): towards the dark factory

This was generated by AI during triage.

c8ctl agentic workflows

Design only. No workflows deployed or repository settings changed.

Architecture

Use five gh-aw workers:

• Issue fitness (Copilot): assess implementation readiness.
• Implementation (Copilot): implement accepted scope and open a PR.
• Copilot review: independently review correctness and merge eligibility.
• Claude review: independently review correctness and merge eligibility.
• Re-implementation (Copilot): address combined review findings and CI failures.

A deterministic Actions coordinator owns state, report validation, dispatch,
CI gates and merging. /goal is the objective, not a scheduler;
workflow_run chains cannot implement an unbounded loop.

Reviews use separate Copilot CLI and Claude Code runs, with a non-Claude model
selected for Copilot.

Dependency freshness

• Reuse Renovate with daily release checks. Track one gh-aw version declaration
  through a regex manager using github-releases for github/gh-aw.
• A trusted maintenance job regenerates lockfiles with the candidate compiler.
  Group compiler, generated runtime/action pins and supported engine updates in
  the same PR; do not independently edit generated lockfiles.
• Require compilation, lockfile-drift checks, both review streams and workflow
  regression trials. Upstream minor/patch numbering alone does not prove safety,
  especially before v1.0.
• Open/update dependency PRs promptly. Surface failed updates or approval blockers;
  never silently freeze dependencies. Evaluate prereleases separately before adoption.

Replace Renovate's current broad minor/patch auto-merge rule with the shared merge
gate. Toolchain/workflow changes still require human approval under the protected
change policy; agents must not approve changes to their own execution controls.

Issue implementation fitness

Check every incoming issue against main, tests, docs, merged/open PRs and SDK
gaps. Assess each acceptance criterion; implement only clearly specified, missing
scope, including when a request is already partially implemented.

flowchart TD
    I[Incoming issue] --> F{Implementation fitness}
    F -->|Ready| P[Record scope and acceptance tests]
    P --> W[Implement missing scope]
    W --> PR[Open PR]
    F -->|Already implemented| E[Post behavior evidence and references]
    F -->|Needs specification| Q[Ask focused questions; wait]
    F -->|Work in progress| L[Link existing PR; wait for outcome]
    F -->|Blocked or out of scope| B[Explain blocker; route to owner]
    E --> N[No implementation PR]
    Q --> N
    L --> N
    B --> N

Decision	Required evidence / action
ready	Testable expected behavior, bounded scope, understood compatibility constraints, no unresolved implementation dependency
already_implemented	Every criterion satisfied on main; cite code/merged PR plus tests or CLI reproduction
needs_spec	Identify missing expected behavior, reproduction, acceptance criteria or conflicting requirements; ask only the blocking questions
in_progress	Existing PR covers the request; follow it instead of starting competing work
blocked	Identify upstream SDK/API gap, unavailable dependency or out-of-scope request; do not invent a local workaround

Publish {decision, issue_revision, base_sha, criteria, evidence, blockers}.
Only ready authorizes implementation; otherwise explain and leave the issue open.
Reassess after relevant edits/replies, linked-PR completion or maintainer retry.
Recheck issue revision and main before coding. Deduplicate by issue; exclude
automation-generated diagnostic issues.

PR convergence

All incoming PRs enter the loop, regardless of author. Missing testable intent in
the linked issue/PR description blocks autonomous fixes and merging.

flowchart TD
    R[Implementation-ready issue] --> I[Implement / re-implement]
    I -->|New commit| P[Create or update PR]
    I -->|Blocked or no progress| X[Escalate; never mark clean]
    P --> S[Snapshot head and base]
    E[Incoming PR or changed head/base] --> S
    S --> C[Copilot review]
    S --> A[Claude review]
    S --> T[Existing Test CI]
    C --> G{Both reviews complete and CI settled?}
    A --> G
    T --> G
    G -->|Blocked report or timeout| X
    G -->|Findings or failed CI| B{Fewer than 3 re-implementation attempts?}
    B -->|Yes: increment attempt; combine feedback| I
    B -->|No: budget exhausted| X
    G -->|Two clean reviews and green CI| M{Safe patch or additive minor?}
    M -->|Both agree; all merge gates pass| U[SHA-pinned squash merge]
    M -->|Other or uncertain| H[Human merge decision]

Implement the agreed issue scope initially. After independent reviews, re-implement
against their combined findings and CI failures, with regression tests. Resolve
contradictory findings with evidence or escalate.

Head/base changes invalidate both reviews, CI and merge eligibility. Reuse Test
CI's lint, typecheck, cross-platform unit and Node/Camunda integration matrix.
Bind results to the workflow and head/base, including synthetic merge commits.
Missing/skipped required checks are not green.

Allow at most three review/CI -> re-implementation attempts per session.
Initial implementation does not count. Increment before dispatching each
re-implementation, including attempts that fail or produce no changes.

Run both reviews and CI after each new commit, including the third attempt.
If that final pass is clean and green, proceed to the merge gate; otherwise
escalate. Never dispatch a fourth re-implementation.

Time/spending limits, worker failure or no progress may stop the loop earlier.
Head/base changes do not reset the counter. Only an explicit maintainer resume
resets the budget.

Auto-merge policy

Both reviewers must independently agree on change class and cite diff/test
evidence. A fix: or feat: title alone never establishes safety.

Class	Auto-merge condition
Patch / bounded fix	Reproduced defect; failing regression test before the fix and passing afterward; restores intended behavior without refactoring or unrelated changes
Minor / additive feature	New capability only; existing behavior, defaults, public contracts and side effects unchanged; existing-behavior guards and new-feature tests pass
Refactor, mixed, breaking or uncertain	Human decision, even with green CI and no correctness findings

Additive registration/wiring in existing files is allowed. A fix may change only
the demonstrated defective behavior; abstraction changes and cleanup are refactoring.

Require all of:

• Both reports are complete, clean and explicitly merge-eligible for this revision.
  Safety is an evidence-backed judgment, not a proof of non-regression.
• Existing-behavior guards remain intact; changed assertions are justified by
  the demonstrated defect. No weakened, skipped or deleted tests to obtain green CI.
• No automation/instruction/security-policy, dependency-manifest, migration,
  authentication/authorization or release-configuration changes. Those require
  human review regardless of the proposed release size.
• PR is open, non-draft, conflict-free, targets main, has no unresolved review
  threads/blocking reviews, and satisfies repository-required approvals and checks.
  A maintainer hold or global kill switch always wins.
• Revalidated head/base and a validated final squash message: fix: for a patch,
  feat: for an additive minor, with no breaking-change markers. Classify the full
  diff, not the last fix-up commit; review-fix commits remain chore:.

Merge through GitHub's API with an App token and expected head SHA. Require strict
up-to-date branch checks; never bypass rules. Concurrent head/base changes require
fresh CI/reviews. Do not leave standing --auto requests for future unreviewed heads.

gh-aw's experimental merge output refuses default-branch merges; use the coordinator.
If rules require a merge queue, first add merge_group CI and revision-bound gates;
the current Test workflow lacks that trigger.

Semantic-release publishes alpha from main, stable from release.
Auto-merge does not authorize stable promotion. Check the final squash message and
pending release history against trusted release rules; major/unknown results need
review. Keep publication in Release; failures pause auto-merge.

State and trust boundaries

Persist per-PR {generation, head_sha, base_sha, reimplementation_attempts, phase, expected_run_ids, artifact_ids, deadline, budget} in App-owned state.
Serialize transitions and reconcile periodically.

Route issue/PR events, worker/CI completion, review/hold changes and main updates;
dispatch workers explicitly from the default branch.

Use custom report-review safe outputs, not prose parsing or GitHub review counts.
Reports contain {schema_version, status, findings, change_class, release_intent, merge_eligible, evidence}. The trusted publisher stamps engine, revision, generation
and run/attempt identifiers. Validate expected workflow/ref/actor/run and artifact
identity, strict schemas and size limits. Missing, stale, malformed or blocked
reports never count as clean.

The event router is metadata-only; never execute PR code in pull_request_target.
Treat external content/reports as untrusted. Sandbox agents/tests without write
credentials; writers use safe outputs with path allowlists protecting policy files.
Only the coordinator merges. Use App-originated writes to trigger CI/releases.

For unwritable forks, create a linked same-repository remediation PR and converge
it. Never transfer its clean status to the original or automatically close it.

Rollout

Configure Copilot inference, ANTHROPIC_API_KEY, a least-privilege App, budgets,
a kill switch, and strict required checks without App bypass.

Validate fitness decisions, duplicate/stale events, invalid reports, reviewer
disagreement, absent/failing CI, forks, the three-attempt limit and merge races.
Prove that a clean third attempt can merge and a fourth attempt cannot start.
Require compile-drift checks and an end-to-end trial before activation.

Recheck earlier blockers: baseline test-directory race, missing integration
Camunda service, and unconfirmed Claude/App credentials.

References

• gh-aw / latest non-prerelease / reviewed preview
• Custom reports
• PR writes, protected files and merge limitations
• GitHub merge API
• Renovate GitHub releases datasource

No repository file or test path is named. Start by inventorying the existing gh-aw workflows, Renovate configuration, and Test workflow, then review the listed baseline blockers and credential requirements. Done means the design is validated against the stated event, review, CI, trust-boundary, dependency, rollout, and three-attempt scenarios without deploying workflows or changing repository settings.