test(release): hold the seven-day release gap and the no-auto-merge rule

[yeongseon]

#895 중 kpubdata 저장소에서 할 수 있는 부분입니다. Builder·Studio 쪽 작업과 토큰 방식 결정은 남아 있어 이슈는 열어 둡니다.

바뀐 것

• 7일 간격 검사 테스트 (tests/unit/scripts/test_release_window.py): 간격 규칙은 이미 scripts/release_window.py 로 분리돼 있어 새 스크립트는 만들지 않았습니다. 실제 v0.9.0 게시 시각(2026-10-06T02:43:55Z)으로 6일째(10/12)는 거부, 7일째(10/13)는 허용, 그리고 UTC 로는 6일이지만 서울 시간으로 7일째인 순간(10/12 15:00 UTC)은 허용되는지 확인합니다. release.yml 의 prepare 와 release 두 경로가 태그·버전을 쓰기 전에 on-demand 창 검사를 거치는지도 확인합니다.
• v0.10.0 이 사흘 만에 나간 이유: 검사가 놓친 것이 아닙니다. release-please PR chore: release v0.10.0 #830 본문에 Critical-Patch: #821 줄이 있었고, 릴리스 실행 로그에 release allowed: critical patch for #821, outside the on-demand rule 이 남아 있습니다. 테스트가 release.yml 의 Read a critical-patch declaration 스크립트를 그대로 실행해, 그 줄이 있으면 통과하고 없으면 10/09 에 거부된다는 것을 보입니다.
• 워크플로가 PR 을 병합하지 않는다는 검사 (tests/unit/test_no_workflow_merges.py): 세 저장소 어디에도 Dependabot 자동 병합 워크플로는 없고 저장소 자동 병합 설정도 꺼져 있습니다. 브랜치 보호는 승인 수를 요구하지 않으므로(무거운 변경 리뷰 라벨이 붙은 PR 만 승인 필요) 자동 병합은 필수 체크는 지켜도 사람을 건너뜁니다. 그래서 .github/ 의 어떤 파일도 PR 을 병합·자동 병합·승인하지 못하게 막고, 그런 워크플로를 실제로 잡아내는 테스트를 함께 둡니다.
• 문서: POLICY.md 2.1.3 의 "버전은 prepare 의 bump 를 사람이 고른다" 를 release-please 절차로 고쳤습니다. docs/compatibility.md 5.1 에 v0.10.0 경위와 자동 병합 금지를 적었고, RELEASE_POLICY.md 의 절차 1단계를 맞췄습니다.

확인

uv run ruff check .                      -> All checks passed!
uv run ruff format --check .             -> 432 files already formatted
uv run mypy src                          -> Success: no issues found in 70 source files
scripts/check_english_comments.py        -> no Korean comments or docstrings
scripts/check_plain_codes.py             -> no bare review/verification code
uv run pytest                            -> 3366 passed, 2 failed (test_build_dataset_verifier, origin/main 에서도 같은 2건 실패 — 이 변경과 무관)
mkdocs build --strict                    -> built
python -m build                          -> built

릴리스·태그는 하지 않았고 #890 도 병합하지 않았습니다.

Refs #895

🤖 Generated with Claude Code