DiluxOne/.github

How every DiluxOne repository is checked, reviewed, merged and released, written once, here.

Each repository calls the workflows in this one instead of carrying its own copy, and inherits its community files (contributing guide, security policy, issue forms, pull request template). Change a rule here and every repository follows it.

🎫 No issue, no code	🔍 Checked and reviewed	🚦 Nothing merges red
Every pull request closes an issue a maintainer accepted. A paid or already planned feature is stopped there, before anyone writes it.	Deterministic checks for the kind of project, then a Claude review that labels risk and complexity and comments on what blocks.	Rulesets require every check. A change merges on its own only when it touches low-risk paths alone, the review rates it low risk and low complexity, nothing blocks, its author is trusted and every check is green. Anything else waits for a person, and every release waits for a person's approval.

The life of a change

flowchart LR
    A["📝 Issue<br/>a PRD: problem, scope, criteria"] --> B{"Maintainer<br/>accepts?<br/>(PRD sealed)"}
    B -- "no" --> X["Closed or<br/>kept for later"]
    B -- "accepted" --> C["🤖 Autopilot: Spec, branch,<br/>code, tests, pull request<br/>Closes #n"]
    C --> D["✅ Conventions<br/>+ accepted-issue gate"]
    D --> E["🧪 Checks of its kind<br/>tests, lint, Plugin Check…"]
    E --> F["🤖 Claude review<br/>risk · complexity · type"]
    F -- "blocks" --> C
    F --> L["Merges on its own when<br/>not Critical · no protected path<br/>review clean · within the lane<br/>a test per criterion · every check green"]
    L --> G{"All of them?"}
    G -- "yes" --> H["⚡ Auto-merge"]
    G -- "any no" --> I["👤 A person merges"]
    H --> R{"🔐 Release approved<br/>by a person?"}
    I --> R
    R -- "approved" --> J["📦 Tag X.Y.Z<br/>→ wordpress.org"]
    R -- "not yet" --> W["Waits on main,<br/>nothing published"]

Loading

Step by step, with every detail: What happens on a pull request.

Who holds what

flowchart TB
    subgraph ORG["🏢 The organisation (GitHub settings)"]
        O1["Rulesets on main and tags"]
        O2["Required workflow on every pull request"]
        O3["Issue types, Projects, secrets, Apps"]
        O4["Runners: GitHub's for public repos, one-job containers on the organisation's VM for private ones"]
    end
    subgraph HUB["⚙️ This repository"]
        H1["Reusable workflows"]
        H2["Kinds of project: rules and settings"]
        H3["Review profiles and policy"]
        H4["Community files, labels, sync"]
    end
    subgraph REPO["🧩 Each product repository"]
        R1["Its code and tests"]
        R2["review-policy.yml · AGENTS.md · roadmap"]
        R3["A few caller workflows"]
    end
    ORG --> REPO
    HUB --> REPO

Loading

The rules in one minute

• Conventional Commits for branches, titles and commits. CI rejects anything else.
• One accepted issue per pull request. Bots' pull requests (Dependabot, releases) are the exception.
• Autonomy is data too, and only ever narrower. What may proceed without a person comes from policy/autonomy.yml: named lanes, each checked against GitHub, never against an issue's text. A repository can only tighten it, the rules that govern it always need a person, and DX_AUTOPILOT=off stops it all.
• Policy is data. Risk paths, models, budget and auto-merge live in policy/ and in each repository's .github/review-policy.yml, read from the base branch, so a pull request cannot loosen its own rules.
• A review lesson becomes a rule. Something a reviewer sent back once becomes one entry in its kind's rules.yml, with fixtures, never a new script (kinds/).
• Secrets never meet a fork's code. Actions are pinned to a commit and every token asks for the least it needs.
• Every job starts clean. Public repositories run on GitHub's runners; private ones on the organisation's VM, each job in a disposable container of an image rebuilt and smoke-tested every week (runner/).
• Every pending step names its action and its URL. Agents tell a maintainer exactly what to accept, approve or merge, with the link; an outside contributor is never asked for a maintainer's step.
• Versions are tags. Repositories call @v5. A breaking change ships as v6, and older majors stay where they are.

What's inside

	Folder	What it holds
⚙️	.github/workflows/	The reusable workflows and the organisation's required pull request pipeline
🧩	kinds/	One pack per kind of project (today, wordpress-plugin): its rules, review profile and settings
📜	policy/	The default review policy every repository adds to
🤖	review-profiles/	What the Claude review looks for
🛠️	scripts/	The logic behind the workflows, each script with its own --test; scripts/runner-vm/ keeps the organisation's VM in its described state
🏃	runner/	The image every job on the organisation's VM runs in, ghcr.io/diluxone/runner
📋	workflow-templates/	Ready-made callers for a new repository
🏷️	labels.yml · repos.yml	Labels, settings and Projects, kept in step by scripts/sync-repos.py
🖼️	profile/	The organisation's public page on GitHub

Read more

If you want to…	Read
Contribute to any DiluxOne repository	CONTRIBUTING.md
Point an AI agent at a repository	docs/agents.md
Follow a pull request through every step	docs/pull-requests.md
Bring a new repository in	docs/adopting.md
Move a repository to a newer major	docs/migrating.md
Look up a workflow, a script, a secret	docs/workflows.md
Add a rule or a kind of project	kinds/README.md
Change this repository and ship it	docs/maintaining.md
Report a security problem	SECURITY.md
See where this is going: one human decision per change, gates, receipts	The plan, issue #78
Read the story of how we build software	Cómo construimos software en DiluxOne · How we build software