denizaslan36 Release Ready
Find release blockers that correctness checks alone miss.
Readiness Audit
- Establish the release target, intended audience, supported environment, and claims being made. Infer only what the artifact itself makes clear.
- Inspect the applicable surfaces:
- functional correctness and fresh verification evidence;
- public interface, configuration, and compatibility;
- documentation accuracy and runnable examples;
- package metadata, versions, entry points, and generated artifacts;
- secrets, private data, unsafe defaults, and dependency risk;
- license, attribution, and provenance of bundled material;
- reproducibility of benchmark, performance, and quality claims;
- repository hygiene, including accidental local or internal files.
- Trace the shortest newcomer path from acquisition to useful result. Record blockers in the artifact; do not write a user testing guide unless asked.
- Rank each finding:
- blocker — release could fail, mislead, leak, or violate a requirement;
- important — release works but creates material support or trust risk;
- nice-to-have — improvement that does not justify delaying release.
- Re-check changed surfaces after authorized fixes. Do not silently broaden into unrelated cleanup.
- Give one verdict: ready, ready with known limitations, or not ready. List only evidence and unresolved items that justify the verdict.
Release Boundaries
- Do not push, publish, tag, upload, message third parties, or change external state without explicit authorization.
- Never treat a clean diff, passing unit tests, or polished documentation as sufficient on its own.
- Do not require checks irrelevant to the artifact's actual distribution model.
- If legal or policy certainty is required, identify the issue and avoid pretending the audit is professional legal advice.