docs(devlog): Windows CI repair and v2.40.0 release outcome

[lidge-jun]

Summary

• Devlog only: devlog/_plan/260902_windows_ci_release/070_outcome.md records the Windows CI repair (dispatch table across eight rounds, reviewer verdicts, fuck-powershell cases), the v2.40.0 / v2.40.0-preview.20260902 release proof, and the two follow-ups (Actions PR-creation setting; service-lifecycle path-filter on workflow-only release-branch commits). Plus the 070 correction and closeout marker.
• Final confirmation: dispatch 33618250161 on the released dev tip 272ff6b11 — Windows 1/4, 2/4, 3/4, 4/4 SUCCESS and every other job SUCCESS.

Verification

• bun run privacy:scan green on the branch; no code.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed.
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults (n/a).

Summary by CodeRabbit

• Chores

  • Updated release automation permissions to support successful version bump workflows.
  • Improved reliability of release and Windows CI processes, reducing failures during release validation.

• Documentation

  • Added release outcome documentation covering the v2.40.0 promotion, Windows CI repairs, validation results, and follow-up items.

[github-actions]

✅ Deterministic PR hygiene checks passed.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-02T10:41:52.375695Z	3ebb0f2	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[lidge-jun]

Owner admin merge, user-authorized (release train closeout, devlog only).

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Team

Run ID: eb362af0-48d8-4ba3-8616-6ef8139ef4b7

📥 Commits

Reviewing files that changed from the base of the PR and between 272ff6b and 3ebb0f2.

📒 Files selected for processing (2)

• .github/workflows/release.yml
• devlog/_plan/260902_windows_ci_release/070_outcome.md

---

📝 Walkthrough

Walkthrough

The release workflow grants write permissions to the reusable development-version workflow. A new outcome document records the Windows CI repair, regression audit, release promotions, validation results, and follow-up actions.

Changes

Windows CI release workflow

Layer / File(s)	Summary
Reusable workflow permissions .github/workflows/release.yml lines 70–77	The bump-dev-version reusable-workflow call now grants contents: write and pull-requests: write permissions.
CI and release outcome record devlog/_plan/260902_windows_ci_release/070_outcome.md lines 1–62	The document records the Windows shard failure cause, dispatch results, regression audit, release promotions, successful publish validation, and non-blocking follow-ups.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: wibias

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/release-workflow-permissions

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[lidge-jun]

리뷰 · 우선순위 38 / 80

이 PR은 제품 코드를 고치는 작업이 아니다. Windows CI가 2026-08-30 이후 모든 브랜치에서 빨갛던 원인을 #3257/#3258로 고치고, v2.40.0 / v2.40.0-preview.20260902 를 실제로 npm·GitHub에 올린 뒤, 그 전체 과정을 한 장으로 남기는 마무리 문서다. 머지 결과로 dev에 실제로 들어온 파일은 devlog/_plan/260902_windows_ci_release/070_outcome.md 한 개뿐이다 (62줄 추가).

지금 dev HEAD는 이미 7424719ab (#3267) 이다. 그 바로 앞은 #3265로 package.json 이 2.40.0 → 2.41.0 이 됐고, 그 앞은 #3262로 release.yml 의 bump-dev-version 호출 잡에 contents: write + pull-requests: write 가 붙어 v2.40.0 첫 디스패치의 startup_failure 가 풀렸다. 이 070 문서는 그 기차가 왜 막혔는지, 어느 런에서 어느 샤드가 풀렸는지, 릴리스 증명이 뭔지, 다음에 손볼 설정이 뭔지를 한곳에 모아 둔다.

문서가 말하는 Windows 쪽 핵심은 짧다. e5d588669 이후 hardenConfigDir 이 icacls.exe 를 불 지르고 잊어버리는 비행으로 돌렸고, server.stop() 이 그 자식을 기다리지 않아서 픽스처 rmSync 가 EPERM/EBUSY 를 맞았다. #3257 이 종료 계약에 플러시를 넣었고, #3258 이 쓰기 가능 fsync 핸들과 테스트 레인 ACL 레인·해체 코디모드를 이었다. 문서에 적힌 디스패치 표(33595585136 … 33612731522)와 마지막 확인 런 33618250161 (HEAD 272ff6b11 기준 Windows 1/4·2/4·3/4·4/4 전부 SUCCESS) 이 그 주장의 증거다.

릴리스 쪽도 문서에 숫자로 남아 있다. 프로모션 #3260/#3261 → 첫 디스패치 실패 → #3262 권한 상속 수정 → main/preview 캐리 #3263/#3264 → 서비스 라이프사이클 수동 디스패치 → publish SUCCESS → npm latest=2.40.0 / preview=2.40.0-preview.20260902 → 봇이 브랜치는 밀었지만 Actions의 PR 생성 설정 때문에 gh pr create 가 거절되어 #3265 를 손으로 연 것까지. 다음에 같은 일이 나면 070 만 펼치면 된다.

주의할 점 하나. PR 파일 목록/디프에는 .github/workflows/release.yml (+8) 도 같이 보인다. 같은 브랜치 codex/release-workflow-permissions 에 #3262 커밋이 남아 있어서 생긴 착시다. 당시 dev 로 fast-forward 된 내용은 070 문서뿐이고, 권한 수정 본문은 이미 #3262 로 들어와 있다. 문서만 보고 다시 워크플로를 손대면 안 된다.

types.ts/config.ts 분할 캠페인과는 무관하다. 중복 PR도 아니다. 닫을 대상이 아니라, 이미 머지된 기록 PR이다. 제품 회귀 위험은 사실상 없다.

라인 - 제품 코드 변경 없음. 머지 팁 기준 추가 파일은 070_outcome.md 한 개.
070_outcome.md / Follow-ups 1 - Actions가 PR을 만들·승인하지 못하게 막힌 저장소 설정이 그대로면 다음 릴리스마다 봇이 브랜치만 밀고 PR은 사람이 열어야 한다.
070_outcome.md / Follow-ups 2 - release.yml 만 고친 릴리스 브랜치 커밋은 service-lifecycle 경로 필터에 안 걸려서, 게이트 전에 수동 디스패치가 또 필요할 수 있다.
PR 파일 목록의 release.yml - 이미 #3262 로 랜딩된 내용이 브랜치에 겹쳐 보이는 착시. 이 PR 범위로 다시 리뷰·재적용하지 말 것.
070_outcome.md 디스패치 표 - 마지막 행 33612731522 는 merge 시점 in flight 표기. 최종 4/4 초록은 본문 아래 33618250161 로 보완되어 있어 표만 보면 헷갈릴 수 있다.

메인테이너의 판단이 필요한 지점

• Follow-ups 1: 저장소 Settings → Actions → General 에서 GitHub Actions의 PR 생성/승인 허용을 켤지, 아니면 매 릴리스 수동 PR을 유지할지.
• Follow-ups 2: workflow-only 릴리스 커밋에도 service-lifecycle 이 자동으로 돌게 경로 필터를 넓힐지, 문서대로 수동 디스패치를 운영 규칙으로 둘지.
• 070 문서를 이 상태로 닫을지, 표에 33618250161 행을 한 줄 더 넣어 in-flight 표기와 최종 4/4 를 한 표에서 보이게 보정할지 (이미 머지됨 → 후속 문서 PR).

너의 추천
이미 머지된 기록 PR이므로 추가 코드 작업은 없다. 라벨도 바꾸지 않는다. 우선순위는 문서·후속 설정 이슈로 낮다(38/80). 다음 액션은 제품 PR이 아니라 (1) Actions PR 생성 허용 여부를 메인테이너가 결정하고, (2) 필요하면 070 표에 최종 4/4 런을 한 줄 보강하는 아주 작은 docs PR 정도다. types/config 분할과 무관하니 close-don't-rebase 대상도 아니다.

이 댓글은 grok-bot이 작성했습니다