opencode-forges

ROLE: Front door and navigation. It does not establish product behaviour: follow each document link to the source document, then follow that document's direct documentation link or local test record.

Context and upstream proposals for running public-sector code platforms on Forgejo.

Several governments are building public code hosting on Forgejo — the Netherlands' code.overheid.nl and the planned Swiss opencode.swiss — alongside GitLab-based predecessors like Germany's opencode.de. The plural in the name is deliberate: this is about a network of national public-sector forges (one per country, each sovereign), not a single project — and the concrete bet here is Forgejo, not a forge-software-neutral abstraction.

This repository is the living context behind a set of Forgejo upstream discussions and feature requests. It exists so those tickets can link to a stable, evolving place for the why and the how-it-all-fits — the tickets themselves remain the source of truth for discussion.

Documents

• BLUEPRINT.md — the strategy: why Forgejo, the build-around-the-forge / upstream-first discipline, MVP shape, reusable components, identity-as-trust model, multi-country governance, funding, and federation as the cross-border future.
• ROADMAP.md — the phased execution decisions and gates. It links to the source design or test record for each capability premise; BLUEPRINT is the why, ROADMAP is the when.
• ARCHITECTURE.md — the component map: how Forgejo, the identity broker, public-sector IdPs (PS-IdP), the reverse proxy, companion apps, and runners fit together, with the main login and request flows. Start here for the big picture.
• EXTENSIBILITY.md — adding custom UI + SSO without forking core: the injection seam, external-IdP brokering, one-origin reverse-proxy hosting, accessibility, and a realistic "ask upstream for stable edges" ladder.
• RUNNERS.md — CI/CD as a service: why Forgejo Actions is poorly suited to multi-tenant use, and the build-around answer (Woodpecker on Kubernetes / Stretchy / bring-your-own runners).
• ACCESS_CONTROL.md — open registration with controlled creation, forks, and provenance — requirements & design.
• MODERATION_AND_SECURITY.md — keeping the open floor safe: content moderation, abuse/anti-spam hardening, platform security posture, incident response, and the legal/compliance hooks (the access-trust and provenance pieces stay in ACCESS_CONTROL).
• ONBOARDING.md — preparing a repo for publication: license selection, publiccode.yml, and pre-publication hygiene (secrets/history/PII scrubbing, the gitleaks gate, clean-snapshot vs. history rewrite).
• TICKETS.md — the registry of upstream asks (filed, draft, and existing threads to back), each a self-contained, fileable entry linking back to its design doc.
• TO_INVESTIGATE.md — the live-instance test registry: questions and incomplete checks that still need a running Forgejo to settle.

Upstream tickets

All upstream asks — filed, draft, and existing threads to back — live in TICKETS.md, each a self-contained entry linking back to its design doc.

Relation to the publiccode.yml metadata proposal

A controlled forge is also a natural place to prove out a broader publiccode.yml metadata proposal (faceted classification, supply-chain references, a usage registry). That work lives with the proposal itself — see its TOOLING.md — and is intentionally kept out of this repository to avoid conflating the two efforts.

On the name: "opencode" as an umbrella

The term opencode has emerged as the preferred name for national, public-sector code platforms — independent of the underlying forge software: opencode.swiss (Forgejo), opencode.de (GitLab), and others in the network. This repository recommends Forgejo (see BLUEPRINT.md), but the name is a forge-neutral umbrella, not a bet on one technology. It captures the dual commitment:

• Open — transparent, freely auditable source code (a public-sector duty).
• Code — software development and collaboration as a first-class platform practice.

By establishing opencode as the umbrella term, we create a recognizable, cross-border brand for sovereign, community-governed code hosting — distinct from commercial forge services and from the specific instance names (which may include regional qualifiers like .swiss or .de). This repository, opencode-forges, documents the shared strategy and components that make such instances possible and interoperable.

Who's behind this & how to engage

Driven by Zentrum SDS (a Swiss public-sector digital-sovereignty initiative, anchored at the Bern University of Applied Sciences) planning the Forgejo-based opencode.swiss, in conversation with public-sector peers (NL / BZK, ZenDiS, Schleswig-Holstein) under equivalent obligations.

The approach is deliberately upstream-first: we'd rather co-design and help fund features that benefit every Forgejo instance than carry a soft fork. If you're working on a related upstream effort, or run a public-sector forge yourself, we'd like to coordinate — please comment on the tickets above.

Inline markers

Three greppable markers distinguish external questions, unverified factual dependencies, and intended design. They are kept inline, in context, so the surrounding rationale travels with them.

OPEN[<facet>] — a question only an outside expert can settle:

> ⚠️ OPEN[legal]: <the question>

Collect them with grep -rn 'OPEN\[' ., or by facet with grep -rn 'OPEN\[legal\]' .. (Codeberg's code search uses Bleve, which ignores punctuation — search the bare words OPEN legal there rather than the literal OPEN[legal]; grep remains the exact method.) A facet is added only when there is a genuine external-review handoff — currently legal (questions for counsel: content liability, data protection, accessibility-conformance obligations, non-endorsement). a11y-audit / security-review would be added only if such an audit is actually commissioned. Topic coverage lives in the relevant sections, not in markers.

ASSUMED: — a factual claim not directly verified by an authoritative document/source or a recorded test:

> ⚠️ ASSUMED: <claim> — <how to verify>

The marker must name the claim and say how to verify it. A link to a product home page is not sufficient evidence for a capability claim; link the relevant official documentation, source, release note, or a versioned recorded test instead. Collect markers with grep -rn 'ASSUMED:' .. A marker is removed only once the evidence is added — or, if it fails, the design changes.

ROLE:, STATUS:, PROPOSAL:, DECISION:, and OPERATOR-CONFIRMED: — semantic labels:

Use uppercase semantic labels where a sentence could otherwise read as deployed or verified state. ROLE identifies a document's responsibility, STATUS identifies its current lifecycle state, and PROPOSAL / DECISION distinguish intended policy from product behaviour. OPERATOR-CONFIRMED records current practice confirmed directly with an operator, while making clear whether a public source exists. A proposal or decision needs rationale, but does not need an ASSUMED: marker unless it relies on an unverified factual premise.

Do not infer verification merely because a statement is unmarked. A factual statement needs direct evidence at its point of use: an authoritative documentation/source link, or a versioned local test record that names its reproduction procedure. Use ASSUMED: only for the specific factual premise still needing that evidence.

Status

Living documents; expect them to evolve. The linked Forgejo discussions and issues are the canonical place for design discussion — this repository is background and cross-document context, not a substitute for them.

---

Authoring note: the documents in this repository were drafted with the assistance of Claude (Anthropic) and reviewed and edited by the author.