Release Curator
Roster name: curator.
What it does
Every day it reads what merged since its last run and drafts the release notes, a documentation report, an audit of those changes and test scenarios, then drops any draft the changes do not support.
- Release notes: an Added / Changed / Fixed section.
- Stale documentation: the sections a change made wrong or incomplete, with what to change and why.
- Change security audit: issues the change introduces, such as secrets in code, missing authorisation, injection or path traversal, with severity, CWE/OWASP mapping and a fix.
- Change compliance audit: control-relevant changes mapped to SOC 2, ISO/IEC 27001 and ISO/IEC 42001 criteria, each marked Satisfied, Gap or Needs-evidence.
- Thread replies and test scenarios: a short status note on related issues, and a short checklist of user-test scenarios.
What it reads
The commits and file summaries since its last run, the raw diff, and the current README and documentation.
What it produces
A pull request carrying the release notes, the documentation report and the two audits, plus short comments on open issues and pull requests that your organisation’s own members opened. Test scenarios are kept with the run’s records, not in the pull request. It also tidies branches: it deletes a branch whose pull request merged more than a week ago (a few per repository per run), and comments on a pull request closed without merging to record why, leaving that branch in place. Started by core @curate, by schedule, or by a playbook.
Human oversight
A person reviews and merges the curator’s pull request. It never merges its own work. A scheduled run stays dry, publishing, commenting and deleting nothing, until an administrator turns that off. A dry run does not count as curated: the next armed run covers the same changes.
Model
Qwen3.6-35B-A3B, by Qwen, licensed Apache-2.0 (the general tier). Runink domain adaptation for this agent is planned; this release uses the base model.
Where it runs and data handling
On your Runink TIDE deployment’s own inference, on your Server or in your cloud. Diffs and documents go to that model plane and to no third-party AI service.
Guardrails
- Grounded or dropped: a second pass scores every draft against the raw diff. A draft that is not judged grounded, or scores below the threshold, is dropped whole; nothing is published from it.
- Screened before it is public: everything it publishes (release notes, the documentation report and audits in its pull request, comments on issues and pull requests) is checked by the output guardrails first. A flagged item is not posted, and the run’s log names the rule.
- It is instructed never to invent files, APIs or vulnerabilities, and the grounding pass is the check on that instruction.
- A “Satisfied” in the change audit is a reading of one change, not a certification.
Limitations
- It sees only what merged. It does not test the code.
- Known vulnerabilities in dependencies are Dependency Risk’s job.
- A green dry run published nothing.
Evaluation
No published evaluation scores yet.
Illustrative example
Invented changes. Nine pull requests merged. The draft release notes have seven bullets. The grounding pass finds that “adds single sign-on” has no supporting change (the diff only renames a field) and judges the draft not grounded, so the release notes are left out of this run’s pull request and the run’s log says why.