Plan policy alignment and release workflow updates

docs/roadmap/policy.md

@@ -10,7 +10,8 @@ only for substantive, locally significant requirements or decisions and explain
 their justification. Follow template adoption instructions and customize required
 project-specific sections rather than copying instructional placeholders.
 
-This document defines the target and scope, not implementation stages. It
+This document defines the target and scope; the [implementation plan](implementation.md)
+owns sequencing and concrete validation choices. It
 supersedes the earlier licensing-only roadmap: public upstream discovery,
 copied-policy attribution, and coordinated release-workflow alignment are now
 included. The earlier prohibition on policy-project references and deferral of
@@ -164,8 +165,8 @@ guidance together so rules and executable behavior agree:
 - Select additional gates by concrete risk and distinct protection. Do not keep
   race, static, module-hygiene, formatting, or other checks merely because they
   exist; document reasons for retained checks. Do not remove useful checks merely
-  to minimize command count. Resolve the exact set during implementation planning
-  against these criteria rather than leaving a blanket exemption or expansion.
+  to minimize command count. The implementation plan records the selected checks
+  and their distinct justification under these criteria.
 - Keep offline default tests, required build targets, fresh-version checks,
   clean candidate/exact source/tag guards, and explicit-ref publication.
 - Treat ordinary review and roadmap retirement as preparation, not new human