Open-source maintainer in Vietnam. I build deterministic contract layers for coding agents and applied research workflows.
The common rule is simple: make the boundary explicit, make the output reproducible, and leave claims about real users to evidence.
| Project | What it checks | Public starting point |
|---|---|---|
| PatchGate | Whether a GitHub pull request has the policy, evidence, ownership and human boundaries needed before review | try it locally · beta release |
| contribkit | Whether a repository contribution contract is satisfied before a pull request is opened | README · npm package |
| OpenSheet-AI | Whether a typed spreadsheet operation passes policy and produces a reviewable receipt before a workbook is changed | npm package · quickstart |
| quant-research | Whether instruments, recodes, coverage and measurement specifications are internally consistent before analysis | npm package · reproducibility guide |
I also maintain agentsmd, a project for linting and synchronising agent-instruction files, and keep slower public experiments in Flecto and desklore.
I define the product boundary and acceptance criteria, then use coding agents for implementation. Tests, clean-room checks, release metadata and public CI decide what can be claimed. Every project documents its non-goals alongside its capabilities.
The longer account of the workflow is in How this repo is built.
These projects are public pre-release work. A source tag, an npm publication, a local fixture, a maintainer-reviewed PR and an external pilot are different evidence levels; the repositories keep those states separate.
For a real failure or confusing first run, open an issue in the relevant repository with the command, runtime version and observed output. That is more useful than a generic endorsement.