Duaility-maintained open source projects will not accept pull requests. That includes pull requests written by people, assisted by LLMs, generated by coding agents, or produced through any other automation. Governance Kit is the first project where this matters publicly, but the policy applies to Duaility open source as a whole.
This can sound harsher than it is. We are not closing the door to outside contribution. We are being precise about the kind of contribution that creates leverage for the projects we maintain. We want valid bug reports, strong feature suggestions, design critique, and architectural input. If that input leads to a change that lands in the repository, we will count it as a valid contribution and credit the person who made it.
The contribution is the judgment that improved the project. The final diff may be written by Duaility maintainers.
Code became cheap; review did not
Open source has always had a mismatch between how easy it is to send a patch and how expensive it is to accept one. Coding agents made production cheap and widened that mismatch. A plausible diff can now appear in seconds. The cost of producing the patch has fallen, but the cost of understanding it, testing it, integrating it, and living with it has not.
For a maintainer, a pull request makes a claim about the shape of the project. It argues that a behavior should exist, an abstraction should be introduced, a boundary should move, a test should define the contract, a piece of wording should become the public explanation. Even a small change has to be read against the whole system.
When code was expensive to write, the effort inside a pull request was a useful signal. It was never a perfect signal, but it meant someone had usually spent time with the problem. Coding agents weaken that signal. A large, confident-looking diff can now arrive before the author has really understood the design, the tradeoffs, or the maintenance burden it is asking the project to accept.
We want the scarce part
The asymmetric workflow between humans and agents gives the agent the long mechanical chain and the human a clear decision. Our contribution model follows the same allocation: contributors sharpen the decision; maintainers own the chain that turns it into a repository change.
The scarce part isn't the diff, it's the judgment behind it: a real failure case, a missing workflow, a better boundary, a product constraint we missed, a design pressure that should change the direction of the code. That is where outside contributors can improve Duaility projects most directly.
A good bug report can be more valuable than a patch. It gives maintainers the exact failure, the reproduction, the environment, the expected behavior, and the consequence. It sharpens the problem before anyone touches the code. A good feature suggestion does the same for product direction: it explains who is blocked, what they are trying to do, what alternatives exist, and what tradeoff the project would be making by accepting the idea.
The same is true for architecture. "Here is a diff" often asks maintainers to infer the design argument from the implementation. We would rather receive the design argument directly: which boundary is wrong, which concept is carrying too much weight, where the public API will make the next feature harder, and what should be simpler, and why.
Why this fits Governance Kit
An AI twin adds a durable judgment layer around an agent's work. Governance Kit applies a concrete slice of that idea to software repositories. Rules should not live only in a chat transcript. Corrections should not have to be retaught to every new agent session. The repo should carry the standards, checks, receipts, and rationales that determine which changes it accepts.
We apply that philosophy to the maintenance of Governance Kit itself. If we accept every credible-looking patch, the project will slowly become a collage of local fixes. Each one may be reasonable in isolation. Together they can blur the model, widen the wrong extension point, or encode behavior before the underlying concept is stable.
Governance tools need unusually tight conceptual integrity. A new directive, receipt field, pack convention, or check runner behavior affects how other repositories govern agents. We want outside pressure on those choices, but we want that pressure at the level of failure cases, design constraints, and architecture.
What to send us
Send us issues and discussions that make the project more correct. A useful bug report includes a reproduction, the version or commit, the environment, the observed behavior, the expected behavior, and the practical consequence. A useful feature suggestion explains the workflow it would unlock, the user it serves, the alternatives considered, and why it belongs in the project instead of outside it.
A useful design note names the tension. It might say that an API is too broad, that a receipt is missing a field reviewers actually need, that a check belongs in a pack instead of core, or that a concept should be split before it hardens. A useful architecture suggestion explains the boundary, the failure mode, the migration path, and the maintenance impact.
Minimal examples, traces, logs, screenshots, and failing cases are welcome when they make the report concrete. We do not need a pull request wrapped around them. We need the problem to be clear enough that the maintainers can decide what change deserves to exist.
How credit works
We will credit contributors for accepted judgment, not only accepted diffs. If your report, suggestion, critique, or architecture note leads to a change that is merged into a Duaility open source repository, that counts as a contribution. We will acknowledge it in the appropriate project records: a contributors list, release note, changelog, or commit acknowledgment.
Open source contribution has too often been equated with authorship of the final patch. In an agentic software world, that is an increasingly poor proxy for value. The person who finds the real bug, or names the better design, or keeps the wrong abstraction out of the project has contributed something material.
The policy
Pull requests to Duaility-maintained open source projects are not accepted. Maintainers may close them without code review and point to this policy. This applies equally to human-authored, LLM-assisted, and coding-agent-generated patches. It applies to code, documentation, tests, configuration, generated files, and formatting-only changes.
Issues and discussions are open for real reports and real suggestions. AI tools can help someone prepare their thoughts, but the submitter is responsible for verifying the claim. Low-signal AI-generated reports that have not been checked by the author may be closed. The standard isn't whether a tool was used, it's whether the contribution improves the project through evidence and judgment.
We are narrowing the accepted submission format, not the scope for contribution. The work we value is finding what is wrong, naming what should change, and helping the project stay coherent as the code evolves.