EduarD3V/gotoi

Watch

Fork 0

Agent flow: integrate on agent-develop, one promotion PR, and a decision protocol #33

Merged

EduarD3V merged 10 commits from chore/integration-branch into agent-develop

2026-10-06 21:39:57 +02:00

EduarD3V commented

2026-10-06 17:33:21 +02:00

Owner

Makes the operator's click land on one clean batch instead of one rebase per issue.

What changes

agent-develop becomes the branch agent work integrates on; issue PRs target it, and develop receives exactly one promotion PR. The run still never merges: scripts/agent-pipeline/integrate.py does the merging into agent-develop as a separate scheduled job, so the session that wrote the code cannot land it.
The integrator: sync (by PR - a protected branch refuses direct pushes), retarget issue PRs still aimed at develop, merge each PR whose trial merge is clean and whose required checks are green, then open/keep one promotion PR. 15 self-checks, dry-run by default.
A decision protocol so an operator answer actually reaches a run: forgejo.py label add|rm, the needs_attention label as a triage skip (unless the operator has answered since), and DECISION: comments as the only authoritative answer.
The documented flow, audited: docs/agent-pipeline/integration-branch.md, flow-canvas.html, and the corrections the audit found (the ~/.claude manual still claimed the runner merges into develop automatically; verifier.md said shadow where the state is off; the contract pointed at a path that does not exist).

Verified: 569 header gates ok, UC catalogue conforms, integrate.py 15/15, a real merge of PR #31 into agent-develop by the bot with read-back, and PR #32 (the promotion batch) opened from it. Refs #26, #27, #28.

Makes the operator's click land on one clean batch instead of one rebase per issue. **What changes** - `agent-develop` becomes the branch agent work integrates on; issue PRs target it, and `develop` receives exactly one promotion PR. The run still never merges: `scripts/agent-pipeline/integrate.py` does the merging into `agent-develop` as a separate scheduled job, so the session that wrote the code cannot land it. - The integrator: sync (by PR - a protected branch refuses direct pushes), retarget issue PRs still aimed at `develop`, merge each PR whose trial merge is clean and whose required checks are green, then open/keep one promotion PR. 15 self-checks, dry-run by default. - A decision protocol so an operator answer actually reaches a run: `forgejo.py label add|rm`, the `needs_attention` label as a triage skip (unless the operator has answered since), and `DECISION:` comments as the only authoritative answer. - The documented flow, audited: `docs/agent-pipeline/integration-branch.md`, `flow-canvas.html`, and the corrections the audit found (the `~/.claude` manual still claimed the runner merges into develop automatically; verifier.md said shadow where the state is off; the contract pointed at a path that does not exist). **Verified**: 569 header gates ok, UC catalogue conforms, integrate.py 15/15, a real merge of PR #31 into `agent-develop` by the bot with read-back, and PR #32 (the promotion batch) opened from it. Refs #26, #27, #28.

EduarD3V added 8 commits

2026-10-06 17:33:22 +02:00

feat: an integration branch the agent may merge into, so develop stays manual dc89049354

Agents' branches target agent-develop; the bot is allowlisted to merge there and absent
from develop's whitelist, so the forge refuses the same actor one branch over. No closing
keyword: Refs #25, #26, #27, #28.

fix: read-back compares lists order-insensitively; add a drift check a966ff7072

The server returns merge_whitelist_usernames reordered, so the positional comparison
reported a false READ-BACK MISMATCH on the first apply and told the operator to roll back
a rule that was already correct. Refs #28.

docs: update the flow docs, and document the integration branch dc010d0437

Verified every copy against the live pipeline. agent-develop was documented nowhere;
the ~/.claude copy of the issue-flow manual still claimed the runner merges into develop
automatically (removed from the repo copy on 2026-10-05) and is now re-synced; verifier.md
said shadow mode where the measured state is off; triage.md's auto-merge tier line had a
tier it could now name; the contract had no mention of the hidden test set.

Adds docs/agent-pipeline/integration-branch.md and a self-contained flow-canvas.html.
Refs #26, #28.

docs: fix the two path/version errors the audit found 56ec2f74e1

The contract's index pointed at .claude/skills/gotoi-coding-agent/, which does not exist:
the law lives in the Hermes profile. The canonical skill still named Forgejo 15.0.9 in two
places (the instance reports 16.0.5+gitea-1.22.0). Refs #26, #28.

feat: a decision protocol, so an operator answer actually reaches the run 0d9ef41117

An agent that stops on NEEDS-DECISION had no way to be answered: nothing in the law read
the thread, and the helper could not set a label at all. Adds forgejo.py label add|rm
(one label, never a wholesale set — that would drop ai-assist and unqueue the issue), the
needs_attention label as the triage skip, and the DECISION: protocol in the contract and
the omp manual. Only an operator-authored comment counts as a decision. Refs #26.

fix: an issue with needs_attention and an answer is eligible, not skipped c27082325b

The skip rule as first written deadlocked every decision: triage skipped any issue carrying
the label, so the run could never pick one up to read the DECISION: comment, and so would
never clear the label. The label now means exactly 'waiting on the operator': a DECISION:
comment newer than the agent's own last comment on that thread unblocks the issue. Refs #26.

feat: an integrator, so agent work reaches agent-develop without the operator d2e00daf61

Sync, retarget, merge, promote. The bot merges each issue PR into agent-develop once its trial
merge is clean and its required checks are green, and one promotion PR carries the batch to
develop. Two things the first live run taught, both now fixed: a protected branch refuses
direct pushes (pre-receive hook declined), so the sync is a PR too; and the promote step read
stale refs after a server-side merge, so every step re-fetches. --quiet exists for a scheduler.
Refs #26.

feat: agent work integrates on agent-develop, and one promotion PR carries the batch

agent-guards / test-tampering (pull_request) Successful in 32s

Details

CI and agent release / check-docs (pull_request) Successful in 26s

Details

CI and agent release / test-agent (pull_request) Successful in 1m32s

Details

CI and agent release / test-dashboard (pull_request) Successful in 2m37s

Details

CI and agent release / test-middleware (pull_request) Successful in 8m21s

Details

CI and agent release / build (pull_request) Has been skipped

Details

CI and agent release / release (pull_request) Has been skipped

Details

CI and agent release / publish-images (pull_request) Has been skipped

Details

4ea617f2e8

With more than one issue in flight, PRs to develop make the operator rebase each one and let two
issues collide on the shipping branch. Issue PRs now target agent-develop, the integrator merges
them there once their trial merge is clean and their checks are green, and a single promotion PR
carries the batch to develop. The run still never merges anything: the merging is the integrator's
separate job, so the session that wrote the code cannot land it. Refs #26.

EduarD3V added 1 commit

2026-10-06 21:38:41 +02:00

Merge branch 'develop' into chore/integration-branch

CI and agent release / check-docs (pull_request) Successful in 25s

Details

agent-guards / test-tampering (pull_request) Successful in 35s

Details

CI and agent release / test-agent (pull_request) Successful in 1m36s

Details

CI and agent release / test-dashboard (pull_request) Successful in 2m33s

Details

CI and agent release / build (pull_request) Has been cancelled