项目文件夹

文件
Asim Aslam 666fc4b794 ci+docs: name the loop workflows by role (planner/generator/evaluator) (#3556)
Rename the autonomous-loop workflows so the Actions list maps to the
long-running-agent harness pattern (planner → generator → evaluator):
  architecture-review.yml   -> loop-architect.yml   "Loop: Architect (Planner)"
  continuous-improvement.yml -> loop-builder.yml     "Loop: Builder (Generator)"
  devrel-review.yml          -> loop-devrel.yml      "Loop: DevRel"
  harness-triage.yml         -> loop-triage.yml      "Loop: Triage (Evaluator feedback)"
harness.yml stays the shared Evaluator/CI gate (triage still matches it by the
"Harness (E2E)" name). Document the pipeline + role mapping in
CONTINUOUS_IMPROVEMENT.md, and point to it from CONTRIBUTING so the development
process is discoverable. No behavior change — schedules, gates, and required
checks are unaffected.

Co-authored-by: Claude <noreply@anthropic.com>
2026-07-01 15:59:46 +01:00

66 行
4.6 KiB
YAML

name: "Loop: Builder (Generator)"
# Durable backbone for the autonomous improvement loop
# (see internal/docs/CONTINUOUS_IMPROVEMENT.md).
#
# A Claude Max subscription provides no API key for CI, so the loop is driven by
# Codex rather than Claude Code: on a cadence this opens a fresh tracking issue and
# posts an @codex instruction on it, and Codex runs one improvement increment, opens
# a PR (git push + gh pr create — the make_pr tool is a no-op stub), and enables
# GitHub auto-merge (gh pr merge --auto) so the PR lands once the required CI checks
# pass. No separate merge sweep — branch protection + native auto-merge is the gate.
# (See the per-issue rationale below.)
#
# Codex does NOT respond to comments authored by the github-actions bot, so the
# dispatch is GATED on a CODEX_TRIGGER_TOKEN secret (a PAT for a user account Codex
# follows). Until that secret is set the workflow runs but no-ops — this avoids
# piling up @codex comments that Codex silently ignores. The moment the secret is
# added the loop activates with no further change.
#
# Each run opens a FRESH issue and dispatches Codex there, rather than re-commenting
# on one tracker issue. Codex derives its PR branch name from the triggering issue's
# context, so repeated dispatches on a single issue all collapse onto one branch name
# (codex/github-mention-<that-issue-slug>) — the first increment opens a PR, the rest
# collide on the occupied branch and silently fail to open one. A unique issue per
# run gives each increment its own branch and a clean PR. The dispatch asks Codex to
# "Closes #<issue>" so each tracking issue auto-closes when its PR merges.
on:
workflow_dispatch: {}
schedule:
- cron: "29 * * * *" # hourly, off-minute (tune as needed)
permissions:
issues: write
concurrency:
group: continuous-improvement
cancel-in-progress: false
jobs:
dispatch:
runs-on: ubuntu-latest
steps:
- name: Open a fresh increment issue and dispatch Codex
env:
GH_TOKEN: ${{ secrets.CODEX_TRIGGER_TOKEN || github.token }}
HAS_TRIGGER_TOKEN: ${{ secrets.CODEX_TRIGGER_TOKEN != '' }}
REPO: ${{ github.repository }}
RUN_NUMBER: ${{ github.run_number }}
run: |
if [ "$HAS_TRIGGER_TOKEN" != "true" ]; then
echo "CODEX_TRIGGER_TOKEN is not set — skipping dispatch."
echo "Codex ignores comments from the github-actions bot, so posting now"
echo "would only create noise. Add a CODEX_TRIGGER_TOKEN secret (a PAT for"
echo "a user account Codex follows) to activate the loop."
exit 0
fi
# A unique issue per run → unique codex/ branch → no collisions.
ISSUE_URL=$(gh issue create --repo "$REPO" \
--title "Continuous improvement increment #$RUN_NUMBER" \
--body "Autonomous continuous-improvement increment. North Star: internal/docs/THESIS.md; charter: internal/docs/CONTINUOUS_IMPROVEMENT.md. Tracker: #3024.")
ISSUE_NUM="${ISSUE_URL##*/}"
echo "Opened issue #$ISSUE_NUM — dispatching Codex."
gh issue comment "$ISSUE_NUM" --repo "$REPO" --body \
"@codex Run one continuous-improvement increment per internal/docs/CONTINUOUS_IMPROVEMENT.md, aligned to the North Star in internal/docs/THESIS.md (the holistic services → agents → workflows lifecycle). PICK THE WORK FROM THE QUEUE: read internal/docs/PRIORITIES.md and take the highest-ranked item whose linked issue is still OPEN — that is your task, and its issue number is the one you close. (If PRIORITIES.md is missing or every listed item's issue is already closed, fall back to picking the single highest-value roadmap/issue/improvement-radar item yourself.) Implement it, and verify \`go build ./...\`, \`go test ./...\`, and \`golangci-lint run ./...\`. Then open the PR YOURSELF from the shell — do NOT use the make_pr tool (in this environment it only records metadata and never creates a PR). Create a uniquely-named branch under the codex/ prefix and open the PR from it: \`git switch -c codex/increment-$ISSUE_NUM\`, then \`git push -u origin codex/increment-$ISSUE_NUM\`, then \`gh pr create --base master --label codex --title \"<title>\" --body \"<body; include 'Closes #<the priority issue you built>' so it leaves the queue, and 'Closes #$ISSUE_NUM' for this run's tracker>\"\`. Finally enable auto-merge so GitHub merges it once CI is green: \`gh pr merge --squash --auto --delete-branch\`. The gh CLI is installed and authenticated and origin points to $REPO. One concern per PR; stay out of brand/positioning copy and breaking public API."