commitgate 0.1.0 → 0.1.1

package/README.en.md

@@ -0,0 +1,341 @@
+# CommitGate 🚦
+
+🌐 [한국어](./README.md) · **English**
+
+**A "commit gate" that lets AI-written code be committed only after a *different* AI reviews and approves it.**
+
+> In one line: pair a **Builder AI** with a **Reviewer AI** so that **nothing gets committed without review, approval, and evidence.**
+
+[![license](https://img.shields.io/badge/license-MIT-blue.svg)](./LICENSE)
+
+---
+
+## 🤔 What is this? (an analogy)
+
+Think of an airport security checkpoint. No matter how much of a hurry you're in, you **can't reach the gate without passing through security.**
+
+CommitGate works the same way. No matter how much code you produce, **`git commit` is blocked until it passes the "review → approval" gate.**
+
+- 🛠️ **Builder (the maker)** — you, or your AI coding tool (e.g. Claude Code). Designs the requirement and writes the code.
+- 🔎 **Reviewer (the checker)** — the **Codex CLI**. **Independently re-reviews** what the Builder made and rules pass / needs-fix.
+- 🚦 **CommitGate** — stands between them and lets **only Reviewer-approved code** be committed.
+
+In short, instead of "build alone, commit alone," it enforces **cross-verification between the AI that built it and the AI that checked it.**
+
+## 🎯 What problem does it solve?
+
+AI produces code **fast**, but committing it without verification is risky. CommitGate:
+
+- ✅ Forces **every change through review.**
+- ✅ Binds approval to **"the exact code that was reviewed."** (You can't swap in changes after approval — it's compared like a fingerprint.)
+- ✅ **Blocks by default (fail-closed)** whenever something is ambiguous or missing. "Pass only when certain" is the default, so it's safe.
+- ✅ Leaves **evidence on disk** of who approved what and when.
+
+## 🔄 The flow at a glance
+
+```
+① create ticket   →  ② write design →  ③ design review(Codex) →  ④ implement code
+      req:new                            req:review-codex
+
+   →  ⑤ gate check   →  ⑥ code review(Codex)  →  ⑦ commit once approved
+        req:doctor        req:review-codex           req:commit
+```
+
+At each step, **if it doesn't pass, you can't move to the next.**
+
+---
+
+## 📦 Prerequisites
+
+You need these 4 things before starting. Check each in your terminal.
+
+| What | Check command | If missing |
+|---|---|---|
+| **Git** (required) | `git --version` | install from [git-scm.com](https://git-scm.com) |
+| **Node.js 18.17+** (required) | `node --version` | install from [nodejs.org](https://nodejs.org) |
+| **Codex CLI** (for review) | `codex --version` | install OpenAI Codex CLI (without it only review is unavailable; the rest works) |
+| **Package manager** | `npm --version` | `npm` ships with Node (or use `pnpm`/`yarn`) |
+
+> 💡 **Reviewer = Codex CLI.** To actually run reviews, the Codex CLI must be installed. Without it, review commands **fail safely (fail-closed)** — they never silently pass.
+
+### 🔧 Install & log in to the Codex CLI (Reviewer setup)
+
+Reviews in CommitGate are handled by the **OpenAI Codex CLI**. Three steps:
+
+**① Install**
+
+```sh
+# npm (all OSes)
+npm install -g @openai/codex
+
+# or macOS Homebrew
+brew install codex
+```
+
+Verify:
+
+```sh
+codex --version      # e.g. codex-cli 0.4x.x
+```
+
+**② Log in** — pick whichever is easier
+
+- **Option A. With a ChatGPT account (recommended, browser)**
+  ```sh
+  codex login
+  ```
+  A browser opens → sign in with your ChatGPT account → return to the terminal when done.
+
+- **Option B. With an OpenAI API key**
+  ```sh
+  # via environment variable (simplest)
+  export OPENAI_API_KEY=sk-...        # Windows PowerShell: $env:OPENAI_API_KEY="sk-..."
+
+  # or store the key in Codex
+  printenv OPENAI_API_KEY | codex login --with-api-key
+  ```
+  Create an API key at [platform.openai.com](https://platform.openai.com/api-keys).
+
+**③ Verify login**
+
+```sh
+codex login status     # shows login status
+codex doctor           # full diagnosis of install, auth, and environment (explains any issue)
+```
+
+> ✅ If `codex --version` and `codex login status` look good, the Reviewer is ready. Move on to `npx commitgate`.
+> ⚠️ If Windows can't find the `codex` command, open a **new terminal** so PATH is reloaded (a common issue right after a global install).
+
+---
+
+## 🚀 Install (one line)
+
+**In your project folder** (= a git repo that has a `package.json`):
+
+```sh
+npx commitgate
+```
+
+What this does automatically (it **never overwrites** existing files):
+
+1. Copies the workflow scripts (`scripts/req/`) and schemas.
+2. Creates a `req.config.json` (settings file).
+3. Adds the `req:*` commands and required devDependencies (`tsx`, `ajv`, `cross-spawn`) to your `package.json`.
+4. Creates an `AGENTS.md` template (the rules file the Reviewer reads) if you don't have one.
+
+After installing, fetch the newly added dependencies:
+
+```sh
+npm install
+```
+
+> Add `--dry-run` to preview what it would do **without changing anything**: `npx commitgate --dry-run`
+
+---
+
+## 🤖 How to use it — hand it to an AI agent via a prompt (recommended)
+
+Honestly, **nobody types `req:new → review → implement → review → commit` by hand, one at a time.** It's tedious.
+
+The real way to use CommitGate is this: **give your AI coding agent a prompt with your "requirements" plus "use this workflow," and the agent drives the whole thing.** You only approve at **control points (commit, merge, push, etc.).**
+
+### What this mode assumes
+- **An AI coding agent that can run shell commands** — Claude Code, Cursor (agent), Codex CLI, etc. (it must be able to run terminal commands in your repo)
+- **Codex CLI installed** — the Reviewer role. Without it, the review step stops (fail-closed).
+- **A filled-in `AGENTS.md`** — write your project's rules (coding conventions, test commands, etc.) into the template that `npx commitgate` created; it improves review quality.
+
+### Three steps and you're done
+1. Copy the **prompt template** below and fill the `[Requirements]` block at the bottom with your request.
+2. Paste the whole thing **into your AI agent's chat.**
+3. The agent's **first reply reports only the REQ number, branch, phase plan, and control points.** After that it asks you **only at control points** — everything else (implementation, tests, Codex review, applying NEEDS_FIX, re-review) is automatic.
+
+### 📋 Copy-paste prompt template
+
+````text
+Do NOT handle this as a normal implementation task. You MUST use the CommitGate (AI REQ workflow) installed in this project.
+
+Issue a new REQ ticket for the [Requirements] below and drive it all the way through:
+  req:new → write design docs (00/01/02) → req:review-codex (design review)
+  → implement phase + tests → req:doctor (gate) → req:review-codex (phase review) → req:commit
+
+[Do automatically]
+- Within the approved phase scope, do implementation, tests, keeping codex-request consistent, applying NEEDS_FIX, and re-review (resume) automatically. Do not ask me every time.
+- If Codex returns NEEDS_FIX, apply the feedback and re-run the review until approved (max 3 rounds per phase).
+- Only what is `git add`ed is reviewed. NEVER `git add` state.json or responses/ (the tool manages those).
+
+[Control points — stop and ask me ONLY here]
+- Right before `req:commit --run` (the actual commit / HIGH impact)
+- Right before merging to main or `git push`
+- Destructive operations such as reset, clean, force push
+- When a design-scope change or a feature not in [Requirements] is needed
+- When Codex review exceeds 3 rounds without approval, or the judgment is unclear
+- When a prerequisite is missing (not a git repo, no Codex CLI / Node / package manager) and you must fail-closed
+
+[First reply] Report only the REQ number, branch, phase plan, and control points. After that, stop only at control points.
+
+[Requirements]
+- What: (e.g.) Add a user-profile edit API
+- Why:  (e.g.) Only the name is editable today — email and bio should be editable too
+- Constraints: (e.g.) Reuse the existing auth middleware, validate email format, no new external libraries
+- Done when: (e.g.) PATCH /profile works + unit tests pass + existing tests unbroken
+````
+
+> The `[Requirements]` example above is **just a sample.** Just replace the 4 lines (What / Why / Constraints / Done when) with your own. If the request is large, it's split into multiple phases, each going through its own review and gate.
+
+### Example of the agent's first reply
+
+```
+Issued REQ-2026-002 · branch feat/req-2026-002-profile-edit-api
+Phase plan:
+  - phase-1: PATCH /profile handler + validation
+  - phase-2: unit tests + regression
+Control points: proceed per phase after design approval / confirm before req:commit --run / push needs separate approval
+→ Starting with the design docs. Once the design review passes, I'll move to implementation.
+```
+
+Now you just **wait** until a control-point notification arrives. When it asks "commit as-is?" right before committing, you confirm.
+
+---
+
+## 🔧 Appendix: what the workflow actually runs under the hood (manual steps)
+
+> With the prompt approach above, you **don't need to type the commands below** — the agent runs them for you.
+> These are the actual commands the workflow runs internally. Refer to them only when you need to **understand the behavior, debug, or run steps manually.**
+
+Let's walk the whole flow with one small feature as an example. (Commands use `npm`; arguments after `npm run` go after `--`. With `pnpm` you can drop the `--`, e.g. `pnpm req:new my-feature --run`.)
+
+### Step 1 — create a work ticket
+
+```sh
+npm run req:new -- my-feature --run
+```
+
+- A new branch (`feat/req-...`) is created, and three design docs appear under `workflow/REQ-2026-001/`.
+- The output shows a **ticket number** (e.g. `REQ-2026-001`). Later commands use just the number → `2026-001`
+
+### Step 2 — write the design docs
+
+Fill in the three files under `workflow/REQ-2026-001/`:
+
+- `00-requirement.md` — **what** to build and why
+- `01-design.md` — **how** to build it
+- `02-plan.md` — in what **order/phases** to proceed
+
+### Step 3 — get a design review (Codex)
+
+Stage your design (i.e. `git add`):
+
+```sh
+git add workflow/REQ-2026-001/00-requirement.md workflow/REQ-2026-001/01-design.md workflow/REQ-2026-001/02-plan.md
+npm run req:review-codex -- 2026-001 --kind design --run
+```
+
+- Codex reads the design and returns **approval** or **NEEDS_FIX**.
+- If NEEDS_FIX, apply the feedback, then **`git add` again → re-run the command.** Repeat until approved.
+
+### Step 4 — implement code + tests
+
+Once the design is approved, write the actual code and tests.
+
+### Step 5 — gate check
+
+Stage your changes and preview the gate status:
+
+```sh
+git add <files-you-changed>
+npm run req:doctor -- 2026-001
+```
+
+- It checks several things (is the design approval valid, does the staged code match the approved code, is the working tree clean, etc.) and shows **PASS/FAIL.**
+
+> ⚠️ **Important:** `git add` **only your own code/docs.** Do **not** stage workflow-internal files like `state.json` or `responses/` (the tool manages them; staging them by mistake gets blocked at the commit step).
+
+### Step 6 — get a code review (Codex)
+
+```sh
+npm run req:review-codex -- 2026-001 --kind phase --run
+```
+
+- Codex reviews the **implementation code.** Again, apply feedback → re-run until approved.
+- Once approved, `commit_allowed=true` and the commit opens.
+
+### Step 7 — commit
+
+```sh
+npm run req:commit -- 2026-001 --run -m "feat: implement my-feature"
+```
+
+- After passing the gate (doctor) one final time, it makes a **code commit + an evidence commit.**
+- If it isn't approved, or the code changed after approval, it **stops here.** (That's the heart of CommitGate.)
+
+🎉 Done! Your code is now committed safely with review, approval, and evidence all recorded.
+
+---
+
+## 📋 Command cheat sheet
+
+| Command | What it does |
+|---|---|
+| `npx commitgate` | Install (scaffold) CommitGate into your project |
+| `req:new <name> --run` | Create a new ticket + branch + design docs |
+| `req:review-codex <num> --kind design --run` | **Design** review (Codex) |
+| `req:review-codex <num> --kind phase --run` | **Implementation** review (Codex) |
+| `req:doctor <num>` | Gate check (shows pass/fail) |
+| `req:commit <num> --run -m "message"` | Commit approved code (+ evidence) |
+
+> Instead of `-m "message"`, multi-line messages can be read from a file with `--message-file message.txt`.
+
+---
+
+## ⚙️ Configuration (`req.config.json`, optional)
+
+You can tweak behavior via `req.config.json` at the project root. **Without the file it works on sensible defaults**, so you can ignore it at first.
+
+| Key | Default | Meaning |
+|---|---|---|
+| `branchPrefix` | `"feat/req-"` | Prefix for newly created branch names |
+| `ticketRoot` | `"workflow"` | Where ticket folders live |
+| `packageManager` | auto-detected | `npm` / `pnpm` / `yarn` |
+| `designDocs` | `00-/01-/02-*.md` | Filenames of the three design docs |
+
+Invalid values (e.g. an empty `branchPrefix`, a path that escapes the folder) are **rejected safely.**
+
+---
+
+## ❓ FAQ / troubleshooting
+
+**Q. It says the `codex` command is not found.**
+A. The Reviewer (Codex CLI) must be installed for reviews to run. Before it's installed, review commands don't "silently pass" — they **fail clearly** (that's the intended fail-closed behavior).
+
+**Q. I get an error like "staged tree != approved" at the commit step.**
+A. It means **the approved code and the code you currently staged (`git add`) differ.** If you changed code after approval, redo Step 6 (implementation review) to re-approve. (This safeguard prevents approval swapping.)
+
+**Q. I get a "non-code staged not allowed (state/responses)" error.**
+A. You `git add`ed `state.json` or `responses/`. **Don't stage those** (the tool manages them); stage only your own code/docs.
+
+**Q. Does running `npx commitgate` twice overwrite things?**
+A. No. **Existing files are skipped** (idempotent). To force overwrite, add `--force`.
+
+**Q. On Windows my commit message newlines look wrong.**
+A. For multi-line messages, use `--message-file file.txt` instead of `-m`.
+
+---
+
+## 🔒 How is "safety" guaranteed? (fail-closed)
+
+CommitGate's principle is **"pass only when definitely approved; block on the slightest doubt."**
+
+- Design docs missing or malformed → treated as not approved
+- Codex not installed / review failed → not a pass, fails clearly
+- The approved code fingerprint differs from the current code → commit rejected
+- The working tree is dirty (unreviewed changes mixed in) → review/commit rejected
+
+In other words, **blocking is the default and passing is the exception**, minimizing the chance of unverified code slipping through.
+
+---
+
+## 📄 License
+
+[MIT](./LICENSE) © 2026 sol5288
+
+> This workflow was extracted as a standalone package from the REQ-2026-017 portability kit of `palm-kiosk-app`, and was validated by **reviewing and approving itself through this very workflow (dogfood).**

package/README.md

@@ -1,5 +1,7 @@
 # CommitGate 🚦
 
+🌐 **한국어** · [English](./README.en.md)
+
 **AI가 짠 코드를, 다른 AI가 리뷰하고 승인해야만 커밋되게 하는 "커밋 관문(gate)".**
 
 > 한 줄 요약: **만드는 AI(Builder)** 와 **검사하는 AI(Reviewer)** 를 짝지어, **리뷰·승인·증거 없이는 커밋이 통과하지 못하게** 막아줍니다.
@@ -56,6 +58,54 @@ AI는 코드를 **빠르게** 만들지만, 검증 없이 그대로 커밋되면
 
 > 💡 **Reviewer = Codex CLI** 입니다. 리뷰를 실제로 돌리려면 Codex CLI가 설치되어 있어야 해요. 없으면 리뷰 명령이 "안전하게 실패(fail-closed)"합니다 — 조용히 통과되는 일은 없습니다.
 
+### 🔧 Codex CLI 설치 & 로그인 (Reviewer 준비)
+
+CommitGate의 리뷰는 **OpenAI Codex CLI**가 담당합니다. 아래 3단계면 끝납니다.
+
+**① 설치**
+
+```sh
+# npm (모든 OS)
+npm install -g @openai/codex
+
+# 또는 macOS Homebrew
+brew install codex
+```
+
+설치 확인:
+
+```sh
+codex --version      # 예: codex-cli 0.4x.x
+```
+
+**② 로그인** — 둘 중 편한 방법 하나
+
+- **방법 A. ChatGPT 계정으로 (권장, 브라우저)**
+  ```sh
+  codex login
+  ```
+  브라우저가 열리면 ChatGPT 계정으로 로그인 → 터미널로 돌아오면 완료.
+
+- **방법 B. OpenAI API 키로**
+  ```sh
+  # 환경변수로 (가장 간단)
+  export OPENAI_API_KEY=sk-...        # Windows PowerShell: $env:OPENAI_API_KEY="sk-..."
+
+  # 또는 키를 Codex에 저장
+  printenv OPENAI_API_KEY | codex login --with-api-key
+  ```
+  API 키는 [platform.openai.com](https://platform.openai.com/api-keys) 에서 발급합니다.
+
+**③ 로그인 확인**
+
+```sh
+codex login status     # 로그인 상태 표시
+codex doctor           # 설치·인증·환경 종합 진단(문제 있으면 원인 안내)
+```
+
+> ✅ `codex --version` 과 `codex login status` 가 정상이면 리뷰 준비 끝. 이제 `npx commitgate` 로 넘어가세요.
+> ⚠️ Windows에서 `codex` 명령을 못 찾으면 **새 터미널**을 열어 PATH를 새로 읽게 하세요(전역 설치 직후 흔한 문제).
+
 ---
 
 ## 🚀 설치 (딱 한 줄)
@@ -70,7 +120,7 @@ npx commitgate
 
 1. 워크플로 스크립트(`scripts/req/`)와 스키마를 복사합니다.
 2. `req.config.json`(설정 파일)을 만들어 둡니다.
-3. `package.json`에 `req:*` 명령들과 필요한 devDependencies(`tsx`, `ajv`)를 추가합니다.
+3. `package.json`에 `req:*` 명령들과 필요한 devDependencies(`tsx`, `ajv`, `cross-spawn`)를 추가합니다.
 4. `AGENTS.md`(Reviewer가 읽는 규칙 파일)가 없으면 템플릿을 만들어 줍니다.
 
 설치 후, 방금 추가된 의존성을 받습니다:
@@ -83,9 +133,76 @@ npm install
 
 ---
 
-## 👣 처음부터 끝까지 따라하기
+## 🤖 사용법 — AI 에이전트에게 프롬프트로 맡기기 (권장)
+
+솔직히, `req:new → 리뷰 → 구현 → 리뷰 → 커밋`을 **손으로 하나씩 치는 사람은 없습니다.** 피곤하니까요.
+
+CommitGate의 진짜 사용법은 이겁니다: **당신의 AI 코딩 에이전트에게 "요구사항"과 "이 워크플로를 쓰라"는 프롬프트를 던지면, 에이전트가 알아서 전 과정을 굴립니다.** 당신은 **통제점(커밋·머지·푸시 등)에서만** 승인하면 됩니다.
+
+### 이 방식의 전제
+- **셸 명령을 실행할 수 있는 AI 코딩 에이전트** — Claude Code, Cursor(agent), Codex CLI 등. (당신의 저장소에서 터미널 명령을 직접 돌릴 수 있어야 함)
+- **Codex CLI 설치** — 리뷰어(Reviewer) 역할. 없으면 리뷰 단계가 fail-closed로 멈춥니다.
+- **`AGENTS.md` 채우기** — `npx commitgate`가 만든 템플릿에 당신 프로젝트의 규칙(코딩 컨벤션·테스트 명령 등)을 적어두면 리뷰 품질이 올라갑니다.
+
+### 3단계면 끝
+1. 아래 **프롬프트 템플릿**을 복사하고, 맨 아래 `[요구사항]` 칸을 당신 요구로 채웁니다.
+2. 전체를 **AI 에이전트 대화창에 그대로 붙여넣습니다.**
+3. 에이전트가 **첫 응답으로 REQ 번호·브랜치·phase 계획·통제점**만 보고합니다. 이후엔 **통제점에서만** 당신에게 확인을 받습니다 — 나머지(구현·테스트·Codex 리뷰·NEEDS_FIX 반영·재리뷰)는 자동입니다.
+
+### 📋 복사해서 쓰는 프롬프트 템플릿
+
+````text
+이 요청은 일반 구현으로 처리하지 말고, 반드시 이 프로젝트에 설치된 CommitGate(AI REQ workflow)를 사용해라.
+
+아래 [요구사항]으로 새 REQ 티켓을 발행하고 다음 흐름을 끝까지 태워라:
+  req:new → 설계문서(00/01/02) 작성 → req:review-codex(design 리뷰)
+  → phase 구현·테스트 → req:doctor(게이트) → req:review-codex(phase 리뷰) → req:commit
+
+[자동으로 진행할 것]
+- 승인된 phase 범위 안에서 구현·테스트·codex-request 정합·NEEDS_FIX 반영·재리뷰(resume)는 자동으로 진행해라. 매번 확인받지 마라.
+- Codex가 NEEDS_FIX를 주면 지적을 반영하고 재리뷰를 돌려 승인까지 반복해라(phase당 최대 3라운드).
+- 리뷰 대상은 git add 한 것만이다. state.json·responses/ 는 절대 git add 하지 마라(도구가 관리한다).
+
+[멈춰서 사람 확인을 받을 통제점 — 여기서만 멈춰라]
+- req:commit --run 직전 (실제 커밋 / HIGH 영향)
+- main 병합 또는 git push 직전
+- reset·clean·force push 등 destructive 작업
+- 설계 범위 변경 또는 [요구사항]에 없는 기능 추가가 필요할 때
+- Codex 리뷰가 3라운드를 넘겨도 승인 안 되거나 판단이 불명확할 때
+- git 저장소가 아니거나 Codex CLI·Node·패키지매니저 전제가 없어 fail-closed 해야 할 때
+
+[첫 응답] REQ 번호, 브랜치, phase 계획, 통제점만 간단히 보고해라. 그 뒤부터는 통제점에서만 멈춰라.
+
+[요구사항]
+- 무엇을: (예) 사용자 프로필 편집 API 추가
+- 왜:     (예) 지금은 이름만 수정 가능 — 이메일·소개도 편집 필요
+- 제약:   (예) 기존 인증 미들웨어 재사용, 이메일 형식 검증, 외부 라이브러리 추가 금지
+- 완료 기준: (예) PATCH /profile 동작 + 단위 테스트 통과 + 기존 테스트 무손상
+````
+
+> 위 `[요구사항]` 예시는 **샘플일 뿐**입니다. 4줄(무엇을/왜/제약/완료 기준)을 당신 요구로 바꾸기만 하면 됩니다. 요구가 크면 phase가 여러 개로 쪼개지고, 각 phase마다 리뷰·게이트를 거칩니다.
+
+### 에이전트가 보고하는 첫 응답 예시
+
+```
+REQ-2026-002 발행 · 브랜치 feat/req-2026-002-profile-edit-api
+phase 계획:
+  - phase-1: PATCH /profile 핸들러 + 유효성 검증
+  - phase-2: 단위 테스트 + 회귀
+통제점: design 승인 후 phase별 진행 / req:commit --run 직전 확인 / push는 별도 승인
+→ 설계문서 작성부터 진행합니다. design 리뷰 통과하면 구현으로 넘어갑니다.
+```
+
+이제 당신은 통제점 알림이 올 때까지 **기다리기만** 하면 됩니다. 커밋 직전에 "이대로 커밋할까요?" 물으면 확인해 주면 되고요.
+
+---
+
+## 🔧 부록: 워크플로가 내부에서 실제로 하는 일 (수동 단계)
+
+> 위 프롬프트 방식이면 아래 명령을 **직접 칠 필요가 없습니다** — 에이전트가 알아서 실행합니다.
+> 아래는 워크플로가 내부에서 돌리는 실제 명령들입니다. **동작 이해·디버깅·수동 실행**이 필요할 때만 참고하세요.
 
-작은 기능 하나를 예로, 전체 흐름을 그대로 밟아 봅시다. (명령은 `npm` 기준이며, `npm run` 뒤 인자는 `--` 다음에 씁니다. `pnpm`을 쓰면 `pnpm req:new my-feature --run` 처럼 `--` 없이 됩니다.)
+작은 기능 하나를 예로, 전체 흐름을 그대로 밟아 봅니다. (명령은 `npm` 기준이며, `npm run` 뒤 인자는 `--` 다음에 씁니다. `pnpm`을 쓰면 `pnpm req:new my-feature --run` 처럼 `--` 없이 됩니다.)
 
 ### 1단계 — 작업 티켓 만들기
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "commitgate",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "CommitGate — Builder↔Reviewer(Claude↔Codex) fail-closed 커밋 게이트: 리뷰·승인·증거 없인 커밋을 통과시키지 않는 AI REQ 워크플로 kit (req:new/review-codex/doctor/commit)",
   "type": "module",
   "license": "MIT",
@@ -43,7 +43,8 @@
     "bin",
     "AGENTS.template.md",
     "req.config.json.sample",
-    "README.md"
+    "README.md",
+    "README.en.md"
   ],
   "engines": {
     "node": ">=18.17"