pdurlej/platform

Fork 0

feat(agents): Antigravity/Gemini scheduled PR factory for platform issues #57

New issue

Closed

opened 2026-05-04 18:04:38 +02:00 by Iskra · 1 comment

Iskra commented

2026-05-04 18:04:38 +02:00

Collaborator

Context

Piotr proposed using Gemini / Antigravity as an aggressive background issue worker:

sprawdzaj co 2h i rób PR-y

The attractive idea: use a strong Google/Gemini coding agent to continuously inspect our Forgejo issue backlog and open small PRs autonomously.

Goal

Design a safe Antigravity/Gemini PR factory for platform issues.

This should help burn down boring/clear issues without consuming Piotr's attention, but must not create unbounded PR spam or bypass platform governance.

Desired behavior

Every ~2h:

Scan eligible open issues.
Select a small bounded task.
Create isolated worktree/branch.
Implement only within issue scope.
Run required local checks/canary/smoke where applicable.
Open a PR with evidence, risk, and review instructions.
Stop after a strict PR budget.

Eligibility rules

Only work issues that are:

labeled/marked as agent-safe or default-path;
small or medium scope;
not requiring owner decision;
not touching secrets/admin/auth unless explicitly allowed;
not modifying production/deploy semantics without stronger review;
not already assigned/in progress by another agent.

Hard guardrails

No direct merge.
No admin MCP by default.
Use actor-specific Forgejo identity, not pdurlej.
Max PRs per run, e.g. 1.
Max open PRs from Antigravity at once, e.g. 3.
No chained autonomous escalation.
No touching secrets, tokens, infra credentials, production deploys unless issue explicitly allows it.
Must include evidence: tests, diff summary, files changed, risk class, remaining uncertainty.
Must respect ADR 0001/0002 review/canary rules.

Scheduling shape

Suggested cron/checkpoint:

every 2h during an allowed window;
skip if open Antigravity PR budget is full;
skip if platform has unresolved higher-priority owner decision;
report only when PR created or blocked by systemic issue.

Candidate first slice

Dry-run mode:

inspect open issues;
rank top 5 eligible candidates;
explain why selected/skipped;
do not write code;
produce a planning comment or local report.

Then production mode:

one small issue → one branch → one PR.

Acceptance criteria

Antigravity/Gemini CLI/API route is identified.
Actor identity is configured separately from Piotr/admin.
Dry-run candidate selector works on real platform issues.
PR budget/lock prevents PR spam.
First generated PR is small, reviewable, and evidence-backed.
Cron/scheduler entry is visible in inventory.
Failure modes are documented.

Success test

After 48h, the system should produce a small number of useful PRs, not a pile of ambiguous work that increases Piotr's review burden.

#56 — split Forgejo MCP identity per agent and disable admin MCP by default
ADR 0001 / ADR 0002 — canary/review governance
Owner Action Board / strategic stop cadence

## Context Piotr proposed using Gemini / Antigravity as an aggressive background issue worker: > sprawdzaj co 2h i rób PR-y The attractive idea: use a strong Google/Gemini coding agent to continuously inspect our Forgejo issue backlog and open small PRs autonomously. ## Goal Design a safe **Antigravity/Gemini PR factory** for platform issues. This should help burn down boring/clear issues without consuming Piotr's attention, but must not create unbounded PR spam or bypass platform governance. ## Desired behavior Every ~2h: 1. Scan eligible open issues. 2. Select a small bounded task. 3. Create isolated worktree/branch. 4. Implement only within issue scope. 5. Run required local checks/canary/smoke where applicable. 6. Open a PR with evidence, risk, and review instructions. 7. Stop after a strict PR budget. ## Eligibility rules Only work issues that are: - labeled/marked as agent-safe or default-path; - small or medium scope; - not requiring owner decision; - not touching secrets/admin/auth unless explicitly allowed; - not modifying production/deploy semantics without stronger review; - not already assigned/in progress by another agent. ## Hard guardrails - No direct merge. - No admin MCP by default. - Use actor-specific Forgejo identity, not `pdurlej`. - Max PRs per run, e.g. 1. - Max open PRs from Antigravity at once, e.g. 3. - No chained autonomous escalation. - No touching secrets, tokens, infra credentials, production deploys unless issue explicitly allows it. - Must include evidence: tests, diff summary, files changed, risk class, remaining uncertainty. - Must respect ADR 0001/0002 review/canary rules. ## Scheduling shape Suggested cron/checkpoint: - every 2h during an allowed window; - skip if open Antigravity PR budget is full; - skip if platform has unresolved higher-priority owner decision; - report only when PR created or blocked by systemic issue. ## Candidate first slice Dry-run mode: - inspect open issues; - rank top 5 eligible candidates; - explain why selected/skipped; - do not write code; - produce a planning comment or local report. Then production mode: - one small issue → one branch → one PR. ## Acceptance criteria - Antigravity/Gemini CLI/API route is identified. - Actor identity is configured separately from Piotr/admin. - Dry-run candidate selector works on real platform issues. - PR budget/lock prevents PR spam. - First generated PR is small, reviewable, and evidence-backed. - Cron/scheduler entry is visible in inventory. - Failure modes are documented. ## Success test After 48h, the system should produce a small number of useful PRs, not a pile of ambiguous work that increases Piotr's review burden. ## Related - #56 — split Forgejo MCP identity per agent and disable admin MCP by default - ADR 0001 / ADR 0002 — canary/review governance - Owner Action Board / strategic stop cadence

claude referenced this issue from a commit

2026-05-05 00:03:49 +02:00

docs(repo): swarm-fundament — onboarding map + AGENTS amend + issue templates

claude referenced this issue

2026-05-05 00:04:36 +02:00

docs(repo): swarm-fundament — onboarding map + AGENTS amend + issue templates #58

claude referenced this issue

2026-05-05 00:22:46 +02:00

[meta] L4 materialization: decompose remaining work into atomic issues #59

pdurlej referenced this issue

2026-05-05 01:01:16 +02:00

chore(audit): L4.3 module manifests audit — count v1→v2 gap #60

glm referenced this issue

2026-05-05 01:02:46 +02:00

chore(audit): L4.3 module manifests audit — count v1→v2 gap #61

pdurlej referenced this issue

2026-05-05 02:08:26 +02:00

arch(governance): kontrakt + granica między pdurlej/platform a pdurlej/iskra-openclaw — co gdzie mieszka #74

claude commented

2026-05-06 00:24:17 +02:00

Collaborator

Operator decision: DROP (2026-05-06)

Operator-confirmed via chat 2026-05-06: dropping Antigravity/Gemini PR factory.

Rationale

Operator now uses Ollama Pro for weak-model experimentation:

ZAI did not deliver on large-context use cases
Ollama Pro allows running operator's own models locally
Antigravity/Gemini scheduled PR factory adds external dependency without clear advantage

What this means

No Antigravity identity in canary 3+3 ensemble (stays at 4-voice tech-claude/tech-codex × product-claude/product-codex; 3+3 with GLM remains the canonical setup until separate decision)
Future weak-model experimentation routes through Ollama Pro (operator-managed)
If a "scheduled PR factory" pattern is ever wanted, it would be a fresh design — likely Ollama-Pro-based, with different security model

Action

Closing issue. If operator changes mind later, open a new issue (do not re-open this one).

## Operator decision: DROP (2026-05-06) Operator-confirmed via chat 2026-05-06: dropping Antigravity/Gemini PR factory. ### Rationale Operator now uses **Ollama Pro** for weak-model experimentation: - ZAI did not deliver on large-context use cases - Ollama Pro allows running operator's own models locally - Antigravity/Gemini scheduled PR factory adds external dependency without clear advantage ### What this means - No Antigravity identity in canary 3+3 ensemble (stays at 4-voice tech-claude/tech-codex × product-claude/product-codex; 3+3 with GLM remains the canonical setup until separate decision) - Future weak-model experimentation routes through Ollama Pro (operator-managed) - If a "scheduled PR factory" pattern is ever wanted, it would be a fresh design — likely Ollama-Pro-based, with different security model ### Action Closing issue. If operator changes mind later, open a new issue (do not re-open this one).

claude closed this issue

2026-05-06 00:24:18 +02:00