pdurlej/platform

Fork 0

Establish Forgejo branding and global agentic development defaults #94

New issue

Closed

opened 2026-05-06 00:13:45 +02:00 by pdurlej · 2 comments

pdurlej commented

2026-05-06 00:13:45 +02:00

Owner

Context

This Forgejo instance is becoming the home workspace for human + agent development. The current setup still reads like a default Forgejo install in a few places, and agents perform better when the UI, repository defaults, and workflow rules are explicit and English-first.

Branding direction

Recommended positioning: this is not just a Git server, it is an agentic software workbench.

Candidate instance branding:

Instance name: Pdurlej Forge
Slogan: Agentic software workbench
Alternative names to consider: Agentic Forge, Pdurlej Code, Iskra Forge

Suggested app.ini direction:

[DEFAULT]
APP_NAME = Pdurlej Forge
APP_SLOGAN = Agentic software workbench
APP_DISPLAY_NAME_FORMAT = {APP_NAME}: {APP_SLOGAN}

Optional image/logo prompt for later generation:

Create a clean dark-mode brand mark for “Pdurlej Forge”: a precise software forge/workbench where human product thinking and AI agents collaborate. Visual language: sharp but warm, high-signal, systems thinking, small sparks of creation, subtle graph/network structure, no fantasy blacksmith cliches, no generic robot mascot. Should work as a square avatar/favicon and as a header mark.

Language policy

Set admin/human account and agent accounts (claude, codex, glm, Iskra) to English UI.
Keep Polish available only if useful for the operator, but default agent-facing work should be English because Forgejo/Git terminology, CI logs, and agent instructions are easier to parse in English.
If we decide to force English globally, use Forgejo i18n config after testing:

[i18n]
LANGS = en-US
NAMES = English

Runner policy

Current admin audit found two global rs2000-docker Actions runners: one idle, one offline.

An offline runner is a registered worker that Forgejo knows about, but that worker is not currently connected. It may be an old container/VM, a stopped service, or a duplicate registration. It can confuse CI debugging because jobs may appear to have capacity that is not really available.

Rules:

Keep at least one healthy global runner online for normal repos.
Remove stale offline runners if their underlying machine/container no longer exists.
If the runner should exist, restart/fix the runner service instead of deleting it.
Document runner labels: ubuntu-latest, ubuntu-22.04, docker.

Repository defaults

Recommended defaults for new serious repositories:

Pull Requests: on
Issues: on
Actions: on
Wiki: off unless needed
Packages: off unless needed
Projects: off unless needed
Default branch: main
Default merge style: prefer squash for small/agentic PRs
Delete branch after merge: enabled where safe
Branch protection on important repos: require PR + passing checks before merge

Every serious repo should include:

README.md with purpose and status
AGENTS.md with agent operating rules
PR template/checklist
minimal CI workflow
topics/description in English

Review bot direction

Short-term: do not invest in CodeRabbit for Forgejo directly unless we mirror selected repos to GitHub/GitLab. CodeRabbit does not appear to support Forgejo/Gitea as a first-class direct integration.

Better local direction:

Build a small Forgejo review-bot v0.
Trigger on PR open/update via Forgejo webhook or Actions.
Run deterministic checks first: install, lint, tests, typecheck, diff summary.
Add one cheap model sanity review through an Ollama-compatible or other low-cost model endpoint, with a strict rubric.
Post one concise comment on the PR: risks, failing checks, suggested next action.
Later add Oracle/Codex/GPT-5.5 Pro escalation only for high-risk PRs.

Important: the cheap model should not replace tests or human/operator judgment. It is a low-cost early warning layer.

Acceptance criteria

Instance branding is updated from the default Forgejo title/slogan.
Admin and agent accounts use English UI.
Offline runner is either removed or brought back online with documented ownership.
Repository defaults are documented as global development rules.
A repo template/checklist exists for new platform repos.
A small review-bot v0 design exists, including trigger, model endpoint, rubric, and failure behavior.
No secrets or provider tokens are stored in repositories.

## Context This Forgejo instance is becoming the home workspace for human + agent development. The current setup still reads like a default Forgejo install in a few places, and agents perform better when the UI, repository defaults, and workflow rules are explicit and English-first. ## Branding direction Recommended positioning: this is not just a Git server, it is an agentic software workbench. Candidate instance branding: - Instance name: `Pdurlej Forge` - Slogan: `Agentic software workbench` - Alternative names to consider: `Agentic Forge`, `Pdurlej Code`, `Iskra Forge` Suggested app.ini direction: ```ini [DEFAULT] APP_NAME = Pdurlej Forge APP_SLOGAN = Agentic software workbench APP_DISPLAY_NAME_FORMAT = {APP_NAME}: {APP_SLOGAN} ``` Optional image/logo prompt for later generation: > Create a clean dark-mode brand mark for “Pdurlej Forge”: a precise software forge/workbench where human product thinking and AI agents collaborate. Visual language: sharp but warm, high-signal, systems thinking, small sparks of creation, subtle graph/network structure, no fantasy blacksmith cliches, no generic robot mascot. Should work as a square avatar/favicon and as a header mark. ## Language policy - Set admin/human account and agent accounts (`claude`, `codex`, `glm`, `Iskra`) to English UI. - Keep Polish available only if useful for the operator, but default agent-facing work should be English because Forgejo/Git terminology, CI logs, and agent instructions are easier to parse in English. - If we decide to force English globally, use Forgejo i18n config after testing: ```ini [i18n] LANGS = en-US NAMES = English ``` ## Runner policy Current admin audit found two global `rs2000-docker` Actions runners: one idle, one offline. An offline runner is a registered worker that Forgejo knows about, but that worker is not currently connected. It may be an old container/VM, a stopped service, or a duplicate registration. It can confuse CI debugging because jobs may appear to have capacity that is not really available. Rules: - Keep at least one healthy global runner online for normal repos. - Remove stale offline runners if their underlying machine/container no longer exists. - If the runner should exist, restart/fix the runner service instead of deleting it. - Document runner labels: `ubuntu-latest`, `ubuntu-22.04`, `docker`. ## Repository defaults Recommended defaults for new serious repositories: - Pull Requests: on - Issues: on - Actions: on - Wiki: off unless needed - Packages: off unless needed - Projects: off unless needed - Default branch: `main` - Default merge style: prefer squash for small/agentic PRs - Delete branch after merge: enabled where safe - Branch protection on important repos: require PR + passing checks before merge Every serious repo should include: - `README.md` with purpose and status - `AGENTS.md` with agent operating rules - PR template/checklist - minimal CI workflow - topics/description in English ## Review bot direction Short-term: do not invest in CodeRabbit for Forgejo directly unless we mirror selected repos to GitHub/GitLab. CodeRabbit does not appear to support Forgejo/Gitea as a first-class direct integration. Better local direction: 1. Build a small Forgejo review-bot v0. 2. Trigger on PR open/update via Forgejo webhook or Actions. 3. Run deterministic checks first: install, lint, tests, typecheck, diff summary. 4. Add one cheap model sanity review through an Ollama-compatible or other low-cost model endpoint, with a strict rubric. 5. Post one concise comment on the PR: risks, failing checks, suggested next action. 6. Later add Oracle/Codex/GPT-5.5 Pro escalation only for high-risk PRs. Important: the cheap model should not replace tests or human/operator judgment. It is a low-cost early warning layer. ## Acceptance criteria - [ ] Instance branding is updated from the default Forgejo title/slogan. - [ ] Admin and agent accounts use English UI. - [ ] Offline runner is either removed or brought back online with documented ownership. - [ ] Repository defaults are documented as global development rules. - [ ] A repo template/checklist exists for new platform repos. - [ ] A small review-bot v0 design exists, including trigger, model endpoint, rubric, and failure behavior. - [ ] No secrets or provider tokens are stored in repositories.

pdurlej commented

2026-05-06 00:41:52 +02:00

Author

Owner

Research update: Forgejo review bot + Ollama

Recommendation after docs research + Oracle GPT-5.5 Pro review: start with a hybrid v0, not a full custom bot and not PR-Agent/Qodo as the default path.

Decision

v0: Forgejo Actions + deterministic checks + one small Ollama-backed advisory PR comment.

Run install/lint/test/typecheck/build where configured.
Generate diffstat, changed-file summary, failed-command summary.
If Ollama is configured and the diff is small enough, ask one cheap model for a short sanity review.
Post/update exactly one bot comment using a sentinel marker like .
Treat model output as advisory only; never block merges on it.

v1: Pilot PR-Agent/Qodo Merge against Forgejo/Gitea after v0 works.

PR-Agent has documented Gitea webhook support and Ollama config.
Use it manually first for /describe, /review, /ask.
Do not auto-enable noisy /improve comments.
Keep it only if signal/noise and ops burden are better than our v0 commenter.

v2: Risk-based escalation.

Small docs/config PR: deterministic checks only.
Small code PR: deterministic checks + cheap Ollama review.
Auth/security/infra/db migration/high-risk PR: cheap review + optional Oracle/GPT-5.5 Pro escalation.
Large diff: ask for decomposition or human summary; skip local model review.

Why not full custom bot first

A custom webhook bot gives maximum control, but it creates maintenance surface too early: auth, webhook validation, retries, comment updates, queueing, config, observability, model failures. Forgejo Actions already gives us the boring reliable execution layer, so v0 should be a workflow + small script, not a bot platform.

Why not CodeRabbit direct

CodeRabbit docs list GitHub, GitLab, Azure DevOps, Bitbucket Cloud/Data Center as supported platforms. I do not see first-class Forgejo/Gitea support. It may still be useful for GitHub mirrors, but not as the native path for this Forgejo instance.

Ollama strategy

Use Ollama as a bounded sanity layer, not a security reviewer.

Start with:

local/cloud coding model with enough context, e.g. Qwen coder class model;
low temperature, short output cap;
max 5 findings;
require file/hunk references;
skip model review on large diffs or when deterministic checks fail catastrophically.

Important: PR-Agent docs explicitly warn that local open-source models are often not production-grade for serious PR review, and Ollama context must be configured high enough for PR diffs. That means Ollama is good for cheap early warning, but not the final authority.

v0 acceptance criteria

Workflow runs on PR opened/synchronize/reopened.
Missing scripts are reported as not configured, not silent success.
Bot posts or updates one comment only.
Comment separates deterministic failures from AI observations.
No secrets are committed or printed in logs.
Bot token has minimal permissions.
Model review is skipped when Ollama is unavailable, diff is too large, or skip-ai-review label is present.
At least one healthy Forgejo runner is online before rollout.
Tested on 3 PRs: passing PR, failing-check PR, small intentional bug PR.

Sources

Forgejo webhooks: https://forgejo.org/docs/latest/user/webhooks/
PR-Agent Gitea install: https://docs.pr-agent.ai/installation/gitea/
PR-Agent model/Ollama config: https://docs.pr-agent.ai/usage-guide/changing_a_model/
Qodo code review docs: https://docs.qodo.ai/code-review
CodeRabbit supported platforms: https://docs.coderabbit.ai/platforms/overview
Ollama OpenAI-compatible API: https://docs.ollama.com/api/openai-compatibility
Ollama cloud/pricing: https://ollama.com/turbo

## Research update: Forgejo review bot + Ollama Recommendation after docs research + Oracle GPT-5.5 Pro review: **start with a hybrid v0**, not a full custom bot and not PR-Agent/Qodo as the default path. ### Decision **v0:** Forgejo Actions + deterministic checks + one small Ollama-backed advisory PR comment. - Run install/lint/test/typecheck/build where configured. - Generate diffstat, changed-file summary, failed-command summary. - If Ollama is configured and the diff is small enough, ask one cheap model for a short sanity review. - Post/update exactly one bot comment using a sentinel marker like ``. - Treat model output as advisory only; never block merges on it. **v1:** Pilot PR-Agent/Qodo Merge against Forgejo/Gitea after v0 works. - PR-Agent has documented Gitea webhook support and Ollama config. - Use it manually first for `/describe`, `/review`, `/ask`. - Do not auto-enable noisy `/improve` comments. - Keep it only if signal/noise and ops burden are better than our v0 commenter. **v2:** Risk-based escalation. - Small docs/config PR: deterministic checks only. - Small code PR: deterministic checks + cheap Ollama review. - Auth/security/infra/db migration/high-risk PR: cheap review + optional Oracle/GPT-5.5 Pro escalation. - Large diff: ask for decomposition or human summary; skip local model review. ### Why not full custom bot first A custom webhook bot gives maximum control, but it creates maintenance surface too early: auth, webhook validation, retries, comment updates, queueing, config, observability, model failures. Forgejo Actions already gives us the boring reliable execution layer, so v0 should be a workflow + small script, not a bot platform. ### Why not CodeRabbit direct CodeRabbit docs list GitHub, GitLab, Azure DevOps, Bitbucket Cloud/Data Center as supported platforms. I do not see first-class Forgejo/Gitea support. It may still be useful for GitHub mirrors, but not as the native path for this Forgejo instance. ### Ollama strategy Use Ollama as a bounded sanity layer, not a security reviewer. Start with: - local/cloud coding model with enough context, e.g. Qwen coder class model; - low temperature, short output cap; - max 5 findings; - require file/hunk references; - skip model review on large diffs or when deterministic checks fail catastrophically. Important: PR-Agent docs explicitly warn that local open-source models are often not production-grade for serious PR review, and Ollama context must be configured high enough for PR diffs. That means Ollama is good for cheap early warning, but not the final authority. ### v0 acceptance criteria - [ ] Workflow runs on PR opened/synchronize/reopened. - [ ] Missing scripts are reported as `not configured`, not silent success. - [ ] Bot posts or updates one comment only. - [ ] Comment separates deterministic failures from AI observations. - [ ] No secrets are committed or printed in logs. - [ ] Bot token has minimal permissions. - [ ] Model review is skipped when Ollama is unavailable, diff is too large, or `skip-ai-review` label is present. - [ ] At least one healthy Forgejo runner is online before rollout. - [ ] Tested on 3 PRs: passing PR, failing-check PR, small intentional bug PR. ### Sources - Forgejo webhooks: https://forgejo.org/docs/latest/user/webhooks/ - PR-Agent Gitea install: https://docs.pr-agent.ai/installation/gitea/ - PR-Agent model/Ollama config: https://docs.pr-agent.ai/usage-guide/changing_a_model/ - Qodo code review docs: https://docs.qodo.ai/code-review - CodeRabbit supported platforms: https://docs.coderabbit.ai/platforms/overview - Ollama OpenAI-compatible API: https://docs.ollama.com/api/openai-compatibility - Ollama cloud/pricing: https://ollama.com/turbo

pdurlej commented

2026-05-06 01:02:19 +02:00

Author

Owner

v0 implementation plan: Forgejo PR sanity review with Ollama Cloud

Chosen default model: qwen3-coder:480b-cloud.

Why this model:

It is the strongest Ollama cloud coding model available for this job.
Ollama lists it as a coding/agentic model with a 256K context window.
It is a better fit than gpt-oss:120b-cloud for PR review because this task is code-specific, not general reasoning.
v0 will keep usage bounded by reviewing only small/medium diffs and posting one concise advisory comment.

Fallback/cost-saver model for later: qwen3-coder-next:cloud, especially if 480b-cloud is too slow or burns too much quota.

Architecture

Add a small Forgejo-native review layer, not a full bot platform yet.

Files:

.forgejo/workflows/pr-sanity.yml
tools/pr-sanity/review-pr.mjs
tools/pr-sanity/forgejo-api.mjs
tools/pr-sanity/ollama-review.mjs
tools/pr-sanity/render-comment.mjs
docs/pr-review-bot.md

Flow:

Trigger on PR opened, synchronize, and reopened.
Checkout the PR.
Run deterministic checks first:
- install
- lint
- test
- typecheck
- build
Detect missing scripts and report them as not configured, not as silent success.
Build a bounded review bundle:
- PR title/body
- changed file list
- diffstat
- capped unified diff
- deterministic check summary
- relevant repo instructions if present: AGENTS.md, PR template, package metadata
If model review is allowed, call Ollama Cloud.
Post or update exactly one PR comment using a sentinel:

<!-- forgejo-pr-sanity-review -->

Secret handling

The provider key already lives in Infisical at:

project path: /home-platform/providers
environment: production
secret: OLLAMA_CLOUD_API_KEY

Do not duplicate the Ollama key into git.

Preferred runner setup:

Store only an Infisical service token / machine identity token in Forgejo Actions secrets, e.g. INFISICAL_TOKEN.
Fetch the provider key at runtime:

infisical run   --env=prod   --path=/home-platform/providers   --token "$INFISICAL_TOKEN"   -- node tools/pr-sanity/review-pr.mjs

The script should read OLLAMA_CLOUD_API_KEY and send it as:

Authorization: Bearer $OLLAMA_CLOUD_API_KEY

to:

https://ollama.com/api/chat

Ollama call

Use native Ollama Cloud API, not local localhost:11434 for v0.

Request shape:

{
  "model": "qwen3-coder:480b-cloud",
  "stream": false,
  "messages": [
    { "role": "system", "content": "You are a concise PR sanity reviewer..." },
    { "role": "user", "content": "<bounded review bundle>" }
  ]
}

Prompt rules:

advisory only;
max 5 findings;
every finding must cite changed file and hunk/context;
no style nits;
no merge approval/rejection;
say No high-signal model finding when unsure;
deterministic failures outrank AI observations.

Guardrails

Skip model review when:

skip-ai-review label is present;
Ollama key is missing;
diff exceeds threshold, e.g. 1,500 changed lines or 80k diff chars;
binary/generated files dominate;
deterministic checks fail before useful context can be built;
PR comes from an untrusted fork and secrets would be exposed.

Never use model output as a required merge gate in v0.

Comment format

<!-- forgejo-pr-sanity-review -->
## Forgejo PR sanity review

Status: advisory only
Model: qwen3-coder:480b-cloud

### Deterministic checks
- install: passed / failed / not configured
- lint: passed / failed / not configured
- test: passed / failed / not configured
- typecheck: passed / failed / not configured
- build: passed / failed / not configured

### Changed files
- ...

### AI sanity findings
1. ...

### Manual verification
- ...

Test plan

Local/unit:

diff cap/truncation tests;
missing-script detection tests;
comment renderer snapshot tests;
Forgejo API comment upsert mocked tests;
Ollama API mocked success/failure/timeout tests;
Infisical env missing path test: should skip model, not fail whole workflow.

Forgejo live smoke on platform only:

PR with docs-only change: deterministic summary, model maybe skipped or no findings.
PR with intentional lint/test failure: comment shows deterministic failure clearly.
PR with small intentional bug: verify model can flag a concrete issue.
Push update to same PR: bot updates existing comment, does not spam.
Add skip-ai-review: model call is skipped.

Rollout

Fix/confirm at least one healthy Forgejo runner.
Add v0 to platform only.
Run 5-10 PRs and collect signal/noise.
Tune prompt, thresholds, and model choice.
Only then copy to pyfallow, BMADX, or other repos.

Follow-up decision gate

After v0 has real data, decide whether to pilot PR-Agent/Qodo Merge.

Adopt PR-Agent only if it is better than this v0 on:

signal/noise;
comment ergonomics;
Forgejo compatibility;
setup complexity;
predictable Ollama usage.

## v0 implementation plan: Forgejo PR sanity review with Ollama Cloud Chosen default model: **`qwen3-coder:480b-cloud`**. Why this model: - It is the strongest Ollama cloud coding model available for this job. - Ollama lists it as a coding/agentic model with a 256K context window. - It is a better fit than `gpt-oss:120b-cloud` for PR review because this task is code-specific, not general reasoning. - v0 will keep usage bounded by reviewing only small/medium diffs and posting one concise advisory comment. Fallback/cost-saver model for later: `qwen3-coder-next:cloud`, especially if `480b-cloud` is too slow or burns too much quota. ### Architecture Add a small Forgejo-native review layer, not a full bot platform yet. Files: - `.forgejo/workflows/pr-sanity.yml` - `tools/pr-sanity/review-pr.mjs` - `tools/pr-sanity/forgejo-api.mjs` - `tools/pr-sanity/ollama-review.mjs` - `tools/pr-sanity/render-comment.mjs` - `docs/pr-review-bot.md` Flow: 1. Trigger on PR `opened`, `synchronize`, and `reopened`. 2. Checkout the PR. 3. Run deterministic checks first: - install - lint - test - typecheck - build 4. Detect missing scripts and report them as `not configured`, not as silent success. 5. Build a bounded review bundle: - PR title/body - changed file list - diffstat - capped unified diff - deterministic check summary - relevant repo instructions if present: `AGENTS.md`, PR template, package metadata 6. If model review is allowed, call Ollama Cloud. 7. Post or update exactly one PR comment using a sentinel: ```md  ``` ### Secret handling The provider key already lives in Infisical at: - project path: `/home-platform/providers` - environment: `production` - secret: `OLLAMA_CLOUD_API_KEY` Do not duplicate the Ollama key into git. Preferred runner setup: 1. Store only an Infisical service token / machine identity token in Forgejo Actions secrets, e.g. `INFISICAL_TOKEN`. 2. Fetch the provider key at runtime: ```sh infisical run --env=prod --path=/home-platform/providers --token "$INFISICAL_TOKEN" -- node tools/pr-sanity/review-pr.mjs ``` The script should read `OLLAMA_CLOUD_API_KEY` and send it as: ```http Authorization: Bearer $OLLAMA_CLOUD_API_KEY ``` to: ```text https://ollama.com/api/chat ``` ### Ollama call Use native Ollama Cloud API, not local `localhost:11434` for v0. Request shape: ```json { "model": "qwen3-coder:480b-cloud", "stream": false, "messages": [ { "role": "system", "content": "You are a concise PR sanity reviewer..." }, { "role": "user", "content": "<bounded review bundle>" } ] } ``` Prompt rules: - advisory only; - max 5 findings; - every finding must cite changed file and hunk/context; - no style nits; - no merge approval/rejection; - say `No high-signal model finding` when unsure; - deterministic failures outrank AI observations. ### Guardrails Skip model review when: - `skip-ai-review` label is present; - Ollama key is missing; - diff exceeds threshold, e.g. 1,500 changed lines or 80k diff chars; - binary/generated files dominate; - deterministic checks fail before useful context can be built; - PR comes from an untrusted fork and secrets would be exposed. Never use model output as a required merge gate in v0. ### Comment format ```md  ## Forgejo PR sanity review Status: advisory only Model: qwen3-coder:480b-cloud ### Deterministic checks - install: passed / failed / not configured - lint: passed / failed / not configured - test: passed / failed / not configured - typecheck: passed / failed / not configured - build: passed / failed / not configured ### Changed files - ... ### AI sanity findings 1. ... ### Manual verification - ... ``` ### Test plan Local/unit: - diff cap/truncation tests; - missing-script detection tests; - comment renderer snapshot tests; - Forgejo API comment upsert mocked tests; - Ollama API mocked success/failure/timeout tests; - Infisical env missing path test: should skip model, not fail whole workflow. Forgejo live smoke on `platform` only: 1. PR with docs-only change: deterministic summary, model maybe skipped or no findings. 2. PR with intentional lint/test failure: comment shows deterministic failure clearly. 3. PR with small intentional bug: verify model can flag a concrete issue. 4. Push update to same PR: bot updates existing comment, does not spam. 5. Add `skip-ai-review`: model call is skipped. ### Rollout 1. Fix/confirm at least one healthy Forgejo runner. 2. Add v0 to `platform` only. 3. Run 5-10 PRs and collect signal/noise. 4. Tune prompt, thresholds, and model choice. 5. Only then copy to `pyfallow`, `BMADX`, or other repos. ### Follow-up decision gate After v0 has real data, decide whether to pilot PR-Agent/Qodo Merge. Adopt PR-Agent only if it is better than this v0 on: - signal/noise; - comment ergonomics; - Forgejo compatibility; - setup complexity; - predictable Ollama usage.