v0.23.1

전체 변경 이력: CHANGELOG.md

stopGate: "auto" 의 통합 게이트를 세 군데에서 조입니다 — 그리고 설치 계약을 도구와 맞춥니다.

🔴 0.23.0 을 쓰신다면 올리시는 것을 권합니다. 0.23.0 의 AGENTS.template.md 는 설치 프로젝트로
복사되는 에이전트 계약인데, stopGate 를 phase/req/merge 만 열거하고 "통합 승인은 어느
값에서도 필요하다"고 적었습니다. 도구는 auto + 유효 위임에서 다시 묻지 않으므로 계약이 도구와
반대로 말하고 있었고, 새 프로젝트의 에이전트는 계약을 따라 불필요하게 멈춥니다.

stopGate: "auto" 를 쓰는 경우 통합 게이트에 세 갈래 우회가 있었습니다. 셋 다 티켓을 만들 때
확정된 정책이 최종 통합에서 약해지는 형태입니다:
① 최종 integrate 만 정본 resolver 를 쓰지 않아 나중에 설정을 바꾸면 위임 없이 병합됐습니다.
② 브랜치 이름을 바꾸면(feat/req-renamed) 정책 대상을 잃고 현재 설정으로 폴백했습니다.
③ 대상·정책을 판정할 수 없을 때 HIGH·hardCap·BLOCKED 가 평가되지 않은 채 사람 확인만으로
열릴 수 있었습니다.

업그레이드(패치이므로 caret 범위 안입니다):

npm i -D commitgate@0.23.1
npx commitgate sync --apply --gitignore   # 배포 템플릿 자산 동기화
npx commitgate check                      # C5 가 옛 계약 문장을 짚어 줍니다

🔴 AGENTS.md 는 사용자 소유라 도구가 고치지 않습니다. check 의 C5 가 옛 문장을 구체적으로
알려 주고, 관리 블록(commitgate:autonomy)은 npx commitgate quickstart --apply 로 갱신합니다.
🔴 동작 변경 세 가지(전부 fail-closed 방향): 티켓 state.json·묶음 레코드를 읽지 못하면 ·
정책 대상을 확정할 수 없으면 · 그 상태에서 읽힌 대상이 HIGH·hardCap·BLOCKED 이면 —
비대화형은 거부하고, 대화형은 최종 확인으로 사람이 판단합니다(마지막 것은 사람 확인으로도 열리지
않습니다).

• fix: "사람 확인으로 통합하세요"라는 안내가 실제로는 실행되지 않던 문제 — stopGate: "auto" 에서
  통합 대상을 브랜치 이름에서 확정할 수 없으면(delivery/<slug> 도 <branchPrefix><연도>-<번호>-…
  도 아닌 이름) 도구는 거부하면서 "사람 확인으로 통합하세요"라고 안내했지만, 대화형에서도 즉시
  멈췄습니다 — y 를 입력할 기회가 없었습니다.

  • 이제 이 경우에만 대화형 최종 확인([y/N] 기본 No)으로 사람이 직접 통합할 수 있습니다.
    위임이 없으므로 로컬 병합까지만이고 push 하지 않습니다.
  • 🔴 열리는 것은 이것 하나뿐입니다. 위임 부재·만료·철회·이미 소비 · trunk 이동 ·
    source 불일치 · 위임 범위 밖 변경 · HIGH 미위임 · hardCap 도달 · 리뷰 BLOCKED 는
    사람 확인으로도 열리지 않습니다.
  • 🔴 설계 리뷰가 보안 우회를 잡았습니다: 처음 설계는 scope 를 못 읽으면 곧바로 대화형 확인으로
    넘겼는데, 그 경로에서는 riskLevel·hardCap·리뷰 상태가 아예 평가되지 않습니다(scope 가
    없으면 사실을 수집하지 않았기 때문입니다). HIGH 티켓이 y 하나로 통과할 수 있었습니다.
    이제 커밋 귀속으로 찾은 정책 대상의 위험 사실을 먼저 합쳐 평가하고, 그 셋 중 하나라도
    성립하면 거부합니다. HIGH 는 --high-risk 위임으로만 풀리는데 이 경로에는 위임 자체가 없습니다.
  • 🔴 판정은 두 자리에 있습니다(phase-1 r01 P1). 정책 자체가 판정 불가면 위임 게이트를 아예
    돌리지 않으므로, 그 분기에서도 같은 함수로 HIGH·hardCap·BLOCKED 를 먼저 봅니다.
  • 🔴 읽지 못한 state 는 "위험"이 아니라 "모름"입니다. 도구는 state 를 못 읽으면 위험도를
    HIGH 로 되돌리는데, 그것을 실제 사실처럼 쓰면 ① "HIGH 라서 막혔다"는 거짓 사유를 말하고
    ② 직전 판의 "판정 불가는 사람이 확인할 수 있다" 경로를 영구히 닫습니다. 그래서 이 판정은
    읽은 state 만 모아서 합니다.
  • 🔴 거부 사유를 문자열로 재분류하지 않습니다 — 판정은 생산 지점에서 타입으로 합니다
    (manual-confirmation-required). 문자열을 보고 열어 줄지 정하면 문구가 바뀌는 순간 조용히 열립니다.
  • 계약(AGENTS.template.md)과 워크플로 문서(한/영)가 "열리는 것 하나 / 열리지 않는 것 전부" 를
    구분해 적고, 회귀 가드가 "열리지 않는다" 쪽 문장이 없으면 red 입니다 — 열리는 쪽만 검사하면
    절반만 지킵니다.

  확인할 파일: bin/integrate.ts(delegationGate 의 scope === null 분기) ·
  tests/unit/integrate-delegation.test.ts(④⑤⑥⑦ 이 핵심 오라클)

• fix: auto 로 만든 티켓의 통합 통제가 나중 설정 변경으로 약해지던 문제 — commitgate integrate
  만 정본 resolver(effectiveStopGate)를 쓰지 않고 현재 req.config.json 의 stopGate 를 그대로
  읽고 있었습니다. 그래서 stopGate: "auto" 로 만든 티켓을 나중에 설정이 merge 로 바뀐 뒤
  비대화형에서 integrate --run 하면, 위임 검사가 꺼지고(설정이 merge 라서) 최종 확인도 묻지
  않아(비대화형) 사전 위임 없이 main 에 병합됐습니다. 반대로 merge 로 시작한 티켓이 나중
  auto 설정을 만나 없던 위임 요구를 받는 경우도 있었습니다.

  • 이제 티켓이 만들어질 때 확정된 정책이 phase 진행부터 최종 통합까지 그대로 갑니다.
  • 🔴 합치기 규칙을 새로 만들지 않고 멤버마다 effectiveStopGate 를 적용한 뒤 그 결과만
    합칩니다(설계 r01 P1). "그 외 → 설정값" 으로 접으면 유효한 merge 스냅샷이 버려져
    묶음 통합에서 없던 위임 요구가 생깁니다. 묶음은 하나라도 auto 면 위임이 필요합니다 —
    한 번에 병합되므로 그 티켓의 통제가 사라지기 때문입니다.
  • 🔴 의도적 동작 변경 ①: 통합 대상 SHA 의 트리에서 티켓 state.json 이나 묶음 레코드를
    읽지 못하면 정책을 판정할 수 없습니다. 비대화형은 거부하고(fail-closed), 대화형은 최종
    확인([y/N] 기본 No)으로 사람이 판단합니다. 같은 입력을 못 읽으면 위험도는 이미 HIGH 로
    되돌리는데 정책만 "모르니까 통과"로 읽을 수는 없습니다.
  • 🔴 의도적 동작 변경 ②: 정책 대상을 확정할 수 없으면 같은 처리를 합니다. 예전에는
    브랜치에서 대상을 못 읽으면 "현재 설정을 따른다"로 폴백했는데, 그것이 우회 통로였습니다 —
    branchPrefix 만 만족하고 REQ 번호 형식이 아닌 브랜치(feat/req-renamed)로 이름을 바꾸면
    auto 스냅샷이 통째로 무시됐습니다.
    • 정책 대상과 위임 대상을 분리했습니다. 위임 권한은 지금까지처럼 브랜치에서 확정한
      대상만 쓰고(원장을 뒤져 위임을 고르게 하면 그 선택이 곧 권한 확대입니다), 정책은
      범위의 커밋 귀속에서도 티켓을 찾습니다.
    • 귀속되지 않은 커밋이 하나라도 있거나 묶음 멤버를 읽지 못하면 모름입니다 — "없음"으로
      읽지 않습니다.
  • 판정 근거를 보고에 출력합니다(정책: REQ-…: 스냅샷 auto → 사전 위임 필요).
  • hardCap · HIGH · BLOCKED · 범위 밖 변경 · 위임 만료/철회/소비 정지는 그대로입니다.

• fix: 설치되는 에이전트 계약이 auto 를 부정하던 문제 — AGENTS.template.md 가 정지 지점을
  phase/req/merge 만 열거하고 "통합 승인은 어느 값에서도 필요하다"고 적었습니다. 도구는
  auto + 유효 위임에서 다시 묻지 않으므로 계약이 반대로 말하고 있었고, 이 파일은 설치
  프로젝트로 복사되는 계약이라 모든 소비자의 에이전트가 그것을 읽습니다.
  🔴 도구가 맞아도 계약이 틀리면 에이전트는 계약을 따릅니다 — 새 프로젝트에서 위임이 있는데도
  통합에서 멈추게 됩니다.

  • 계약이 auto 의 양쪽을 적습니다: 유효 위임이 없으면 merge 와 똑같이 멈추고, 있으면 사람이
    다시 승인하지 않습니다. auto 에서도 멈추는 다섯(HIGH 미위임 · hardCap · BLOCKED ·
    위임 범위 밖 변경 · 만료/철회/소비)도 함께 적습니다.
  • 관리 블록 commitgate:autonomy 의 예외표도 고쳤습니다 — 같은 파일 안에서 이 표만 옛말이면
    에이전트는 이 표를 읽습니다. R1/R2/R3(tag·publish·release)는 위임 대상이 아닙니다.
  • 같은 주장이 남아 있던 곳을 전수로 훑었습니다: docs/configuration.md(한/영) 요약 행 ·
    docs/workflow.md(한/영) 자율 진행 절 · docs/ssot-design/04 · scripts/req/lib/config.ts 주석.
  • 기존 설치본은 자동으로 고치지 않습니다(AGENTS.md 는 사용자 소유). 대신 옛 문장을
    retired-claims 정본에 등재해 commitgate check C5 · req:doctor D29 가 구체적으로
    통지합니다. 관리 블록은 commitgate quickstart --apply 로 갱신할 수 있습니다.
  • 계약과 워크플로 문서에 **"권한 판단은 설정값이나 브랜치 이름만으로 내려지지 않는다"**를
    명시했습니다.
  • 회귀 가드는 정지 지점 열거를 CONFIG_SCHEMA 의 enum 에서 파생합니다 — 축이 늘면 자동으로
    red 입니다. 🔴 처음 만든 가드는 검사 범위가 넓어 열거에서 auto 를 지워도 통과했습니다
    (바로 아래 항목의 auto 가 대신 만족시켰습니다). 변이 검사가 그것을 잡아 범위를 좁혔습니다.