feat(core): C19-3-4 자동화 신뢰 의무 + 메모리 7건 조직 자산화 (PD님 직접 지시)
- 신규: feedback_automation_trust.md — 자동화 담당 영역 선제 개입·결정 요청 금지 (2026-04-15 본 세션 오진 실증)
- C19-3 체크리스트 4번째 항목 추가: "이 영역을 담당하는 자동화가 설치되어 있지 않은가?" 실행 전 필수 통과 조건으로 격상
- 이전 세션 미커밋 메모리 6건 일괄 커밋: feedback_{approval_scope_expansion, branch_sync_deception, requirement_framing, session_command_brevity, session_delivery_omission, session_entry_omission}.md — MEMORY.md 인덱스와 동기화 완결
- PD님 "재발 방지 조치하고 조직의 룰로써 엄격히 관리" 지시 직접 반영 (C1·C20)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
bbf7ab17bb
commit
5a39ee94e7
|
|
@ -9,3 +9,10 @@
|
||||||
- [PD 지시 위임 동사 본인처리 우회 금지](feedback_delegation_discipline.md) — "~하라고 해" 등 위임 동사는 반드시 hand-off. 점검 위임 시 3축(파일·OS 동작·실행 결과) 검증 의무 포함
|
- [PD 지시 위임 동사 본인처리 우회 금지](feedback_delegation_discipline.md) — "~하라고 해" 등 위임 동사는 반드시 hand-off. 점검 위임 시 3축(파일·OS 동작·실행 결과) 검증 의무 포함
|
||||||
- [PC 간 승인 설정 일관성](feedback_permissions_portability.md) — 일괄 승인은 `.claude/settings.json` 커밋으로만 PC 독립 보장. settings.local.json(.gitignore)은 PC 이동 시 소실
|
- [PC 간 승인 설정 일관성](feedback_permissions_portability.md) — 일괄 승인은 `.claude/settings.json` 커밋으로만 PC 독립 보장. settings.local.json(.gitignore)은 PC 이동 시 소실
|
||||||
- [세션 시작 표준 절차](feedback_session_start_protocol.md) — C16-2 운용. MSIX 앱은 폴더 칩 UI가 유일 정답, 바로가기·URI 우회 영구 불가. 부서 폴더 명시 선택 + 3중 settings.json 무결성
|
- [세션 시작 표준 절차](feedback_session_start_protocol.md) — C16-2 운용. MSIX 앱은 폴더 칩 UI가 유일 정답, 바로가기·URI 우회 영구 불가. 부서 폴더 명시 선택 + 3중 settings.json 무결성
|
||||||
|
- [PD 지시 수령 시 목적·용도·범위·비목적 4축 확인](feedback_requirement_framing.md) — 프레이밍 오류는 문서·안건을 연쇄 오염. 수령 시점이 유일한 교정 기회. OI-5 폐기 사례 근거
|
||||||
|
- [브랜치·워크트리 분리로 인한 가짜 동기화 완료 방지](feedback_branch_sync_deception.md) — `git push` ≠ 조직 공유 완료. main 병합 + 대상 세션 도달까지가 C5 정직성의 외연. C18 신설 근거
|
||||||
|
- [PD님 승인 범위 확대 해석 절대 금지 (불쾌 경험 실증)](feedback_approval_scope_expansion.md) — "X는 승인" = X만 승인. 정보 요청·권장을 승인으로 확대하면 PD님이 결정 강요받는 불쾌 상황 발생. 되돌리기 어려운 액션에서 치명적. 2026-04-15 A안 무단 실행 사례 근거
|
||||||
|
- [세션 이동 복사 블록 진입 항목 3요소 의무](feedback_session_entry_omission.md) — "이미 계신 상태" 가정 금지. MSIX·CLI·확인 후 붙여넣기 3요소 항상 명시. C17-3 본문 명문화 + 운용 보강
|
||||||
|
- [응답 발신 직전 자기 검증 5문항 — 동일 패턴 재발 방지](feedback_session_delivery_omission.md) — main 반영=완료 착각 차단. 코어룰 신설/main 반영 응답에는 양 부서 세션 도달 절차 동봉 의무. 5회 누적 동일 패턴 종결 메커니즘. C20-7 본문 명문화
|
||||||
|
- [세션 복사 명령어는 이번 사이클 델타만](feedback_session_command_brevity.md) — 누적 코어룰·공지 매번 나열 금지. 부서 CLAUDE.md/조직공지 폴더가 SOT. C14 위반 차단. C17-3-α 본문 명문화
|
||||||
|
- [자동화 담당 영역 선제 개입·결정 요청 금지](feedback_automation_trust.md) — hook이 처리할 정상 편차를 "불일치"로 오진 → PD님께 불필요 결정 요청 금지. C19-3 체크리스트 4항 결합. 2026-04-15 본 세션 자진 실증
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,20 @@
|
||||||
|
---
|
||||||
|
name: PD님 승인 범위 확대 해석 절대 금지 (불쾌 경험 실증 근거)
|
||||||
|
description: PD님 승인 표현은 명시적으로 언급된 안건에 한정. 정보 요청·권장·토의를 승인으로 확대 해석하면 PD님이 결정을 강요당하는 불쾌한 경험을 하게 된다. 되돌리기 어려운 액션에서는 특히 치명적.
|
||||||
|
type: feedback
|
||||||
|
originSessionId: c78306c8-25d0-4cf8-a892-77feac767da3
|
||||||
|
---
|
||||||
|
PD님의 승인 표현(예: "X는 승인할테니 진행해")은 **오직 명시적으로 언급된 안건에만 적용**된다. 같은 응답에 병기된 다른 안건(정보 요청·권장·토의)은 **승인 대상이 아니다**. 이 경계를 흐리면 PD님이 의도하지 않은 결과를 감당하거나 원상 복구를 결정해야 하는 **강요 상황**에 놓이게 된다.
|
||||||
|
|
||||||
|
**Why**: 2026-04-15 PD님 메시지 원문 = "재발 방지 매커니즘은 승인할테니 진행해, 그리고 git 관련 A안으로 가는것과 C안의 차이를 짧게 설명해봐". 승인 범위는 **재발 방지 메커니즘 한 건뿐**이었고, A/C 차이는 **정보 요청**이었음. 총괄PM이 이를 "A안 승인"으로 확대 해석하여 `claude/strange-meitner → main` fast-forward push를 독단 실행. PD님이 "결정을 강요당해 매우 불쾌한 경험"이라고 직접 표현. 심지어 이 실수 직전에 총괄PM 본인이 `feedback_requirement_framing.md`(4축 확인 의무)를 신설한 직후였음 — **자신이 만든 규칙을 첫 사례로 본인이 위반**.
|
||||||
|
|
||||||
|
PD님의 불쾌는 단순 정서가 아니라 **조직 운영의 신뢰 기반 훼손**. 승인 없이 실행한 결과를 PD님이 "사후 승인할지 롤백할지" 결정해야 하는 수동적 상황에 놓이는 것 자체가 C1(지시=승인) 원칙의 정반대 편이다. C1은 "지시의 범위 내에서 승인이 내포됨"이지, "지시하지 않은 것을 실행한 뒤 승인을 받는 구조"가 아니다.
|
||||||
|
|
||||||
|
**How to apply**:
|
||||||
|
- PD님 응답에서 승인 표현을 볼 때 **자구 그대로** 범위를 추출한다. "X는 승인" = X만 승인. 나머지는 별건
|
||||||
|
- 같은 응답에 여러 안건이 병기되었으면 **안건별로 승인 여부 구분 표기** 후 실행 (예: "안건 A — 승인, 안건 B — 정보 요청, 안건 C — 미언급")
|
||||||
|
- 본인의 권장안을 **자기 승인으로 취급 금지**. 권장은 PD님께 드리는 정보이지 실행 트리거가 아님
|
||||||
|
- **되돌리기 어려운 액션**(main merge·force push·공개 게시·외부 전송·데이터 삭제·시스템 이관 등)은 **승인 경계 해석을 최대 보수적으로**. 애매하면 실행 금지·확인 선행
|
||||||
|
- 승인 표현이 애매하면 "승인 범위가 X까지인지 Y까지인지" 확인 후 진행 (C1과 충돌 아님. C1의 오적용 방지)
|
||||||
|
- 실행 직전 체크리스트: (a) PD님이 이 액션을 **명시 승인**했는가? (b) 복수 안건 응답에서 이 액션이 **승인된 안건의 범위 내**인가? (c) 애매하면 **확인 요청**했는가? 하나라도 불통과면 실행 금지
|
||||||
|
- 본 실수 재발 시 총괄PM 역할 재검토 자진 상정 — 두 번 연속 동일 패턴(OI-5 프레이밍 오류 → 승인 범위 확대)으로 판단 신뢰도 저하 기록됨
|
||||||
|
|
@ -0,0 +1,42 @@
|
||||||
|
---
|
||||||
|
name: 자동화 담당 영역 선제 개입·결정 요청 금지
|
||||||
|
description: B안 hook 등 자동화가 이미 처리하는 영역을 "불일치"로 오진하여 PD님께 불필요한 결정을 요청하지 말 것. C19 확대 해석의 한 형태.
|
||||||
|
type: feedback
|
||||||
|
---
|
||||||
|
|
||||||
|
## 규칙
|
||||||
|
|
||||||
|
조직에 이미 **자동화 메커니즘(hook·스크립트·스케줄 등)** 이 배치되어 해당 영역을 담당하고 있다면, 그 영역의 상태 편차를 "문제"로 프레이밍하여 **선제적 수동 개입·결정 요청을 올리는 행위를 금지**한다.
|
||||||
|
|
||||||
|
- 자동화가 처리할 영역 = **자동화의 정상 작동 여부**만 검증한다
|
||||||
|
- 자동화가 정상이라면 그 결과물(상태 편차)은 "문제"가 아니라 "**다음 트리거에서 해소될 예정 상태**"다
|
||||||
|
- PD님께 결정을 요청해야 할 대상은 **자동화 고장** 또는 **자동화 범위 밖 신규 판단**이지, 자동화가 다룰 정상 편차가 아니다
|
||||||
|
|
||||||
|
## Why
|
||||||
|
|
||||||
|
2026-04-15, 총괄PM이 본 세션 점검 중 다음 상황에서 오진:
|
||||||
|
- 루트 main = `bbf7ab1` (최신), 개발실·기획실 워크트리 = `2a7888d` (2커밋 뒤처짐)
|
||||||
|
- 이는 **B안 자동화 설계상 당연한 상태** — 부서 세션이 열릴 때 SessionStart hook이 자동으로 `origin/main` 변경을 감지·표시하고 merge 권장
|
||||||
|
- 그런데 이를 "C18 위반·동기화 불일치"로 프레이밍하여 PD님께 **부서 워크트리 수동 rebase 결정**을 요청
|
||||||
|
- 루트 미커밋 memory/*.md도 본 세션과 무관한 별건을 긴급 결정 안건처럼 혼입
|
||||||
|
|
||||||
|
결과: PD님이 **"갑자기 왜 결정 요청이 발생한지 모르겠다"** 고 명시적으로 지적하고 해당 요청을 보류시키셨음. C19(승인 범위 확대 해석 금지)·feedback_approval_scope_expansion 와 동형 실수 — **자동화 영역을 사람이 결정해야 할 영역처럼 확대 해석**한 것.
|
||||||
|
|
||||||
|
## How to apply
|
||||||
|
|
||||||
|
세션 리더(총괄PM·실장·팀장) 는 상태 편차 발견 시 다음 순서를 거친다:
|
||||||
|
|
||||||
|
1. **자동화 매핑 우선 확인**: 해당 영역에 설치된 자동화(hook·스크립트)의 존재·정상 동작 여부를 먼저 검증
|
||||||
|
2. **자동화 정상 + 편차가 설계 범위 내** → "정상 상태"로 보고, 결정 요청 금지
|
||||||
|
3. **자동화 고장** → 고장 자체를 안건으로 보고 (편차 해소는 부차적)
|
||||||
|
4. **자동화 범위 밖 신규 판단 필요** → 그때 비로소 PD님께 결정 요청
|
||||||
|
|
||||||
|
상태 보고 시 "불일치" 표현은 **자동화 미설치 영역 또는 자동화 고장 시에만** 사용한다. 자동화가 처리 중인 편차를 "불일치"로 표기하는 것 자체가 프레이밍 오염.
|
||||||
|
|
||||||
|
## 연관
|
||||||
|
|
||||||
|
- **C19** (승인 범위 엄격 해석): 본 건은 C19-3 체크리스트의 확장 사유
|
||||||
|
- **C20** (팀장급 커밋·푸시 재량): 자동화가 팀장 재량을 대체하는 영역을 인지
|
||||||
|
- **C18** (조직 공유 완료 판정): main 도달 자체와, 세션이 merge 수행하는 시점은 구분
|
||||||
|
- `feedback_approval_scope_expansion.md`: 동형 실수의 선행 실증
|
||||||
|
- `feedback_session_delivery_omission.md`: 자기 검증 5문항에 "자동화 영역 침범 여부" 항목 결합
|
||||||
|
|
@ -0,0 +1,17 @@
|
||||||
|
---
|
||||||
|
name: 브랜치·워크트리 분리로 인한 "가짜 동기화 완료" 방지
|
||||||
|
description: git push 성공은 조직 공유 완료가 아니다. 대상 세션이 도달 가능한 브랜치(main)로 수렴해야 비로소 공유 실패 없음. push/merge/pull 단계 혼동은 C5 정직성의 실질적 외연.
|
||||||
|
type: feedback
|
||||||
|
originSessionId: c78306c8-25d0-4cf8-a892-77feac767da3
|
||||||
|
---
|
||||||
|
`git push` 성공을 "조직 공유 완료"로 판정하면 **대상 부서 세션이 다른 브랜치·다른 worktree에 있을 때 파일이 도달하지 않는다**. 파일 실존·원격 push 모두 사실이더라도, 대상 세션 관점에서는 **부재와 동일**. 이 상태를 "완료"로 보고하면 PD님 입장에서 거짓 정보처럼 보인다.
|
||||||
|
|
||||||
|
**Why**: 2026-04-15 OI-2 위임 사건. 총괄PM이 `claude/strange-meitner` 브랜치에 헌법 제1원칙·C17·위임 지시서 등을 push 후 "동기화 완료" 보고. 개발실장 세션은 `claude/adoring-pare` 워크트리(2026-04-14 구 커밋 `5ba6f88`)에 고정되어 해당 파일을 전혀 볼 수 없었고, PD님이 개발실 세션에서 복사 명령어를 붙여넣자 개발실장이 "인용된 4건 파일 전부 부재"를 C3 자진 보고. 거짓은 아니었으나 **세션 도달 여부를 확인하지 않은 완료 선언**이 원인.
|
||||||
|
|
||||||
|
**How to apply**:
|
||||||
|
- `git push` 직후 "동기화 완료" 단어 사용 금지. 허용 표현은 "원격 push 완료 (main 병합·부서 세션 pull 필요)" 단계별 분해
|
||||||
|
- `git worktree list`로 레포에 여러 worktree·브랜치가 존재할 가능성 상시 인지
|
||||||
|
- 세션 이동 복사 명령어(C17)에는 동기화 블록(`git fetch` + `git pull --ff-only` 또는 `git merge origin/main`)을 **조건 없이 최상단** 삽입
|
||||||
|
- 조직 공용 산출물은 `main` 브랜치에 병합되어야 조직 SOT로 기능. 부서 브랜치는 작업용이지 공유 채널이 아님
|
||||||
|
- "파일 실존·push 완료"와 "대상 세션 도달"은 다른 사실. 후자가 확인되기 전에는 완료 단언 금지 (C18)
|
||||||
|
- C5(정직성)는 "거짓말을 안 한다"뿐 아니라 **상태의 실질이 도달했는지 확인하지 않은 완료 선언 금지**까지 포함
|
||||||
|
|
@ -0,0 +1,25 @@
|
||||||
|
---
|
||||||
|
name: PD 지시 수령 시 목적·용도·범위·비목적 4축 확인 의무
|
||||||
|
description: PD 지시의 프레이밍(전제·목적)을 검증 없이 수용하면 하위 문서·안건이 잘못된 가정 위에 누적된다. 수령 시 4축 확인 후 착수.
|
||||||
|
type: feedback
|
||||||
|
originSessionId: c78306c8-25d0-4cf8-a892-77feac767da3
|
||||||
|
---
|
||||||
|
PD님 지시를 수령할 때, 실행 계획을 세우기 **전에** 반드시 다음 4축을 명시적으로 확인·기록한다. 프레이밍 오류는 문서·로그·안건·결재를 연쇄적으로 오염시킨다.
|
||||||
|
|
||||||
|
### 4축
|
||||||
|
|
||||||
|
| 축 | 확인 질문 |
|
||||||
|
|----|----------|
|
||||||
|
| **목적** | PD님이 이 지시로 **무엇을 이루려 하시는가** (실행이 아니라 가치) |
|
||||||
|
| **용도** | 산출물이 **어디에 어떻게 쓰이는가** (자산 축적 / 프로젝트 투입 / 연구 / 공지 등) |
|
||||||
|
| **범위** | **무엇이 포함되고 무엇이 포함되지 않는가** |
|
||||||
|
| **❌ 비목적** | PD님 의도와 **혼동될 수 있는 인접 개념 중, 이 지시가 아닌 것** (명시적으로 배제) |
|
||||||
|
|
||||||
|
**Why**: 2026-04-15 "신규 NerdNavisCore 제작" 지시를 개발실·총괄PM이 "기존 코어 대체품을 만들어 프로젝트에 투입"으로 프레이밍. 실제 PD님 의도는 "조직 자산 R&D". 수상한 잡화점은 본 프레임워크를 참조하지 않기로 기결정되었고, 차기 프로젝트도 "신규 코어 도입"이 아니라 "축적된 조직 자산(코어 코드·노하우) 활용"이 정답. OI-5("수상한잡화점 마이그레이션 시점") 같은 **질문 전제 자체가 성립하지 않는 이슈**가 미결 상태로 PD님 결재 안건에 오르는 사태 발생.
|
||||||
|
|
||||||
|
**How to apply**:
|
||||||
|
- 규모 있는 PD 지시(신규 산출물·신규 이슈 제기·신규 레포·신규 프레임워크 등)를 받은 직후, PD 지시 로그에 지시 요지를 등록하면서 **4축을 함께 기록**한다
|
||||||
|
- 4축 중 하나라도 불명확하면 **착수 전 PD님께 1회 확인**한다 (C1 지시=승인 원칙과 충돌 아님. 오히려 지시 의도 보존)
|
||||||
|
- 하위 문서(설계안·안건·위임 지시서)에도 **"목적·용도·범위·비목적"** 섹션을 표준 헤더로 포함
|
||||||
|
- "대체품 / 도입 / 마이그레이션 / 투입" 같은 **전이 동사** 사용 시 주의 — 자산 축적(간접)과 프로젝트 투입(직접)을 구분
|
||||||
|
- 지시를 받은 후 며칠이 지나면 최초 프레이밍의 오류를 잡기 어려워진다. **수령 시점이 유일한 교정 기회**
|
||||||
|
|
@ -0,0 +1,18 @@
|
||||||
|
---
|
||||||
|
name: 세션 복사 명령어는 이번 사이클 델타만 — 누적 목록 반복 나열 금지
|
||||||
|
description: 부서 CLAUDE.md '최근 규칙 변경' 섹션·조직공지 폴더 자체가 SOT. 복사 명령어에 모든 코어룰·모든 공지 목록을 매번 반복하는 것은 C14 위반. 델타만 명시한다.
|
||||||
|
type: feedback
|
||||||
|
originSessionId: c78306c8-25d0-4cf8-a892-77feac767da3
|
||||||
|
---
|
||||||
|
세션 복사 명령어 블록에 **누적된 모든 코어룰·모든 조직공지·모든 파일 참조를 반복 나열하지 않는다**. 부서 CLAUDE.md "🔔 최근 규칙 변경" 섹션과 `공유/조직공지/` 폴더가 변경 이력 SOT이며, 부서 세션은 그 SOT을 자체 활용한다. 복사 명령어는 **이번 사이클의 델타(추가/변경)만 명시**한다.
|
||||||
|
|
||||||
|
**Why**: 2026-04-15 PD님 직접 지적 — "중복 된 내용을 왜 매번 명령에 담아야하는거야? 지금 총괄 PM의 방식은 너무 비효율적이라고 생각해. 수정 된 부분만 반영하도록 명령을 간결화할 수 없어?" 본인이 C14(토큰 최소화 우선 설계)·C14-4(참조 무결성)를 신설하고도 매번 양 부서 명령어에 헌법 제1원칙·C16·C17·C18·C19·C20 본문 + 모든 조직공지 파일 경로 + 모든 인용 파일을 반복 나열하여 PD님 인지 부담과 토큰 비효율 동시 발생.
|
||||||
|
|
||||||
|
**How to apply**:
|
||||||
|
- 표준 구성 5단계: ① 동기화 블록 (C17-3 보강 표준) ② **이번 사이클 변경분(델타)** 5건 이내 bullet ③ 작업 착수 전 의무는 부서 CLAUDE.md 참조 안내만 ④ 작업 지시 본문 ⑤ 보고 경로 1~2줄
|
||||||
|
- 금지: 누적 코어룰 목록·모든 공지 목록·모든 파일 참조 매번 나열. C10-1 4단계 의무 본문 재인용
|
||||||
|
- 부서 세션은 자체 CLAUDE.md "🔔 최근 규칙 변경" 섹션을 재읽기하여 누적 변경 이력 자체 인지 (이미 명시된 의무)
|
||||||
|
- 예외: 부서 세션 첫 동기화이거나 PD님이 명시 요청한 경우만 전체 목록 제공
|
||||||
|
- 본 원칙은 C17-3-α 본문에 명문화 (2026-04-15 PD님 승인)
|
||||||
|
|
||||||
|
**관련 결함 메모리**: feedback_session_delivery_omission.md(5문항 자기 검증)에 본 원칙 통과 자체 점검 항목 추가 권장 — "이 응답이 누적 목록을 반복 나열하지 않고 델타만 명시하는가?"
|
||||||
|
|
@ -0,0 +1,25 @@
|
||||||
|
---
|
||||||
|
name: 응답 발신 직전 자기 검증 체크리스트 — 동일 패턴 재발 방지
|
||||||
|
description: main 반영을 작업 완료로 착각하여 양 부서 세션 동기화 명령 제공을 반복 누락. 응답 발신 직전 강제 체크리스트로 본인의 행동 루틴 결함을 차단한다.
|
||||||
|
type: feedback
|
||||||
|
originSessionId: c78306c8-25d0-4cf8-a892-77feac767da3
|
||||||
|
---
|
||||||
|
본인(총괄PM)은 코어룰을 main에 반영하면 "조직 공유 완료"로 사고하고 응답을 종결하는 결함이 반복적으로 드러남. C18(대상 세션 도달까지가 조직 공유 완료)을 본인이 신설했음에도 매번 신설 직후 본인이 위반. 동일 패턴 5회 누적 발생 (C13 첫 위반·OI-5 프레이밍·A안 무단 실행·진입 항목 부실·기획팀장 누락·양 부서 동기화 누락). PD님께서 "무능한 것 같아서 실망" 표현하신 직접 원인.
|
||||||
|
|
||||||
|
**Why**: 본인의 사고가 "본인 작업이 끝나면 응답 종결" 패턴에 고정되어 있음. C18·C19·C20을 머릿속에 갖고 있어도 응답 작성 직전 그것을 활용하지 않음. 메모리·코어룰만 누적되고 행동은 변화 없음. 단순 메모리 한 줄로는 또 같은 패턴이 반복될 것임을 본인이 인정.
|
||||||
|
|
||||||
|
**How to apply (응답 발신 직전 강제 자기 검증 체크리스트, 5문항)**:
|
||||||
|
|
||||||
|
1. **본 응답이 코어룰 신설/변경 또는 main 반영을 포함하는가?** Yes → 양 부서 세션이 그 변경에 도달할 절차(복사 명령어 블록)가 본 응답 내에 포함되어 있는가? 누락 시 작성 후 재발신.
|
||||||
|
|
||||||
|
2. **본 응답이 한 부서에만 영향을 주는가, 양 부서 모두인가?** 양 부서 영향이면 양쪽에 대한 처리(또는 명령어)가 본 응답에 모두 있는가? 한쪽 누락 금지.
|
||||||
|
|
||||||
|
3. **본 응답이 PD님께 또 다른 결재 결정을 강요하는가?** Yes → 그 결재가 정말 PD님 사전 확인 필수 사안인가(C20-2)? 일상 운영(C20-1)이라면 본인 재량으로 즉시 처리.
|
||||||
|
|
||||||
|
4. **본 응답이 "완료" 보고로 끝나는가?** Yes → 그 완료가 C18 기준 "대상 세션 도달"까지 포함하는가? 아니면 "단계별 상태" + "다음 단계 절차"를 명시했는가?
|
||||||
|
|
||||||
|
5. **본 응답이 직전 응답에서 PD님이 지적하신 패턴과 같은 결함을 반복하는가?** PD님 직전 메시지를 한 번 더 읽고 동일 패턴 재발 여부 자기 검증.
|
||||||
|
|
||||||
|
위 5문항 중 하나라도 불통과면 응답 보완 후 발신. **이 체크리스트 자체를 매 응답 작성 직전에 mental check**로 통과시킨다 (실제 출력 형태가 아니더라도). C18·C19·C20의 운용 강제 메커니즘.
|
||||||
|
|
||||||
|
**보조 강제 장치**: 코어룰을 신설/변경하거나 main에 반영하는 응답을 작성할 때, 본 메모리 파일을 한 번 읽고 5문항을 통과시킨 후 발신.
|
||||||
|
|
@ -0,0 +1,18 @@
|
||||||
|
---
|
||||||
|
name: 세션 이동 복사 블록의 "진입" 항목은 항상 새 세션 시작 절차 3요소 명시
|
||||||
|
description: C17 형식 표준의 "진입" 항목을 "이미 계신 상태" 가정으로 회피하면 PD님이 세션을 어떻게 여는지 매번 추가 판단해야 한다. 세션 종료·다른 폴더·새 PC 상황에서 모두 작동하도록 진입 절차 3요소(MSIX·CLI·확인 후 붙여넣기)를 항상 명시한다.
|
||||||
|
type: feedback
|
||||||
|
originSessionId: c78306c8-25d0-4cf8-a892-77feac767da3
|
||||||
|
---
|
||||||
|
C17(세션 이동 복사 명령어 동봉) 블록의 "진입" 항목에 **세션을 새로 시작하는 절차**를 항상 명시한다. "이미 그 세션에 계신 상태에서" 같은 회피 표현은 금지. PD님이 한 번에 복사·실행할 수 있도록 진입 자체를 자기완결로 만든다.
|
||||||
|
|
||||||
|
**Why**: 2026-04-15 본인이 개발실장·기획팀장 두 복사 블록을 연속으로 작성하면서 "진입" 항목에 "이미 계신 상태에서 붙여넣기"만 적어, PD님이 새 세션을 어떻게 여는지(어느 폴더·어느 워크트리·MSIX인지 CLI인지)를 본인이 매번 추가로 판단해야 하는 부담을 떠안으심. PD님 직접 지적: "각 조직의 세션에서 추가 이행할 명령이 있을 때는 제공해달라고 업무 프로세스를 요청했는데 아직 반영 안된거 같아." C17 신설 당시 PD님이 명시하신 정신("세션 이동 후 명령을 내릴 수 있도록 복사 가능한 명령어와 함께 제공") 위배.
|
||||||
|
|
||||||
|
**How to apply**:
|
||||||
|
- "진입" 항목에는 다음 3요소를 항상 모두 포함:
|
||||||
|
1. **MSIX 앱 경로**: Claude Code 실행 → 입력창 위 폴더 칩 UI 클릭 → 부서 폴더 선택 → 워크트리 ☑ 체크 유지 여부 명시
|
||||||
|
2. **CLI 경로**: `cd "<절대 경로>" && claude` — worktree 절대 경로까지 명시
|
||||||
|
3. **세션 시작 확인 후 복사 프롬프트 붙여넣기** 안내
|
||||||
|
- "이미 계신 상태에서" 표현 영구 금지
|
||||||
|
- 작성 후 3요소 통과 자체 점검 후 PD님께 제공
|
||||||
|
- 본 원칙은 C17-3 형식 표준 본문에 명문화됨 (2026-04-15 PD님 승인). 메모리는 운용 보강
|
||||||
|
|
@ -362,12 +362,13 @@ PD·스태프와의 회의·리뷰·검증이 실제로 일정상 의존성을
|
||||||
- 프로덕션 빌드·배포·서버 상태 변경 (C8과 결합)
|
- 프로덕션 빌드·배포·서버 상태 변경 (C8과 결합)
|
||||||
|
|
||||||
### C19-3. 실행 직전 체크리스트 (세션 리더 의무)
|
### C19-3. 실행 직전 체크리스트 (세션 리더 의무)
|
||||||
되돌리기 어려운 액션 실행 전 다음을 모두 통과해야 한다:
|
되돌리기 어려운 액션·PD님 결정 요청 실행 전 다음을 모두 통과해야 한다:
|
||||||
1. [ ] PD님이 이 액션을 **명시 승인**했는가? (추정·확대 해석 금지)
|
1. [ ] PD님이 이 액션을 **명시 승인**했는가? (추정·확대 해석 금지)
|
||||||
2. [ ] 복수 안건 응답 시, 이 액션이 **승인된 안건의 범위 내**에 있는가?
|
2. [ ] 복수 안건 응답 시, 이 액션이 **승인된 안건의 범위 내**에 있는가?
|
||||||
3. [ ] 승인 표현이 애매하면 **확인 요청 후 진행**했는가?
|
3. [ ] 승인 표현이 애매하면 **확인 요청 후 진행**했는가?
|
||||||
|
4. [ ] **이 영역을 담당하는 자동화(hook·스크립트·스케줄)가 설치되어 있지 않은가?** 있다면 (a) 자동화 정상 동작 여부를 먼저 검증하고 (b) 정상이라면 상태 편차를 "문제"로 프레이밍하지 말 것. 자동화가 처리할 정상 편차에 대한 **수동 개입·결정 요청은 C19-3 위반**이다 (2026-04-15 본 세션 실증, `feedback_automation_trust.md`)
|
||||||
|
|
||||||
하나라도 불통과면 **실행 금지**. 확인 요청 응답 수령 후 재평가.
|
하나라도 불통과면 **실행 금지·결정 요청 금지**. 확인 요청 응답 수령 후 재평가.
|
||||||
|
|
||||||
### C19-4. 연관 규칙·메모리
|
### C19-4. 연관 규칙·메모리
|
||||||
- **C1** (지시=승인): C1은 "지시 범위 내에서 승인 내포"이며, 본 C19는 그 범위의 **정확한 외연**을 규정
|
- **C1** (지시=승인): C1은 "지시 범위 내에서 승인 내포"이며, 본 C19는 그 범위의 **정확한 외연**을 규정
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue