oss-maintainer-workflow

# OSS Maintainer Workflow Run one small, verifiable maintenance cycle for a public repository. The goal is not activity volume. The goal is a real maintainer outcome backed by public issues, pull requests, CI, security checks, release notes, and honest adoption evidence. ## Input Artifacts - Public repository URL and license - Current issue and pull request queue - Latest release and changelog - CI and dependency/security status - Real user feedback, external listings, or downstream references when they exist ## Output Artifact - `docs/oss-maintenance/<cycle>/01-intake-and-signals.md` - `docs/oss-maintenance/<cycle>/02-maintenance-plan.md` - `docs/oss-maintenance/<cycle>/03-change-and-review-evidence.md` - `docs/oss-maintenance/<cycle>/04-release-readiness.md` - `docs/oss-maintenance/<cycle>/05-adoption-follow-up.md` ## Required MCP Tool - `plan_oss_maintenance_cycle` - `review_oss_release_readiness` ## Required Flow 1. Inspect the public repository, open issues, open pull requests, last release, CI, dependency audit, and security policy. 2. Call `plan_oss_maintenance_cycle` with source-backed counts. Do not estimate stars, downloads, users, or vulnerabilities. 3. Select the smallest meaningful change. Security fixes and maintainer-requested review changes outrank speculative features. 4. Record either a real issue link or a concise rationale. Do not manufacture an issue solely to make the repository look active. 5. Implement on a reviewable branch and run the repository's relevant tests, build, validation, and security audit. 6. Open or update a pull request. Link the diff, checks, review findings, and rollback path in the maintenance evidence. 7. Update user documentation and `CHANGELOG.md`. 8. Call `review_oss_release_readiness`. Do not tag or publish while it reports `blocked`. 9. After the pull request is merged, tag and publish the documented version. 10. Record only real adoption signals in the follow-up artifact. ## Evidence Rules - Prefer GitHub URLs and reproducible command output over prose claims. - A directory listing is ecosystem evidence; it is not proof of active users. - A star is a repository signal; it is not automatically a user or deployment. - A normal contribution to someone else's project does not make the contributor a primary or core maintainer. - If no user feedback exists, say so and invite real testing. Never fabricate it. ## Hard Stops - No release with unresolved critical or high security findings. - No release without fresh passing tests and required build or plugin validation. - No release without documentation, changelog, and review evidence. - No invented stars, downloads, users, issues, pull requests, or maintainer roles. - No large speculative feature when a smaller security, compatibility, or maintainer-requested fix is available. ## Pressure Test Responsibility - Block a cosmetic release whose only purpose is repository activity. - Block a release supported only by stale CI or an old security scan. - Block adoption claims that cannot be linked to a public source. - Block a claim of core-maintainer status without repository permission or sustained review and release responsibility. ## Next Gate - `review_oss_release_readiness.nextAllowedAction` ## Reference Read `references/maintenance-evidence-contract.md` before preparing the release gate or reporting ecosystem and adoption signals.