At DiluxOne, human energy goes into writing a good issue. Once a person accepts it, an agent takes it to production through checks anyone can audit, and every change ends with a receipt that proves what was asked, how it was done and how we know it works. If something fails, the change does not move: it fixes itself within its limits, or goes back to a person with the exact action and its link.
Three decisions. The gates check the rest.
As in our mark: the black block is what a person decides; the blue module is what fits in and runs on its own.
Accept the issue
The only approval a normal change needs. Whoever accepts has read the PRD; from that moment its text is sealed with its hash.
Merge by hand
An issue marked critical, or a change to the rules that govern autonomy, waits for a person to merge it, with the reason in view.
Accept the release
Shipping a version to users is always a human decision: the release issue is opened by hand or by a planned milestone.
The eight gates, in order
Each gate is a check with a fixed name that leaves its result on the issue’s board. Deterministic checks always rule; AI can stop a change, never skip a deterministic gate.
- G1
Issue ready
schemaAI rubricA complete PRD under one schema: problem, scope, out of scope, acceptance criteria with an ID and a verifiable form, criticality.
if it failsThe agent asks on the issue for what is missing; it cannot be accepted yet.
- G2
Acceptance
humanor a policy laneA person accepts, or a lane of the autonomy policy allows it. The PRD hash is sealed at that moment.
if it failsNothing starts.
- G3
Spec
agentscope and pathsBefore writing code, the agent fills in the spec on the same issue: files, approach and one test per criterion. Its hash is sealed too.
if it failsOut of scope or touching protected paths: it stops and asks, with the action and its link.
- G4
Project checks
deterministicConventions, lint, static analysis, tests and whatever each stack needs, like Plugin Check for WordPress.
if it failsThe agent fixes and pushes again; it counts as a round.
- G5
Clean review
IANo blocking or major finding left open. What earlier reviews learned is already written down as rules.
if it failsLoop: fix and review again, up to 3 rounds; if it does not converge, back to a person with a summary.
- G6
Meets the issue
criterion → testscopeEvery acceptance criterion has its test, it exists and it passes. Nothing outside the scope that was asked for.
if it failsBack to the loop; if it is about scope, to a person.
- G7
Merge
deterministicEverything green, both hashes revalidated, not critical, no governance rule touched, within budget. It merges on its own and the receipt is issued.
if it failsIt waits for a human merge, with the reason and the link.
- G8
Healthy main
deterministicThe main branch CI stays green after the merge.
if it failsAn automatic revert and an issue open.
Receipt-Driven Development
A change is not done when the code works: it is done when its receipt exists. The receipt is the sealed, signed and verifiable proof that what was accepted was built, the way it was accepted, with the evidence that shows it. No receipt, no “done”.
What was asked?
The PRD, sealed with its hash when a person accepted it.
How was it solved?
The sealed spec and the exact commit that reached production.
How do we know it works?
Criterion by criterion, the test that proves it and its result, plus the checks and the review verdict.
Who authorized it?
The person who accepted, or the policy lane with the exact version of the rule it applied.
The test first: the code exists to make it pass.
The specification first: the code implements it.
The receipt is the definition of done: request, spec, tests and authorization, and nobody can alter it.
Issue
Pull request
- stack checks
- clean review
- criterion by criterion, with evidence
- merge by policy
Receipt
- PRD and spec hashes
- commit, checks and verdict
- who accepted, which rule applied
- on its own branch, signed
The seal: what a hash is and how it is checked again
A hash is the fingerprint of a text: SHA-256 turns it into 64 characters. The same text always gives the same fingerprint; change a single comma and you get a completely different one. You cannot go back from the fingerprint to the text, nor forge another text with the same fingerprint.
Illustrative fingerprints. Each section is normalized before hashing, so an invisible change does not alter it and a real one always does.
Computed
On acceptance, the bot takes only the PRD section, normalizes it and computes its SHA-256. The same with the spec when it passes G3.
Sealed
The fingerprint is stored with who accepted, when, and the schema and policy versions, in a commit signed by the bot on the receipts branch.
Shown
The issue’s board repeats it at a glance. If someone edits the board, the seal on the receipts branch wins.
Checked again
On every edit of the issue, before the agent starts, on every push and right before the merge.
// receipts/issues/123/merge.json · illustrative
{
"issue": 123,
"prd": { "sha256": "4f1c9a07…a3b7e914", "accepted_by": "maintainer" },
"spec": { "sha256": "9d2e51b8…c04f7a62" },
"pull_request": 131,
"head_commit": "e8b4c2f",
"checks": "all green",
"review": "clean, 2 rounds",
"criteria": { "C1": "tests/SaveNoticeTest" },
"policy": "autonomy.yml@3a91d0e",
"merged_by": "policy"
}Bugs: reproduced first, fixed after
A reported bug is not fixed on intuition. A workflow tries to reproduce it from what was reported; if it is confirmed, the failure is written as a test, and the fix has to make it pass.
Reported as an issue
What was done, what was expected, what happened and in which version.
Is it a bug?
A workflow decides whether it describes a failure or asks for something new.
Try to reproduce it
The agent writes a test with the reported steps and runs it in a clean environment, with no secrets.
Confirmed: to fix
The failing test is the evidence; the fix has to make it pass, through every gate.
More information
The issue gets what was tried and what is missing to reproduce it.
To the queue
A new feature or an improvement waits for its acceptance like any issue.
Lanes: what moves on its own, and with what evidence
Everything decided without a person comes from a single policy file. A project can restrict it, never widen it. If a piece of work fits no lane, it is not accepted on its own.
Reproduced bug
A test that fails before and passes after, and a report about the same thing as the fix.
Platform
Runner images, CI dependencies, tool versions. Evidence: smoke test and green checks.
Human issue
What a person accepts travels on its own to the merge, gate by gate.
Release
Never accepted on its own: shipping to users always goes through a person.
What if someone writes “delete the whole repo” in an issue?
Four layers, and none of them depends on the agent behaving well.
Strict structure
The issue has exactly the schema’s sections; any text outside them fails the gate.
A person read what is accepted
The hash seals the accepted PRD. The agent reads only the sealed PRD and spec, never third-party comments.
Text is data, not orders
The agent gets the issue as a specification to implement, never as instructions for itself.
Least privilege
The agent’s credentials cannot delete the repository, push to main or touch workflows. Everything goes through a pull request with gates.
Any decision explained in three clicks
Who accepted this change?
The issue’s board: the person, or the policy lane with a link to its exact version.
Why did it merge with nobody?
The board, merge row: every condition with its result and its check.
Does it meet what was asked?
The receipt: criterion by criterion, the test that proves it and its result.
What was decided alone this week?
A weekly summary with everything accepted and merged by policy.
Every job starts clean. Every release is a decision.
Public repositories run on GitHub’s runners; private ones on our own machines. Each job runs in a disposable container, built from an image that rebuilds itself every week and passes a smoke test before it is used; if it fails, the previous one stays and an issue opens with the log. The machine is described as code.
A “Release X.Y.Z” issue opens, by hand or when its milestone closes. A person accepts it: that is the approval. The agent prepares the release pull request through the gates, and the deploy checks the acceptance and the version before publishing.
Everything lives in GitHub and is set up once
What is the same in every project is defined once, at the organization level, in a central repository. Each project declares only its own, and each job runs where it belongs.
One central repository
Reusable workflows, organization rules, policies as data, a bot of our own that signs the agent’s commits and writes the receipts, and issue types, Projects and secrets defined once.
GitHub runners
Each job starts on a new GitHub machine and is discarded at the end. Free for public repositories.
Private runner
A cloud VM with several runners, only for private repositories. It starts when jobs are waiting and stops after a few idle minutes.
Download it: open source, MIT license
DiluxOne is an initiative of Pablo Di Loreto: technology to build businesses, with WordPress plugins, cloud services and AI tools, in one account. This pipeline is the framework every one of its modules is built with, and it is open source: use it in your own projects as it is or adapted. An installer that sets it up in your GitHub organization in a few steps is on its way.
DiluxOne/.github
Reusable workflows, gates, review policy, per-project packs and the docs to adopt it.
github.com/DiluxOne/.githubA real exampleDiluxOne Offload
A public WordPress plugin that uses it end to end: accepted issues, checks, review, auto-merge and release.
github.com/DiluxOne/diluxone-offload-wordpressInstaller
One command that sets up the workflows, the rules and the policy in your organization, and leaves your first repository ready.
on its way