Harness (E2E) / Harnesses (mock LLM) (push) Has been cancelled
Harness (E2E) / Provider harnesses (live LLM conformance) (push) Has been cancelled
Lint / golangci-lint (push) Has been cancelled
govulncheck / govulncheck (push) Has been cancelled
Run Tests / Etcd Integration Tests (push) Has been cancelled
Comment out the automatic triggers on every loop workflow so the
autonomous engine stops firing on its own while we land the current
round of fixes 1:1:
- planner / builder / coherence / security / release: drop the cron
schedules (no more hourly/daily/weekly runs, no nightly auto-release).
- triage: drop the workflow_run trigger so CI failures no longer
auto-dispatch agent tasks.
Each keeps workflow_dispatch, so any loop can still be run on demand,
and re-enabling is just uncommenting the trigger. No prompts, tokens, or
logic changed — only when the workflows fire.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL
The last-100-commit assessment found the loop producing busy-work — but the root
cause was the roadmap: every forward item was hardening/conformance/docs-polish,
no net-new capability. The loop was faithfully executing a maintenance backlog.
Restock the roadmap with real capability bets and demote maintenance to explicit
background:
- Now: agents that pay (wire the existing x402 buyer into the agent runtime);
AP2 mandate foundation over A2A+x402 (#3552).
- Next: gRPC-reflection MCP; Kubernetes operator + CRDs.
- Later: the runtime-fitness loop (live Mu + operator/canary); HTTP/3; A2A
reconnection; memory/RAG.
- Ongoing: hardening/conformance/DX, capped so it never crowds out capability.
Repoint .github/loop/PRIORITIES.md to rank the capability bets at the top, with
the flagship decomposed into buildable issues (#4786 buyer wiring, #4787 spend
observability, #4788 example), so the loop pulls real work instead of grooming
itself.
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL
Co-authored-by: Claude <noreply@anthropic.com>
An assessment of the last 100 commits found ~45% were pure "refresh planner
priorities" bookkeeping and much of the rest was thrashing on one weak provider
(AtlasCloud text-tool-call repair) and guarding docs the loop already wrote —
motion, not progress. Two prompt-policy fixes:
PLANNER (planner.md):
- Default to NOT committing. Post the assessment and close the issue; open a
PRIORITIES.md PR ONLY when the change is MATERIAL (top item changes, an item
is added/removed, or a top item's issue closed). No PRs for reorders below
the top, reword, or "keep it current" — that churn was the loop's #1 waste.
- Add a diminishing-returns guard: don't queue the Nth doc-guard or the Nth
robustness workaround for an already-tolerated class; mark exhausted areas
needs-human and rank real-headroom capability instead.
TRIAGE (triage.md):
- Cap the AtlasCloud/plan-delegate tail-chase: another instance of a class the
agent already tolerates is NOT filed as a routine patch — comment "recurred —
capped" and, if worth more, needs-human. Real regressions (lint/tests/
govulncheck on master) and genuinely new defects still get filed.
Prompt-only; reversible. Steers the loop toward outcomes over busy-work.
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL
Co-authored-by: Claude <noreply@anthropic.com>
Adds a deterministic reachable-CVE gate: `govulncheck ./...` on every push/PR,
failing on any reachable vulnerability EXCEPT an explicit allow-list of
known-unfixable ones. Today the allow-list holds exactly the two pgx/v4 CVEs
(GO-2026-5004, GO-2026-4518) with no upstream fix (tracked in #4556), so the
gate is green now and turns red the moment a NEW vulnerability appears.
This is the deterministic layer under the `security` loop role: the role
audits with judgment, this blocks known CVEs mechanically. Also adds
`govulncheck` to the loop-triage watch list, so a newly-disclosed CVE that
reddens the gate on master auto-files a fix issue for the loop to bump the dep.
Make `govulncheck` a required status check on master to enforce it.
Verified locally: exit 3 with only the two allow-listed IDs -> gate PASS.
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL
Co-authored-by: Claude <noreply@anthropic.com>
govulncheck reported 30 reachable vulnerabilities. Remediation:
- Pin `toolchain go1.25.12` and build CI on Go 1.25 (lint/tests workflows):
clears ~24 Go standard-library CVEs (crypto/tls, crypto/x509, net/http,
html/template, net/url, os, …) that were present under go1.24.7.
- Bump `golang.org/x/net` v0.38.0 -> v0.55.0 and `google.golang.org/grpc`
v1.71.1 -> v1.79.3 (grpc raises the module's Go directive to 1.25).
Result: govulncheck drops from 30 -> 2. The remaining two
(github.com/jackc/pgx/v4, github.com/jackc/pgproto3/v2) have no upstream fix
and require a pgx v5 migration — tracked separately; the govulncheck gate will
follow with those explicitly allow-listed until migrated.
Note: this raises go-micro's minimum Go to 1.25 (forced by the grpc security
bump). Verified: build, go vet, and the ai/agent/flow/store/registry/broker/
wrapper/cmd + grpc/net-dependent packages pass on 1.25.12.
Claude-Session: https://claude.ai/code/session_01CmdEY7pYmV5zzwCjNJ4ykL
Co-authored-by: Claude <noreply@anthropic.com>
Claude