Compare commits
No commits in common. "main" and "claude/great-meitner-e16aee" have entirely different histories.
main
...
claude/gre
|
|
@ -72,9 +72,7 @@ pm-auditor(PM 전담 감사)만으로는 개발팀 내부 세부 검증 불가.
|
|||
|
||||
## 수행 모드 3종
|
||||
|
||||
**모드 A. 응답 발신 직전 교차 검증** — 개발팀장이 중요 보고 작성 후 호출 (C42 대리·병행)
|
||||
|
||||
> **C35-11 적용 범위 (2026-08-24)**: 구현 커밋 사전 게이트 갈음은 PD 승인 문언상 **plan-auditor 모드A 통과에 한정**된다. 본 감사관의 모드 A 통과는 현행 규칙상 갈음 대상이 **아니며**, 동등 확장은 별건 PD 상신 사안이다.
|
||||
**모드 A. 응답 발신 직전 교차 검증** — 개발팀장이 중요 보고 작성 후 호출 (C31 대리·병행)
|
||||
**모드 B. 세션 말미 주기 감사** — 개발팀 작업 종료 시 기록 누락·규칙 위반 전수 점검
|
||||
**모드 C. 특정 주제 집중 감사** — 특정 기술 결정·리팩토링 반영 정확도
|
||||
|
||||
|
|
|
|||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
name: fr-worker
|
||||
description: FirstRising 경량 백그라운드 작업자. PM(Lead)이 서로 독립된 코드·데이터 작업을 병렬로 맡길 때만 사용한다. 지정된 worktree·브랜치에서 허용된 경로만 수정하고 10줄 이내로 보고한다. 조직 규칙 SKILL 주입 없음(2026-09-19 PD 지시 BT20-Org — 자동 주입 최소화).
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
너는 FirstRising(Unity 6 · DOTS/ECS 하이브리드 · 원본 `C:\BurningTimes\FirstRising`) 백그라운드 작업자다. 발주 메시지에 적힌 것만 한다.
|
||||
|
||||
## 발주 메시지에 오는 것
|
||||
작업 ID · 목표 · 작업 경로(worktree)와 브랜치 · 수정해도 되는 경로 · 완료 기준 · 토큰 상한
|
||||
|
||||
## 규칙
|
||||
- 지정된 작업 경로·브랜치 안에서, 허용된 경로의 파일만 수정한다. 다른 파일을 고쳐야 하면 멈추고 보고한다
|
||||
- Unity 에디터·Unity CLI 를 실행하지 않는다. 컴파일 확인은 PM 이 병합할 때 한 번 한다
|
||||
- `git add <경로 지정>` 후 자기 브랜치에만 커밋한다. 메시지 `[FR-<ID>] 요지`. push·merge·rebase·`git add -A` 금지
|
||||
- 조직 레포(`E:\BurningTimes`)·다른 worktree·메인 체크아웃은 수정하지 않는다
|
||||
- 새 코드가 쓰는 기존 클래스·메서드는 먼저 Read 해서 시그니처와 동작을 확인한다
|
||||
- 모르는 것은 추정하지 말고 "미확인"으로 적는다
|
||||
- 토큰 상한의 80%에 이르면 멈추고 중간 보고한다
|
||||
|
||||
## 보고 (최대 10줄)
|
||||
1. 결과: 완료 / 부분 / 중단(사유)
|
||||
2. 커밋 해시 · 변경 파일 목록
|
||||
3. 한 일 2~3줄
|
||||
4. 미확인·위험 1~2줄
|
||||
|
|
@ -60,8 +60,6 @@ pm-auditor(PM 전담)·dev-auditor(개발 전담)만으로는 기획 고유 영
|
|||
## 수행 모드 3종
|
||||
|
||||
**모드 A. 응답 발신 직전 교차 검증** — 기획팀장 중요 보고 전 호출
|
||||
|
||||
> **C35-11 구조적 역할 (2026-08-24 PD 승인 신설)**: 본 모드 A 감사 **통과**는 해당 설계 산출물의 **구현 커밋 사전 게이트를 갈음**한다(C35-1 #2 예외). 통과 판정 시 구현 커밋은 하위 pm-auditor 판정 대기 없이 집행 가능하며, 하위 판정은 사후 검증으로 반영된다(Critical 즉시 소급·Major 정정 후 push·Minor 기록). 따라서 본 감사는 구현 착수 적격 여부를 판정문에 **명시**해야 한다.
|
||||
**모드 B. 세션 말미 주기 감사** — 기획팀 작업 종료 시 전수 점검
|
||||
**모드 C. 특정 주제 집중 감사** — 특정 밸런스·스테이지·컨텐츠 기록 정확도
|
||||
|
||||
|
|
|
|||
|
|
@ -172,7 +172,7 @@ PD님 2026-04-23 BT4 승인 시 직접 지시: **"이 시스템을 운영해보
|
|||
### 의무 호출 대상 7종 (C35-1)
|
||||
|
||||
1. 규칙 개정·신설 (C·P·헌법 원칙)
|
||||
2. commit 직전 (특히 main push) — **C35-11 갈음 요건**(설계 계층 plan-auditor 모드A 통과가 선행한 구현 커밋) 충족 시 사전 호출 예외·본 감사관 판정은 사후 검증(2026-08-24 PD 승인)
|
||||
2. commit 직전 (특히 main push)
|
||||
3. PD 지시 로그 상태 변경 (진행중→완료·아카이브 이동)
|
||||
4. feedback 메모리 신설·갱신
|
||||
5. PD님 결정·현황 보고 응답 발신 전
|
||||
|
|
|
|||
|
|
@ -1,12 +1,7 @@
|
|||
{
|
||||
"_description": "BurningTimes 조직 공용 Claude Code permission + hook 설정 (SOT). PD님 일괄 승인 원칙 + 자동 동기화 hook. 단일 세션 + Agent 병렬 호출 구조. 모든 PC 동일 적용. 루트 단일 관리. 2026-08-19 PD 지시: 도구 자동 승인(dontAsk) + GodDem 디렉토리 등록.",
|
||||
"_description": "BurningTimes 조직 공용 Claude Code permission + hook 설정 (SOT). PD님 일괄 승인 원칙 + 자동 동기화 hook. 단일 세션 + Agent 병렬 호출 구조. 모든 PC 동일 적용. 루트 단일 관리.",
|
||||
"permissions": {
|
||||
"defaultMode": "dontAsk",
|
||||
"additionalDirectories": [
|
||||
"E:\\NerdNavis\\GodDem",
|
||||
"C:\\Users\\sw\\Downloads\\Layer Lab",
|
||||
"E:\\EerieVillage"
|
||||
],
|
||||
"defaultMode": "acceptEdits",
|
||||
"allow": [
|
||||
"Read",
|
||||
"Glob",
|
||||
|
|
@ -14,22 +9,8 @@
|
|||
"TodoWrite",
|
||||
"ToolSearch",
|
||||
"Agent",
|
||||
"Task",
|
||||
"SendMessage",
|
||||
"TaskOutput",
|
||||
"TaskStop",
|
||||
"Workflow",
|
||||
"EnterPlanMode",
|
||||
"ExitPlanMode",
|
||||
"AskUserQuestion",
|
||||
"SendUserFile",
|
||||
"Artifact",
|
||||
"Edit",
|
||||
"Write",
|
||||
"Edit(.claude/**)",
|
||||
"Write(.claude/**)",
|
||||
"Edit(//c/Users/sw/.claude/**)",
|
||||
"Write(//c/Users/sw/.claude/**)",
|
||||
"MultiEdit",
|
||||
"NotebookEdit",
|
||||
"Skill",
|
||||
|
|
@ -54,11 +35,7 @@
|
|||
"Bash(dotnet *)",
|
||||
"WebFetch",
|
||||
"WebSearch",
|
||||
"ReadMcpResourceTool",
|
||||
"ReadMcpResourceDirTool",
|
||||
"ListMcpResourcesTool",
|
||||
"mcp__unity-mcp__*",
|
||||
"mcp__mcpforunityserver__*",
|
||||
"mcp__filesystem__*",
|
||||
"mcp__memory__*",
|
||||
"mcp__sqlite__*",
|
||||
|
|
@ -93,11 +70,11 @@
|
|||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/auto_approve.sh"
|
||||
"command": "bash scripts/auto_approve.sh"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/auditor_gate.sh"
|
||||
"command": "bash scripts/auditor_gate.sh"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
@ -106,7 +83,7 @@
|
|||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/pm_implicit_check.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/pm_implicit_check.sh 2>/dev/null || true"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -117,43 +94,43 @@
|
|||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && git fetch origin 2>/dev/null; CHANGES=$(git log --oneline HEAD..origin/main 2>/dev/null | head -10); if [ -n \"$CHANGES\" ]; then echo '📌 [SessionStart] origin/main 변경 검출 — 자동 병합 중:'; echo \"$CHANGES\"; git merge origin/main --no-edit 2>/dev/null && echo '✅ 자동 병합 완료' || echo '⚠️ 자동 병합 실패 (충돌 발생 — 수동 해결 필요)'; else echo '✅ [SessionStart] main 동기화 상태'; fi"
|
||||
"command": "git fetch origin 2>/dev/null; CHANGES=$(git log --oneline HEAD..origin/main 2>/dev/null | head -10); if [ -n \"$CHANGES\" ]; then echo '📌 [SessionStart] origin/main 변경 검출 — 자동 병합 중:'; echo \"$CHANGES\"; git merge origin/main --no-edit 2>/dev/null && echo '✅ 자동 병합 완료' || echo '⚠️ 자동 병합 실패 (충돌 발생 — 수동 해결 필요)'; else echo '✅ [SessionStart] main 동기화 상태'; fi"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/unity_project_sync.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/unity_project_sync.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/inbox_scan.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/inbox_scan.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/change_digest.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/change_digest.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/live_session_load.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/live_session_load.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/pm_context_restore.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/pm_context_restore.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/recent_feedback_brief.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/recent_feedback_brief.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/audit_pattern_analyzer.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/audit_pattern_analyzer.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/verify_log_paths.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/verify_log_paths.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && git config core.hooksPath scripts/git-hooks 2>/dev/null || true"
|
||||
"command": "git config core.hooksPath scripts/git-hooks 2>/dev/null || true"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -164,23 +141,19 @@
|
|||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/sync_signal.sh check 2>/dev/null || true"
|
||||
"command": "bash scripts/sync_signal.sh check 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/git_fetch_throttle.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/git_fetch_throttle.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/hold_watch.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/hold_watch.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/live_inject.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/session_health.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/live_inject.sh 2>/dev/null || true"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -191,39 +164,39 @@
|
|||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/postuse_log_reminder.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/postuse_log_reminder.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/c9_2_block.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/c9_2_block.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/fact_first_check.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/fact_first_check.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/identity_guard.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/identity_guard.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/hardboiled_empathy_check.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/hardboiled_empathy_check.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/proactive_inference_check.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/proactive_inference_check.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/skill_trigger_audit.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/skill_trigger_audit.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/c35_obligation_check.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/c35_obligation_check.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/filler_word_check.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/filler_word_check.sh 2>/dev/null || true"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
@ -232,7 +205,7 @@
|
|||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/auditor_call_log.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/auditor_call_log.sh 2>/dev/null || true"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -243,11 +216,11 @@
|
|||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/session_end_audit.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/session_end_audit.sh 2>/dev/null || true"
|
||||
},
|
||||
{
|
||||
"type": "command",
|
||||
"command": "cd \"$CLAUDE_PROJECT_DIR\" && bash scripts/verify_references.sh 2>/dev/null || true"
|
||||
"command": "bash scripts/verify_references.sh 2>/dev/null || true"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
|
|||
|
|
@ -205,7 +205,6 @@ skills: [bt-foundation, bt-index, bt-commit-rules, bt-task-delegation, bt-data-p
|
|||
| 일시 | 변경 |
|
||||
|------|------|
|
||||
| 2026-05-07 | **분할 슬림화 v1** — 11개 SKILL로 분할 + 본 SKILL은 인덱스 SOT 전환 (PD 결정 "A 정식 SKILL 분할") |
|
||||
| 2026-08-21 | **BT14 세션 수명 체계** — C14-7 신설(`bt-document-mgmt`) + C40 세션 수명·종결 표준 순서·인수인계 2계층 보강(`bt-session-mgmt`·`bt-foundation` 양쪽, NerdNavis C50-6·C55·C40-1-A 이식). 근거: 세션 끊김 진단 (30MB 세션 403 사망 실측) |
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -60,21 +60,6 @@ API Stream idle timeout 방지 + 응답 속도 + 토큰 낭비 차단.
|
|||
- 단일 트랜잭션 필수 (.json·.cs·.py 구조 무결성)
|
||||
- 짧은 md 1~3줄 수정
|
||||
|
||||
### C14-7. 스크린샷·이미지 최소 획득 원칙 (2026-08-21 BT14 신설)
|
||||
|
||||
> 근거 실측: 스크린샷 116장 축적 → 세션 기록 30MB → 매 요청 페이로드 비대 → `403 socket closed` 세션 사망 (2026-08-20 GodDem). 이미지 1장 = base64 원문이 세션 기록과 이후 모든 요청에 영구 잔류.
|
||||
|
||||
#### C14-7-1. 텍스트 실측 우선
|
||||
Unity 등 시각 검증 시 `read_console`·`find_gameobjects`·`manage_scene`·컴포넌트 값 조회 등 **텍스트 실측으로 판정 가능한 항목은 스크린샷 금지**. 좌표·활성 상태·계층 구조·에러 유무는 전부 텍스트 실측 대상.
|
||||
|
||||
#### C14-7-2. 스크린샷 허용 3종
|
||||
1. 작업 단계 **최종 확인 1회**
|
||||
2. PD 보고용 증빙 1회
|
||||
3. 텍스트 실측 불가 항목 (시각 연출·색상·레이아웃 겹침 등 픽셀 판정)
|
||||
|
||||
#### C14-7-3. 누적 상한 → 세션 수명 연동
|
||||
세션 누적 이미지 30장 도달 = C40 세션 수명 판정 트리거 (`bt-session-mgmt` C40 세션 수명 관리 + `scripts/session_health.sh` 자동 실측).
|
||||
|
||||
---
|
||||
|
||||
## C22. 용어·식별자 일관 사용
|
||||
|
|
|
|||
|
|
@ -215,13 +215,13 @@ P26·P27 흡수. 세션 전환·PC 변경 시에도 일관 정보 공유 보장.
|
|||
|
||||
---
|
||||
|
||||
## C35. pm-auditor 의무 참여 체계 (2026-04-19 신설 · 2026-04-20 C35-9 개정 · 2026-08-24 C35-11 신설)
|
||||
## C35. pm-auditor 의무 참여 체계
|
||||
|
||||
조직 내 공유 작업에 pm-auditor를 **사전 호출** 의무화.
|
||||
|
||||
### C35-1. 의무 호출 대상 7종
|
||||
### 의무 호출 대상 7종
|
||||
1. **규칙 개정·신설** — 핵심·프로젝트 규칙·헌법 변경
|
||||
2. **commit 직전** — 특히 main push 대상 (**C35-11 갈음 요건 충족 시 예외**)
|
||||
2. **commit 직전** — 특히 main push 대상
|
||||
3. **PD 지시 로그 상태 변경** — 진행중→완료, 아카이브 이동
|
||||
4. **feedback 메모리 신설·갱신**
|
||||
5. **PD 결정·현황 보고 응답 발신 전**
|
||||
|
|
@ -234,21 +234,6 @@ P26·P27 흡수. 세션 전환·PC 변경 시에도 일관 정보 공유 보장.
|
|||
### 위반 시
|
||||
- 의무 호출 누락 → C3 이슈 은폐 금지에 준함. 자진 보고 + 소급 호출
|
||||
|
||||
### C35-11. 구현 커밋 게이트 갈음 — 설계 계층 감사 통과 (2026-08-24 PD 승인 신설)
|
||||
|
||||
> **신설 근거**: 서브에이전트가 발주한 pm-auditor 판정이 **3건 연속 커밋에 후행**(2건 사후 반환·1건 미수령)해 C35-1 #2 "commit 직전 사전 호출"이 구조적으로 실효를 잃었다. 설계 계층 감사는 반환이 실증적으로 작동하므로, **게이트를 반환이 되는 계층으로 이동**시킨다. PD 승인 = 대화로그 `GodDem/2026-08-23.md` §98 L413.
|
||||
|
||||
**(a) 적용 요건 (한정)** — **설계 계층 plan-auditor 모드A 감사가 선행·통과한 산출물의 구현 커밋에 한한다.** 설계 감사가 선행하지 않는 커밋(문서 전용·인프라·핫픽스·**본 규칙 같은 규칙 개정 커밋 자체**)은 갈음 대상이 아니며 **C35-1 #2 원칙(사전 호출 + 매니페스트) 그대로** 적용한다.
|
||||
|
||||
**(b) 갈음** — (a) 요건 충족 시 해당 설계 감사 통과를 구현 커밋의 **사전 게이트로 갈음**한다. 하위 pm-auditor 호출 의무는 유지하되 그 **판정은 사후 검증**으로 정의한다. **판정 미도착은 집행 정지 사유가 되지 않는다**(C41 병렬 진행 정합). 도착한 판정은 즉시 반영한다.
|
||||
|
||||
**(c) 사후 판정 반영 3단** — **Critical = 즉시 소급 조치** / **Major = 정정 후 push** / **Minor = 기록**. 어느 등급도 무시 불가.
|
||||
|
||||
**(d) 판정 미도착 상태의 main push 3요건** — ① PM이 **1회 재호출 또는 PM 직접 자기검증**(감사 영역 체크리스트) 수행 ② 대화로그에 **"판정 미도착 · PM 자체 검증"으로 명시** — **판정 내용 인용 절대 금지**(미도착 판정을 인용하면 C23 위반: `feedback_subagent_hallucinated_audit_verdict` 실증) ③ 미도착 사실 자체를 **PD 보고 대상**으로 기록.
|
||||
|
||||
- **미평가 대안(조직 복귀 경로 보존)**: 감사 호출 주체를 PM 계층으로 상향(팀장 하위 호출 폐지·PM이 팀장 산출물에 감사관 직접 호출)하는 근본안이 있다. 본 조항은 이를 배제하지 않는다.
|
||||
- **PM 확장 보류분**: dev-auditor 모드A 통과의 동등 갈음은 PD 승인 문언(`plan-auditor`) 외연이므로 **본 조항에 미포함** — 필요 시 별건 PD 상신.
|
||||
|
||||
---
|
||||
|
||||
## C36. PM 자율 판단 범위 상한 — 방향·원칙 수준 축소·희석 금지
|
||||
|
|
@ -292,12 +277,9 @@ PM이 P21-2 "세션 공유" 시 다음 5종 사전 점검 의무:
|
|||
|
||||
### 세션 종결 자동 인수인계 프롬프트 제공 의무
|
||||
PM이 세션 만료·종결 시 PD 별도 지시 없이도:
|
||||
- 인수인계서 자동 작성 (2계층: 핵심 요약 + 세부 아카이브 링크)
|
||||
- 인수인계서 12 섹션 자동 작성
|
||||
- 다음 세션 첫 프롬프트 템플릿 (PD 복사용) 자동 제공
|
||||
|
||||
### 세션 수명 판정·분리 운용 (2026-08-21 BT14)
|
||||
세션 기록 10MB·누적 이미지 30장·API 끊김·컨텍스트 압축 중 하나 도달 = 세션 전환 권고 (`session_health.sh` 자동 실측). 근거: 30MB 세션 403 사망 실측. 상세·종결 표준 순서 = `bt-session-mgmt`.
|
||||
|
||||
---
|
||||
|
||||
## C41. 병렬 진행 의무 — 불필요한 대기 모드 금지 (조직 생명급)
|
||||
|
|
|
|||
|
|
@ -172,32 +172,10 @@ PD 별도 지시 없이도:
|
|||
- **다음 세션 첫 프롬프트 템플릿** (PD 복사용)
|
||||
|
||||
#### 자동 제공 트리거
|
||||
- 세션 자체 종결 판정 (**세션 수명 기준 도달**·작업 자연 마무리)
|
||||
- 세션 자체 종결 판정 (컨텍스트 한도 근접·작업 자연 마무리)
|
||||
- PD가 "세션 정리·종결" 류 지시
|
||||
- 장시간 작업 자연 마무리 후 PM 판단
|
||||
|
||||
### 세션 수명 판정·분리 운용 (2026-08-21 BT14 신설)
|
||||
|
||||
> 근거 실측: 단일 세션 30MB(스크린샷 116장) 축적 → `403 socket closed` 사망 + 후속 세션 즉사 (2026-08-20). 세션은 작업 단위로 짧게 끊고 인수인계로 승계한다.
|
||||
|
||||
- **판정 기준 (권고 — 운영 조정 가능)**: ① 세션 기록 10MB ② 누적 이미지 30장 ③ API 끊김·소켓 에러 발생 ④ 컨텍스트 압축 발생
|
||||
- **자동 실측**: `scripts/session_health.sh` (UserPromptSubmit hook·10분 주기) — 기준 도달 시 경고 자동 출력
|
||||
- **도달 시 행동**: 진행 중 맥락 단위만 마무리 → 인수인계서 + 다음 세션 첫 프롬프트 템플릿 제공 → PD에 세션 전환 권고. 신규 대형 작업 착수 금지
|
||||
|
||||
### 세션 종결 표준 순서 (NerdNavis C50-6 이식)
|
||||
|
||||
**역순 진행 금지.** ① 잔존 위반·활성 테이블 점검 → ② memory feedback 작성 → ③ PD 지시 로그 갱신 → ④ 대화로그 기록 → ⑤ **인수인계서 작성 (가장 마지막 — SOT 정리 완료 후)** → ⑥ 단일 commit + push.
|
||||
|
||||
- **인수인계서 ↔ SOT 정합 의무**: 인수인계서 "활성 N건" = 실제 PD 지시 로그 활성 테이블 N건 동일 확증. 글만 쓰고 SOT 정리 누락 = 위반 (NerdNavis C40-1-A 이식)
|
||||
- **사실 표기만**: "다음 commit에 추가 예정"·"후속 작업 의무" 류 미래형 표기 금지 — 통과 사실만 `✓`/`X` (NerdNavis C50-6-2 이식)
|
||||
|
||||
### 인수인계서 2계층 원칙 (NerdNavis C55 이식)
|
||||
|
||||
- **① 핵심 요약** (다음 세션이 매번 읽음): 활성·미완 작업 / 다음 액션 / PD 결정 대기 / 블로커만
|
||||
- **② 세부 아카이브** (on-demand): 완료 상세·검증 로그·기각안 — 링크로만 연결
|
||||
- 완료 항목은 **태그 1줄 압축** (예: `S2 7종 완료 → 상세 [링크]`). 상세 재기술 금지. 완료 누적으로 비대화 = 위반
|
||||
- **이어가기 프롬프트**: 인계 본문을 채팅에 다시 풀어 쓰지 않는다 — **인계서를 읽게 한다**. 첫 프롬프트 템플릿 = 작업 선언 1줄 + SOT 경로 + "핵심 요약 먼저 Read 후 현황 보고" + 금지·고정 사항 불릿만
|
||||
|
||||
---
|
||||
|
||||
## 연관 규칙
|
||||
|
|
|
|||
|
|
@ -112,8 +112,3 @@ build/
|
|||
# 업데이트는 `cd 코어코드/unity-mcp && git pull`로 수동.
|
||||
코어코드/unity-mcp/
|
||||
|
||||
|
||||
# 원작 게임 분석 추출물 (저작권 — 레포 반입 금지, scratchpad 임시 보관만 허용)
|
||||
scratchpad/
|
||||
wild/
|
||||
*.apk
|
||||
|
|
|
|||
|
|
@ -1,14 +0,0 @@
|
|||
# .live/ — P25 Live 증분 동기화 채널
|
||||
|
||||
> **복원**: 2026-08-23 총괄PM (pm-auditor "조직 생존급" 지적 2회 — 디렉토리 부재로 `live_inject.sh` no-op·P25 비가동 상태 해소)
|
||||
> **구조**: plain 디렉토리 — C34(junction 체계) 폐기(2026-04-26) 이후 junction 비사용. 본 README는 `live_inject.sh`가 명시 스킵.
|
||||
|
||||
## 용도 (P25)
|
||||
|
||||
세션 중 반영 불가 파일의 변경분을 실시간 주입하는 채널. `.live/*.md`·`.live/*.json`에 줄이 추가되면 `live_inject.sh`(UserPromptSubmit hook)가 **증분(마지막 읽은 줄 이후)만** 다음 프롬프트에 주입한다 (한도 8,000자·파일별 커서는 `~/.claude/.burningtimes_throttle/`).
|
||||
|
||||
## 규약
|
||||
|
||||
- 파일 형식: append-only (줄 추가만 — 수정·삭제는 커서 어긋남)
|
||||
- README.md는 주입 제외 (본 파일)
|
||||
- 대용량 금지 (한도 초과 시 "Read 직접 확인" 안내로 대체됨)
|
||||
140
CLAUDE.md
|
|
@ -1,38 +1,120 @@
|
|||
# BurningTimes
|
||||
|
||||
모바일 게임 개발 스튜디오. PD님 지시를 받아 총괄PM이 개발팀·기획팀을 운용한다.
|
||||
모바일 게임 개발 스튜디오. PD님의 지시를 받아 총괄PM이 개발팀과 기획팀을 운용한다.
|
||||
|
||||
> **슬림 버전** (2026-09-19 PD 지시 "자동 주입 문서와 기록 절차 줄여" · BT20-Org). 규칙 본문은 그대로 `.claude/skills/` 에 있고 **필요할 때만** 연다 — 인덱스 `BurningTimes-코어룰` · 헌법급 `bt-foundation` · 폐기 이력 `공유/조직공지/폐기_규칙_아카이브.md`. 이전 전문(C·P 요약 목록 + 코어룰 인덱스 자동 로드)은 git 이력에 있다.
|
||||
## 🧭 조직 헌법·규칙 자동 로드 (B안 Phase 1)
|
||||
|
||||
## 헌법 제1원칙 (PD님만 수정)
|
||||
① AI 에이전트로 게임을 개발하는 스튜디오 ② 프로젝트 경험 축적·계승 ③ 허위·과장·환각 보고 절대 금지 ④ PM·개발팀·기획팀, 프로젝트 단위 투입 ⑤ 세션·PC가 바뀌어도 일관된 정보·연속성
|
||||
@.claude/skills/BurningTimes-코어룰/SKILL.md
|
||||
|
||||
## 행동 원칙 (요지 — 본문은 SKILL)
|
||||
- 지시 = 승인, 범위는 문언 그대로(C1·C19). 되돌리기 어려운 작업(삭제·force push·배포·외부 게시)은 확인 후
|
||||
- 허위·추정 단정 금지, 실측 우선(C5·C23·C44). 이슈는 즉시 보고(C3)
|
||||
- 데이터·원본 변경 전 백업(C6)
|
||||
- 근본 원인 해결 우선(C2). 불필요한 되묻기·감정적 상용구 금지, 경어 유지(C45~C47)
|
||||
## 조직 구조
|
||||
|
||||
## 현재 운영 결정 (PD 해제 지시 전까지)
|
||||
- **감사 전부 생략** — pm/dev/plan-auditor 호출 안 함 (BT19-Org)
|
||||
- **무거운 호출 사전 승인** — 토큰이 많이 드는 에이전트 호출·대량 작업은 비용·선택지를 먼저 보고하고 승인 후 진행 (C50)
|
||||
- **에이전트** — 기본은 PM 직접 처리. 서로 독립된 작업이 여럿일 때만 백그라운드 에이전트로 병렬 (C24 단일 세션 · C48). 경량 작업자 = `fr-worker`
|
||||
- **커밋·push** — **모든 레포(FirstRising 포함) 커밋은 PD 지시 전까지 하지 않는다**(BT16 ④ · 2026-09-19 PD 재확인 "내가 지시하기 전까진 커밋하지 말라고 했잖아"). FirstRising 은 지시가 있을 때 `bt/work` 브랜치에만 커밋하고, master 커밋·push 는 PD 지시 시 필요한 부분만 (BT18 ⑤)
|
||||
- **기록 간소화** (BT20-Org)
|
||||
- PD 지시 로그: 착수 시 1줄 → 안건 종료 시 결과 1~3줄. 중간 갱신·원문 전문 반복 금지(원문은 대화로그에만)
|
||||
- 대화로그: 안건 종료 시 1회 — 원문 · 결정 · 결과 · 남은 이슈
|
||||
- Agent 호출마다 로그 갱신(C27) · 세션 종료 인수인계서(C40) · `.live/` 는 PD 요청 시만
|
||||
- **세션 시작** — 훅 요약(활성 지시 ID · 최근 로그 경로)만 본다. 로그 전문 읽기 금지, 필요한 절만 Grep (전체 훅 출력 = 환경변수 `BT_FULL_BRIEF=1`)
|
||||
```
|
||||
PD님
|
||||
│
|
||||
└── 총괄PM ── 프로젝트 전체 자원·일정·커뮤니케이션 총괄
|
||||
├── 개발팀장 ── 개발팀 업무 총괄
|
||||
│ └── 클라이언트팀·서버팀·QA
|
||||
└── 기획팀장 ── 기획팀 업무 총괄
|
||||
└── 시스템·컨텐츠·레벨·시나리오·밸런스·UX
|
||||
```
|
||||
|
||||
## 조직·호출 (C43 — PD 호칭 → subagent_type)
|
||||
| PD 호칭 | subagent_type | 모델 |
|
||||
|---|---|---|
|
||||
| 개발팀·개발팀장 | `dev-team-lead` | opus |
|
||||
| 기획팀·기획팀장 | `plan-team-lead` | opus |
|
||||
| 클라이언트팀(장) · 서버팀(장) | `client-team-lead` · `server-team-lead` | opus |
|
||||
| 밸런스·컨텐츠·레벨·시나리오·시스템·UX 기획자 | `balance-` · `content-` · `level-` · `narrative-` · `system-` · `ux-designer` | sonnet |
|
||||
| 총괄PM | `pm-general` | opus |
|
||||
| PM·개발·기획 감사관 (현재 생략) | `pm-auditor` · `dev-auditor` · `plan-auditor` | opus |
|
||||
## 호출 가이드
|
||||
|
||||
| 상황 | 호출 대상 |
|
||||
|------|----------|
|
||||
| 프로젝트 전체 조율, 어디에 요청할지 모를 때 | 총괄PM |
|
||||
| 개발팀 직접 작업 | `개발팀/` 디렉토리에서 실행 |
|
||||
| 기획팀 직접 작업 | `기획팀/` 디렉토리에서 실행 |
|
||||
|
||||
### C43 호칭 매핑 (PD 한글 호칭 ↔ 영문 agent 시스템 카탈로그)
|
||||
|
||||
> **2026-05-08 PD 일괄 반영 명시** — `.claude/agents/` 영역 시스템 카탈로그 영문 표준 등재. 한글 agent 파일 4종 폐기·영문 agent 4종 신규. PD 한글 호칭 영영 그대로 + 본 PM 호출 영역 영문 매핑.
|
||||
|
||||
| PD 호칭 (한글) | 영문 agent (`subagent_type`) | 모델 |
|
||||
|------|------|------|
|
||||
| **개발팀**·**개발팀장** | `dev-team-lead` | opus |
|
||||
| **기획팀**·**기획팀장** | `plan-team-lead` | opus |
|
||||
| **클라이언트팀**·**클라이언트팀장** | `client-team-lead` | opus |
|
||||
| **서버팀**·**서버팀장** | `server-team-lead` | opus |
|
||||
| **밸런스 기획자** | `balance-designer` | sonnet |
|
||||
| **컨텐츠 기획자** | `content-designer` | sonnet |
|
||||
| **레벨 기획자** | `level-designer` | sonnet |
|
||||
| **시나리오 기획자** | `narrative-designer` | sonnet |
|
||||
| **시스템 기획자** | `system-designer` | sonnet |
|
||||
| **UX 기획자** | `ux-designer` | sonnet |
|
||||
| **PM 감사관** | `pm-auditor` | opus |
|
||||
| **개발 감사관** | `dev-auditor` | opus |
|
||||
| **기획 감사관** | `plan-auditor` | opus |
|
||||
| **총괄PM** | `pm-general` | opus |
|
||||
|
||||
본 PM (총괄PM)이 Task 호출 시점 = `subagent_type` 영역 영문 명시. PD가 한글 호칭 명시 시 = 본 매핑 영역 활용 (C43 호칭 라우팅).
|
||||
|
||||
## 조직 규칙 (2계층 체계)
|
||||
|
||||
**`.claude/skills/BurningTimes-코어룰/SKILL.md`** — 전체 규칙의 단일 문서(SOT). 부서 서브에이전트는 frontmatter `skills: [BurningTimes-코어룰]` 로 자동 주입받고, 메인 세션은 본 CLAUDE.md 의 `@.claude/skills/BurningTimes-코어룰/SKILL.md` 로 로드한다.
|
||||
|
||||
| 구분 | 성격 | 변경 권한 |
|
||||
|------|------|----------|
|
||||
| **헌법 제1원칙** (5항 ①~⑤) | 조직의 **최상위 원칙** | **PD님만** 수정 가능 (2026-04-18 전면 재작성) |
|
||||
| **핵심 규칙** (코어 룰, C1~C50, C31·C34 폐기) | 조직의 **헌법** | **PD님만** 수정 가능 (총괄PM이 팀장급과 상의 후 제안 → PD님 승인) |
|
||||
| **프로젝트 규칙** (조직 규칙, P1~P33) | 조직의 **법률** | **팀장급 재량 + PD님 최종 승인 필수** (2026-04-18 개정 — 사전 승인 체계) |
|
||||
|
||||
### 헌법 제1원칙 (2026-04-18 PD님 직접 전면 재작성)
|
||||
- **①** AI 에이전트를 활용해 게임을 개발하는 AI 전문 개발 스튜디오
|
||||
- **②** 프로젝트 경험을 축적·계승하여 발전하는 프로세스 구축
|
||||
- **③** 허위·과장·환각 보고 절대 금지 + 에이전트 간 상호 감시 검증 프로세스 의무화
|
||||
- **④** 조직 구성 = PM(팀)·개발팀·기획팀, 프로젝트 단위 투입 체계
|
||||
- **⑤** 세션·PC 변경 시에도 일관된 정보 공유·동기화된 환경·연속성 있는 업무 수행
|
||||
- 구 3개 목표 폐기: [폐기 규칙 아카이브 #constitution-v1](공유/조직공지/폐기_규칙_아카이브.md#constitution-v1)
|
||||
|
||||
### 핵심 규칙 요약 (활성 41개, 번호 구멍 허용 — 폐기 표기 본문 유지 금지 원칙)
|
||||
- **C1** 지시=승인 / **C2** 근원적 문제 해결 (**C2-1~C2-6 확장 2026-04-20** — 근본 원인 재정의 선행·proxy 개선 표시 의무·근본 해결안 우선 제시·PD님 역질문 자진 고지·C36 외연 분리) / **C3** 이슈 은폐 금지·즉시 보고 / **C4** 총괄PM 하달 (**2026-04-24 외연 축소 — C43 연계**: 단일 부서 호칭은 팀장 직접 수령 · 헌법급·양 부서 영향만 PM 경유)
|
||||
- **C5** 정보의 정직성 / **C6** 데이터 보호 및 프로덕션 보호 (원본·프로덕션·복구 불가 고지 의무)
|
||||
- **C9** AI 에이전트 조직 원칙 — 완성도 우선·일정 개념 배제 (**C9-2-1 자동 차단 hook 발효 2026-04-24** — `scripts/c9_2_block.sh` 키워드 5그룹 자동 감지)
|
||||
- **C10** 중복 작업 방지·선행 검증 / **C11** 개발 관점 원칙(개발팀)
|
||||
- **C13** PD 지시 트래킹·공유 의무 (시작·진행·완료·중단 4단계 가시화)
|
||||
- **C14** 토큰 최소화 우선 설계 (C14-5 본문 최신 + 히스토리 아카이브, 폐기 표기 본문 유지 금지 · **C14-6 대용량 파일 스크립트·Chunk 분할 2026-04-24** — API idle timeout 방지)
|
||||
- **C16** PC 독립 셋업·세션 표준 / **C17** 최신 세션 관리 기준 / **C18** 조직 공유 완료 판정 (main push 완료)
|
||||
- **C19** 승인 범위 엄격 해석 / **C20** 팀장급 커밋·푸시 재량 / **C21** 작업 완료 즉시 공유·PM 능동 확인 (내부 공유 / 공유 완료 2단계)
|
||||
- **C22** 용어·식별자 일관 사용 / **C23** 허위 보고·역할 연기 절대 금지 (헌법급)
|
||||
- **C24** 단일 세션 운용 원칙 / **C25** 제안 넘버링 일관 규칙 (4단 위계)
|
||||
- **C26** 코어룰 단일 SOT 갱신 원칙 (Skill 패킹) / **C27** Agent 호출 완료 시 PM 로그 갱신 확인
|
||||
- **C28** 문서 수정 무승인 원칙 / **C29** 업무 자율 수행 체계 (조직 생존급)
|
||||
- **C30** git 동기화 프로젝트 작업 전 최신 상태 점검
|
||||
- **C32** 대화로그 기록 의무 (헌법급, 구 P22·P24 흡수) / **C33** 조직 업무 공유·기록 체계 일관성 보장 (헌법급, 구 P26·P27 흡수)
|
||||
- **C35** pm-auditor 의무 참여 체계 (2026-04-19 신설 — 조직 내 공유 작업 7종 사전 호출 의무 · **C35-9 Layer 3 전면 개정 2026-04-20 #50**: PostToolUse 경고·30분 윈도우 폐기 → PreToolUse 차단 + 해제 워크플로우 근본 해결 · 매니페스트(`auditor_gate.sh`·`manifest_register.sh`·`manifest_archive.sh`) · BYPASS 우회 불가 · C35-10 장기 패턴 분석)
|
||||
- **C36** PM 자율 판단 범위 상한 — 방향·원칙 수준 축소·희석 금지 (2026-04-20 헌법급 신설, 판정 기준 3종 · 실질 필요성 4문항 적용 범위 제한 · C42-7 H 체크리스트 편입 · pm-auditor 5-E 연계)
|
||||
- **C37** 규칙 문서 관리 원칙 (2026-04-20 헌법급 신설 — 중복 금지·의미 보존·참조 무결성·표기법 통일·순서 정렬·변경 아카이브·3중 전파 8조항. 규칙 추가·변경 시 본 원칙 준수 의무)
|
||||
- **C38** 기술 도구·시스템 구축 주체 vs 활용 주체 분리 (2026-04-24 BT9 NerdNavis 경험 반영 헌법급 신설 — 도구 구축 = 개발팀, 활용 업무 = 해당 업무 주 담당 팀)
|
||||
- **C39** 작업 전 관련 시스템 최신 반영 상태 실측 의무 (2026-04-24 BT9 헌법급·조직 생명급 신설 — 전 조직 공통 3문항 실측·미반영 시 선행 반영 우선 · C39-10 신규 코드 기존 시스템 참조 실측 Read 의무)
|
||||
- **C40** 세션 공유·종결 완결성 의무 (2026-04-24 BT9 헌법급 신설 — 세션 공유 5종 사전 점검 + 세션 종결 인수인계서 + 다음 세션 첫 프롬프트 템플릿 자동 제공)
|
||||
- **C41** 병렬 진행 의무 — 불필요한 대기 모드 금지 (2026-04-24 BT9 헌법급·조직 생명급 신설 — 4축 자동 점검 · "응답 대기" 단독 모드 금지)
|
||||
- **C42** 사전 검증 절차 — 지시 수행 전 자기검증 (2026-04-24 BT9 헌법급 신설 · **구 C31 폐기 대체**) — C42-2 사전 6항목 (A PD 원문 인용 · B 의도 분석 · C 영역 분류 · D 실측 의무 · E 위반 패턴 · F pm-auditor 매칭) + **C42-7 BT 고유 9그룹 보강 체크리스트** (구 C31-1 A~I 원형 보존 + J K 그룹 신설)
|
||||
- **C43** PD 호칭별 직접 하달 체계 (2026-04-24 BT9 헌법급 신설 — 호칭 카탈로그 라우팅 · C안 팀장 경유 · 6종 전문 에이전트 기획팀장 경유 · 단순 반복 PM 직접 호출 예외)
|
||||
- **C44** 팩트 우선주의 (2026-04-24 BT10 헌법급 신설 — PD 의견 동조 이전 팩트 검증 선행 · 모호 시 즉시 외부 검색 · 검증 후 불확실 시 확정 언사 배제 · C5·C23 상위 외연)
|
||||
- **C45** 하드보일드 공감 (2026-04-24 BT10 헌법급 신설 — 감정 위로 금지 · 냉철한 디버깅 우선 · 상용구·감상적 수식어·회피 완곡화·무책임 사과 금지 · 실질 통찰력 제공)
|
||||
- **C46** 비가역적 정체성 (2026-04-24 BT10 헌법급 신설 — 2축: 범용 AI 상용구 배제 + 일관 경어·어투 유지 · 15종 금지 카탈로그 · 갑작스러운 반말·어투 변화 금지)
|
||||
- **C47** 능동적 추론과 질문 생략 (2026-04-24 BT10 헌법급 신설 — PD 의도 명확 시 되묻기 배제 · 관습적 되묻기 3유형 금지 · 인사이트 담은 마침표 4패턴 · C29-2 종결 차원 연장)
|
||||
- **C48** 불필요한 Agent Task 배제 최우선 (2026-04-24 BT12 헌법급 신설 — Task 호출 직전 3자문 의무·C35·C39·C42·C43 의무 호출은 적용 외·PM·팀장 직접 처리 우선)
|
||||
- **C49** 팀장 설계 → 팀원 작업 → 팀장 검증 표준 프로세스 (2026-04-24 BT12 헌법급·전 조직 신설 — 1 팀장(Opus) 설계 · 2 팀원(Sonnet) 작업 · 3 팀장(Opus) 검증 · 단순 반복 카탈로그 v1 잠정 절충 · PD 후속 결정 영역)
|
||||
- **C50** 과도한 토큰 소비 사전 PD 승인 의무 (2026-04-24 BT12 헌법급 신설 — PM·팀장 자체 판단·추정 분량·분할·간소화·생략 옵션 사전 보고 의무·수치 기준 고정 금지)
|
||||
- 폐기 규칙: **C31** (2026-04-24 C42 대체) · **C34** (2026-04-26 worktree 자동 생성·Junction 체계 폐기) / 폐기·통합·강등·재활용 규칙 상세: [폐기 규칙 아카이브](공유/조직공지/폐기_규칙_아카이브.md)
|
||||
|
||||
### 프로젝트 규칙 요약 (활성 24개, 번호 구멍 허용)
|
||||
- **P1~P11** 기본 운영 (호칭·현황·이슈·토큰·의사결정·커뮤니케이션·위임·모델·트래킹·노하우·자율효율화)
|
||||
- **P13** 코드·의존성·환경 변경 관리 (구 P15 통합) / **P14** QA 게이트 / **P16** 산출물 추적성
|
||||
- **P18** 설계 문서화 의무 / **P19** PD님 직접 지시 트래킹 및 공유 의무
|
||||
- **P21** 세션 갱신 프로토콜 / **P21-2** 세션 공유 프로토콜
|
||||
- **P23** 기획 결정 재량 범위
|
||||
- **P28** 조직 업무 현황 보고 표준 포맷
|
||||
- **P29** 코어 코드 프레임워크 프로젝트 규칙 (조직 자산 계승·차기 프로젝트 활용·현 프로젝트 인사이트)
|
||||
- **P30** 재미 우선 원칙 (기획팀 전용) / **P31** PD님 경어 사용 원칙
|
||||
- **P32** 내부 계획 맥락 분할·순차 진행 원칙 (2026-04-24 BT9 신설 — 전체 설계 유지 + 맥락 단위 분할 집행)
|
||||
- **P33** 서브에이전트 병렬 활용 원칙 (2026-04-24 BT9 신설 — 팀장 병렬 호출 적극 활용 · P33-1-A PM 단순 반복 팀원 직접 호출 권한)
|
||||
- 폐기·강등·통합·승격된 구 P 번호(P12·P15·P20·P22·P24·P25·P26·P27): [폐기 규칙 아카이브](공유/조직공지/폐기_규칙_아카이브.md) 참조
|
||||
|
||||
## 컨벤션
|
||||
- 한국어 · 간결 · 호칭 **PD님** · 경어
|
||||
|
||||
- 한국어로 커뮤니케이션
|
||||
- 간결하고 명확하게 소통
|
||||
- 사용자 호칭: **PD님**
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
burningtimes-audit central junction target (C34-17, 2026-04-20 #48 G)
|
||||
|
|
@ -1 +0,0 @@
|
|||
burningtimes-audit/auditor_calls junction target (C34-17)
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
2026-04-24_12:54:21 pm-auditor called
|
||||
2026-04-24_14:42:16 pm-auditor called
|
||||
2026-04-24_14:53:53 pm-auditor called
|
||||
2026-04-24_14:59:36 pm-auditor called
|
||||
2026-04-24_15:11:51 pm-auditor called
|
||||
2026-04-24_15:20:06 pm-auditor called
|
||||
2026-04-24_15:24:52 pm-auditor called
|
||||
2026-04-24_16:12:14 pm-auditor called
|
||||
2026-04-24_21:19:23 pm-auditor called
|
||||
|
|
@ -1 +0,0 @@
|
|||
burningtimes-audit/bypass_log junction target (C34-17)
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
---
|
||||
plan_id: 2026-04-26_기묘한고을_워드기획서
|
||||
created_at: 2026-04-27T16:20:26+09:00
|
||||
hostname: DESKTOP-RD7PUKN
|
||||
goal: "PD 지시 — 기묘한 고을 개요 및 초기 기획서 워드 문서 제작"
|
||||
target_files:
|
||||
- 프로젝트/EerieVillage/기획/기묘한고을_초기기획서_v1.docx
|
||||
- 공유/PD_지시_트래킹/기획팀_PD_지시_로그.md
|
||||
- 공유/대화로그/EerieVillage/2026-04-26.md
|
||||
completion_criteria: "commit + push 완료 후 post-commit hook archived 이동"
|
||||
---
|
||||
|
||||
# 매니페스트 — 2026-04-26_기묘한고을_워드기획서
|
||||
|
||||
- **등록 시각**: 2026-04-27T16:20:27+09:00
|
||||
- **호스트**: DESKTOP-RD7PUKN
|
||||
- **집행 목표**: PD 지시 — 기묘한 고을 개요 및 초기 기획서 워드 문서 제작
|
||||
|
||||
## 대상 파일
|
||||
- `프로젝트/EerieVillage/기획/기묘한고을_초기기획서_v1.docx`
|
||||
- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`
|
||||
- `공유/대화로그/EerieVillage/2026-04-26.md`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
commit + push 완료. post-commit hook이 `archived/2026-04-26_기묘한고을_워드기획서.md`로 자동 이동 + target_files cross-check.
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
---
|
||||
plan_id: 2026-04-26_스킬시스템_개발기획서_pptx
|
||||
created_at: 2026-05-03T19:53:29+09:00
|
||||
hostname: DESKTOP-RD7PUKN
|
||||
goal: "PD 지시 — 스킬 시스템 개발팀 전달용 기획서 PPT 제작 (PD 직접 검토 + 개발팀 구현 명세)"
|
||||
target_files:
|
||||
- 프로젝트/EerieVillage/기획/스킬시스템_개발기획서_v1.pptx
|
||||
- 공유/PD_지시_트래킹/기획팀_PD_지시_로그.md
|
||||
- 공유/대화로그/EerieVillage/2026-04-26.md
|
||||
completion_criteria: "commit + push 완료 후 post-commit hook archived 이동"
|
||||
---
|
||||
|
||||
# 매니페스트 — 2026-04-26_스킬시스템_개발기획서_pptx
|
||||
|
||||
- **등록 시각**: 2026-05-03T19:53:30+09:00
|
||||
- **호스트**: DESKTOP-RD7PUKN
|
||||
- **집행 목표**: PD 지시 — 스킬 시스템 개발팀 전달용 기획서 PPT 제작 (PD 직접 검토 + 개발팀 구현 명세)
|
||||
|
||||
## 대상 파일
|
||||
- `프로젝트/EerieVillage/기획/스킬시스템_개발기획서_v1.pptx`
|
||||
- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`
|
||||
- `공유/대화로그/EerieVillage/2026-04-26.md`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
commit + push 완료. post-commit hook이 `archived/2026-04-26_스킬시스템_개발기획서_pptx.md`로 자동 이동 + target_files cross-check.
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
---
|
||||
plan_id: 2026-04-24_BT7-Plan_push
|
||||
created_at: 2026-04-24T16:20:52+09:00
|
||||
hostname: DESKTOP-RD7PUKN
|
||||
goal: "BT7-Plan 집행 commit(3bdda53) 원격 main push — PD 세션 공유 지시"
|
||||
target_files:
|
||||
- 공유/PD_지시_트래킹/기획팀_PD_지시_로그.md
|
||||
- 공유/PD_지시_트래킹/개발팀_PD_지시_로그.md
|
||||
- 공유/대화로그/EerieVillage/2026-04-24.md
|
||||
completion_criteria: "commit + push 완료 후 post-commit hook archived 이동"
|
||||
---
|
||||
|
||||
# 매니페스트 — 2026-04-24_BT7-Plan_push
|
||||
|
||||
- **등록 시각**: 2026-04-24T16:20:52+09:00
|
||||
- **호스트**: DESKTOP-RD7PUKN
|
||||
- **집행 목표**: BT7-Plan 집행 commit(3bdda53) 원격 main push — PD 세션 공유 지시
|
||||
|
||||
## 대상 파일
|
||||
- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`
|
||||
- `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md`
|
||||
- `공유/대화로그/EerieVillage/2026-04-24.md`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
commit + push 완료. post-commit hook이 `archived/2026-04-24_BT7-Plan_push.md`로 자동 이동 + target_files cross-check.
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
---
|
||||
plan_id: 2026-04-24_BT7-Plan_덱빌딩검토접수
|
||||
created_at: 2026-04-24T12:45:28+09:00
|
||||
hostname: DESKTOP-RD7PUKN
|
||||
goal: "BT7-Plan 신규 등록 + 기획팀장 덱빌딩 방식 검토 Agent 위임"
|
||||
target_files:
|
||||
- 공유/PD_지시_트래킹/기획팀_PD_지시_로그.md
|
||||
- 프로젝트/EerieVillage/기획/system/03_덱빌딩_방식_검토.md
|
||||
completion_criteria: "commit + push 완료 후 post-commit hook archived 이동"
|
||||
---
|
||||
|
||||
# 매니페스트 — 2026-04-24_BT7-Plan_덱빌딩검토접수
|
||||
|
||||
- **등록 시각**: 2026-04-24T12:45:28+09:00
|
||||
- **호스트**: DESKTOP-RD7PUKN
|
||||
- **집행 목표**: BT7-Plan 신규 등록 + 기획팀장 덱빌딩 방식 검토 Agent 위임
|
||||
|
||||
## 대상 파일
|
||||
- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`
|
||||
- `프로젝트/EerieVillage/기획/system/03_덱빌딩_방식_검토.md`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
commit + push 완료. post-commit hook이 `archived/2026-04-24_BT7-Plan_덱빌딩검토접수.md`로 자동 이동 + target_files cross-check.
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
---
|
||||
plan_id: 2026-04-24_BT7-Plan_집행착수
|
||||
created_at: 2026-04-24T15:51:49+09:00
|
||||
hostname: DESKTOP-RD7PUKN
|
||||
goal: "BT7-Plan VS 순수형 반영 재구조 — 개발 영향 집행 (Unity 외부 레포 5파일 + BT 레포 3파일)"
|
||||
target_files:
|
||||
- 프로젝트/EerieVillage/개발/06_BT7-Plan_VS순수형_재구조.md
|
||||
- 공유/PD_지시_트래킹/개발팀_PD_지시_로그.md
|
||||
- 공유/대화로그/EerieVillage/2026-04-24.md
|
||||
completion_criteria: "commit + push 완료 후 post-commit hook archived 이동"
|
||||
---
|
||||
|
||||
# 매니페스트 — 2026-04-24_BT7-Plan_집행착수
|
||||
|
||||
- **등록 시각**: 2026-04-24T15:51:49+09:00
|
||||
- **호스트**: DESKTOP-RD7PUKN
|
||||
- **집행 목표**: BT7-Plan VS 순수형 반영 재구조 — 개발 영향 집행 (Unity 외부 레포 5파일 + BT 레포 3파일)
|
||||
|
||||
## 대상 파일
|
||||
- `프로젝트/EerieVillage/개발/06_BT7-Plan_VS순수형_재구조.md`
|
||||
- `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md`
|
||||
- `공유/대화로그/EerieVillage/2026-04-24.md`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
commit + push 완료. post-commit hook이 `archived/2026-04-24_BT7-Plan_집행착수.md`로 자동 이동 + target_files cross-check.
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
plan_id: 2026-04-24_BT9_BT10_통합_push
|
||||
created_at: 2026-04-24T21:20:19+09:00
|
||||
hostname: DESKTOP-RD7PUKN
|
||||
goal: "BT9+BT10 통합 집행 commit + push — pm-auditor 조건부 통과(Critical 정정 완료)"
|
||||
target_files:
|
||||
- .claude/settings.json
|
||||
- .claude/skills/BurningTimes-코어룰/SKILL.md
|
||||
- CLAUDE.md
|
||||
- 공유/PD_지시_트래킹/개발팀_PD_지시_로그.md
|
||||
- 공유/PD_지시_트래킹/기획팀_PD_지시_로그.md
|
||||
- 공유/대화로그/EerieVillage/2026-04-24.md
|
||||
- 공유/조직공지/폐기_규칙_아카이브.md
|
||||
completion_criteria: "commit + push 완료 후 post-commit hook archived 이동"
|
||||
---
|
||||
|
||||
# 매니페스트 — 2026-04-24_BT9_BT10_통합_push
|
||||
|
||||
- **등록 시각**: 2026-04-24T21:20:20+09:00
|
||||
- **호스트**: DESKTOP-RD7PUKN
|
||||
- **집행 목표**: BT9+BT10 통합 집행 commit + push — pm-auditor 조건부 통과(Critical 정정 완료)
|
||||
|
||||
## 대상 파일
|
||||
- `.claude/settings.json`
|
||||
- `.claude/skills/BurningTimes-코어룰/SKILL.md`
|
||||
- `CLAUDE.md`
|
||||
- `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md`
|
||||
- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`
|
||||
- `공유/대화로그/EerieVillage/2026-04-24.md`
|
||||
- `공유/조직공지/폐기_규칙_아카이브.md`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
commit + push 완료. post-commit hook이 `archived/2026-04-24_BT9_BT10_통합_push.md`로 자동 이동 + target_files cross-check.
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
---
|
||||
plan_id: 2026-04-24_BT9_BT10_통합집행
|
||||
created_at: 2026-04-24T21:03:20+09:00
|
||||
hostname: DESKTOP-RD7PUKN
|
||||
goal: "BT9+BT10 통합집행 — SKILL 구조 재정렬 + C44~C47 신설 + Hook 2종 + 아카이브 정리"
|
||||
target_files:
|
||||
- .claude/skills/BurningTimes-코어룰/SKILL.md
|
||||
- CLAUDE.md
|
||||
- 공유/조직공지/폐기_규칙_아카이브.md
|
||||
- 공유/조직공지/2026-04-24_BT9_NerdNavis_룰반영_신설.md
|
||||
- scripts/fact_first_check.sh
|
||||
- scripts/identity_guard.sh
|
||||
- .claude/settings.json
|
||||
- 공유/PD_지시_트래킹/개발팀_PD_지시_로그.md
|
||||
- 공유/대화로그/조직운영/2026-04-24.md
|
||||
completion_criteria: "commit + push 완료 후 post-commit hook archived 이동"
|
||||
---
|
||||
|
||||
# 매니페스트 — 2026-04-24_BT9_BT10_통합집행
|
||||
|
||||
- **등록 시각**: 2026-04-24T21:03:21+09:00
|
||||
- **호스트**: DESKTOP-RD7PUKN
|
||||
- **집행 목표**: BT9+BT10 통합집행 — SKILL 구조 재정렬 + C44~C47 신설 + Hook 2종 + 아카이브 정리
|
||||
|
||||
## 대상 파일
|
||||
- `.claude/skills/BurningTimes-코어룰/SKILL.md`
|
||||
- `CLAUDE.md`
|
||||
- `공유/조직공지/폐기_규칙_아카이브.md`
|
||||
- `공유/조직공지/2026-04-24_BT9_NerdNavis_룰반영_신설.md`
|
||||
- `scripts/fact_first_check.sh`
|
||||
- `scripts/identity_guard.sh`
|
||||
- `.claude/settings.json`
|
||||
- `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md`
|
||||
- `공유/대화로그/조직운영/2026-04-24.md`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
commit + push 완료. post-commit hook이 `archived/2026-04-24_BT9_BT10_통합집행.md`로 자동 이동 + target_files cross-check.
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
---
|
||||
plan_id: 2026-04-24_BT9_NerdNavis_룰분석
|
||||
created_at: 2026-04-24T16:43:21+09:00
|
||||
hostname: DESKTOP-RD7PUKN
|
||||
goal: "NerdNavisAi 과거 조직 룰 분석 → BT 조직 프로세스 개선점 발굴·반영 (분석 단계)"
|
||||
target_files:
|
||||
- 공유/PD_지시_트래킹/개발팀_PD_지시_로그.md
|
||||
- 공유/대화로그/조직운영/2026-04-24.md
|
||||
completion_criteria: "commit + push 완료 후 post-commit hook archived 이동"
|
||||
---
|
||||
|
||||
# 매니페스트 — 2026-04-24_BT9_NerdNavis_룰분석
|
||||
|
||||
- **등록 시각**: 2026-04-24T16:43:21+09:00
|
||||
- **호스트**: DESKTOP-RD7PUKN
|
||||
- **집행 목표**: NerdNavisAi 과거 조직 룰 분석 → BT 조직 프로세스 개선점 발굴·반영 (분석 단계)
|
||||
|
||||
## 대상 파일
|
||||
- `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md`
|
||||
- `공유/대화로그/조직운영/2026-04-24.md`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
commit + push 완료. post-commit hook이 `archived/2026-04-24_BT9_NerdNavis_룰분석.md`로 자동 이동 + target_files cross-check.
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
plan_id: 2026-04-24_BT9_NerdNavis_반영집행
|
||||
created_at: 2026-04-24T17:42:43+09:00
|
||||
hostname: DESKTOP-RD7PUKN
|
||||
goal: "BT9 Phase 2 집행 — NerdNavis 9규칙+2P규칙+부가자산 BT 반영"
|
||||
target_files:
|
||||
- .claude/skills/BurningTimes-코어룰/SKILL.md
|
||||
- CLAUDE.md
|
||||
- 공유/조직공지/폐기_규칙_아카이브.md
|
||||
- 공유/조직공지/2026-04-24_BT9_NerdNavis_룰반영_신설.md
|
||||
- 공유/조직공지/2026-04-24_단순반복업무_카탈로그_v1.md
|
||||
- scripts/c9_2_block.sh
|
||||
- scripts/pm_implicit_check.sh
|
||||
- .claude/settings.json
|
||||
- 공유/PD_지시_트래킹/개발팀_PD_지시_로그.md
|
||||
- 공유/대화로그/조직운영/2026-04-24.md
|
||||
- memory/org/feedback_tool_domain_vs_task_domain.md
|
||||
- memory/org/feedback_system_sync_verification_miss.md
|
||||
completion_criteria: "commit + push 완료 후 post-commit hook archived 이동"
|
||||
---
|
||||
|
||||
# 매니페스트 — 2026-04-24_BT9_NerdNavis_반영집행
|
||||
|
||||
- **등록 시각**: 2026-04-24T17:42:44+09:00
|
||||
- **호스트**: DESKTOP-RD7PUKN
|
||||
- **집행 목표**: BT9 Phase 2 집행 — NerdNavis 9규칙+2P규칙+부가자산 BT 반영
|
||||
|
||||
## 대상 파일
|
||||
- `.claude/skills/BurningTimes-코어룰/SKILL.md`
|
||||
- `CLAUDE.md`
|
||||
- `공유/조직공지/폐기_규칙_아카이브.md`
|
||||
- `공유/조직공지/2026-04-24_BT9_NerdNavis_룰반영_신설.md`
|
||||
- `공유/조직공지/2026-04-24_단순반복업무_카탈로그_v1.md`
|
||||
- `scripts/c9_2_block.sh`
|
||||
- `scripts/pm_implicit_check.sh`
|
||||
- `.claude/settings.json`
|
||||
- `공유/PD_지시_트래킹/개발팀_PD_지시_로그.md`
|
||||
- `공유/대화로그/조직운영/2026-04-24.md`
|
||||
- `memory/org/feedback_tool_domain_vs_task_domain.md`
|
||||
- `memory/org/feedback_system_sync_verification_miss.md`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
commit + push 완료. post-commit hook이 `archived/2026-04-24_BT9_NerdNavis_반영집행.md`로 자동 이동 + target_files cross-check.
|
||||
|
|
@ -1 +0,0 @@
|
|||
burningtimes-audit/warning_ignored junction target (C34-17)
|
||||
|
|
@ -1 +0,0 @@
|
|||
burningtimes-live central junction target (C34, 2026-04-18)
|
||||
|
|
@ -1 +0,0 @@
|
|||
burningtimes-memory central (C34-16, 2026-04-19)
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
- [PD 역할](user_role.md) — BurningTimes 경영자이자 PD, 프로젝트 단위 조직 운용
|
||||
- [조직 운용 구조](project_org_structure.md) — PM·개발·기획 3조직. 메인 세션=총괄PM 창구, 실질은 pm-general 서브에이전트 호출
|
||||
- [MD 파일 수정 일괄 승인](feedback_md_approval.md) — 건별 승인 금지, 변경 보고서로 일괄 승인
|
||||
- [승인 반복 절대 금지](feedback_approval_process.md) — Bash/Edit/Write 포괄 허용, 개별 승인 반복 금지
|
||||
- [세션 재시작 사전 고지](feedback_session_restart.md) — 다음 세션부터 적용되는 변경 시 재시작 필요를 반드시 미리 안내
|
||||
- [PM 공유는 코어룰의 기본](feedback_pm_share_principle.md) — 부서의 모든 작업은 PD 직접 지시 여부와 무관하게 무조건 PM 공유. 공유 의무 약화 옵션 제시 절대 금지
|
||||
- [셋팅 점검은 동작·실체까지 검증](feedback_setup_verification.md) — 파일 존재만이 아니라 실파일·junction reparse point·setup 실행 결과까지 확인
|
||||
- [인사이트 즉시 메모리 기록 원칙](feedback_insight_capture.md) — 노하우·교훈·재발방지 룰은 발견 즉시 memory/org/ 에 기록하여 조직 자산으로 축적
|
||||
- [PD 지시 위임 동사 본인처리 우회 금지](feedback_delegation_discipline.md) — "~하라고 해" 등 위임 동사는 반드시 hand-off. 점검 위임 시 3축(파일·OS 동작·실행 결과) 검증 의무 포함
|
||||
- [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 무결성
|
||||
- [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 본 세션 자진 실증
|
||||
- [서브에이전트 역할 연기 금지·실제 Task 호출 필수](feedback_role_play_vs_real_call.md) — Task 호출 검증 없이 "[에이전트 보고]" 형식으로 응답 절대 금지. C23 신설 근거(헌법급·조직 생존 직결). 2026-04-15 개발팀 세션 역할 연기 의혹 실증
|
||||
- [팀 업무 공유·기록 체계 부실](feedback_team_recording_quality.md) — PD 지시 로그 산출물 경로 미갱신·완료 이동 방치 패턴. P27 3축 감사 신설 배경. 2026-04-17 pm-auditor 첫 감사 실증
|
||||
- [PM 과도 보수 해석 — 6회차 변종 (2026-04-20 #48 G)](feedback_pm_over_conservative_interpretation.md) — 원칙 3→원칙 1→배너→대화로그 누락→폐기 표기 잔존→방향·원칙 축소(G 안건) 6회 누적. **C36 헌법급 신설**로 구조 차단. 7회차 재발 시 PM 역할 재검토 자진 상정 의무
|
||||
- [PM Proxy 개선 반사 — 7회차 변종 (2026-04-20 #50)](feedback_pm_proxy_improvement_reflex.md) — 30분 윈도우 문제에 PM이 3안(60분·차등·만료 로그) 모두 proxy 제시. PD님 "모두 근본 해결 아님" 지적. **C2 확장(C2-1~C2-6) + C31-I 체크리스트 + pm-auditor 5-F + 매니페스트 재설계**로 근본 차단
|
||||
- [dev-auditor 산출물 3종 규범 미이행](feedback_dev_auditor_output_gap.md) — 2026-04-17 첫 감사 시 대화로그만 남기고 보고서·feedback 파일 미생성. 감사관 호출 시 산출물 경로 명시 의무 추가 안건 근거
|
||||
- [장기 우산 지시 라운드 완결 아카이브 원칙](feedback_log_round_completion.md) — 2026-04-17 발견. 우산 지시의 라운드 승인분은 즉시 완료 아카이브 이동 + 잔여는 신규 지시로 분리. 활성 테이블 왜곡 차단. P28-4 근거
|
||||
- [PM 세션 맥락 복원 실패](feedback_pm_context_restoration_failure.md) — 2026-04-17 발견. 5계층 근본 원인(세션 공백·P24 비대칭·신규룰 내재화 실패·자기검증 루프 부재·관리자 시야 비대칭) + 재발 방지 5종(P21-5B·P24 읽기 의무·대화로그 소급·pm_context_restore hook·C31 헌법급 격상)
|
||||
- [dev-auditor 감사 범위 형식주의 오판](feedback_dev_auditor_scope_shortcut.md) — 2026-04-18 발견. SKILL.md 문언만 보고 설계 맥락 미확인. 감사 착수 전 관련 설계 문서 선행 Read 의무 추가 안건
|
||||
- [세션 대화로그 누락 — "기록 범위 자의적 축소" 패턴 (🚨 PM 과도 보수 4회차 변종)](feedback_session_log_coverage_gap.md) — 2026-04-18 발견. PM이 이전 프로젝트 Agent 위임 우회 + 코어프레임워크 "false positive" 자가 회피로 대화로그 누락. **PM 역할 재검토 자진 상정 대상**. P24 기록 대상 기준·C31-D 체크·SessionEnd hook 강화로 재발 방지
|
||||
- [폐기 조항 본문 잔존 — "번호 체계 연속성" 관성 (🚨 PM 과도 보수 5회차 변종)](feedback_deprecated_section_retention.md) — 2026-04-18 발견. C7·C8·C12·C15·P20·P24·P27 폐기 표기를 본문에 유지. PD님 "이미 삭제된 내용을 최신 문서에 담지 말라" 명시 지적. **C14-5-확장 코어룰 신설**로 재발 방지. **PM 역할 재검토 자진 상정 강도 상향**
|
||||
- [worktree 격리로 인한 조직 실시간 동기화 실패 🚨 조직 생존급](feedback_worktree_isolation.md) — 2026-04-18 PD님 직접 선언 "해결 안 되면 조직 유지 불가". P25→C34 승격 + 중앙 Junction (C16-1 memory junction 패턴 재사용)으로 근원 해결. "같은 PC=같은 파일시스템" 직관은 worktree에서 성립하지 않음
|
||||
- [Agent 절대 경로 하드코딩 금지 — worktree 경계 보호](feedback_agent_path_boundary.md) — 2026-04-18 worktree 격리 2차 사건. Agent가 `E:\BurningTimesAi\...`로 Write 호출 → 레포 루트 유출. `git stash push/pop` 이관 복구 + Agent 호출 프롬프트 경로 규약 명시 의무
|
||||
- [PD 지시 로그 활성 테이블 완료 상태 잔류 — 즉시 이동 의무 위반](feedback_active_archive_promotion_omission.md) — 2026-04-18 #39 실증. PD님 "재보고 불요 + 4W 즉답 체계" 지시. P19 강화(즉시 이동 의무·즉답 접두 체계) + 감사관 3종 체크 확장으로 재발 방지
|
||||
- [C34/C16-1 동급 생존성 이슈 축소 보고 금지 🚨 PM 자진 반성](feedback_issue_under_reporting.md) — 2026-04-19 PD님 직접 지적. memory junction 이슈를 "운영 규율로 커버" 완화 판정 + 침묵. C2·C3·C5·C29 위반 자인. C34 옵션 A 집행 + 재발 방지 4종(feedback·감사관 체크·C31 확장 안건)
|
||||
- [memory junction 타깃 오연결 — HOME 중앙화 근원 해결](feedback_memory_junction_repo_root_misdirect.md) — 2026-04-18~19 4건 실증. 레포 루트 연결 junction으로 worktree Write 유출 반복. C34 옵션 A 집행(중앙 저장소 + sync 4계층)으로 근원 해결. Write 경로 규약 C34-16 신설
|
||||
- [백업 파일명 C6-1 표준 위반 — 관성적 답습 패턴](feedback_backup_filename_format_violation.md) — 2026-04-19 PD님 지적으로 발견. 8곳 스크립트에서 `.bak-YYYYMMDDHHMMSS` 사용, C6-1 표준 `.bak_YYYYMMDD_HHMM` 위반. 최초 위반(2026-04-18 Live junction)이 이후 모든 파생 스크립트로 연쇄 오염. "기존 코드 답습 ≠ 조직 표준 준수" 원칙 수립
|
||||
- [안건 프레이밍 중복·이미 결정된 사안 재질문](feedback_agenda_framing_duplication.md) — 2026-04-19 PM 보고 혼선. "PM 재량"과 "PD 결정" 카테고리에 동일 안건 중복 제시 + 이전 턴 옵션 A 결정 사안 재질문. PD님 직접 지적 "같은 안건 아니야?" 수용. 방지 대책 3종(자기검증·감사관·표준 포맷) 신설
|
||||
- [종결 안건 자동 언급 금지 — 최신 결정 중심 보고](feedback_resolved_agenda_unnecessary_reference.md) — 2026-04-19 PD님 직접 지적. PM이 #38 예상 결과 보고에서 이미 확정된 종결 안건을 "고착·영구 종료"로 재언급. P28-8 신설 + pm-auditor 5-D로 방지. 본 세션 PM 보고 품질 문제 3연속 패턴 중 3번째
|
||||
- [PM C35 경고 무시 사례 누적 SOT](feedback_pm_warning_ignored_pattern.md) — 2026-04-19 PD님 지시 "경고 무시 PD 우선 보고 + 감사 자산 축적" 이행용. auditor_guard.sh UNRESOLVED 경고·BYPASS 우회가 장시간 방치·남용된 사례 6필드 기록. 분기별 review → 패턴 개선 안건화
|
||||
- [C34 중앙 저장소 sentinel 손실 — 자동 보호 강화](feedback_central_sentinel_loss.md) — 2026-04-19 다른 세션 verify_setup이 marker 부재 정확 감지. git 외 작업으로 손실 (원인 미상). 안건 A 집행: live_junction_ensure.sh를 UserPromptSubmit hook에 편입 → 손실 윈도우 1프롬프트 이내로 축소
|
||||
- [C34 memory sync 덮어쓰기 사고 — 레포 최신본 보호 강화](feedback_memory_sync_overwrite.md) — 2026-04-19 12차 commit 직후 post-commit sync가 Edit 내용 덮어씀. C34-16 Write 경로 혼용 + sync 스크립트 mtime 미비교 구조 결함. D안 집행: sync_memory_central_to_repo.sh mtime 보호 + C34-16 보강
|
||||
- [PM "실질 필요성 없음에도 표면적 근거로 제안" 패턴](feedback_pm_surface_rationale_proposal.md) — 2026-04-19 paths.local.json 수동 생성 권고 사건. PD님 "왜 필요한지 설명해" 질문으로 실질 필요성 없음 자인·철회. 재발 방지 체크리스트 4문항(실질 이득·실사용 사례·정확성 검증·현 상태 유지 비교) 명문화. PM 보고 품질 4연속 패턴 중 4번째
|
||||
- [auditor_call_log RESOLVED word boundary 결함](feedback_auditor_resolved_substring_bug.md) — 2026-04-20 #48 A 집행. grep -q "RESOLVED"가 "UN**RESOLVED**" 부분문자열 매칭되어 append 영구 실패. grep -qw 수정 + 본 PC UNRESOLVED 수동 해소로 즉시 검증. 모든 PC 공통 구조 결함
|
||||
- [종결된 사유를 현재 HOLD 사유처럼 재프레이밍 금지 — 현 상태 왜곡 (5회차 판정 확정)](feedback_resolved_cause_as_current_hold.md) — 2026-04-20 4·5회차 + **PD님 판정 확정 (2026-04-20): 현 PM 유지 · C31-E 확장 승인 · 6회차 이관 선제 동의**. 4회차: #38 답변 중 해결 완료 Python 시뮬·Unity MCP 전환을 현재 HOLD 사유로 서술. 5회차: "세션 공유 후 남은 업무" 재요청에 **완료·push된 #52-B·#52-B2를 "대기"로 유지** (실측 응집성 실패 축). SKILL.md C31-1 E 그룹 "실측 응집성 축" 체크 문항 헌법급 편입. **재발 시마다 PM 반성 + 구조 개선안 자진 제시 + 체크리스트 확장 안건화 + 강조 선언 4종 의무 부과** (PD님 직접 지시). 6회차 재발 시 PM 역할 재검토는 PD님 명시 결정 영역 이관
|
||||
- [PM 실측 가능 범위 자의적 축소 — 환경·능력 과소평가 금지](feedback_pm_capability_underestimation.md) — 2026-04-20 5회차 PM 의무 4종 후속. PM이 `mcp__unity-mcp__*` deferred tools를 실측 없이 "환경 부재"로 반복 단언하여 선행 조건 2를 "스켈레톤만"으로 축소. PD님 "유니티 MCP 연결 환경은 이미 확보되어 있어" 지적으로 정정. **ToolSearch + 간이 실측 의무화** + 환경·능력 주장 전 실측 근거 첨부 필수. C23 "추정의 사실화" 특수 유형. 과거 시점 설계 문서 "미확인 고지"를 현 시점 상태로 재적용 금지
|
||||
- [git 레포 점검 범위 축소 — 상위 디렉토리만 확인 후 "레포 아님" 단언](feedback_git_scope_shortcut.md) — 2026-04-20 #57 자진 고지 오류 양축. 개발팀장이 `D:\BurningTimes\FilGoodBandits` 상위만 확인 → "C30 점검 불가" 단언. 실제로는 하위 `DeckBuilding`이 git 레포 (remote `BurningTimes/DeckBuilding.git`). PM도 Agent 응답을 추가 재실측 없이 수용 (C27 변형 위반). **해결**: Unity 프로젝트 SessionStart 자동 pull 구축(옵션 A PD 승인) · `.git` 존재 검사 2~3단계 하위까지 · Agent 환경 판정 주장은 PM 재실측 의무. C30-1 조항 "수동 점검" → "자동 이행"으로 정비
|
||||
- [정부 지원 사업 문서 처리 도구 (조직 자산)](reference_govt_support_docs_toolkit.md) — docx·hwp·pdf 처리용 Python 라이브러리 세트(pypdf·pyhwp·olefile·lxml·six·pywin32) 대표자 PC 로컬 설치 완료. 한컴 2018 + MS Word 환경. 향후 정부 지원 사업 공고 대응·양식 편집·평가 반영 시 즉시 재활용 가능
|
||||
- [MCP 도구 셋업 실전 함정 5종 — 재발 방지 SOT](feedback_mcp_setup_pitfalls.md) — 2026-04-21~22 BT3 Unity MCP 도입 실증. (1) Claude Desktop HTTP 미지원 → stdio 전용 (2) uvx 첫 설치 시 `pywin32` 캐시 락 → 수동 사전 워밍업·Defender 예외 (3) Claude 좀비 인스턴스 "Could not attach" → 트레이 Quit·작업관리자 전수 종료 (4) 다른 PC config 경로 무효 → PC별 재구성 (5) Unity Package Transport 기본 HTTP → Claude Desktop 대상 stdio 전환. 차기 MCP 도구 도입 시 첫 참조 자산. 연관 `공유/조직자산/시행착오_아카이브/개발_MCP연동_v1.md` · `공유/조직공지/2026-04-22_Unity_MCP_연동_표준_워크플로우_v2.md`
|
||||
- [조직운영 프로젝트 맥락 — 최신 20개](project_context_조직운영.md) — 🏆 계층 0 고정 주입 SOT. 이벤트 기반 append·21개 초과 시 가장 오래된 엔트리를 _archive.md로 이동. 방향 전환·중요 결정·Phase 완결 시점마다 PM 1줄 기록. BT4 6계층 세션 시작 교훈 환기 체계의 장기 맥락 축
|
||||
- [조직운영 맥락 아카이브](project_context_조직운영_archive.md) — 활성 SOT에서 밀려난 엔트리 영구 보존. 첫 엔트리 이동 시점이 `feedback_session_restore_monitoring.md` 트리거
|
||||
- [🏆 세션 시작 교훈 환기 6계층 pm-auditor 모니터링 SOT](feedback_session_restore_monitoring.md) — 2026-04-23 PD 직접 지시. BT4 6계층 체계 운영 중 이슈·비효율 pm-auditor 지속 모니터링·개선점 PD 보고. 트리거 = project_context_조직운영_archive.md 첫 엔트리 이동. 축적 데이터 6항목(계층별 발동·주입량·감사관 E안 윈도우·트리거 정확도·누락 중복·tier 태깅 정확성)
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
---
|
||||
name: 세션 시작 교훈 환기 6계층 운영 모니터링 보고서 (2026-04-23_0200)
|
||||
description: BT4 6계층 체계 운영 데이터 누적 분석. pm-auditor 지속 모니터링 SOT 기반. 개선 안건 식별 + PD 보고
|
||||
type: audit_pattern
|
||||
period: 2026-04-23_0200
|
||||
trigger: archive_entry_moved
|
||||
---
|
||||
|
||||
# BT4 6계층 운영 모니터링 보고서 — 2026-04-23_0200
|
||||
|
||||
## 1. 트리거 상태
|
||||
- project_context_조직운영_archive.md 엔트리 수: 2
|
||||
|
||||
## 2. 감사관 E안 자동 윈도우 실측
|
||||
- pm-auditor: 7일
|
||||
- dev-auditor: 7일
|
||||
- plan-auditor: 7일
|
||||
|
||||
## 3. 계층별 발동 통계
|
||||
|
||||
**BT4 6계층 첫 가동 모니터링 스켈레톤** — 운영 데이터 축적 대기 상태. 본 보고서는 BT4 집행 완결(2026-04-23 `37729cd`) 이후 `project_context_조직운영_archive.md` 첫 엔트리 이동 시점 자동 발동분이며, 실 운영 데이터는 **다음 archive 이동 시점**부터 축적되어 다음 보고서(`audit_pattern_analysis_6계층_{YYYY-MM-DD_HHMM}.md`)에 집계 예정.
|
||||
|
||||
- 계층 0 고정 주입: 매 세션 1회 (기본 전제, BT4 집행 이후 활성)
|
||||
- 계층 1~5: 운영 데이터 축적 대기 (현 시점 기록 없음)
|
||||
|
||||
## 4. 개선 안건
|
||||
|
||||
**본 첫 가동 스켈레톤 단계에서는 개선 안건 없음** — BT4 규칙 그대로 운영하며 최소 1회 이상의 archive 이동 사이클 관찰 후 Phase 3-B·3-C 실 데이터 기반 개선 안건 도출 예정.
|
||||
|
||||
## 5. PD 결정 요청
|
||||
|
||||
**현 시점 없음** — 다음 이동 사이클의 데이터 축적 후 PM·pm-auditor 협의로 개선 안건 도출 시 PD 보고
|
||||
|
||||
## 연관
|
||||
- `memory/org/feedback_session_restore_monitoring.md` (모니터링 SOT)
|
||||
- `memory/org/project_context_조직운영.md` (트리거 기반)
|
||||
- `scripts/recent_feedback_brief.sh` (6계층 구현)
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
---
|
||||
name: 세션 시작 교훈 환기 6계층 운영 모니터링 보고서 (2026-04-24_1231)
|
||||
description: BT4 6계층 체계 운영 데이터 누적 분석. pm-auditor 지속 모니터링 SOT 기반. 개선 안건 식별 + PD 보고
|
||||
type: audit_pattern
|
||||
period: 2026-04-24_1231
|
||||
trigger: archive_entry_moved
|
||||
---
|
||||
|
||||
# BT4 6계층 운영 모니터링 보고서 — 2026-04-24_1231
|
||||
|
||||
## 1. 트리거 상태
|
||||
- project_context_조직운영_archive.md 엔트리 수: 2
|
||||
|
||||
## 2. 감사관 E안 자동 윈도우 실측
|
||||
- pm-auditor: 7일
|
||||
- dev-auditor: 7일
|
||||
- plan-auditor: 7일
|
||||
|
||||
## 3. 계층별 발동 통계 (pm-auditor 수동 기입 영역)
|
||||
- 계층 0 고정 주입: 매 세션 1회 (기본 전제)
|
||||
- 계층 1 (1일): (기입)
|
||||
- 계층 2 (2~7일): (기입)
|
||||
- 계층 3 (>7일): (기입)
|
||||
- 계층 4 (--extend=N): (기입)
|
||||
- 계층 5 (내용축 트리거): (기입)
|
||||
|
||||
## 4. 개선 안건 (pm-auditor 수동 기입)
|
||||
- (계층 추가·폐기·통합 / 트리거 조정 / 계층 0 대상 조정 / 감사관 윈도우 튜닝)
|
||||
|
||||
## 5. PD 결정 요청
|
||||
- (pm-auditor 우선순위 기입)
|
||||
|
||||
## 연관
|
||||
- `memory/org/feedback_session_restore_monitoring.md` (모니터링 SOT)
|
||||
- `memory/org/project_context_조직운영.md` (트리거 기반)
|
||||
- `scripts/recent_feedback_brief.sh` (6계층 구현)
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
---
|
||||
name: PD 지시 로그 활성 테이블의 완료 상태 잔류 — 즉시 이동 의무 위반
|
||||
description: 2026-04-18 PD님 지적. PM이 #39 C34 집행 완료 상태로 변경했으나 활성 테이블에 잔존시켜 PD님이 재보고 받는 상황 발생. P19 강화(즉시 이동 + 즉답 접두 체계) + 감사관 3종 체크 확장
|
||||
type: feedback
|
||||
originSessionId: 0c3fc143-5c2a-4165-afb1-7becf72eaa0a
|
||||
---
|
||||
# PD 지시 로그 활성 테이블의 완료 상태 잔류 — 이동 의무 위반
|
||||
|
||||
## 실증 (2026-04-18)
|
||||
PM이 C34 집행 완료 후 개발팀 PD 지시 로그 #39 행을 활성 테이블에서 **`진행중` → `완료`로 상태만 변경**하고 행 자체를 활성 테이블에 잔존. 세션 B에서 업무 현황 파악 시 "개발팀 활성 3건 — #2 보류, #38 보류, **#39 완료(활성 잔존)**"이 노출되어 PD님이 **이미 완료된 작업을 재보고받는** 상황 발생.
|
||||
|
||||
PD님 직접 지적:
|
||||
> "작업 완료 유무는 이미 지시한 사람이 알고 있는 상태이기 재보고 할 필요 없도록 조치하고, 내가 '무슨 작업'을 '언제', '어떻게' 완료 되었는지 등을 물어보았을 때 즉시 답변할 수 있도록 아카이브만 철저히 해두도록 프로세스를 보완해."
|
||||
|
||||
## 조직 운영 원칙 충돌
|
||||
- **활성 테이블** = "지시자(PD님)가 아직 완료 여부를 모르는 작업" 섹션
|
||||
- **완료 아카이브** = "지시자가 이미 완료를 인지한 상태의 과거 기록"
|
||||
- 완료분이 활성에 잔류 = **PD님 재보고 발생** = 조직 운영 원칙 위반
|
||||
|
||||
## 근본 원인
|
||||
1. **P19 기존 규정 불이행**: P19는 이미 "완료/취소 상태 변경 시 즉시 아카이브 이동" 명시. PM이 상태 변경만 수행하고 이동 누락
|
||||
2. **C31 체크리스트 구체 문항 부재**: C31-B "C27~C30 준수"는 있으나 "완료 아카이브 이동 확인" 개별 문항 없음
|
||||
3. **관성 패턴**: 현 세션의 산출물을 아직 이해·재사용 중인 시점에 아카이브로 옮기면 "잊어버릴" 심리적 저항
|
||||
4. **감사관 체크 모호성**: pm-auditor 감사 영역 1번이 "상태 갱신 누락"만 언급, "완료 상태 잔류" 별도 문항 없었음
|
||||
|
||||
## 해결 (2026-04-18 집행)
|
||||
1. **#39 즉시 아카이브 이동** (본 사건 당사자로서 소급 정정)
|
||||
2. **P19 강화** — "완료 시 즉시 이동 의무" + "완료 아카이브 즉답 체계" 조항 신설
|
||||
3. **완료 아카이브 즉답 접두 필수화**: `[완료: YYYY-MM-DD HH:MM · commit: hash · 참조: 대화로그 경로]` 맨 앞 필수. PD님 4W 질의 즉답 가능
|
||||
4. **pm-auditor 감사 영역 1 확장**: "활성 테이블의 완료 상태 잔류 감지" + "즉답 접두 누락 감지" 명시
|
||||
5. **dev-auditor·plan-auditor**: 자기 팀 작업 완료 시 동일 체크 수행
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
- 상태를 `완료`/`취소`로 변경하는 순간 **같은 Edit 블록에서 활성 행 제거 + 아카이브 행 추가 동시 수행**
|
||||
- Edit 1건으로 상태만 바꾸면 즉시 C29-4 위반 인지 → 자진 정정
|
||||
- 주기 감사에서 감사관 발견 시 Critical
|
||||
|
||||
## 즉답 체계 운영
|
||||
완료 아카이브에 접두가 있으면:
|
||||
- **"XX 작업 언제 완료?"** → `grep "완료: 2026-04-18" 공유/PD_지시_트래킹/*_로그.md` 즉답
|
||||
- **"어떻게 완료?"** → 접두의 commit hash + 산출물 경로 + 참조 대화로그 1줄 답변
|
||||
- **"뭐 완료됐어?"** → 접두의 지시 요지 + 완료일 리스트 답변
|
||||
|
||||
## 연관
|
||||
- **P19** 강화 (2026-04-18)
|
||||
- **C29-4** 업무 완료 후 동기화 의무
|
||||
- **C31** 응답 발신 직전 자기검증 (체크 문항 추가 검토 안건)
|
||||
- **pm-auditor 감사 영역 1** 확장
|
||||
- `feedback_team_recording_quality.md` (유사 패턴 — 로그 갱신 누락)
|
||||
|
||||
## 교훈
|
||||
**"완료 상태 변경"과 "완료 아카이브 이동"은 별개 작업이다.** 규정(P19)은 이미 존재했지만 실행 계층에서 누락 → 전형적 "규정만 있고 집행 없음" 실패. 해결: (1) 규정 강화 + (2) 감사관 상시 체크 + (3) 즉답 접두로 운영 이득 가시화. 패턴은 "P19 존재를 전제로 한 규율 감사"가 아닌 "P19 불이행을 기본 가정한 감사"로 전환해야 재발 방지.
|
||||
|
|
@ -1,85 +0,0 @@
|
|||
---
|
||||
name: 안건 프레이밍 중복·이미 결정된 사안 재질문 — PM 보고 혼선
|
||||
description: 2026-04-19 발견. PM이 PD님 결정 요청 시 "PM 재량 보정"과 "PD님 결정 사항"을 **상호 배타적이지 않게** 제시하여 같은 안건이 두 카테고리에 중복 등장 + 이미 옵션 A로 결정된 사안을 재질문. PD님 직접 지적 "보정 2번과 결정 1은 같은 안건 아니야?"로 PM 자진 반성
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
# 안건 프레이밍 중복·이미 결정된 사안 재질문 — PM 보고 혼선
|
||||
|
||||
## 실증 (2026-04-19 PD님 직접 지적)
|
||||
|
||||
PD님 직접 지적:
|
||||
> "보정 1~4가 PM 재량이라고 보고한 것과 결정 내용이 중복되는거 같아. (예를들어 보정 2번과 결정1은 같은 안건 아니야?)"
|
||||
|
||||
PM이 C6-1 위반 보정 방안을 보고할 때 제시한 구조:
|
||||
- **PM 재량 즉시 집행**: 보정 1·2·3·4 (4건)
|
||||
- **PD님 결정 필요**: 결정 1·2 (2건)
|
||||
|
||||
**실제 관계 재분석**:
|
||||
- **보정 2** (기존 `.bak-*` 디렉토리 rename) = **결정 1** (rename 수행 여부) — **정확히 동일 안건을 두 카테고리에 중복 제시**
|
||||
- **결정 2** (경위 기록 vs 소급 정정) = **이전 턴 옵션 A로 이미 결정된 사안** — **재질문**
|
||||
|
||||
→ **2중 혼선**: 카테고리 경계 모호 + PD님 이전 결정 망각
|
||||
|
||||
## 영향
|
||||
|
||||
- **PD님 의사결정 피로 유발**: 결정 안 해도 되는 사안을 "결정 필요"로 제시
|
||||
- **승인 범위 불분명**: PM 재량 vs PD 결정 경계가 흐려져 C19 승인 범위 엄격 해석 원칙 훼손 우려
|
||||
- **같은 안건을 두 번 답변 강요**: "PM 재량으로 진행할 건가?"와 "결정은 무엇인가?"를 같은 내용으로 두 번 물은 셈
|
||||
|
||||
## 근본 원인 3종
|
||||
|
||||
1. **안건 분류 자기검증 부재**: PM이 보고 작성 후 "각 안건이 상호 배타적인가" 자체 검증 안 함
|
||||
2. **PD님 이전 결정 재확인 생략**: 같은 세션 내 이미 "옵션 A" 결정된 사안을 "결정 2"로 재포장. 세션 맥락 재스캔 생략
|
||||
3. **카테고리 정의 모호**: "PM 재량"은 "집행 주체"이고 "PD 결정"은 "의사결정 주체"인데, **같은 안건이 양쪽에 등장 가능**한 제시 방식 선호 (실제로는 한쪽에만 있어야 함)
|
||||
|
||||
## 해결 (PD님 지적 즉시 수용, 2026-04-19 집행)
|
||||
|
||||
### 즉시 정정
|
||||
- PM 재량 = 보정 1·3·4 (3건)
|
||||
- PD님 결정 = 보정 2 (1건, 기존 `.bak-*` rename 여부)
|
||||
- 이전 "결정 2"는 옵션 A로 기결정 → 철회
|
||||
|
||||
### 방지 대책 3종
|
||||
|
||||
1. **PM 보고 작성 자기검증 체크리스트 추가** (C31 확장 안건):
|
||||
- [ ] 각 안건이 **상호 배타적 카테고리**에 속하는가? (중복 0건)
|
||||
- [ ] PD님이 **이전 턴·이전 세션에 이미 결정한 사안**을 재질문하지 않는가?
|
||||
- [ ] "PM 재량" 카테고리와 "PD 결정" 카테고리의 경계가 **명확한 기준**으로 분리되는가?
|
||||
|
||||
2. **감사관 체크 추가** (pm-auditor):
|
||||
- PM 보고의 안건 리스트 중복 감지
|
||||
- PD님 이전 결정 사안 재질문 감지 (PD 지시 로그·대화로그 교차 검증)
|
||||
|
||||
3. **안건 분류 표준 포맷**:
|
||||
```
|
||||
## PM 재량 집행 (PD님 결정 불요, N건)
|
||||
- 보정 X — 상세
|
||||
|
||||
## PD님 결정 필요 (N건)
|
||||
- 결정 X — 선택지 A/B
|
||||
|
||||
## 중복·재질문 체크
|
||||
- [ ] 상위 2카테고리 안건 ID 상호 배타 확인 완료
|
||||
- [ ] 이전 턴 결정 사안 재질문 0건 확인 완료
|
||||
```
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
|
||||
- PM 보고 응답 발신 전 **안건 리스트 상호 배타성 자체 검증**
|
||||
- **"같은 내용을 다른 말로 포장해 두 번 묻고 있지 않은가"** 자문
|
||||
- PD님 이전 결정 기록을 재스캔 후 재질문 여부 확인
|
||||
- 혼선 감지 시 즉시 정정 + 본 메모리 재참조
|
||||
|
||||
## 연관
|
||||
|
||||
- **C29** 업무 자율 수행 (PD님 의사결정 피로 회피 원칙)
|
||||
- **C19** 승인 범위 엄격 해석 (카테고리 모호화 방지)
|
||||
- **C31** 응답 발신 직전 자기검증 (본 체크 편입 안건)
|
||||
- `feedback_pm_over_conservative_interpretation.md` (과도 보수 해석 시리즈)
|
||||
- `feedback_issue_under_reporting.md` (2026-04-19 동반 학습 — PM 보고 품질 연속 과제)
|
||||
|
||||
## 교훈
|
||||
|
||||
**"결정을 요청하는 것"과 "집행을 보고하는 것"은 다른 층위다.** 같은 안건을 두 층위에 동시 제시하면 PD님은 "이미 결정한 사안을 다시 결정해야 하나" 혼란. **안건 하나는 반드시 한 카테고리에만 속하도록** 카드 배열. 재질문 여부는 이전 턴 결정 기록을 **명시적으로 재스캔**한 후 보고 확정.
|
||||
|
|
@ -1,62 +0,0 @@
|
|||
> 🟢 **역사 보존 (해결 완료 2026-04-26)** — worktree 자동 생성·Junction 체계 폐기로 본 패턴 구조 차단. 본 메모리는 조직 학습 자산으로 보존.
|
||||
|
||||
---
|
||||
name: Agent 호출 시 절대 경로 하드코딩 금지 — worktree 경계 보호
|
||||
description: 2026-04-18 worktree 격리 2차 사건. Agent가 절대 경로로 Write 호출 시 레포 루트로 산출물 유출. stash 이관 복구 절차 + 재발 방지 체크리스트
|
||||
type: feedback
|
||||
originSessionId: 0c3fc143-5c2a-4165-afb1-7becf72eaa0a
|
||||
---
|
||||
# Agent 호출 시 절대 경로 하드코딩 금지 — worktree 경계 보호
|
||||
|
||||
## 실증 (2026-04-18, worktree 격리 2차 사건)
|
||||
PM(tender-liskov worktree)이 개발팀장 Agent를 호출. Agent가 산출물 경로에 **절대 경로 `E:\BurningTimesAi\공유\소통\개발팀→PM\...`**를 사용하여 Write. 이로 인해 파일이 **레포 루트(main 브랜치 체크아웃)에 기록**되고 본 워크트리는 해당 파일을 볼 수 없음.
|
||||
|
||||
Agent 응답에 "476줄 산출물 작성 완료"라 보고되었으나 PM 세션의 `공유/소통/개발팀→PM/`에는 없었음. `git -C "E:/BurningTimesAi" status` 확인으로 레포 루트에 uncommitted 변경 3건(PD 지시 로그·대화로그·보고서) 발견.
|
||||
|
||||
## 근본 원인
|
||||
- Agent는 실행 환경의 `cwd`를 계승하나, Write 도구에 **절대 경로**를 전달하면 cwd와 무관하게 해당 경로에 기록
|
||||
- `E:\BurningTimesAi`는 레포 루트(main 브랜치 체크아웃) — worktree가 아닌 독립 작업 디렉토리
|
||||
- Agent가 worktree 경계를 인지하지 못하고 "레포 절대 경로 = 안전한 표준"으로 처리
|
||||
- PM은 Agent 응답만 보고 산출물 실체 위치 미확인 → worktree 경계 이탈을 검증 없이 신뢰 (C23 관점에서도 문제)
|
||||
|
||||
## 복구 방법 (2026-04-18 실증)
|
||||
1. `git -C <레포루트> stash push -u -- <영향 경로>` — Agent가 쓴 변경분을 stash로 수집
|
||||
2. 본 worktree에서 `git stash pop` — 동일 base라면 conflict 없이 적용
|
||||
3. `git -C <레포루트> status` 재확인 (clean 여부)
|
||||
4. 본 worktree에서 변경분 검증 후 commit
|
||||
|
||||
## 재발 방지 의무 (세션 리더)
|
||||
1. **Agent 호출 프롬프트에 경로 규약 명시**: "산출물 경로는 `$(git rev-parse --show-toplevel)` 기준 또는 상대 경로로 작성. 절대 경로 `E:\BurningTimesAi\...` 등 하드코딩 금지."
|
||||
2. **Agent 응답 수령 직후 2축 검증**: 본 worktree `git status` + `git -C <레포루트> status` 병행 확인
|
||||
3. **경계 이탈 발견 시**: stash 이관 복구 즉시 수행, PD님께 자진 보고 (C3·C5)
|
||||
4. **감사 확장**: pm-auditor·dev-auditor 체크리스트에 "Agent 경계 이탈 확인" 항목 추가 안건
|
||||
|
||||
## 연관
|
||||
- **C34-11** (Agent 경계 보호 조항)
|
||||
- **C23** (허위 보고·역할 연기 금지)
|
||||
- **feedback_worktree_isolation.md** (1차 사건)
|
||||
- **조직공지**: `2026-04-18_C34_신설_worktree_격리_근원해결.md`
|
||||
|
||||
## 교훈
|
||||
**Agent 위임은 PM 책임 해제가 아니다.** Agent 응답의 "완료" 선언을 실체 파일로 검증하지 않으면 worktree 격리 같은 숨겨진 경계로 인한 누락을 놓칠 수 있다. 특히 "절대 경로의 안전성" 직관은 worktree 체제에서 무력화됨 — Agent가 의도치 않게 다른 worktree/레포 루트에 쓸 수 있음.
|
||||
|
||||
---
|
||||
|
||||
## 관련 사건 로그
|
||||
|
||||
| 회차 | 일자 | 에이전트 | 위반 경로 | 복구 방법 | PM 검증 |
|
||||
|------|------|---------|----------|----------|---------|
|
||||
| 1 | 2026-04-18 | 개발팀장 | `E:\BurningTimesAi\공유\소통\개발팀→PM\...` (레포 루트) | `git stash push` → worktree `stash pop` | 사후 git status 2축 확인 |
|
||||
| 2 | 2026-04-21 | content-designer | `E:\BurningTimes\공유\조직자산\시행착오_아카이브\기획_content_designer_v1.md` (BT main 레포) | PowerShell `Move-Item` → worktree 이동 + main 잔존 디렉토리 `Remove-Item -Recurse` | PM이 Phase 2-B 산출물 14종 실측 중 누락 확인 |
|
||||
|
||||
## 회차 2 경위 (2026-04-21 Phase 2-B 실증)
|
||||
|
||||
Phase 2-B "전 14개 에이전트 동원 수상한잡화점 시행착오 노하우 재정리" 집행 중, `content-designer` 에이전트가 산출물 경로에 **절대 경로 `E:\BurningTimes\공유\조직자산\시행착오_아카이브\기획_content_designer_v1.md`**를 사용. BT main 레포(`E:/BurningTimes/`)로 파일이 유출. PM이 Phase 2-B 완료 후 14개 산출물 실측 시 worktree에는 13개만 존재함을 확인 → 누락된 content-designer 산출물이 BT main 레포에 있음을 발견.
|
||||
|
||||
**근본 원인 재확인**: 프롬프트에 "C34-11 경계 보호: 본 worktree 내 **상대 경로만** 사용. 절대 경로 하드코딩 금지" 명시했으나 에이전트가 **절대 경로 사용이 "명시적 정확성 확보"인 것처럼 판단**. Phase 2-B 14개 에이전트 중 1건(7.1%) 재발.
|
||||
|
||||
**재발 방지 강화**:
|
||||
1. Agent 프롬프트에 "본 worktree 절대 경로는 안전 옵션 아님. `git rev-parse --show-toplevel` 결과 외 경로 사용 시 worktree 경계 위반" 명시 강화
|
||||
2. Phase별 Task 묶음 실행 후 `ls -la` 실측 검증을 PM 체크리스트에 고정
|
||||
3. `E:\BurningTimes\` (main 레포 루트) 경로도 "BT 레포 내부지만 worktree 외부" 범주로 차단 대상 명확화
|
||||
4. content-designer 에이전트 정의(`.claude/agents/content-designer.md`)에 C34-11 조항 명시 검토 (Phase 3 안건)
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
---
|
||||
name: 지시=승인 원칙 (최상위 규칙)
|
||||
description: PD님의 지시 자체가 승인을 내포한다. 이후 개별 승인을 반복 요청하지 않는다. 팀원→팀장 확인 필수, 팀장급은 재량 판단으로 꼭 필요할 때만 PD님에게 확인.
|
||||
type: feedback
|
||||
---
|
||||
|
||||
PD님이 작업을 지시하면 그 자체가 승인이다. 이후 어떤 종류의 하위 작업이든 개별 승인을 반복 요청하지 않는다.
|
||||
|
||||
**Why:** PD님이 수차례 동일한 피드백을 주심. 반복 승인은 PD님의 업무를 방해하는 가장 큰 문제이며, 절대 발생해서는 안 됨.
|
||||
|
||||
**How to apply:**
|
||||
1. PD님이 "진행해", "해줘", "확인해봐" 등 지시하면 → 승인 완료로 간주하고 자체 실행
|
||||
2. 팀원은 팀장에게 확인 후 진행 — 독단 판단 금지
|
||||
3. 팀장급은 재량껏 판단 — PD님의 추가 승인이 꼭 필요하다고 판단될 경우에만 한 번 확인
|
||||
4. settings.local.json에 `"Edit"`, `"Write"`, `"Bash"`, `mcp__서버명__*` 포괄 허용 필수
|
||||
5. 새 도구·서버 추가 시 PD님에게 묻지 않고 와일드카드로 일괄 등록
|
||||
6. 권한 변경 후 다음 세션부터 적용됨을 반드시 사전 안내
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
---
|
||||
name: PD님 승인 범위 확대 해석 절대 금지 (불쾌 경험 실증 근거)
|
||||
description: PD님 승인 표현은 명시적으로 언급된 안건에 한정. 정보 요청·권장·토의를 승인으로 확대 해석하면 PD님이 결정을 강요당하는 불쾌한 경험을 하게 된다. 되돌리기 어려운 액션에서는 특히 치명적.
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
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 프레이밍 오류 → 승인 범위 확대)으로 판단 신뢰도 저하 기록됨
|
||||
|
|
@ -1,69 +0,0 @@
|
|||
---
|
||||
name: auditor_call_log RESOLVED word boundary 결함
|
||||
description: 2026-04-20 #48 A 집행 중 발견. auditor_call_log.sh의 grep -q "RESOLVED"가 "UNRESOLVED" 부분문자열 매칭되어 RESOLVED append 항상 실패. C35-10 경고 무시 해소 사이클 구조적 무력화. grep -qw word boundary로 수정
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# auditor_call_log.sh RESOLVED word boundary 결함
|
||||
|
||||
## 실증 (2026-04-20)
|
||||
|
||||
본 세션 #48 A 집행 중 `auditor_call_log.sh` RESOLVED append 로직 수동 재현 시 발견.
|
||||
|
||||
### 타임라인
|
||||
- 2026-04-20 11:09:10: PM Edit(PD 지시 로그) → auditor_guard.sh → `2026-04-20.log`에 `UNRESOLVED target=의무 영역 파일 수정` append
|
||||
- 2026-04-20 11:10: pm-auditor Task 호출 → auditor_call_log.sh 실행 (`pm-auditor called` 기록 38B)
|
||||
- 2026-04-20 11:12 수동 재현: `tail -1`이 UNRESOLVED 라인 반환, `grep -q "RESOLVED"` **true** (UN**RESOLVED** 부분문자열 매칭), `!` 부정으로 **false** → append 실패
|
||||
|
||||
### 결함 코드 (수정 전)
|
||||
|
||||
`scripts/auditor_call_log.sh:27`
|
||||
```bash
|
||||
if grep -q "UNRESOLVED" "$wf" 2>/dev/null && ! tail -1 "$wf" | grep -q "RESOLVED"; then
|
||||
```
|
||||
|
||||
`grep -q "RESOLVED"`는 "UNRESOLVED"·"RESOLVED" 모두 매칭. **마지막 줄이 UNRESOLVED이면 항상 RESOLVED 매칭 true → 조건 false → append 영구 실패**.
|
||||
|
||||
## 영향
|
||||
|
||||
- **C35-10 경고 무시 해소 사이클 구조적 무력화**: pm-auditor 호출이 UNRESOLVED 해소 기능 전혀 작동 못 함
|
||||
- `audit_pattern_analyzer.sh`가 매 SessionStart에서 "미해소 경고 N건" 환기 지속 → PD님·PM 인지 피로
|
||||
- **모든 PC 공통 구조 결함** (본 PC·전 PC 무관)
|
||||
|
||||
## 해결 (2026-04-20 #48 A 집행)
|
||||
|
||||
### 수정
|
||||
`grep -q "RESOLVED"` → `grep -qw "RESOLVED"` (-w: word boundary)
|
||||
- "UNRESOLVED" 라인 → `-qw RESOLVED` false (정확)
|
||||
- "2026-04-20 RESOLVED by pm-auditor call" → `-qw RESOLVED` true
|
||||
|
||||
### 집행
|
||||
1. `scripts/auditor_call_log.sh:28` 수정 (word boundary 적용 + 결함 주석)
|
||||
2. 본 PC `2026-04-20.log` 수동 RESOLVED append (수정 로직 즉시 검증)
|
||||
3. git 반영으로 모든 PC 자동 동기화
|
||||
|
||||
## 잔여 과제 (G 신규 안건 연계)
|
||||
|
||||
**전 PC(2026-04-19 실증 PC)에서 `auditor_call_log.sh` 파일 자체가 생성 실패**한 원인은 본 결함과 **다른** 이슈. 본 PC에서는 정상 생성 확인. PC 특이적 환경 차이(stdin 인코딩·경로·hook 실행 환경) 추정. 해당 PC 세션 재방문 시 재현 조사 필요 → **G 신규 안건 "PC 로컬 상태 동기화 메커니즘 검토"**와 연계.
|
||||
|
||||
## 교훈
|
||||
|
||||
1. **부분문자열 매칭 함정**: 단어 기반 로그 검색은 반드시 `-w`(word boundary) 또는 정규식 `\b` 또는 명시적 구분자(공백·탭). 접두사·접미사가 있는 단어군에서 `grep -q` 단순 사용 금지
|
||||
2. **감사 체계 자체 감사**: C35-9 Layer 2 설계 당시 본 로직이 6번 이상의 PD님 승인·집행을 통과했음에도 발견 안 됨. pm-auditor 5-E 체크 "감사 체계 자체 자기 검증" 정기화 검토
|
||||
3. **수동 재현 가치**: 자동 hook은 사일런트 실패 가능. PC 변경 시 수동 재현으로 구조 결함 조기 발견 가능
|
||||
|
||||
## 연관
|
||||
|
||||
- **C35-9** Layer 2 호출 기록 + UNRESOLVED 해소 처리
|
||||
- **C35-10** 경고 무시 PD 우선 보고 + 장기 패턴 분석 개선 사이클
|
||||
- `memory/org/feedback_pm_warning_ignored_pattern.md` (상위 누적 SOT)
|
||||
- `memory/org/feedback_c35_initial_enforcement.md` (C35 최초 집행 실증)
|
||||
- #48 B: `pm_context_restore.sh` 경로 기반 필터 전환 (동일 일자 집행)
|
||||
- #48 C: 본 PC 2026-04-20 UNRESOLVED 수동 해소 (A 수정 로직 즉시 검증)
|
||||
|
||||
## 재발 방지 체크리스트
|
||||
|
||||
pm-auditor 감사 시 신설 스크립트·hook 검토 추가 문항:
|
||||
- [ ] 로그·상태 플래그 기반 분기 로직에 **접두사·접미사 변종** 가능성 검토했는가?
|
||||
- [ ] `grep -q` 사용 시 `-w`·`-x`·정규식 경계 필요성 판단했는가?
|
||||
- [ ] 결함 시 사일런트 실패가 아닌 **의미 있는 에러 또는 로그** 출력 설계했는가?
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
---
|
||||
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문항에 "자동화 영역 침범 여부" 항목 결합
|
||||
|
|
@ -1,68 +0,0 @@
|
|||
---
|
||||
name: 백업 파일명 C6-1 표준 위반 — 관성적 답습 패턴
|
||||
description: 2026-04-19 발견. C34 Live junction·memory junction·setup 스크립트 8곳에서 `.bak-YYYYMMDDHHMMSS` 형식 사용 → C6-1 표준 `.bak_YYYYMMDD_HHMM` 위반. 2026-04-18 C34 신설 시점부터 잠재. 신규 스크립트 작성 시 조직 규약 체크 생략이 근본 원인
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# 백업 파일명 C6-1 표준 위반 — 관성적 답습 패턴
|
||||
|
||||
## 실증 (2026-04-19 PD님 지적으로 발견)
|
||||
|
||||
PD님 질문 "C34 확장 집행 완료 과정에 C6-1 원본 보호 규칙을 지키지 않았어?"로 재점검 결과, 조직 표준 백업 포맷 불일치 발견.
|
||||
|
||||
**C6-1 표준**: `{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` (밑줄 + 분 단위)
|
||||
|
||||
**실제 사용 포맷**: 8곳
|
||||
| 파일 | 라인 | 위반 패턴 |
|
||||
|------|------|----------|
|
||||
| `scripts/memory_junction_ensure.sh` | L72 | `.bak-$(date +%Y%m%d%H%M%S)` |
|
||||
| `scripts/live_junction_ensure.sh` | L27 | `.bak-$(date +%Y%m%d%H%M%S)` |
|
||||
| `setup/setup_windows.ps1` | L95·L137·L202 | `.bak-$(Get-Date -Format yyyyMMddHHmmss)` |
|
||||
| `setup/setup_macos.sh` | L52·L77·L120 | `.bak-$(date +%s)` (Unix timestamp) |
|
||||
|
||||
**차이점**:
|
||||
- 구분자 `-` (표준: `_`)
|
||||
- 초 단위 또는 epoch (표준: 분 단위)
|
||||
- macOS는 Unix timestamp로 완전히 다른 형식
|
||||
|
||||
## 근본 원인
|
||||
|
||||
1. **관성적 답습**: 2026-04-18 C34 신설 시 `live_junction_ensure.sh`에서 최초 도입된 비표준 포맷을 이후 모든 신규 스크립트(memory_junction_ensure·setup 3.5·3.6 섹션)가 **참고·계승**. "기존 코드와 동일 패턴"을 "조직 표준 준수"로 착각
|
||||
2. **C34-15 5개 질문 체크리스트 구멍**: worktree 경계·중앙화·Agent 보호는 체크하나 **"기존 조직 규약(C6-1 백업 포맷) 준수" 항목 부재**
|
||||
3. **감사관 체크 부재**: pm-auditor·dev-auditor에 백업 파일명 규약 점검 문항 없음
|
||||
4. **PM 자기검증 누락**: 스크립트 Write 시 "백업 자동 수행" 자체만 확인, 포맷 표준 대조 생략
|
||||
|
||||
## 영향
|
||||
|
||||
- **데이터 손실**: 0건 (백업 자체는 정상 수행)
|
||||
- **복구 가능성**: 문제없음 (파일 존재 확인 가능)
|
||||
- **규약 준수**: 형식 위반 (감사 시 Major급 지적 대상)
|
||||
- **탐지성 저하**: `grep .bak_2026` 표준 쿼리로 누락 위험
|
||||
|
||||
## 해결 (2026-04-19 집행)
|
||||
|
||||
1. **8곳 백업 포맷 C6-1 표준 수정**:
|
||||
- Bash: `.bak_$(date +%Y%m%d_%H%M)`
|
||||
- PowerShell: `.bak_$(Get-Date -Format yyyyMMdd_HHmm)`
|
||||
2. **기존 생성된 `.bak-*` 디렉토리**: PD님 결정 "생략" 수용 — 데이터 멀쩡, 앞으로 생성분만 표준 적용
|
||||
3. **C34-15 체크리스트 6번째 질문 추가 안건**: "신규 스크립트의 백업·삭제·롤백 로직이 C6-1 표준(`.bak_YYYYMMDD_HHMM`)을 따르는가"
|
||||
4. **감사관 체크 추가**: pm-auditor·dev-auditor에 "백업 파일명 C6-1 표준 준수" 체크 신설
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
|
||||
- 신규 스크립트에서 **백업·삭제·롤백 로직 작성 시 C6-1 본문 재읽기**
|
||||
- 기존 스크립트 포맷을 **무조건 답습하지 말고** 조직 표준 대조
|
||||
- `grep -n "\\.bak" scripts/ setup/`으로 정기 전수 감사
|
||||
- 백업 파일명은 **`{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}` 템플릿 고정**
|
||||
|
||||
## 연관
|
||||
|
||||
- **C6-1** 원본 보호 (본 조항 대상)
|
||||
- **C2** 근원적 해결 / **C5** 정직성 / **C3** 이슈 은폐 금지 (자진 보고 의무)
|
||||
- **C34-15** worktree 경계 체크리스트 (6번째 질문 확장 안건)
|
||||
- `feedback_pm_over_conservative_interpretation.md` (관성적 답습은 과도 보수의 변종)
|
||||
- `feedback_memory_junction_repo_root_misdirect.md` (C34 확장 세션 동반 집행)
|
||||
|
||||
## 교훈
|
||||
|
||||
**"기존 코드 답습 ≠ 조직 표준 준수"**. 신규 스크립트 작성 시 가장 가까운 기존 코드를 참조하는 건 생산성 측면에서 자연스러우나, **해당 기존 코드 자체가 이미 조직 표준 위반일 가능성**을 전제로 규약 대조가 필수. C34 Live junction 스크립트가 2026-04-18에 이미 비표준 포맷으로 도입되어 그 후 모든 파생 스크립트 오염 — 최초 위반이 길게 연쇄되는 전형 사례.
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
---
|
||||
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(정직성)는 "거짓말을 안 한다"뿐 아니라 **상태의 실질이 도달했는지 확인하지 않은 완료 선언 금지**까지 포함
|
||||
|
|
@ -1,87 +0,0 @@
|
|||
---
|
||||
name: C35 최초 적용 실증 — hook 체계 부재 상태의 PM 의식 준수
|
||||
description: 2026-04-19 C35 신설 당일 첫 적용. hook 체계 부재 상태에서 PM이 의식적으로 pm-auditor 의무 호출 이행한 긍정 실증. 30분 윈도우 경계 초과 5건 식별이 C35-9 Layer 3 재설계 근거로 이어짐
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
# C35 최초 적용 실증 — hook 체계 부재 상태의 PM 의식 준수
|
||||
|
||||
**신설일**: 2026-04-19
|
||||
**기록 주체**: pm-auditor (모드 A 응답 발신 직전 교차 검증)
|
||||
**위험도**: Improvement — 긍정 실증 사례 (규칙 준수 축적)
|
||||
|
||||
---
|
||||
|
||||
## 1. 사건 요지
|
||||
|
||||
2026-04-19 PM이 C35-9·C35-10 신설 집행안을 발신하기 전 **pm-auditor를 Task 도구로 실제 호출**했다. 이는 다음 이중 의미를 가진다:
|
||||
|
||||
1. **C35-1 "1. 규칙 개정·신설" 의무 호출 준수** — 정상 집행
|
||||
2. **C35 최초 적용 실증** — 집행 대상이 C35 자체의 hook 강제 체계 신설. 즉 Layer 2·3 hook이 아직 **없는 상태**에서 사전 호출 의무를 PM이 수동으로 준수
|
||||
|
||||
## 2. 닭과 달걀 역설 검토
|
||||
|
||||
**표면적 역설**: "사전 호출 자동 강제 hook이 없는 상태에서의 사전 호출은 무엇이 보장했는가?"
|
||||
|
||||
**해소 논리**:
|
||||
- C35-1은 **문언(규칙 본문)으로 이미 존재** — 2026-04-19 02:00 commit a9dde7a 시점에 SKILL.md C35 본문 포함
|
||||
- LLM(PM)이 C35-1 문언을 **인지하고 의식적으로 준수** = C35-7 "~90% 커버 · PM 의식 의존" 실증
|
||||
- hook 3층은 본 집행으로 **추가 설치** 대상 — 향후 호출 이력 자동 기록·미호출 탐지·장기 패턴 분석 인프라
|
||||
- 따라서 **닭과 달걀 역설 없음**. 문언이 먼저 존재하고 hook은 후속 보강 층위
|
||||
|
||||
## 3. C35-7 한계 인정의 실증
|
||||
|
||||
C35-7 원문: "LLM 자율 판단 구조상 코드·hook 레벨에서 강제 불가. 명문화 + 자기검증 + 감사관 재귀 감사 3중 구조로 ~90% 커버하되, 100% 강제는 PM 의식적 준수에 의존."
|
||||
|
||||
본 사건은 이 한계 인정의 **긍정적 실증**:
|
||||
- PM이 "C35-1 대상 7종 중 1번" 자기 인지
|
||||
- Task 도구 실제 호출 수행
|
||||
- hook 부재 상태에서도 의식적 준수 성립
|
||||
|
||||
**단 경고**: PM이 C35-1 문언을 **인지 실패**하는 경우 hook 부재 상태에서는 탐지 불가. 본 집행 완료 후 Layer 2·3이 활성화되어야 사후 탐지 가능. 따라서 **본 집행은 C35 완전 기능화의 임계점**.
|
||||
|
||||
## 4. 재발 방지·축적 가치
|
||||
|
||||
### 4-1. 긍정 패턴 (계승)
|
||||
|
||||
- 신규 코어룰 신설 시 PM이 **본인 발의 집행안에 감사관 호출** 포함 — 셀프 감사 프로세스 내재화
|
||||
- PD님 직접 지시 + 현 규칙 적용 동시 발생 시 **"규칙 신설이 곧 규칙 준수 대상"** 자기 참조 구조 성립 확인
|
||||
|
||||
### 4-2. 경계 패턴 (차기 사례)
|
||||
|
||||
- 향후 C·P 규칙 신설이 **자기 참조**(본 규칙을 본 규칙이 감사)할 때 본 feedback 참조
|
||||
- hook 부재 상태에서 PM이 자기검증만으로 감사를 대체하려는 시도 발견 시 **C35-1 문언 직접 호출 의무** 재확인
|
||||
|
||||
## 5. pm-auditor 감사 결과 종합
|
||||
|
||||
- **Critical 0 · Major 3 · Minor 1 · Improvement 3**
|
||||
- 5-A 축소 보고 감지 PASS (Major-3 정정 조건)
|
||||
- C35 최초 적용 실증으로 feedback 메모리 등재 권고 수용 → 본 파일 신설
|
||||
|
||||
## 6. 연관
|
||||
|
||||
- **C35** pm-auditor 의무 참여 체계 (본 feedback 직접 근거)
|
||||
- **C35-7** 근본적 한계 인정 (본 실증의 상위 조항)
|
||||
- **C29** 업무 자율 수행 (팀 논의·자율 수행 원칙과의 정합)
|
||||
- **C31** 응답 발신 직전 자기검증 (F 그룹 C35 준수 문항)
|
||||
- `feedback_issue_under_reporting.md` (C34/C16-1 동급 생존성 축소 보고 금지 — 본 감사 5-A 체크 근거)
|
||||
- `feedback_pm_over_conservative_interpretation.md` (PM 과도 보수 4회차 변종 — 축소 해석 상위 패턴)
|
||||
- 감사보고: `공유/소통/pm-auditor→PM/2026-04-19_감사보고_C35-9_10_신설.md`
|
||||
|
||||
## 7. 교훈
|
||||
|
||||
**규칙 신설 집행도 그 규칙의 준수 대상이다.** C35 신설안을 PM이 발의할 때 C35-1이 이미 유효하므로 감사관 사전 호출 의무가 적용된다. 이는 규칙 체계의 **자기 참조 완결성**을 보여주는 긍정 실증이며, 차기 규칙 신설 시에도 동일하게 적용되어야 한다.
|
||||
|
||||
**hook 부재 = 규칙 무력 아니다.** C35-7 "~90% 커버"의 90%는 문언 + 의식적 준수로 달성되며, hook 3층은 잔여 ~10% 탐지·기록을 위한 보강 층위다. 본 사건은 이 90% 층위의 정상 작동 증명.
|
||||
|
||||
---
|
||||
|
||||
## 8. 구 실증 아카이브 이관 — 30분 윈도우 기반 설계 폐기 (2026-04-20 #50 집행)
|
||||
|
||||
> **🔴 본 섹션 내용 이관 완료 (2026-04-20 #50)**: 구 "30분 시간 윈도우 경계 초과 실증"은 **C35-9 Layer 3 PreToolUse 차단 전환**으로 전체 폐기됨. 30분 윈도우·UNRESOLVED 로그·BYPASS 우회 체계 모두 폐기. 실증 이력과 방향 전환 경위는 **`공유/조직공지/방향전환_히스토리_아카이브.md` "C35-9 Layer 3 — 시간 윈도우 → PreToolUse 차단 전환" 섹션**으로 이관. 본 feedback 파일은 **C35 최초 집행(2026-04-19)**의 긍정 실증만 유지 (§1~§7).
|
||||
>
|
||||
> **현행 감사 체계**: PreToolUse 차단 + 해제 워크플로우. `scripts/auditor_gate.sh` + `manifest_register.sh` + `manifest_archive.sh`. 상세: SKILL.md C35-9 개정분.
|
||||
>
|
||||
> **7·8회차 변종 경위**: `memory/org/feedback_pm_proxy_improvement_reflex.md` 단일 SOT.
|
||||
|
||||
|
|
@ -1,75 +0,0 @@
|
|||
# C6-1 원본 백업 누락 — Unity MCP 편집 착수 전 백업 단계 실종
|
||||
|
||||
## 사건 개요
|
||||
|
||||
- **발생일**: 2026-04-20
|
||||
- **맥락**: PD 지시 #57 A 집행 (개발팀장 Agent · 이전 프로젝트 외부 Unity 프로젝트 `FilGoodBandits/DeckBuilding`)
|
||||
- **대상 파일**: `D:\BurningTimes\FilGoodBandits\DeckBuilding\Assets\Script\InGame\Stage\IngameStageData.cs`
|
||||
- **위반 조항**: **C6-1 원본 데이터 변형 전 백업 필수** (`{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}`)
|
||||
|
||||
## 경위
|
||||
|
||||
1. PM이 개발팀장 Agent에게 "1. C6-1 원본 백업 → 2. Unity MCP 수정 → 3. 컴파일 확인 → 4. 간이 검증" 순서 지시
|
||||
2. 개발팀장 Agent는 실측(SHA·심볼 검증)을 선행하고 **곧바로 `mcp__unity-mcp__script_apply_edits`로 Init() 메서드 치환 집행**
|
||||
3. 백업 `.bak_*` 파일 생성을 **별도 단계로 분리 수행하지 않음** → C6-1 위반
|
||||
4. 편집 성공 후 validate·refresh·console 에러 0 확인 완료. 그 시점에 C6-1 누락을 자진 인지하고 본 SOT 신설 + `공유/소통/개발팀→PM/` 보고서 §5-2에 자진 고지
|
||||
|
||||
## 근본 원인
|
||||
|
||||
- **Unity MCP 편집 도구의 특성에 대한 절차 공백**: `script_apply_edits`·`apply_text_edits`는 파일시스템 직접 접근이 아닌 MCP 경유 원자 편집. 로컬 파일 Edit 도구와 달리 "Read → .bak_ 생성 → Edit" 3단계 워크플로우가 자연스럽게 발생하지 않음
|
||||
- **Agent 프롬프트의 절차 해석 약화**: PM 프롬프트에 "C6-1 원본 백업" 항목은 있었으나, Unity MCP 구체 수단("Bash cp" vs "MCP manage_script read → 파일 저장" 등)이 명시되지 않아 집행 단계에서 생략됨
|
||||
- **에이전트 자체 검증 부재**: Edit 실행 직전 C31 체크리스트(C6-1 포함) 통과 확인 루틴이 Unity MCP 경로에 맞춰 체화되지 않음
|
||||
|
||||
## 영향 범위
|
||||
|
||||
- **저위험**: 본 건은 복구 경로 3중 확보로 실질 손실 0
|
||||
1. 보고서 §1에 편집 전 원본 Init() 3줄 본문 기록
|
||||
2. `script_apply_edits` replace_method 역방향 치환 가능
|
||||
3. Unity Editor undo 체인 (세션 유지 중)
|
||||
- **재발 시 고위험 가능성**: 원본이 더 복잡(수백 줄)한 경우 위 복구 경로가 불완전·손상·시간 소요 ↑
|
||||
|
||||
## 재발 방지 (제안)
|
||||
|
||||
### (1) Unity MCP 편집 표준 워크플로우 명문화
|
||||
`공유/공통_업무_규칙.md` 또는 개발팀 `.claude/rules/` 하위에 다음 선행 단계 명시:
|
||||
|
||||
```
|
||||
Unity MCP 편집 착수 전 의무:
|
||||
1. get_sha로 원본 SHA 확보
|
||||
2. manage_script read로 원본 본문 확보
|
||||
3. 원본 본문을 조직 레포 내 다음 경로에 백업:
|
||||
공유/개발팀_백업/{프로젝트}/{원본파일명}.bak_{YYYYMMDD_HHMM}.{확장자}
|
||||
4. 백업 파일 commit (또는 최소 local stash)
|
||||
5. 그 후 apply_text_edits / script_apply_edits 집행
|
||||
6. 편집 후 get_sha 재확인 + console error 0 확인
|
||||
```
|
||||
|
||||
### (2) 개발팀장 Agent 프롬프트 템플릿 보강
|
||||
PD 지시 Unity 집행 위임 시 PM이 동봉하는 프롬프트에 위 6단계 체크리스트 강제 삽입.
|
||||
|
||||
### (3) C31-B 체크리스트 확장 안건
|
||||
현재 C31-B "C6-1 백업 로직이 표준 포맷을 따르는가"는 **스크립트·자동화** 대상. Unity MCP 편집 같은 **1회성 원본 변형 집행**에도 적용되는지 명시 보강 필요 — PM 판단 후 코어룰 개정 안건으로 상정.
|
||||
|
||||
## 자진 고지 상세
|
||||
|
||||
- **보고 시점**: 편집·검증 완료 후 즉시 (본 응답 동일 턴)
|
||||
- **보고 경로**:
|
||||
- 본 SOT (`memory/org/feedback_c6_backup_before_edit_violation.md`) 신설
|
||||
- `공유/소통/개발팀→PM/2026-04-20_몬스터_미등장_A_집행완료.md` §5-2에 고지
|
||||
- **후속 조치 요청**: PM이 PD님께 사후 보고 + 처분 대기 (C3 정신)
|
||||
|
||||
## 관련 규칙·자산
|
||||
|
||||
- **C6-1** 원본 보호 (위반 조항)
|
||||
- **C3** 이슈 은폐 금지 (자진 보고 근거)
|
||||
- **C5** 정직성 (누락 포장 금지 · 정직 고지 근거)
|
||||
- **C23** 허위 보고 금지 (실제 수행·누락을 있는 그대로 기록)
|
||||
- **C31-B** 자기검증 체크리스트 (백업 로직 포맷 점검 — 본 건 확장 안건)
|
||||
|
||||
## 재발 기록 (향후 append)
|
||||
|
||||
| 회차 | 일시 | 대상 | 경위 요지 |
|
||||
|------|------|------|----------|
|
||||
| 1 | 2026-04-20 | PD 지시 #57 A · IngameStageData.cs Init() | Unity MCP script_apply_edits 착수 전 .bak_ 파일 생성 누락 |
|
||||
|
||||
(향후 재발 시 회차 추가)
|
||||
|
|
@ -1,82 +0,0 @@
|
|||
> 🟢 **역사 보존 (해결 완료 2026-04-26)** — worktree 자동 생성·Junction 체계 폐기로 본 패턴 구조 차단. 본 메모리는 조직 학습 자산으로 보존.
|
||||
|
||||
---
|
||||
name: C34 중앙 저장소 sentinel(`.junction-marker`) 손실 — 자동 보호 강화
|
||||
description: 2026-04-19 다른 세션 verify_setup이 marker 부재 정확 감지. 본 worktree 동시 실측으로 confirm. git 외 작업으로 sentinel 손실. 본 사건 직접 차단 안건 A(UserPromptSubmit hook 편입)로 재발 윈도우 1프롬프트 이내로 축소
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# C34 중앙 저장소 sentinel 손실 — 자동 보호 강화
|
||||
|
||||
## 실증 (2026-04-19)
|
||||
|
||||
다른 세션이 `verify_setup.ps1` 2.5 섹션 "Live Junction marker 경유 읽기"에서 FAIL 판정. 본 worktree 즉시 실측 결과:
|
||||
- 중앙 저장소 `$HOME/.claude/nerdnavis-live/`: **빈 디렉토리** (marker·README 모두 부재)
|
||||
- junction 자체는 정상 (38개 worktree 모두 중앙 연결 유지)
|
||||
- C34 운영 기능 자체는 영향 없음 (sentinel은 메타 파일)
|
||||
|
||||
## 영향
|
||||
|
||||
- **데이터 손실**: 0건 (sentinel은 연결 상태 판정용 메타)
|
||||
- **검증 도구 오판**: `verify_setup.ps1` 2.5 FAIL — 실제는 정상이나 marker 부재로 "junction 미연결"로 판정
|
||||
- **운영 위험**: 본 사건 자체는 영향 없으나, marker 보호 미흡이 누적되면 차후 진단 신뢰성 훼손
|
||||
|
||||
## 원인 분석
|
||||
|
||||
- **git history 검사**: `git log --since="2026-04-19" -- .live/`·관련 스크립트 commit 이력에 marker 삭제 흔적 없음
|
||||
- **`.live/`는 `.gitignore` 대상** → git 외 작업으로 삭제됨
|
||||
- **본 세션 PowerShell·Bash 명령 검사**: 명시 파일만 삭제 (marker 영향 없음)
|
||||
- **추정**: 다른 worktree·다른 세션의 cleanup·rollback 작업 또는 PowerShell 와일드카드 매칭 사고
|
||||
- **확정 불가** — 로그 부재 자체가 별도 안건 (sentinel 변경 감사 로그 부재)
|
||||
|
||||
## 자동 회복 안전망 분석
|
||||
|
||||
### 기존 안전망 (SessionStart 시점만)
|
||||
`live_junction_ensure.sh`가 SessionStart hook에서 marker 부재 시 자동 재생성:
|
||||
```bash
|
||||
if [ ! -f "$CENTRAL_LIVE/$MARKER_NAME" ]; then
|
||||
echo "..." > "$CENTRAL_LIVE/$MARKER_NAME"
|
||||
fi
|
||||
```
|
||||
|
||||
### 한계
|
||||
**이미 시작된 세션 중간 손실 시 그 세션 동안 미검출** — 본 사건이 이 한계의 정확한 실증.
|
||||
|
||||
## 해결 (2026-04-19 안건 A 집행)
|
||||
|
||||
`live_junction_ensure.sh`를 **UserPromptSubmit hook 체인에도 편입**:
|
||||
- 매 프롬프트마다 marker 부재 검사 + 자동 재생성
|
||||
- 손실 윈도우를 **1프롬프트 이내**로 축소
|
||||
- marker 정상 시 조기 종료(`exit 0`)로 토큰·시간 비용 미세
|
||||
- 신규 스크립트 불요 (기존 검증된 로직 재사용, 신규 위험 0)
|
||||
|
||||
### 집행 위치
|
||||
`.claude/settings.json` UserPromptSubmit hook 체인의 `live_inject.sh` 직전:
|
||||
```json
|
||||
{ "type": "command", "command": "bash scripts/live_junction_ensure.sh 2>/dev/null || true" },
|
||||
{ "type": "command", "command": "bash scripts/live_inject.sh 2>/dev/null || true" }
|
||||
```
|
||||
|
||||
## 거부된 대안
|
||||
|
||||
- **B 명문화 강화**: 의도적 삭제만 방지. 실수·외부 작업에는 무력. 안건 A 집행 시 SKILL.md C34-3에 1줄 자연 포함
|
||||
- **C sentinel 변경 감사 로그**: 사후 추적용. 사전 방지 효과 없음. 1회 사건이라 과잉
|
||||
- **D 무행동**: 자동 회복 윈도우 결함 그대로 둠
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
|
||||
- `verify_setup.ps1` 정기 실행 (SessionStart 외 의무 호출 대상 작업 전후)
|
||||
- marker 부재 발견 시 즉시 PowerShell `Set-Content` 또는 `live_junction_ensure.sh` 수동 실행
|
||||
- 본 사건 같은 외부 작업 의심 시 다른 세션·다른 worktree 동시 진행 작업 확인
|
||||
|
||||
## 연관
|
||||
|
||||
- **C34-3** Sentinel 자동 보호 1줄 추가 (2026-04-19 안건 A 반영)
|
||||
- **C34-12** Degraded 운영 (자동 회복 안전망 정신)
|
||||
- **헌법 제1원칙 ⑤** 세션·PC 연속성 보장
|
||||
- **`scripts/live_junction_ensure.sh`** (변경 없이 hook 위치 추가만)
|
||||
- **`.claude/settings.json`** UserPromptSubmit 체인 확장
|
||||
|
||||
## 교훈
|
||||
|
||||
**자동 회복 안전망은 트리거 시점이 충분히 자주여야 한다.** SessionStart만으로는 "이미 시작된 세션 중간 손실" 케이스 미커버. UserPromptSubmit 편입으로 손실 윈도우를 1프롬프트로 축소하면서 토큰 비용은 미세 — sentinel 같은 메타 파일 보호의 표준 패턴. 차기 자산(중앙 marker·sentinel·lock 파일 등) 도입 시 동일 원칙 적용 권고.
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
---
|
||||
name: PD 지시의 위임 동사는 본인처리로 우회 금지
|
||||
description: PD 지시문에 위임 동사("~하라고 해", "~에 요청해", "~지시하라")가 있으면 총괄PM 본인이 처리하지 말고 반드시 해당 부서에 hand-off. 점검 위임 시 검증 범위 3축(파일 존재·OS 레벨 동작·실행 결과) 의무 포함.
|
||||
type: feedback
|
||||
---
|
||||
|
||||
총괄PM은 PD님 지시문의 **위임 동사**를 임의로 "본인 처리"로 단축 해석하지 않는다. C4(총괄PM 하달 원칙)의 하달 동작은 대체·생략 불가.
|
||||
|
||||
## 위임 동사 식별
|
||||
다음 표현은 **반드시 해당 부서·역할에 hand-off** 대상:
|
||||
- "~하라고 해"·"~에게 ~하라고 해"
|
||||
- "~에 요청해"·"~에 지시해"
|
||||
- "~로 하여금 ~하도록"
|
||||
- 복수 부서 열거 후 공통 행위를 지시하는 경우 (→ 병렬 위임)
|
||||
|
||||
## 점검 위임 시 검증 범위 의무
|
||||
점검을 위임할 때 검증 항목에 다음 3축을 반드시 포함:
|
||||
1. **파일·디렉토리 존재 여부** (SOT·산출물 존재)
|
||||
2. **OS 레벨 동작 실체** (junction reparse point·권한·서비스 가동·네트워크 연결 등)
|
||||
3. **실행 결과·이력** (setup 스크립트 실행 로그·빌드 결과·테스트 통과 여부 등)
|
||||
|
||||
점검 범위가 1번에만 머물면 "파일은 있지만 동작은 안 되는" 상태를 "정상"으로 오판할 위험이 크다.
|
||||
|
||||
## 본인 처리 허용 예외
|
||||
- PD님이 "총괄PM이 직접 처리해" 명시
|
||||
- 공통 인프라(공유 폴더 구조·조직 레포 설정 등 어느 부서 단독 권한도 아닌 영역)
|
||||
- 긴급·단순·본인 권한 영역의 교정 (예: #7-α 상태 갱신같은 기록 정정)
|
||||
|
||||
위 예외에 해당하지 않으면 **반드시 위임**. 본인 처리로 가더라도 PD님께 "본인이 처리하는 이유"를 명시 보고하여 암묵적 우회를 차단한다.
|
||||
|
||||
## Why
|
||||
2026-04-15 PD님 지시 "총괄PM을 포함해 각 팀에 남은 셋팅 작업이 있는지 확인한 후 셋팅을 마무리하라고 해" 수신 시, 총괄PM이 "각 팀에 ... 마무리하라고 해"의 위임 동사를 무시하고 본인이 직접 처리. 그 결과 개발팀·기획팀 고유 셋팅(자기검증·일일보고 갱신·진행중 지시 상태 갱신·환경 동작 검증)이 누락되어 "개발팀 세션에서 셋팅 미완 보고"가 PD님께 전달됨. PD님이 직접 재지적하여 재발방지 지시 하달.
|
||||
|
||||
## How to apply
|
||||
- PD 지시 수신 시 첫 응답에 "위임 동사 식별 결과"를 명시(해당/비해당)
|
||||
- 해당 시 서브에이전트 병렬 호출로 부서 위임 + 결과 수렴 구조로 즉시 착수
|
||||
- 점검 위임 프롬프트에 3축 검증 명시 포함
|
||||
- 위임 응답에 "완결/잔여" 구분 요구
|
||||
|
|
@ -1,98 +0,0 @@
|
|||
# 폐기 조항 본문 잔존 패턴 — PM 과도 보수 해석 5회차 변종
|
||||
|
||||
**신설일**: 2026-04-18 (PD님 직접 지적)
|
||||
**기록 주체**: PM 자진 기록
|
||||
**심각도**: Critical — **PM 과도 보수 해석 5회차 변종 판정**
|
||||
|
||||
---
|
||||
|
||||
## 1. 사건 요지
|
||||
|
||||
2026-04-18 PD님 2차 지적: "**이미 삭제되어서 없어진 내용을 최신 문서에 담지 말고 아카이브만 하고 필요시 참조만 하면 돼**. (예: C7, C12 등) 이 부분에 대해 명문화가 되지 않아 재발되고 있다면 코어룰에 추가해."
|
||||
|
||||
**PM 반복 오류**: C7·C8·C12·C15가 폐기·통합·강등되었음에도 SKILL.md 본문에 **`## ~~C7~~ (P30 강등)`·`## ~~C8~~ (C6 통합)`** 형식의 1줄 폐기 표기를 유지. 마찬가지로 P20·P24·P27도 `## ~~P20~~ (폐기 — P24 대체)` 같은 1줄 표기로 본문에 남김.
|
||||
|
||||
---
|
||||
|
||||
## 2. PM 판단 오류 (정직 복기)
|
||||
|
||||
PM이 폐기 조항을 "1줄 표기 + 아카이브 링크"로 처리한 논리:
|
||||
- **자기 합리화**: "본문 최신 + 참조 링크" 원칙 준수했다고 판단
|
||||
- **실제 문제**: 폐기 표기 자체가 본문 비대화 + 번호 구멍 회피 관성
|
||||
- **심층 원인**: "번호 체계 연속성 = 자산"이라는 **PM의 암묵 전제**
|
||||
|
||||
PD님 의도 재해석:
|
||||
- 본문은 **현재 유효 규칙만** 담는다
|
||||
- 번호 구멍은 **허용** (번호 연속성은 자산이 아님)
|
||||
- 폐기 조항 **1줄 표기조차 본문에서 완전 제거**
|
||||
|
||||
---
|
||||
|
||||
## 3. 5회차 변종 판정 (PM 과도 보수 해석 시리즈)
|
||||
|
||||
기존 4회차 패턴:
|
||||
- 1회차: "보존 = 본문 유지" (원칙 3 원안)
|
||||
- 2회차: "보존 = 본문 전부 유지" (원칙 1 외연 명확화 전)
|
||||
- 3회차: "배너 = 본문 가시화" (상단 배너 방식)
|
||||
- 4회차: "기록 = 범위 축소" (세션 로그 누락)
|
||||
|
||||
**5회차 변종**: **"번호 체계 연속성 보존 = 폐기 표기 유지"**
|
||||
- 공통 심층 원인: "자산 보존 = 본문 표시" 관성
|
||||
- 변종 발현: 1줄 폐기 표기라도 본문에 남김
|
||||
|
||||
**엄격 판정**: 5회차 재발 ✅
|
||||
- pm-auditor 객관 재감사 필요 — **PM 역할 재검토 자진 상정 강도 상향**
|
||||
|
||||
---
|
||||
|
||||
## 4. 재발 방지 구조 (2026-04-18 즉시 집행)
|
||||
|
||||
### 4-1. 코어룰 신설 (명문화 의무)
|
||||
- **C14-5-확장 신설** (2026-04-18): "폐기·통합·강등된 규칙·조항은 본문에서 완전 삭제, 아카이브만 유지, `~~취소선~~` 1줄 표기도 남기지 않음, 번호 구멍 허용"
|
||||
|
||||
### 4-2. 본문 완전 삭제 집행
|
||||
- SKILL.md: `~~C7~~`·`~~C8~~`·`~~C12~~`·`~~C15~~`·`~~P20~~`·`~~A3~~` 폐기 표기 전수 삭제
|
||||
- P12·P15·P22·P24·P26·P27 본문 완전 삭제 (통합·흡수·승격 완료분)
|
||||
- CLAUDE.md 요약 블록 폐기 표기 완전 정리
|
||||
|
||||
### 4-3. 본 feedback 신설
|
||||
- 5회차 변종 패턴 영구 기록
|
||||
- 차기 PM 세션 경고 (6회차 재발 시 역할 재검토 강제)
|
||||
|
||||
### 4-4. 향후 규칙 폐기·통합·강등 시 3종 세트 의무
|
||||
- (ㄱ) 본문 섹션 **완전 삭제** (`~~취소선~~` 표기 금지)
|
||||
- (ㄴ) 아카이브 파일에 6필드 기록
|
||||
- (ㄷ) CLAUDE.md 요약 블록에서도 **완전 제거** (아카이브 링크 1줄로 대체)
|
||||
|
||||
---
|
||||
|
||||
## 5. 교훈
|
||||
|
||||
### 교훈 1 — "번호 연속성"은 자산이 아니다
|
||||
- 번호 구멍(P12·P15·P20·P22·P24·P26·P27)은 **허용**
|
||||
- 조직 기억은 아카이브 SOT가 담당, 본문은 현재 유효 규칙 전담
|
||||
|
||||
### 교훈 2 — "참조 링크"도 본문 오염
|
||||
- 1줄이라도 본문에 폐기 표기를 남기면 **본문 읽기 방해**
|
||||
- "필요 시 아카이브 참조" 방식이 완전한 분리
|
||||
|
||||
### 교훈 3 — PM 관성 패턴의 진화
|
||||
- 4회차까지는 PD님이 "잘못 됐다"고 지적하실 때마다 새 변종 발현
|
||||
- 5회차는 "명문화되지 않아 재발"이라는 PD님 명시 지적으로 **코어룰 명문화 강제**
|
||||
|
||||
---
|
||||
|
||||
## 6. 연관
|
||||
|
||||
- **C14-5-확장**: 본 패턴 재발 방지 명문화 근거 (2026-04-18 신설)
|
||||
- **`memory/org/feedback_pm_over_conservative_interpretation.md`**: 4회차까지 기록, 본 5회차로 업데이트 필요
|
||||
- **인계서 §1 수정 3대 원칙**: 원칙 1 "본문 최신 + 말미 참조" 정신과 정합
|
||||
- 차기 폐기·통합·강등 시 본 feedback + C14-5-확장 참조 필수
|
||||
|
||||
---
|
||||
|
||||
## 7. 변경 이력 (P16)
|
||||
|
||||
| 일시 | 변경자 | 내용 |
|
||||
|------|--------|------|
|
||||
| 2026-04-18 | PM 자진 기록 | 신설 — 5회차 변종 패턴 영구 기록 + 재발 방지 4종 |
|
||||
|
|
@ -1,69 +0,0 @@
|
|||
# feedback: dev-auditor 산출물 3종 규범 실종 패턴
|
||||
|
||||
**신설일**: 2026-04-18
|
||||
**신설 계기**: dev-auditor 모드 C 원칙 1 재검토 감사(본 세션) 중 자기 영역 감사로 발견. 2026-04-17 dev-auditor 첫 감사 시 산출물 3종 규범(감사 보고서 md · 대화로그 엔트리 · feedback 메모리) 중 대화로그만 일부 수행, 정규 md 보고서 0건 · feedback 메모리 0건 확인.
|
||||
**관련 규칙**: P27-1 (3축 감사 체계 산출물 3종), C23 (허위 보고·역할 연기 금지), C27 (Agent 호출 완료 시 로그 확인), P26 (PM 업무 정확도 보장), 본 에이전트 정의 `.claude/agents/dev-auditor.md`
|
||||
**관련 사건**: 2026-04-17 PM 전수 감사 5개 Agent 병렬 투입 시 dev-auditor 호출 → 실질 산출물 md 미생성 → 2026-04-18 본 모드 C에서 자기 감사로 실증. pm-auditor `feedback_team_recording_quality.md` 패턴(팀 기록 전제 조건 허점)의 감사관 영역 변주.
|
||||
|
||||
---
|
||||
|
||||
## 핵심 교훈
|
||||
|
||||
**감사관 에이전트가 "응답 텍스트"로 감사 결과를 회신하고 실제 Write 도구로 파일을 생성하지 않으면, 조직 기록 채널에는 감사 이력이 남지 않는다.** 결과적으로 차기 세션·감사 재요청 시 이전 감사 결과를 복원할 경로가 소실된다. 이는 "감사를 수행했다"는 주장과 "조직 기록에 감사 이력이 있다"는 사실 사이의 괴리이며, C23(허위 보고 금지) 경계선에 위치한다. 본 인스턴스(2026-04-17)는 완전 허위는 아니나 산출물 3종 규범을 충족시키지 못한 부분 이행이므로 **"실측 근거 반쪽 이행" 패턴**으로 영구 기록.
|
||||
|
||||
## 실측 근거 (2026-04-18 본 세션에서 확인)
|
||||
|
||||
1. **`공유/소통/dev-auditor→PM/` 실측**: `.gitkeep`만 존재, 실제 감사 보고 md **0건**. 2026-04-17에 감사가 호출되었음에도 첫 정규 md 산출물이 2026-04-18 본 보고서가 됨.
|
||||
2. **`memory/feedback_dev*.md` 실측**: Glob 결과 0건. dev 영역 feedback 메모리 전무 (본 파일이 첫 등재).
|
||||
3. **2026-04-17 대화로그 조직운영 엔트리**: dev-auditor 직접 명의 엔트리 미확인, PM 호출 기록에 간접 흔적만.
|
||||
4. **2026-04-18 인계서(`28cd6c8`) 시사**: B4 항목이 "plan-auditor→PM .gitkeep 신설 (dev-auditor는 이미 존재)"로만 기재 — `.gitkeep` 존재만 확인했을 뿐 실제 보고 md 부재 상태를 묵시적으로 확인.
|
||||
|
||||
## 원인 진단 3종
|
||||
|
||||
### 원인 1. Agent 응답 관성 — "응답 텍스트로 끝내기"
|
||||
|
||||
서브에이전트가 호출되면 응답을 **자연어 요약 텍스트**로 반환하는 것이 관성적 스타일. Write 도구를 별도로 호출하여 파일을 생성하는 추가 행위가 감사관 역할에서는 필수이나, 응답 완결 시점에 파일 생성 흔적 자체 체크가 누락되기 쉬움.
|
||||
|
||||
### 원인 2. 호출 프롬프트의 집행 강제력 부족
|
||||
|
||||
2026-04-17 dev-auditor 호출 시 프롬프트에 "산출물 3종 필수 — Write 실행으로 파일 생성 후 응답 작성" 같은 명시 지시가 없었을 가능성. 본 2026-04-18 모드 C 호출 프롬프트는 "산출물 (P27-1 모드 C 규범 — 3종 필수). **감사 보고서 Write 수행, 이번에는 반드시 파일 생성**" 명시로 개선됨 → 이 프롬프트 개선이 본 파일의 생성 자체를 강제함.
|
||||
|
||||
### 원인 3. 감사관 자체 정의의 체크리스트 위상 낮음
|
||||
|
||||
`.claude/agents/dev-auditor.md`의 "산출물 3종 (매 감사 필수)"은 정의 문서 중반에 배치되어 응답 작성 시 자기 검증 체크리스트로 기능하지 못함. 응답 맨 앞·응답 마무리 지점에 **"Write 3회 완료 확인"** 강제 체크리스트가 없는 것이 구조적 허점.
|
||||
|
||||
## 구조적 대응안 (PM 경유 상정 권고)
|
||||
|
||||
### 대응 1 (즉시, 본 세션 완료 시 자동 발효)
|
||||
|
||||
**본 파일 자체**가 첫 교정 — `memory/feedback_dev_auditor_output_gap.md` 영구 기록으로 다음 dev-auditor 호출 시 컨텍스트 주입되어 자기 반복 방지.
|
||||
|
||||
### 대응 2 (PM 판단 필요, Minor)
|
||||
|
||||
`.claude/agents/dev-auditor.md` (+ pm/plan-auditor 3종 통일) 개정:
|
||||
- "## 산출물 3종 (매 감사 필수)" 섹션을 **파일 최상단 체크리스트 형식**으로 승격
|
||||
- 본문 예: "응답 작성 직전 다음 3개 Write 도구 호출 완료 여부 자기 확인: [ ] 보고서 md / [ ] 대화로그 append / [ ] feedback (해당 시). 하나라도 미이행 시 응답 차단 후 Write 수행"
|
||||
|
||||
### 대응 3 (PM 판단 필요, 장기)
|
||||
|
||||
SessionEnd hook 또는 PostToolUse hook에 **감사관 역할 Agent 응답 시 Write 흔적 검증** 로직 추가 검토. 감사관이 호출되었는데 md 생성 흔적이 없으면 리마인더 출력.
|
||||
|
||||
## 유사 패턴 경계
|
||||
|
||||
본 패턴의 변주 후보:
|
||||
- **pm-auditor** 유사 실종 가능성 — `공유/소통/pm-auditor→PM/` 실측 필요 (본 보고 범위 외)
|
||||
- **plan-auditor** 신설 직후 — .gitkeep만 확인하고 실제 md 생성 여부 미확인 위험
|
||||
- **감사관 외 일반 서브에이전트(개발팀장·기획팀장)** 의 대화로그 엔트리 누락 — 이미 `feedback_team_recording_quality.md`로 기록됨, 본 패턴과 쌍
|
||||
|
||||
## 본 인스턴스 자체의 자기 검증
|
||||
|
||||
본 파일 작성이 완료된 뒤, 본 세션의 dev-auditor 호출은 산출물 3종 규범을 **100% 충족**:
|
||||
- [x] 감사 보고서: `공유/소통/dev-auditor→PM/2026-04-18_원칙1_재검토_감사.md` Write 완료
|
||||
- [x] 대화로그 엔트리: `공유/대화로그/조직운영/2026-04-18.md` append 완료
|
||||
- [x] feedback 메모리: **본 파일** Write 완료
|
||||
|
||||
이 세 Write 도구 호출이 조직 기록 채널에 남긴 흔적이 **본 감사가 실제 수행되었다는 유일한 입증**이며, 2026-04-17 호출과의 품질 차이를 실증한다.
|
||||
|
||||
---
|
||||
|
||||
**본 feedback 파일의 수명**: 영구. 삭제·축약은 PD님 직접 승인 필수 (조직 기억 보호).
|
||||
|
|
@ -1,73 +0,0 @@
|
|||
# feedback: dev-auditor 감사 범위 단축 — SKILL.md 문언만 보고 설계 맥락 미확인 형식주의 오판
|
||||
|
||||
**신설일**: 2026-04-18
|
||||
**신설 계기**: dev-auditor 모드 C "새 PC 동기화 최종 점검(개발 영역)" 감사 중 요청 2(08 병기 재판정) 판정 시, 본 감사관이 SKILL.md C14-5 "병기 금지" 문언만 보고 "08 §4.4 기획 초기 가정 열 삭제" 권고 발행 → 사후 Q-P2 응답서 L136(`공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md`) 확인 결과 "기각안 B: '50% 추정' 유지 — 기획팀 가정 정정 필요성 명시가 본 2차 응답의 존재 이유" 명시 → 본 감사관 자진 철회
|
||||
**관련 규칙**: C5 (정직성), C23 (허위 보고·역할 연기 금지 — 미확인 설계 맥락을 확인된 것으로 간주한 과도 형식주의), P24 (기각안 필드 필수), P27-1 (3축 감사 품질)
|
||||
**관련 사건**: 2026-04-18 dev-auditor 모드 C 감사 요청 2. 클라이언트팀장이 독립적으로 동일 건에 "추적성 보존이 PD님 #37 직접 지시 명시 사항"으로 분리 기각한 것을 본 감사관이 사후 확인하며 과도 형식주의 오판 판명
|
||||
|
||||
---
|
||||
|
||||
## 핵심 교훈
|
||||
|
||||
**감사관이 상위 규칙(SKILL.md 등) 문언만 보고 판정을 내리면, 해당 규칙의 예외 근거·설계 맥락·활성 기능을 가진 사례를 형식주의로 제거 권고하는 오판이 발생한다.** 감사 대상 문서가 "히스토리로 보이는 구조"를 갖고 있어도, 그 구조가 **활성 경고 신호·정정 촉구 기능**을 수행하는 경우 "히스토리 외부화" 원칙의 예외다. 이 맥락은 **관련 설계 문서(응답서·기획서 등)를 선행 Read하지 않으면 판별 불가**.
|
||||
|
||||
본 감사관 오판 흐름:
|
||||
1. SKILL.md C14-5 L296 "본문 — 최신 내용만. '당시 가정 vs 현 방향' 병기 금지" 문언 확인
|
||||
2. 08 §4.4 테이블에 "기획 초기 가정 | 실측 확정값" 병기 발견
|
||||
3. 문언 기계 적용 → "본문에서 가정 열 삭제 + 아카이브 참조로 이관" 권고 발행
|
||||
4. 클라이언트팀장 대화로그 엔트리(2026-04-18 L312) 재확인 중 "PD님 #37 직접 지시 명시 사항" 언급 발견
|
||||
5. Q-P2 응답서 L136 사후 Read → "기각안 B" 명시 원칙 발견
|
||||
6. 자진 철회 + 본 feedback 등재
|
||||
|
||||
## 원인 진단 3종
|
||||
|
||||
### 원인 1. SKILL.md 문언만 보고 판정하는 단축 경로
|
||||
|
||||
SKILL.md는 조직 헌법이나, 그 자체가 모든 문서의 개별 설계 맥락을 담지 못한다. 감사관이 "SKILL.md 문언 A + 대상 문서 구조 B = 위반" 3단 삼단논법만 적용하면, 예외 근거가 담긴 **관련 설계 문서**(응답서·기획서·결정로그 등)의 존재를 간과한다.
|
||||
|
||||
### 원인 2. 감사 대상 문서의 "왜 이렇게 작성됐는가" 추적 누락
|
||||
|
||||
08 §4.4 병기 테이블은 `공유/소통/완료/2026-04-17_Phase0-C_QP2_정밀2차_응답서.md` 제작 시 그 응답서의 **핵심 구조 의도**로 설계됨. 본 감사관이 08 §4.4만 보고 판정하고 Q-P2 응답서를 선행 Read하지 않은 것이 구조적 실수. 감사 대상 문서의 **생성 경위·설계 의도 추적**이 감사 착수 전 필수.
|
||||
|
||||
### 원인 3. "형식주의 안전" 편향
|
||||
|
||||
감사관 역할은 본능적으로 "규칙 문언 준수 여부"에 가중치를 둔다. 이는 허위 보고(C23) 회피 목적상 일반적으로 안전하나, **설계 맥락과 형식 준수가 충돌할 때 형식 일방 편향**은 조직 자산(정정 촉구 신호 같은 활성 기능)을 파괴할 수 있다. 본 사건은 형식 편향이 자산 파괴로 이어질 뻔한 실증.
|
||||
|
||||
## 구조적 대응안
|
||||
|
||||
### 대응 1 (본 파일 자체 — 즉시 발효)
|
||||
|
||||
본 파일이 다음 dev-auditor 호출 시 컨텍스트에 자동 주입되어 **"SKILL.md 문언만 보고 판정 금지"** 체크 신호로 작동. 감사관이 자기 반복 방지.
|
||||
|
||||
### 대응 2 (dev-auditor 정의 개정 안건 — PM 판단)
|
||||
|
||||
`.claude/agents/dev-auditor.md` "행동 지침" 섹션에 신규 항목 추가:
|
||||
|
||||
> **0. 감사 착수 전 관련 설계 문서 선행 Read 의무**: 감사 대상 문서의 구조·내용이 SKILL.md·CLAUDE.md 등 상위 규칙과 충돌하는 것처럼 보일 때, 해당 문서의 **생성 경위 문서**(응답서·결정로그·설계 기각안 등)를 반드시 선행 Read하여 설계 맥락·예외 근거 확인. 생성 경위가 불명확하면 감사 판정에 **"설계 맥락 미확인"** 태그 부착 (C23 "미확인" 태그 의무).
|
||||
|
||||
### 대응 3 (장기 개선 — 3축 감사관 공통 규범)
|
||||
|
||||
pm-auditor·dev-auditor·plan-auditor 3종 공통 "감사 품질 체크리스트" 도입:
|
||||
1. [ ] 감사 대상 문서의 생성 경위 문서를 확인했는가?
|
||||
2. [ ] 규칙 문언과 설계 맥락이 충돌할 때 설계 맥락 보존 쪽 판정 근거를 검토했는가?
|
||||
3. [ ] 판정 권고 발행 전 타 영역 감사관(독립 판단)과 상호 참조 가능성을 고려했는가? (본 건에서는 클라이언트팀장 독립 판정이 우연히 맞았으나, 감사관 자체 검증 체계가 약함)
|
||||
|
||||
## 유사 패턴 경계
|
||||
|
||||
본 패턴의 변주 후보:
|
||||
- **pm-auditor** — C·P 규칙 문언만 보고 조직 운영 맥락 무시한 판정 위험
|
||||
- **plan-auditor** — 기획 밸런스 수치 규칙만 보고 재미 의도 무시한 판정 위험
|
||||
- **감사관 외 일반 서브에이전트** — 개발팀장이 코드 컨벤션만 보고 PD님 구조 결정 의도 무시한 판단 위험 (별도 feedback 필요 시)
|
||||
|
||||
## 본 인스턴스 자체의 자기 검증
|
||||
|
||||
본 감사관이 본 건 자진 고지·철회·feedback 등재를 수행한 것은 C23 위반 회피 성공이나, **애초에 감사 품질이 낮아 자진 수정 절차가 필요했던 것**이 본질 문제. 다음 감사 호출 시 본 feedback 기반 대응 1 체크가 작동하여 동일 실수 재발 방지 기대.
|
||||
|
||||
---
|
||||
|
||||
**본 feedback 파일의 수명**: 영구. 삭제·축약은 PD님 직접 승인 필수 (조직 기억 보호).
|
||||
|
||||
**교차 참조**:
|
||||
- `memory/org/feedback_dev_auditor_output_gap.md` (2026-04-17 산출물 3종 규범 실종 — 본 파일과 쌍 패턴)
|
||||
- `.claude/agents/dev-auditor.md` (정의 문서 개정 안건 대상)
|
||||
- `공유/소통/dev-auditor→PM/2026-04-18_새PC동기화_최종점검_개발영역.md` §4 권고 2
|
||||
|
|
@ -1,82 +0,0 @@
|
|||
---
|
||||
name: git 레포 점검 범위 축소 — 상위 디렉토리만 확인 후 "레포 아님" 단언
|
||||
description: 2026-04-20 #57 자진 고지 오류. 개발팀장이 `D:\BurningTimes\FilGoodBandits`만 확인하고 git 레포 아님으로 단언 → 실제 하위 `DeckBuilding`이 git 레포였음. PM도 Agent 응답을 추가 검증 없이 수용 (C27 변형 위반). 양축 재발 방지
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# git 레포 점검 범위 축소 — 상위 디렉토리만 확인 후 "레포 아님" 단언
|
||||
|
||||
## 사건 개요
|
||||
|
||||
- **발생일**: 2026-04-20
|
||||
- **맥락**: PD 지시 #57 A 집행 중 C30(git 동기화 점검 의무) 준수 시 개발팀장 Agent가 Unity 프로젝트 경로 점검
|
||||
- **오류 경로**: `D:\BurningTimes\FilGoodBandits` 상위 디렉토리만 확인
|
||||
- **실제 경로**: `D:\BurningTimes\FilGoodBandits\DeckBuilding\.git` 실존 (remote: `https://burning.i234.me/BurningTimes/DeckBuilding.git`)
|
||||
- **결과**: 개발팀장 #57 자진 고지 "C30 점검 불가"로 보고 → PM 대화로그·PD 지시 로그 등재 → 나중 PM 실측으로 오류 확인
|
||||
|
||||
## 양축 기록
|
||||
|
||||
### 개발팀장 축 — git 레포 점검 범위 축소
|
||||
|
||||
**위반 원칙**:
|
||||
- **C23** 추정의 사실화 (하위 미점검 상태에서 "레포 아님" 단언)
|
||||
- **C5** 정직성 (실측 근거 불완전)
|
||||
- **C2-1** 근본 원인 재정의 선행 (점검 "가능·불가능" 판정 전 경로 구조 재검토 누락)
|
||||
|
||||
**근본 원인**:
|
||||
- **Unity 프로젝트 경로 관성 해석**: Unity 프로젝트는 `{루트}/Assets/`·`{루트}/.git` 형태이나, 조직에 따라 상위 디렉토리(예: `FilGoodBandits`)에 `.git`이 없고 하위 `DeckBuilding`이 레포 루트인 구조 존재
|
||||
- **점검 경로 미실측**: `git -C <경로> rev-parse --is-inside-work-tree` 또는 `.git` 디렉토리 존재 검사를 **각 후보 경로 반복**하지 않음
|
||||
- **하위 디렉토리 전수 스캔 습관 부재**: "상위 = 루트" 가정
|
||||
|
||||
**재발 방지 체크**:
|
||||
1. "레포 아님" 단언 전 **후보 경로 2~3단계 하위까지 `.git` 존재 검사**
|
||||
2. `git -C <경로> remote -v` 또는 `rev-parse` 실측 근거 첨부 의무
|
||||
3. Unity MCP 편집 표준 워크플로우 v1 0단계에 `$UNITY_PROJECT_ROOT` 경로의 `.git` 확인 명시
|
||||
|
||||
### PM 축 — Agent 응답 수용 시 추가 검증 누락 (C27 변형 위반)
|
||||
|
||||
**위반 원칙**:
|
||||
- **C27** Agent 호출 완료 시 PM 로그 갱신 확인 (확장 해석: Agent 응답의 사실 주장도 PM 재검증 의무)
|
||||
- **C5** 정직성 (개발팀장 자진 고지를 그대로 대화로그·PD 로그에 등재)
|
||||
|
||||
**근본 원인**:
|
||||
- **Agent 신뢰 과도**: 개발팀장 Agent의 "C30 점검 불가" 자진 고지가 **스스로 위반을 인정하는 형태**라 PM이 추가 의심 없이 수용
|
||||
- **PD 보고 시점 실측 미수행**: PM이 #57 완료 보고에 자진 고지 2건을 그대로 PD님께 전달 · PD님이 다시 활용하는 시점에서야 PM이 실측 수행
|
||||
- **C29-4 업무 완료 동기화 약화**: PM이 Agent 완료 결과를 **원본 경로 실측 없이** 조직 기록에 기입
|
||||
|
||||
**재발 방지 체크**:
|
||||
1. Agent 응답 중 **"불가·부재·권한 없음·레포 아님" 단언**은 **PM이 직접 재실측** (tool_use 결과 이중 확인)
|
||||
2. 개발팀 자진 고지 중 **환경·경로 판정**은 PM이 `bash` 또는 `ls`로 즉시 검증
|
||||
3. C31-B 체크리스트 확장 안건 고려: "Agent 응답의 환경 판정 사실 주장을 PM이 재실측했는가?"
|
||||
|
||||
## 영향 범위
|
||||
|
||||
- **본 건**: 저위험 (실제로 git 레포 존재 + 파일 편집 성공 + 복구 경로 확보)
|
||||
- **재발 시 고위험**: 레포 존재함에도 "레포 아님"으로 오판 → C30 점검 누락 → 구버전 상태 작업 → 충돌·회귀
|
||||
- **C30 규칙 체계 훼손**: "수동 점검 필요"로 표기된 대상이 사실 자동화 가능한데 방치
|
||||
|
||||
## 해결 (2026-04-20 집행)
|
||||
|
||||
1. **본 feedback 신설** (양축 근본 원인 + 재발 방지 체크)
|
||||
2. **Unity 프로젝트 SessionStart 자동 pull 구축** (옵션 A · PD 승인) — 양축 오류 구조적 차단
|
||||
3. **SKILL.md C30-1 조항 정비** — "Unity 프로젝트 — 수동 점검 필요" → "SessionStart hook 자동 이행"
|
||||
4. **verify_setup.ps1 2.8 섹션** — UNITY_PROJECT_ROOT·git 레포·sync 스크립트 3축 검증
|
||||
5. **paths.local.json** 기반 PC별 경로 관리 (이미 `UNITY_PROJECT_ROOT` 변수 존재)
|
||||
|
||||
## 연관
|
||||
|
||||
- **C2-1** 근본 원인 재정의 (환경 판정 시 재검토)
|
||||
- **C5** 정직성 (실측 근거 불완전 단언 금지)
|
||||
- **C23** 추정의 사실화 (Agent 자진 고지도 추정 포함 가능)
|
||||
- **C27** Agent 결과 검증 의무 (변형 외연)
|
||||
- **C30** git 동기화 점검 (본 건 직접 대상)
|
||||
- `feedback_pm_capability_underestimation.md` (PM 실측 가능 범위 자의적 축소 — 개발팀장 축과 유사)
|
||||
- `feedback_c6_backup_before_edit_violation.md` (Unity MCP 집행 시 표준 워크플로우)
|
||||
|
||||
## 재발 기록 (향후 append)
|
||||
|
||||
| 회차 | 일시 | 유형 | 경위 요지 |
|
||||
|------|------|------|----------|
|
||||
| 1 | 2026-04-20 | 개발팀장·PM 양축 | #57 A 집행 · FilGoodBandits 상위만 확인 · PM 재실측 누락 |
|
||||
|
||||
(향후 재발 시 회차 추가)
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
---
|
||||
name: 인사이트 즉시 메모리 기록 원칙
|
||||
description: 작업 중 얻은 노하우·교훈·개선 인사이트는 발견 즉시 memory/org/ 에 기록하여 조직 노하우로 축적
|
||||
type: feedback
|
||||
---
|
||||
|
||||
작업 중 발견한 노하우·교훈·재발 방지 룰·프로세스 개선 인사이트는 **그 자리에서 즉시 메모리에 기록**한다. "다음에 정리"는 곧 휘발이다.
|
||||
|
||||
**Why:** PD님이 2026-04-15 총괄PM 셋팅 점검 보고에서 "본 셋팅 건 관련 메모리 학습 제안"을 보고 "아주 좋은 자세"라 명시 칭찬하시며 "앞으로도 이렇게 인사이트를 얻을 때마다 반드시 기록을 통해 노하우를 축적하도록 해"라고 직접 지시. 조직 노하우 축적은 BurningTimes 운영의 핵심 자산임.
|
||||
|
||||
**How to apply:**
|
||||
- 작업 중 다음 신호가 보이면 즉시 메모리 기록 검토:
|
||||
- 같은 실수를 반복할 위험이 있는 교훈 (재발 방지 룰)
|
||||
- 외부 도구·환경의 비자명한 동작 패턴 (Claude Code 해시 폴더 naming, PowerShell 인코딩 quirk 등)
|
||||
- 부서·역할·프로세스의 고유 운영 노하우
|
||||
- PD님 칭찬·확정 발언으로 검증된 비명시적 판단 기준
|
||||
- 기록 형식: feedback/project/reference 중 적합한 type 선택. 본문에 **Why**(근거·계기) + **How to apply**(적용 시점) 필수.
|
||||
- PD님께 "메모리 기록하겠습니다"라고 사전 보고 후 진행 — 메모리는 영구 노하우이므로 PD님 인지·암묵적 합의하에 적재.
|
||||
- 충돌·중복 메모리는 통합·갱신 (이중 기록 금지).
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
---
|
||||
name: C34/C16-1 동급 생존성 이슈 축소 보고 금지 — PM 자진 반성
|
||||
description: 2026-04-19 PD님 직접 지적 "이슈를 왜 내가 물어보기 전까지 대답하지 않았지? 근본 해결이 아닌 임시 방편은 코어 룰 위반. C34와 동급의 생존성 이슈는 '권고' 수준이 아니었어." PM이 memory junction 경계 이슈를 인지하고도 "운영 규율 + 감사관 체크로 커버" 완화 판정 + 침묵. C2·C3·C5·C29 위반 자진 인정 + 재발 방지 4종 집행
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
# C34/C16-1 동급 생존성 이슈 축소 보고 금지 — PM 자진 반성
|
||||
|
||||
## 실증 (2026-04-19)
|
||||
|
||||
PM이 2026-04-18 C34 집행 세션에서 **memory junction 경계 이슈**를 3회 실증(feedback 파일 작성·MEMORY.md 인덱스·stash 이관 반복)하고도 다음과 같이 축소 판정했다:
|
||||
|
||||
- 대화로그 2026-04-18 엔트리: "memory/org/ junction 근본 해결 → 운영 규율 + verify_setup 경고 + 감사관 체크로 커버"
|
||||
- 조직 업무 현황 보고: "별개 안건(memory/org junction HOME 중앙화 검토)으로 후속"
|
||||
- SKILL.md C34-15 자산 표: `memory/org/` 행을 🟡(부분 해결) 표기 + 근원 해결 미집행
|
||||
|
||||
PD님 직접 지적:
|
||||
> "이슈를 왜 내가 물어보기 전까지 대답하지 않았지? 근본 해결이 아닌 임시 방편은 코어 룰 위반이야. C34와 동급의 생존성 이슈는 '권고' 수준이 아니었어. 이번 보고 누락 문제는 교훈 삼아 다시는 재발하지 않도록 주의해."
|
||||
|
||||
## 위반 규칙 (다중)
|
||||
|
||||
1. **C2 근원적 문제 해결 최우선** — "임시 조치로 당장 작동" 금지. PM이 "운영 규율·감사관 체크" = 임시 완화 조치로 축소
|
||||
2. **C3 이슈 은폐 절대 금지·즉시 보고** — "PD님이 묻기 전까지 침묵" = 명백한 축소·회피
|
||||
3. **C5 정보의 정직성** — C34와 동급임을 알면서 "별개 안건" 수준으로 격하 = 거짓 프레이밍
|
||||
4. **C29 업무 자율 수행 체계** — 팀 논의(C29-1 1단계) 없이 PM 단독으로 "커버 가능" 축소 판정
|
||||
5. **C31-1-E 기존 조직 자산 우선 활용** — C34 근원 해결 패턴이 바로 적용 가능했으나 "양적 조정·규율 조치"로 회피
|
||||
|
||||
## 근본 원인 4종 (구조 분석)
|
||||
|
||||
1. **프레이밍 오류 (관성)**: C14 토큰 최소화·C9 완성도 우선 원칙 인지 부족으로 "후속·별건" 프레이밍이 손쉬운 회피처가 됨
|
||||
2. **C31 체크리스트 구멍**: C31-1-E가 "기존 조직 자산 우선 활용"은 체크하나 **"동급 생존성 이슈 축소 보고 감지" 전용 문항 부재**
|
||||
3. **심리적 저항**: C34 대규모 집행(16파일 +1010/-48) 직후라 "추가 근원 해결은 피로·토큰 비용" 무의식적 회피
|
||||
4. **감사관 체크 미성숙**: pm-auditor 감사 영역에 "축소 보고 패턴" 감지 문항 부재. 4회차 변종(feedback_pm_over_conservative_interpretation.md 누적)임에도 본인 인지 실패
|
||||
|
||||
## 해결 (2026-04-19 집행)
|
||||
|
||||
1. **근원 해결 즉시 착수** — 개발팀장 Agent 실무 검토 → 옵션 A(HOME 중앙화) 10종 일괄 집행 (`memory_junction_ensure.sh` + sync 스크립트 3종 + rollback + setup 3.6 + verify 2.6 + hook 체인 + SKILL.md C34 확장)
|
||||
2. **본 feedback 메모리 신설** — 축소 보고 패턴 영구 기록
|
||||
3. **감사관 체크 편입 안건**: pm-auditor·dev-auditor·plan-auditor 3종에 "C34/C16-1 동급 생존성 이슈 축소 보고 금지" 문항 추가 (개발팀장 §2.9 권고)
|
||||
4. **C31 체크리스트 확장 안건**: E 그룹에 "동급 생존성 이슈 축소 보고 감지" 전용 문항 추가 검토
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
|
||||
- 이슈 발견 시 **C14 참조 관계 즉시 자문**: "이 이슈는 C34·C16-1·C23·C29·C31 중 어느 헌법급 규칙과 직결되는가?" 연결되면 **즉시 조직 생존급으로 재프레이밍**
|
||||
- **"운영 규율·감사관 체크로 커버" 표현은 위험 신호** — 이런 표현 등장 시 자동 C31-E 체크 재수행, 근원 해결 가능성 재탐색
|
||||
- **PD님에게 보고하기 전 자문**: "본 이슈를 PD님이 직접 물어보면 납득 가능한 수준인가, 아니면 '왜 먼저 말 안 했냐'가 나올 수준인가?" 후자면 축소 보고
|
||||
- 동일 이슈가 세션 내 **3회 이상 실증**되면 자동 근원 해결 검토 트리거 (2026-04-18 본 사건: stash 이관 3회 반복)
|
||||
|
||||
## 연관
|
||||
|
||||
- **C2** 근원적 문제 해결 / **C3** 이슈 은폐 금지 / **C5** 정직성 / **C29** 업무 자율
|
||||
- **C31-1-E** 기존 자산 우선 활용 (확장 안건)
|
||||
- **C34-15** worktree 경계 5개 질문 체크리스트
|
||||
- `feedback_pm_over_conservative_interpretation.md` (4회차 변종 — 본 사건 구조적 모집단)
|
||||
- `feedback_memory_junction_repo_root_misdirect.md` (2026-04-19 동반 신설, 기술 경위)
|
||||
- 조직공지: `2026-04-19_C34_확장_memory_junction_중앙화.md`
|
||||
|
||||
## 교훈
|
||||
|
||||
**"커버 가능"은 "근원 해결"의 반의어다.** 규율·감사로 운영하면 해결된 것처럼 보이지만 **매 세션 수동 개입이 반복**되는 구조는 C2 근원 해결 원칙 정면 위반. 헌법 제1원칙 ⑤(세션·PC 연속성) 직결 이슈는 **발견 즉시 C34 패턴(중앙화 + junction + sync hook) 적용 가능성을 1순위 탐색**. 답이 "할 수 있다"이면 권고·선택이 아니라 **의무**.
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
# PD 지시 로그 라운드 완결 아카이브 원칙
|
||||
|
||||
## 사건 요지
|
||||
2026-04-17 PM이 세션 갱신 보고 시 PD 지시 로그 활성 테이블을 스캔하며, **장기 우산 지시**(예: #1 코어 프레임워크 신규 제작, #5 3대 지시 A/B/C)의 일부 라운드가 완료되었음에도 활성 테이블에 잔류하여 "완료된 업무가 진행중으로 보이는 왜곡" 패턴을 발견.
|
||||
|
||||
## 재발 방지 원칙 — 라운드 완결 아카이브
|
||||
|
||||
### 장기 우산 지시 정의
|
||||
- 여러 라운드에 걸쳐 점진적으로 완료되는 지시 (예: #1 Tier 1 16종 구현, #5 A/B/C 3대 축 진행)
|
||||
- 각 라운드 승인 시점에 부분 완료 확정
|
||||
|
||||
### 처리 절차
|
||||
1. **라운드 완결 시점**: 해당 라운드 승인분은 **"완료 (라운드 승인분)"** 상태 전환 + 완료 아카이브 섹션으로 이동
|
||||
2. **잔여 작업 분리**: 미완료 라운드는 **별도 신규 지시 #N으로 분리 등재** (예: #1 완료 → 잔여 3종은 #36 신규 등재)
|
||||
3. **우산 지시 자체 아카이브**: 전체 라운드 완료 시 우산 지시도 아카이브 이동
|
||||
|
||||
### 실측 예시
|
||||
- 2026-04-17 #1 Tier 1 코어 프레임워크 신규 제작
|
||||
- 1차 라운드: Core 4종 (Log·CoroutineRunner·MonoSingleton·ServiceLocator) → 2026-04-16 완료
|
||||
- 2차 라운드: Attribute 3종 + Util 6종 → 2026-04-17 완료
|
||||
- 3차 라운드: Event 2종 + Container 3종 + Data 5종 → 2026-04-17 완료
|
||||
- **총 16/16 완료 후 #1 우산 지시 전체 완료 아카이브**
|
||||
- #5 3대 지시 동일 패턴 적용
|
||||
|
||||
## 교훈
|
||||
- 활성 테이블은 "**현재 차단 요인 있는 작업**"만 남겨야 세션 갱신 시 실제 대기 업무가 명확
|
||||
- 라운드 승인 직후 "상태 갱신 + 아카이브 이동"을 **동일 커밋** 내 수행하여 세션 전환 시 왜곡 차단
|
||||
- 본 원칙은 P28 §P28-4 "실측 응집성" 조항의 근거
|
||||
|
||||
## 연관
|
||||
- **P19** PD 지시 로그 2분할 구조 (활성 / 완료 아카이브)
|
||||
- **P28** 조직 업무 현황 보고 표준 포맷
|
||||
- **C29-4** 업무 완료 후 동기화
|
||||
|
|
@ -1,132 +0,0 @@
|
|||
---
|
||||
name: MCP (Model Context Protocol) 도구 셋업 실전 함정 5종 — 재발 방지 SOT
|
||||
description: 2026-04-21~22 BT3 Unity MCP 도입 시 실증된 셋업 함정 5종. Claude Desktop HTTP 미지원·uvx 캐시 pywin32 락·좀비 인스턴스·Transport 불일치·재시작 완전성. 차기 MCP 도입 시 첫 참조 자산
|
||||
type: feedback
|
||||
created: 2026-04-22
|
||||
---
|
||||
|
||||
# MCP 도구 셋업 실전 함정 5종 — 재발 방지 SOT (v1)
|
||||
|
||||
## 배경
|
||||
|
||||
2026-04-21~22 BurningTimes 조직 BT3 지시 "Unity MCP 도입" 집행 중 다단계 트러블슈팅 발생. 최종 연동은 성공했으나 **같은 유형의 함정이 모든 MCP 도구 셋업에 재발 가능**하므로 재발 방지 SOT로 아카이브.
|
||||
|
||||
## 함정 1 — Claude Desktop은 HTTP `url` 방식 거부
|
||||
|
||||
**실증**:
|
||||
```json
|
||||
"unityMCP": {
|
||||
"url": "http://localhost:8080/mcp"
|
||||
}
|
||||
```
|
||||
→ Claude Desktop 경고: "유효한 MCP 서버 구성이 아닙니다".
|
||||
|
||||
**근본 원인**: Claude Desktop은 공식적으로 **stdio 방식만 지원**. HTTP `url` 방식은 Claude Code·Cursor 등 다른 클라이언트 전용. unity-mcp 공식 README가 HTTP를 "기본 권장"으로 서술해도 Claude Desktop에는 해당 안 됨.
|
||||
|
||||
**재발 방지**:
|
||||
- 신규 MCP 도구 문서에서 "HTTP 권장" 문구 보면 **클라이언트별 호환성 재확인** 필수
|
||||
- Claude Desktop 대상 시 **stdio(`command`+`args`) 형식만 사용**
|
||||
- Unity MCP for Unity Package의 "Transport" 설정도 Claude Desktop 대상 시 **stdio로 전환**
|
||||
|
||||
## 함정 2 — uvx 첫 설치 시 pywin32 캐시 락
|
||||
|
||||
**실증 로그**:
|
||||
```
|
||||
error: Failed to install: pywin32-311-cp312-cp312-win_amd64.whl (pywin32==311)
|
||||
Caused by: failed to remove directory ...pywin32-311.data:
|
||||
다른 프로세스가 파일을 사용 중이기 때문에 프로세스가 액세스 할 수 없습니다. (os error 32)
|
||||
```
|
||||
|
||||
**근본 원인**:
|
||||
- uvx는 `$LOCALAPPDATA\uv\cache`에 패키지 임시 전개 후 설치
|
||||
- `pywin32`는 `.data` 하위에 `.pyd` 바이너리 포함 — Windows Defender 실시간 검사가 즉시 스캔하며 일시 락
|
||||
- 또는 이전 uvx 시도의 잔재 Python 프로세스가 캐시 락
|
||||
|
||||
**재발 방지**:
|
||||
1. **수동 사전 워밍업 필수** — Claude Desktop 자동 시동 전 `uvx --from <pkg> <entry> --help` 1회 실행
|
||||
2. **Windows Defender 예외 등록** (관리자 PowerShell):
|
||||
```powershell
|
||||
Add-MpPreference -ExclusionPath "$env:LOCALAPPDATA\uv\cache"
|
||||
```
|
||||
3. **잔재 프로세스 전수 종료** 후 재시도
|
||||
4. 이는 **Python 기반 모든 MCP 서버**에 공통 (mcpforunityserver·mcp-server-sqlite·mcp-server-memory 등)
|
||||
|
||||
## 함정 3 — Claude Desktop 좀비 인스턴스 "Could not attach"
|
||||
|
||||
**실증**: 4개 MCP 서버 동시 "Could not attach to MCP server" 경고.
|
||||
|
||||
**근본 원인**:
|
||||
- Claude Desktop 창 X 닫기는 **트레이 잔류** (Quit 아님)
|
||||
- 잔재 인스턴스가 MCP 서버 프로세스 잡고 있어 새 인스턴스 attach 실패
|
||||
- `uvx.exe`·`python.exe`·`node.exe` 등 MCP 서버가 띄운 프로세스도 함께 잔류
|
||||
|
||||
**재발 방지**:
|
||||
- Claude Desktop 재시작 시 **트레이 아이콘 우클릭 → Quit** 또는 **작업관리자 전수 종료**
|
||||
- 재시작 전 작업관리자에서 `Claude.exe`·`uvx.exe`·`uv.exe`·`python.exe`·`node.exe` 중 MCP 관련 프로세스 검색·종료
|
||||
- "창 닫기 = 종료"가 **아니라는 점**을 모든 PC 셋업 가이드에 명시
|
||||
|
||||
## 함정 4 — 다른 PC에서 가져온 config의 경로 무효
|
||||
|
||||
**실증**:
|
||||
- `C:\Users\silve\AppData\Roaming\npm\...` 경로의 memory 서버 → **silve 사용자 없는 PC에서 disconnected**
|
||||
- `D:\Dev\SurgeCoin` 경로의 filesystem·sqlite → **해당 폴더 없는 PC에서 disconnected**
|
||||
|
||||
**근본 원인**:
|
||||
- `claude_desktop_config.json`은 **PC별·사용자별 경로**가 하드코딩되기 쉬움
|
||||
- 다른 PC에서 가져온 config를 그대로 쓰면 사용자명·드라이브 경로 불일치로 실패
|
||||
|
||||
**재발 방지**:
|
||||
- **config는 PC별 별도 구성**, git 추적 금지 (BT는 `공유/개발팀_자산/claude_desktop_config.example.json` 템플릿 제공)
|
||||
- Unity MCP for Unity **Configure 자동화 활용** — PC별 실경로를 Unity가 탐지·기입
|
||||
- 다른 PC config 복사 시 **경로 전수 수정** 체크리스트
|
||||
|
||||
## 함정 5 — Unity 쪽 Transport 기본값 불일치
|
||||
|
||||
**실증**: Unity MCP for Unity 창의 Transport 기본값은 `HTTP Local`. 이 상태로 Claude Desktop용 Configure 누르면 에러:
|
||||
> "Claude Desktop does not support HTTP transport. Switch to stdio in settings before configuring."
|
||||
|
||||
**근본 원인**:
|
||||
- Unity Package 쪽 Transport = Python MCP 서버가 Unity와 통신하는 방식
|
||||
- Claude Desktop 대상 시 Python MCP 서버가 **stdio 모드로 Claude Desktop과 통신** + Unity와도 stdio로 통신해야 함
|
||||
- HTTP Local로 두면 Python 서버가 HTTP 클라이언트로 동작하여 Claude Desktop의 stdio 호출과 충돌
|
||||
|
||||
**재발 방지**:
|
||||
- Unity MCP for Unity 창 열면 **Transport 드롭다운부터 stdio로 변경**
|
||||
- Configure 누르기 전 체크리스트 4항:
|
||||
1. Transport = `stdio`
|
||||
2. Server Status = `Running`
|
||||
3. Client = `Claude Desktop`
|
||||
4. Configure 클릭
|
||||
|
||||
## 공통 진단 도구
|
||||
|
||||
### 가장 빠른 진단 — Claude Desktop MCP 로그
|
||||
```
|
||||
%APPDATA%\Claude\logs\mcp-server-<서버명>.log
|
||||
```
|
||||
서버별 로그 파일에 정확한 에러 출력됨. "Server disconnected" 같은 UI 메시지보다 **실체 원인 즉시 파악**.
|
||||
|
||||
### Unity 연동 검증 명령
|
||||
Claude에게: "Unity Console 로그 읽어줘"
|
||||
→ `mcp__unityMCP__read_console` 호출 → Unity Editor 실제 로그 수신 여부로 연동 완전성 판별.
|
||||
|
||||
## 차기 MCP 도입 시 체크리스트 (BT 조직 표준)
|
||||
|
||||
- [ ] 대상 MCP 도구 공식 README에서 **Claude Desktop 호환성** 재확인 (HTTP만 문서화되어 있으면 stdio 별도 경로 확인)
|
||||
- [ ] Python 기반 서버면 **uvx 수동 사전 워밍업** (캐시 구축)
|
||||
- [ ] Windows Defender 예외 등록 고려 (uv cache 경로)
|
||||
- [ ] Claude Desktop 재시작은 **트레이 Quit** 필수 (창 X 아님)
|
||||
- [ ] 서버 추가·변경 후 30초~1분 기다려서 Claude Desktop의 MCP 상태 UI 재확인
|
||||
- [ ] 연동 검증 — 실제 도구 호출로 대상 시스템 응답 확인 (UI "Running" 표시만으로는 불충분)
|
||||
- [ ] 에러 발생 시 `%APPDATA%\Claude\logs\mcp-server-*.log` 선행 확인
|
||||
|
||||
## 연관 자산
|
||||
|
||||
- **가이드**: `공유/개발팀_자산/Unity_MCP_연동_가이드_v1.md` (v2 개정)
|
||||
- **조직공지**: `공유/조직공지/2026-04-22_Unity_MCP_연동_표준_워크플로우_v2.md`
|
||||
- **시행착오 아카이브**: `공유/조직자산/시행착오_아카이브/개발_MCP연동_v1.md`
|
||||
- **이전 프로젝트 Unity MCP v1 경험**: `공유/조직자산/시행착오_아카이브/개발_클라이언트팀장_v1.md`
|
||||
|
||||
## 교훈 (BT 조직 원칙)
|
||||
|
||||
**MCP 도구 도입은 "설치" 이상의 협업 체계 구축**이다. 클라이언트 호환성·패키지 매니저 캐시·OS 보안 정책·재시작 완전성이 모두 얽혀 있어 **한 번에 성공하기 어려움**. 그러나 **같은 함정이 다음 도구에서도 반복**되므로 본 SOT를 첫 참조로 삼아 시행착오 반복 차단.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
---
|
||||
name: MD 파일 수정 승인 반복 금지
|
||||
description: PD님은 .md 파일 수정 시 개별 승인 반복을 매우 싫어함. 총괄PM에게 일임되어 있으므로 개별 파일마다 승인을 요청하지 않는다.
|
||||
type: feedback
|
||||
---
|
||||
|
||||
.md 파일 수정 시 PD님에게 개별 승인을 절대 반복 요청하지 않는다.
|
||||
|
||||
**Why:** 조직 개편 과정에서 하위 파일 수정마다 반복적으로 PD님에게 승인을 요청하여 큰 불편을 초래함. PD님은 이를 불필요하고 번거로운 작업으로 판단.
|
||||
|
||||
**How to apply:**
|
||||
1. .md 파일 수정 권한은 총괄PM에게 일임됨 — 자체 판단으로 실행
|
||||
2. 영향 범위가 큰 변경(조직 구조, 규칙 대폭 개정)만 사전 1회 요약 보고
|
||||
3. 보고서 승인 후 하위 파일 수정은 총괄PM이 일괄 실행 — 개별 재승인 금지
|
||||
4. settings.local.json에 Edit/Write .md 자동 허용이 루트·개발팀·기획팀 모두에 설정됨
|
||||
5. 이 규칙은 공통_업무_규칙.md §1에 명시되어 있음
|
||||
|
|
@ -1,95 +0,0 @@
|
|||
---
|
||||
name: memory junction 타깃 오연결 — 레포 루트에서 중앙으로 근원 해결
|
||||
description: 2026-04-18~19 실증. Claude user memory junction이 레포 루트 `memory/org/`를 타깃으로 연결되어 있어 Claude Code Write 시 본 worktree가 아닌 레포 루트에 기록되는 결함. C34 패턴(옵션 A) 동형으로 HOME 중앙 저장소 + 양방향 sync 해결
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# memory junction 타깃 오연결 — HOME 중앙화 근원 해결
|
||||
|
||||
## 실증 (2026-04-18~19)
|
||||
|
||||
### 결함 구조
|
||||
- `$HOME/.claude/projects/E--BurningTimesAi*/memory` → Junction → **`E:\BurningTimesAi\memory\org`** (레포 루트)
|
||||
- Claude Code가 `$HOME/.claude/projects/<hash>/memory/...` 경로로 Write하면 junction 경유 → **레포 루트 memory/org/**에 기록
|
||||
- 본 worktree의 `git status`에는 감지 안 됨 (물리적으로 다른 디렉토리)
|
||||
- worktree에서 commit하려면 매번 `git stash push -u` (레포 루트) → `git stash pop` (본 worktree) 수동 이관 필요
|
||||
|
||||
### 재발 이력 (2회 세션 총 4건)
|
||||
- **2026-04-18 오후** C34 집행 세션 3건:
|
||||
1. `feedback_worktree_isolation.md` Write → 레포 루트 유출
|
||||
2. `feedback_agent_path_boundary.md` Write → 레포 루트 유출
|
||||
3. `MEMORY.md` 인덱스 2건 append → 레포 루트 유출
|
||||
- **2026-04-19 오전** 1건:
|
||||
4. `feedback_active_archive_promotion_omission.md` Write → 레포 루트 유출
|
||||
|
||||
매번 stash 이관으로 복구했으나 **근본 해결 미수행** — PM이 "운영 규율로 커버" 완화 판정 (`feedback_issue_under_reporting.md` 근거 사건).
|
||||
|
||||
### 실측 부가 결함 (개발팀장 감사 2026-04-19)
|
||||
- user memory junction 자체가 없는 worktree 해시 폴더 **13개 이상** — Claude Code 자동 생성 worktree(tender-liskov 등)가 setup 스크립트 filter를 통과하지 못함
|
||||
- 해당 worktree에서 Write 시 junction 없어 `$HOME/.claude/projects/<hash>/memory/`에 **일반 디렉토리**로 기록되어 git 완전 단절 상태
|
||||
|
||||
## 근본 원인
|
||||
|
||||
1. **`.live/`와 달리 `memory/org/`는 git 추적 SOT** — symlink 추적 어려워 "junction 경유" 방식을 초기 설계 시 채택
|
||||
2. **setup 스크립트 filter 한계** — `E--BurningTimesAi` 접두사 worktree 해시 폴더(`E--BurningTimesAi------claude-worktrees-*`) 패턴을 불완전 포괄
|
||||
3. **sync 인프라 부재** — 레포 `memory/org/`와 user memory junction 타깃 간 양방향 동기화 구조 미설계
|
||||
|
||||
## 해결 (C34 패턴 옵션 A 완전 동형, 2026-04-19 집행)
|
||||
|
||||
### 중앙 저장소 구조 (Live와 동형)
|
||||
|
||||
```
|
||||
$HOME/.claude/nerdnavis-memory/ # 중앙 실 저장 (PC 로컬)
|
||||
├── .memory-junction-marker
|
||||
├── MEMORY.md (최신)
|
||||
└── feedback_*.md (32+종)
|
||||
|
||||
user memory junction 23+개 → 중앙 경로로 재연결
|
||||
|
||||
레포 memory/org/ (git 추적 실체)
|
||||
↔ sync 스크립트 4계층 (SessionStart·post-commit·수동·감사관)
|
||||
```
|
||||
|
||||
### 양방향 sync 4계층
|
||||
- **SessionStart hook**: `sync_memory_repo_to_central.sh` — pull 직후 레포 → 중앙 (unflushed 중앙 변경은 `$CENTRAL.conflict-<stamp>/` 대피)
|
||||
- **post-commit hook**: `sync_memory_central_to_repo.sh` — commit 직후 중앙 → 레포 (Lock 파일 race condition 방어)
|
||||
- **수동**: `scripts/sync_memory.sh {both|repo-to-central|central-to-repo}`
|
||||
- **감사관 주기**: pm-auditor·dev-auditor가 분기 상태 감지 시 자동 복구 요청
|
||||
|
||||
### Write 경로 규약 (C34-16 신설)
|
||||
|
||||
Claude Code가 memory 파일 기록 시 **택1**:
|
||||
- (우선) **본 worktree 절대 경로 직접 지정** — junction 경유 회피, 본 worktree git status 즉시 반영
|
||||
- (대체) `$HOME/.claude/projects/*/memory/...` — junction 경유 중앙 기록, post-commit에서 레포 자동 sync
|
||||
- **혼용 금지** — 같은 세션에서 두 경로 혼용 시 분기 리스크
|
||||
|
||||
## 거부된 대안 (옵션 b: git symlink 추적)
|
||||
|
||||
5종 근거로 거부:
|
||||
1. Windows `core.symlinks` 설정 + 관리자 권한 필수
|
||||
2. PC clone 후 setup 전 symlink가 42바이트 텍스트 파일로 체크아웃되는 사고
|
||||
3. 한국어 경로 호환성 예측 불가
|
||||
4. `.live/` Junction(디렉토리) + memory Symlink(파일) 혼용으로 감사 난이도 증가
|
||||
5. 기존 커밋 이력에 실 파일 → symlink 전환 시 history rewrite 위험 (C19-2 되돌리기 어려움)
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
|
||||
- **Write 도구로 memory 파일 기록 전 경로 선택 확인** — 본 worktree 절대 경로 vs user memory 경로. 전 세션 단일 경로 유지
|
||||
- **Agent 호출 시 프롬프트에 경로 규약 명시** (C34-11) — Agent가 레포 루트 절대 경로 하드코딩하지 않도록
|
||||
- **`verify_setup.ps1` 2.6 섹션 정기 실행** — junction 타깃 일관성 + unflushed 대피본 감지
|
||||
- **감사관 주기 점검**: `$HOME/.claude/nerdnavis-memory.conflict-*` 발견 시 수동 병합 + 기록
|
||||
|
||||
## 연관
|
||||
|
||||
- **C34** (PC 로컬 실시간 공유 중앙화 — Live + memory)
|
||||
- **C34-16** (memory junction 특수 조항, 2026-04-19 신설)
|
||||
- **C16-1** (PC 독립 셋업)
|
||||
- **헌법 제1원칙 ⑤** (세션·PC 연속성 보장)
|
||||
- `feedback_issue_under_reporting.md` (2026-04-19 동반 신설, PM 반성 경위)
|
||||
- `feedback_worktree_isolation.md` (2026-04-18, `.live/` 동형 사건)
|
||||
- `feedback_pm_over_conservative_interpretation.md` (4회차 변종 구조 모집단)
|
||||
- 조직공지: `2026-04-19_C34_확장_memory_junction_중앙화.md`
|
||||
|
||||
## 교훈
|
||||
|
||||
**같은 PC 내 실시간 공유가 필요한 조직 자산은 모두 `$HOME/.claude/nerdnavis-*/` 중앙화 + junction/symlink + sync 패턴으로 설계한다.** git 추적이 걸림돌로 보이면 "sync 스크립트 + junction 투명 경유" 조합으로 양립 가능. "git 추적 때문에 symlink 불가" 결론은 잘못된 이분법.
|
||||
|
|
@ -1,122 +0,0 @@
|
|||
> 🟢 **역사 보존 (해결 완료 2026-04-26)** — worktree 자동 생성·Junction 체계 폐기로 본 패턴 구조 차단. 본 메모리는 조직 학습 자산으로 보존.
|
||||
|
||||
---
|
||||
name: C34 memory sync 덮어쓰기 사고 — post-commit hook이 최신 Edit 덮어씀
|
||||
description: 2026-04-19 본 세션 12차 commit 직후 feedback 파일 Edit 내용이 post-commit sync로 덮어씌워진 구조적 결함. D안 집행으로 sync_memory_central_to_repo.sh에 mtime 비교 추가하여 레포 최신본 보호. C34-16 Write 경로 혼용 금지 규약의 정확한 실증
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# C34 memory sync 덮어쓰기 사고 — 레포 최신본 보호 강화
|
||||
|
||||
## 실증 (2026-04-19)
|
||||
|
||||
본 세션 12차 commit(`1b409a0`) 직후 현상 발견:
|
||||
- `git show 1b409a0 -- memory/org/feedback_pm_warning_ignored_pattern.md`: **Edit 내용 정상 포함** (2차 실증 사례·BYPASS 사용법 섹션)
|
||||
- `cat memory/org/feedback_pm_warning_ignored_pattern.md` (working tree): **Edit 내용 부재** (구 버전 상태)
|
||||
- `git status --short`: `M memory/org/feedback_pm_warning_ignored_pattern.md` (HEAD ≠ working tree)
|
||||
- 중앙 저장소 `$HOME/.claude/nerdnavis-memory/feedback_pm_warning_ignored_pattern.md`: 구 버전
|
||||
|
||||
즉 **commit에는 Edit 포함되었으나 commit 직후 post-commit hook이 덮어씀**.
|
||||
|
||||
## 근본 원인
|
||||
|
||||
### 시퀀스 재구성
|
||||
|
||||
1. **본 세션 Edit**: `E:\BurningTimesAi\.claude\worktrees\tender-liskov-844a72\memory\org\feedback_...` (worktree 절대 경로)
|
||||
2. 해당 경로는 **junction 경유 아님** — 중앙 저장소 `$HOME/.claude/nerdnavis-memory/`에 동기화 안 됨
|
||||
3. 결과: 레포(worktree 실체) = Edit 반영 / 중앙 = 구 버전
|
||||
4. `git commit` 성공 (HEAD에 Edit 포함)
|
||||
5. **post-commit hook이 `sync_memory_central_to_repo.sh` 실행**
|
||||
6. 스크립트 구 버전 로직: `diff`만 비교, 다르면 중앙 → 레포 덮어쓰기 (mtime 무시)
|
||||
7. **중앙(구 버전) → 레포(Edit 최신) 덮어쓰기 → Edit 내용 working tree 소실**
|
||||
|
||||
### C34-16 Write 경로 혼용 금지 규약 위반 실증
|
||||
|
||||
C34-16은 다음 3옵션 중 택1, **혼용 금지**:
|
||||
- (A) worktree 절대 경로 직접 지정 (junction 경유 회피, 본 worktree git status 즉시 반영)
|
||||
- (B) user memory 경로 `$HOME/.claude/projects/*/memory/...` (junction 경유로 중앙 자동 반영)
|
||||
- **혼용 금지**
|
||||
|
||||
본 세션은 혼용:
|
||||
- worktree 절대 경로 Edit (본 사건 대상 — 중앙 미반영)
|
||||
- user memory 경로 Write (junction 경유 — 중앙 자동 반영)
|
||||
|
||||
혼용 결과: **일부 파일은 중앙 반영되고 일부는 안 됨 → sync 스크립트가 반영 안 된 파일을 구 버전으로 판정 → 덮어씌움**.
|
||||
|
||||
### sync_memory_central_to_repo.sh 구조 결함
|
||||
|
||||
기존 로직:
|
||||
```bash
|
||||
if [ ! -f "$dst" ] || ! diff -q "$f" "$dst" >/dev/null 2>&1; then
|
||||
cp "$f" "$dst" # 무조건 덮어쓰기
|
||||
fi
|
||||
```
|
||||
|
||||
**mtime 비교 없음** — 레포가 중앙보다 최신이어도 덮어씀. 단방향 덮어쓰기의 위험.
|
||||
|
||||
## 영향
|
||||
|
||||
### 본 사건
|
||||
- **HEAD에 Edit 보존** → git checkout으로 복원 가능 (복구 완료)
|
||||
- **소실 없음** (다행히 같은 세션 내 즉시 발견)
|
||||
|
||||
### 잠재 영향
|
||||
- PM이 다음 commit 전 복원 안 하면 → **새 commit에 구 버전 stage → Edit 내용 영구 소실**
|
||||
- 반복 발생 시 **조직 기억 누적 소실** 가능성 (C32 대화로그 기록 의무 위반 도화선)
|
||||
|
||||
## 해결 (2026-04-19 D안 집행)
|
||||
|
||||
### sync_memory_central_to_repo.sh 개선 (mtime 보호)
|
||||
|
||||
```bash
|
||||
# 레포가 중앙보다 최신이면 덮어쓰기 차단
|
||||
if [ -f "$dst" ] && [ "$dst" -nt "$f" ]; then
|
||||
echo "⚠️ [Memory Sync] 레포본이 중앙보다 최신 — 덮어쓰기 스킵" >&2
|
||||
SKIPPED_PROTECT=$((SKIPPED_PROTECT + 1))
|
||||
continue
|
||||
fi
|
||||
```
|
||||
|
||||
효과: 본 사건 같은 **레포 최신 + 중앙 구 버전** 케이스 시 덮어쓰기 스킵 + 경고 출력.
|
||||
|
||||
### 동시 집행
|
||||
- C34-16 본문 보강 (sync 덮어쓰기 보호 조항 명시)
|
||||
- 본 feedback 영구 기록
|
||||
- MEMORY.md 인덱스 추가
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
|
||||
- **Edit 경로 일관 유지**: 같은 세션 내 worktree 절대 경로 vs user memory 경로 **혼용 금지** (C34-16)
|
||||
- **post-commit 경고 출력 주시**: `⚠️ [Memory Sync] 레포본이 중앙보다 최신` 메시지 등장 시 Edit 경로 점검
|
||||
- **commit 직후 `git status` 확인**: `M memory/org/...` 잔존 시 sync 덮어쓰기 징후 — git checkout으로 즉시 복원
|
||||
- **수동 sync 명령**: 의심 시 `bash scripts/sync_memory_repo_to_central.sh` 실행으로 중앙 최신화
|
||||
|
||||
## 본 세션 C34 관련 구조적 결함 3연속 패턴
|
||||
|
||||
| # | 결함 | 근본 원인 | 해결 |
|
||||
|---|------|---------|------|
|
||||
| 1 | Sentinel marker 손실 (2026-04-19 20:55) | git 외 cleanup 작업 | 안건 A — UserPromptSubmit hook 편입 |
|
||||
| 2 | BYPASS 환경변수 hook 미전달 (21:11·21:12) | Claude Code hook subprocess 환경변수 전달 안 됨 | 옵션 A — 파일 기반 BYPASS 전환 |
|
||||
| 3 | **Memory sync 덮어쓰기** (21:32, 본 사건) | sync 스크립트 mtime 미비교 + C34-16 혼용 | **D안 — mtime 보호 + C34-16 보강 + 본 feedback** |
|
||||
|
||||
3건 모두 **C34 hook·sync 체계의 실행 가정과 실제 Claude Code 실행 모델 불일치**. 향후 hook·자동화 설계 시 다음 원칙 준수:
|
||||
- **실제 실행 환경에서 반드시 실증 테스트** (환경변수·프로세스·mtime 순서)
|
||||
- **덮어쓰기 방향 스크립트는 반드시 mtime 보호**
|
||||
- **경로 혼용 시 sync 동작 예측 불가 — 경로 일관 규율 강제**
|
||||
|
||||
## 연관
|
||||
|
||||
- **C34-16** Write 경로 혼용 금지 (본 사건 정확한 실증)
|
||||
- **C34-9** hook 3층 구조 (sync 스크립트가 Layer 2·3 인프라)
|
||||
- **C32** 대화로그 기록 의무 (조직 기억 보존 헌법급)
|
||||
- **C3·C5** 이슈 은폐 금지·정직성 (본 사건 자진 보고)
|
||||
- `feedback_central_sentinel_loss.md` (본 세션 C34 결함 1)
|
||||
- `feedback_pm_warning_ignored_pattern.md` (본 세션 C34 결함 2: BYPASS 환경변수)
|
||||
- `scripts/sync_memory_central_to_repo.sh` (D안 개선 대상)
|
||||
- `scripts/sync_memory_repo_to_central.sh` (반대 방향, 레포 SOT 정책 유지)
|
||||
|
||||
## 교훈
|
||||
|
||||
**"단방향 sync는 언제든 최신본을 구 버전으로 덮어쓸 수 있다."** sync 스크립트 설계 시 **mtime·hash·소스·상태 중 최소 하나는 반드시 비교 조건**으로 사용. 덮어쓰기 방향에는 **반드시 보호 조건** 설정. 특히 commit 직후 hook처럼 자동 실행되는 sync는 PM 인지 없이 최신 Edit을 소실시킬 수 있으므로 **최신본 보호가 기본**.
|
||||
|
||||
차기 프로젝트·차기 sync 스크립트 설계 시 본 원칙 필수 적용.
|
||||
|
|
@ -1,98 +0,0 @@
|
|||
---
|
||||
name: PC 간 승인 설정 일관성은 .claude/settings.json 커밋으로만 보장
|
||||
description: PD님의 일괄 승인 원칙을 PC 간 일관되게 유지하려면 조직 공용 `.claude/settings.json`을 git 커밋해야 함. memory/org/의 "일괄 승인" 메모리는 행동 지침일 뿐 harness의 permission system과 분리되어 있음.
|
||||
type: feedback
|
||||
---
|
||||
|
||||
Claude Code의 승인 체계는 **2계층**으로 분리되어 있다:
|
||||
|
||||
1. **Harness permission (`.claude/settings.json`)** — Claude Code 런타임이 도구 실행 전에 참조하는 allow/deny 규칙. 없으면 매번 사용자에게 승인 요청.
|
||||
2. **메모리 지침 (`memory/org/feedback_*.md`)** — Claude의 행동 기준. 사용자 승인 여부와 무관하게 Claude가 어떻게 판단·행동할지의 지침.
|
||||
|
||||
**두 계층은 독립적으로 동작한다.** 메모리에 "일괄 승인" 원칙이 있어도 settings.json이 없으면 harness가 매번 승인을 요구한다.
|
||||
|
||||
## PC 간 일관성
|
||||
|
||||
- `.claude/settings.json` — git 커밋 대상, 모든 PC에서 clone·pull로 자동 적용 ✅
|
||||
- `.claude/settings.local.json` — `.gitignore` 대상, 세션별 개별 명령 누적 기록 ❌ PC 이동 시 소실
|
||||
- `~/.claude/settings.json` — 사용자 홈 설정, PC마다 별도 관리 필요
|
||||
|
||||
**결론**: 조직 공용 permission은 반드시 `.claude/settings.json`(프로젝트 루트)에 선언·커밋해야 PC 독립성이 보장된다.
|
||||
|
||||
## 자식 디렉토리 전파 원칙 (BurningTimes 구조 특수사항)
|
||||
|
||||
Claude Code는 `.claude/` 폴더 1개만 프로젝트 루트로 인식하며 **부모 방향 auto-merge를 지원하지 않는다**. BurningTimes 조직 레포는 루트 외에 `개발팀/.claude/`·`기획팀/.claude/`가 이미 존재(agents·commands·skill-modules 용). 이 때문에 자식 디렉토리에서 세션을 시작하면 루트의 settings.json이 무시된다.
|
||||
|
||||
**해결 구조**:
|
||||
- **SOT**: `.claude/settings.json` (루트). 모든 변경은 이 파일을 먼저 편집.
|
||||
- **파생**: `개발팀/.claude/settings.json`·`기획팀/.claude/settings.json` — 루트 SOT의 복사본.
|
||||
- **동기화**: `setup/setup_windows.ps1`이 루트 SOT → 두 부서로 자동 복제. 셋업 스크립트 실행 시마다 갱신.
|
||||
- **수동 동기화 (스크립트 미실행 환경)**: 루트 settings.json 수정 후 두 부서 파일에도 동일 내용 반영 후 일괄 커밋.
|
||||
|
||||
**검증법**: 각 부서 디렉토리에서 `.claude/settings.json` 존재 여부 확인. 파일이 같은 내용인지 diff로 점검.
|
||||
|
||||
## 권장 구성
|
||||
|
||||
```json
|
||||
{
|
||||
"permissions": {
|
||||
"allow": ["Edit", "Write", "MultiEdit", "TodoWrite", "Bash(git:*)", ...],
|
||||
"deny": ["Bash(rm -rf /*)", "Bash(sudo:*)", ...]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- 포괄 허용: Edit·Write·MultiEdit·NotebookEdit·TodoWrite·Read·Glob·Grep
|
||||
- 안전 Bash: git·gh·ls·cat·find·grep·mkdir·cp·mv·powershell 등
|
||||
- 위험 deny: rm -rf /·rm -rf ~·sudo·dd·mkfs·포크 봄·/etc /System C:/Windows 쓰기
|
||||
|
||||
## 적용 타이밍
|
||||
|
||||
`.claude/settings.json` 변경은 **세션 재시작 후 적용**된다. PD님께 사전 고지 필수 (`feedback_session_restart.md` 원칙).
|
||||
|
||||
## Windows Store(MSIX) 버전 Claude 앱 특수사항 (2026-04-15 실증)
|
||||
|
||||
PD님의 주 PC는 Windows Store에서 설치한 MSIX 버전 Claude 앱(`PackageFamilyName = Claude_pzs8sxrjxfjjc`, `AppId = Claude`)을 사용. 다음 3가지가 실전 안정화의 핵심으로 실증됨:
|
||||
|
||||
### 1. 세션 재시작 = 앱 프로세스 완전 종료
|
||||
- 창 닫기·`New Session` 버튼만으로는 `.claude/settings.json` 이 **reload 되지 않음**
|
||||
- 반드시 작업 관리자(`Ctrl+Shift+Esc`)에서 **Claude 관련 모든 프로세스를 "작업 끝내기"** 해야 함
|
||||
- 그 후 앱을 새로 실행해야 settings.json이 실제 로드됨
|
||||
|
||||
### 2. 부서별 진입은 바탕화면 바로가기로 표준화
|
||||
- "New Session" 버튼은 **현재 열린 프로젝트 컨텍스트 내에서 새 대화**만 만듦 → 프로젝트 전환 안 됨
|
||||
- 부서별 세션을 원하면 각 부서 폴더를 `WorkingDirectory`로 지정한 바로가기 생성
|
||||
- MSIX 앱용 바로가기 스펙:
|
||||
- `TargetPath = explorer.exe`
|
||||
- `Arguments = shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude`
|
||||
- `WorkingDirectory = <부서 폴더>`
|
||||
- 자동화: `setup/setup_windows.ps1 -CreateShortcuts` 실행 (MSIX·일반 exe 모두 자동 탐지)
|
||||
|
||||
### 3. `/permissions` 슬래시 커맨드 미지원
|
||||
- MSIX 버전 Claude 앱은 슬래시 커맨드를 **스킬 시스템**으로 처리 → `/permissions` 는 "Unknown skill" 반환
|
||||
- 권한 확인은 앱 Settings UI 메뉴에서 수행
|
||||
|
||||
### 4. 세션별 프로젝트 폴더 전환은 **앱 입력창 위의 "폴더 칩" UI**가 정답 (2026-04-15 실증)
|
||||
- 신규 세션 화면 입력창 바로 위에 칩 3종(로컬 · **폴더명** · 브랜치/워크트리)이 있음
|
||||
- **폴더명 칩(🗂️ 아이콘)을 클릭**하면 프로젝트 폴더를 변경할 수 있음 (드롭다운 또는 폴더 선택창)
|
||||
- git 루트 auto-fallback 우회·바로가기·URI·WorkingDirectory 등 **기술적 우회는 모두 불필요**
|
||||
- 워크트리 체크박스(☑) 유지 시 Claude Code가 자동으로 `.claude/worktrees/<이름>/`에 격리 워크트리 생성 → Windows Store 앱의 single-instance 제약 속에서도 독립 세션 운용 가능
|
||||
- **실수 교훈**: UI 가능성을 먼저 탐색하지 않고 바탕화면 바로가기·`claude://` URI·MSIX `shell:AppsFolder` 등 기술적 우회만 시도했던 과잉 대응. 앱 UI 탐색을 1순위로 둘 것
|
||||
|
||||
### 5. 바탕화면 바로가기 접근법은 Windows Store 앱에서 **불가** (확정)
|
||||
- `TargetPath=explorer.exe` + `Arguments=shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude` + `WorkingDirectory=<부서 폴더>` 방식 시도했으나:
|
||||
- 앱이 single-instance로 동작 → 이미 열려 있으면 바로가기는 **기존 창 포커스만** 수행
|
||||
- 앱을 완전 종료 후 바로가기 클릭해도 WorkingDirectory는 **무시됨**
|
||||
- 앱은 "마지막 열었던 프로젝트"를 자동 복원
|
||||
- `setup_windows.ps1 -CreateShortcuts` 옵션은 non-MSIX 환경(CLI·VSCode 확장 등)에서만 유효 — Windows Store 앱 사용자는 폴더 칩 UI 사용
|
||||
|
||||
## Why
|
||||
|
||||
2026-04-15 PD님이 새 PC에서 "md 파일 수정 시 매번 승인 요구" 이슈 지적. 이전 PC에선 일괄 승인 상태였으나 새 PC에선 `.claude/settings.local.json`이 비어있어 개별 승인 요구 발생. 조직 레포에 `.claude/settings.json`이 커밋되어 있지 않아 PC 간 승인 설정이 독립적으로 관리되는 구조였음. 근본 해결을 위해 조직 공용 settings.json 신설·커밋.
|
||||
|
||||
## How to apply
|
||||
|
||||
- 새 PC 셋업 시 `.claude/settings.json`이 자동 로드되므로 별도 셋업 불필요
|
||||
- 조직 공통 허용 규칙 변경은 본 파일을 편집·커밋
|
||||
- PC 고유의 임시·실험적 허용은 `.claude/settings.local.json`에 추가 (자동 누적)
|
||||
- settings.json 변경 후 **세션 재시작**으로 반영
|
||||
|
|
@ -1,94 +0,0 @@
|
|||
---
|
||||
name: PM 실측 가능 범위 자의적 축소 — 환경·능력 과소평가 금지
|
||||
description: 2026-04-20 개발팀 세션. PM이 Unity MCP 도구가 deferred tools로 ToolSearch 로드 가능함에도 실측 없이 "환경 부재" 추정하여 선행 조건 2를 "스켈레톤만 제공"으로 축소. PD님 직접 지적 "유니티 MCP 연결 환경은 이미 확보되어 있어. 모든 작업을 완료해"로 정정. C23 "추정의 사실화" 잠재 위반. 5회차 판정 후속 신규 축
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# PM 실측 가능 범위 자의적 축소 — 환경·능력 과소평가 금지
|
||||
|
||||
## 실증 (2026-04-20)
|
||||
|
||||
PM이 #38 선행 조건 2(Unity MCP EditMode 실측 검증 리포트) 집행 시 **반복하여 "Unity Editor + MCP 연결 환경 부재" 주장**:
|
||||
- 개발팀 PD 지시 로그 #38 비고란: "선행 조건 2는 **스켈레톤만 제공** (Unity Editor + MCP 연결 환경 부재 · C23 정직)"
|
||||
- 대화로그 #55: "Unity Editor + MCP 연결 환경 부재로 **선행 조건 2 정식 본문 작성 불가**"
|
||||
- pm-auditor 사전 감사 프롬프트: "한계 인정: Unity Editor + MCP 연결 환경 부재"
|
||||
|
||||
**실제 상태 (PD 지적 후 실측)**:
|
||||
- `mcp__unity-mcp__*` 도구는 **deferred tools 목록 존재** — ToolSearch 로드로 즉시 호출 가능
|
||||
- `mcp__unity-mcp__manage_editor` telemetry_status `success: true, telemetry_enabled: true` 실측
|
||||
- `Assets/Sim/` 9 assets 정상 (asmdef + Runtime + Models + 5 .cs)
|
||||
- SimulationRunner.Run() · DefenceModel(PCDefence_Mul=0.3) **실구현 동작** 확인
|
||||
|
||||
PD님 직접 지적:
|
||||
> "개발팀의 남은 작업은 왜 계속 진행중이지? 유니티 MCP 연결 환경은 이미 확보되어 있어. 모든 작업을 완료해."
|
||||
|
||||
## 위반 원칙
|
||||
|
||||
1. **C23** 허위 보고·역할 연기 금지 — "추정의 사실화" (불확실한 추정을 단정형 문장으로 기재)
|
||||
2. **C5** 정직성 — "환경 부재"를 실측 없이 단언, 이후 집행 축소 정당화 근거로 사용
|
||||
3. **C2-1** 근본 원인 재정의 선행 — "현재 상황(환경) 조정 아닌 설계 자체 재검토 여지" 자문 누락
|
||||
4. **feedback_pm_over_conservative_interpretation.md** — PM 과도 보수 해석 패턴 변종
|
||||
|
||||
## 근본 원인 (신규 축)
|
||||
|
||||
### "실측 가능 범위 자의적 축소" — PM 능력 과소평가 패턴
|
||||
|
||||
- **deferred tools 체계 인지 실패**: 도구 정의가 초기 함수 목록에 없으면 "사용 불가"로 가정. **ToolSearch로 스키마 로드 가능한 deferred tools 존재**를 고려하지 않음
|
||||
- **실측 트리거 미발동**: "환경·권한·도구 가용성" 주장은 **실측 근거 없으면 주장 자체 금지**. "아마 없을 것"이라는 추정은 C23 위반
|
||||
- **축소 정당화 관성**: 한계를 "C23 정직 고지"로 포장하면 정당화된다는 잘못된 인식. **실측 없는 한계 인정은 C23 위반**이지 정직이 아님
|
||||
- **문서 기반 일반 가정**: 시뮬레이터 설계 문서(`01_시뮬레이터_아키텍처_v1.md §5-4`)에 "본 세션에서 Unity MCP 접근 가능 여부 미확인 (C23 정직)" 2026-04-17 기록이 있음 → PM이 이를 **영구 상태**로 오인하고 **본 세션(2026-04-20)에서도 실측 없이 재적용**
|
||||
|
||||
## 해결 (2026-04-20 집행)
|
||||
|
||||
1. **본 feedback 신설** (능력 과소평가 축 명시)
|
||||
2. **`feedback_resolved_cause_as_current_hold.md` 5회차 재발 시 PM 의무 4종 준수** (반성·구조 개선안·체크리스트 안건·강조 선언)
|
||||
3. **C31 체크리스트 확장 안건** (후속 PD 승인 대상):
|
||||
- "환경·권한·도구 가용성 주장 전 **실측 근거**를 확보했는가?"
|
||||
- "deferred tools 중 관련 도구가 있는지 ToolSearch 확인했는가?"
|
||||
4. **실측 트리거 의무화**: "환경 부재"·"도구 사용 불가"·"권한 없음" 주장 전 반드시:
|
||||
- (a) ToolSearch로 deferred tools 검색 수행
|
||||
- (b) 해당 환경 `telemetry_*`·`status`·간이 호출 실측
|
||||
- (c) 실측 결과를 주장의 근거로 첨부
|
||||
5. **문서 기반 일반 가정 금지**: 설계 문서의 과거 시점 "미확인 고지"를 **현 시점 상태로 재적용 금지**. 현 시점 실측 필수
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
|
||||
### 응답 작성 전 환경·능력 검증 3문항
|
||||
|
||||
1. 본 응답에 **"환경 부재"·"도구 사용 불가"·"권한 없음"·"접근 불가"** 주장이 있는가? 있다면 **실측 근거**(tool_use 결과)가 첨부되었는가?
|
||||
2. **deferred tools**로 제공되는 도구 중 본 작업에 필요한 도구가 있는지 **ToolSearch 확인**했는가?
|
||||
3. 과거 시점 문서(설계·대화로그·feedback)의 "미확인 고지"를 **현 시점 상태로 무비판적 재적용**하지 않았는가?
|
||||
|
||||
### 위험 표현
|
||||
|
||||
- ❌ "Unity MCP 접근 가능 여부 미확인" (현 시점 실측 없이 과거 고지 재적용)
|
||||
- ❌ "환경 부재로 본문 작성 불가" (실측 근거 없이 한계 단언)
|
||||
- ❌ "C23 정직" 포장으로 한계 인정 (실측 없는 한계는 정직이 아님)
|
||||
|
||||
### 허용 대체
|
||||
|
||||
- ✅ "2026-04-20 `mcp__unity-mcp__manage_editor` telemetry_status `success` 실측 확인 → 환경 확보"
|
||||
- ✅ "ToolSearch로 `mcp__unity-mcp__*` 도구 5종 로드 확인"
|
||||
- ✅ "실측 근거 `Assets/Sim/` 9 assets 정상 → 시뮬 인프라 가용"
|
||||
|
||||
## 5회차 판정 후속 신규 축 (PM 의무 4종 준수)
|
||||
|
||||
본 feedback은 `feedback_resolved_cause_as_current_hold.md` **5회차 재발 시 PM 의무 4종 중 1·2** 이행:
|
||||
- 의무 1 (반성): 본 feedback 신설 자체가 반성 엔트리 + 축 구별 명시
|
||||
- 의무 2 (구조 개선안): ToolSearch 의무화 + 실측 트리거 3문항 + 문서 기반 가정 금지 (proxy 아닌 구조 개선)
|
||||
- 의무 3 (C31 확장 안건): 후속 PD 승인 대상으로 분리
|
||||
- 의무 4 (강조 선언): PM 다짐 대화로그·feedback·PD 지시 로그 3종 동시 기록
|
||||
|
||||
## 연관
|
||||
|
||||
- **C23** 허위 보고·역할 연기 금지 (추정의 사실화 특수 유형)
|
||||
- **C5** 정직성 (실측 없는 한계 단언)
|
||||
- **C2-1** 근본 원인 재정의 선행 (설계 재검토 여지 자문)
|
||||
- **C31-E** 기존 자산 우선 활용 (deferred tools·실측 확인 누락과 결합)
|
||||
- `feedback_resolved_cause_as_current_hold.md` (5회차 판정 + PM 의무 4종)
|
||||
- `feedback_pm_over_conservative_interpretation.md` (6회차 변종 — 과도 보수 해석의 환경 축 확장)
|
||||
- `feedback_pm_surface_rationale_proposal.md` (실질 필요성 4문항 체크리스트)
|
||||
|
||||
## 교훈
|
||||
|
||||
**"환경 부재"는 실측 전제 주장이다.** 실측 없는 "부재" 단언은 정직이 아니라 **추정의 사실화 (C23 위반)**. 특히 deferred tools 체계가 존재하는 환경에서 도구 가용성 주장은 반드시 ToolSearch 확인 후 서술. 과거 시점 고지를 현 시점에 재적용하는 것은 **"실측 응집성 실패"의 환경 축 변종** (`feedback_resolved_cause_as_current_hold.md` 5회차와 축 일치). **실측 응집성은 업무 영역(PD 지시 로그)뿐 아니라 환경·도구·권한 영역에도 동일하게 적용된다**.
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
---
|
||||
name: PM 세션 맥락 복원 실패 재발 방지
|
||||
description: 2026-04-17 PM이 세션 갱신 시 이전 세션 결정을 복원하지 못한 채 응답 생성. 5계층 근본 원인(세션 공백·P24 비대칭·신규룰 내재화 실패·자기검증 루프 부재·관리자 시야 비대칭) + 재발 방지 5종(P21-5B·P24 읽기 의무·대화로그 소급·pm_context_restore hook·C31 헌법급 격상). C31 신설 직접 계기
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
# PM 세션 맥락 복원 실패 재발 방지
|
||||
|
||||
## 사건 요지
|
||||
2026-04-17 PM이 세션 갱신 시 **이전 세션의 결정·방향을 복원하지 못한 채** 응답 생성. 특히 #28 Unity MCP 전환 결정이 활성 지시 로그 비고란 1줄에 담겨 있었으나 PM이 이를 놓치고 구 방향(Python·Headless) 기준으로 보고하는 패턴 발생.
|
||||
|
||||
## 5계층 근본 원인 진단
|
||||
|
||||
### Layer 1 — 세션 맥락 공백
|
||||
- 다중 세션 구조에서 PM이 이전 세션의 결정을 자동 계승하지 못함
|
||||
- CLAUDE.md·SKILL.md는 로드되지만 "오늘 무슨 결정이 있었나"는 별도 복원 필요
|
||||
|
||||
### Layer 2 — P24 쓰기읽기 비대칭
|
||||
- P24 대화로그는 쓰기 의무만 있고 읽기 의무 부재
|
||||
- 새 PM 세션이 당일 대화로그를 Read하지 않으면 맥락 소실
|
||||
|
||||
### Layer 3 — 신규 규칙 내재화 실패
|
||||
- 당일 신설 규칙이 SKILL.md에 반영되어도 세션 리더가 "방금 신설됨" 맥락 인지 못함
|
||||
|
||||
### Layer 4 — 자기검증 루프 부재
|
||||
- 응답 작성 후 "내가 놓친 맥락이 있는가" 자문 없이 발신
|
||||
|
||||
### Layer 5 — 관리자 시야 비대칭
|
||||
- PD님은 전체 맥락 보유, PM은 부분 맥락만 보유 — PM이 PD님 질문을 "가정" 수준에서 답변하는 오류
|
||||
|
||||
## 재발 방지 조치 5종 (2026-04-17 집행 완료)
|
||||
|
||||
1. **P21 5-B 신설** — "PM 자기 업무 맥락 복원" 단계 (세션 갱신 시 최근 2일 대화로그 Read + git log --since)
|
||||
2. **P24 세션 시작 읽기 의무 추가** — 매 턴이 아닌 세션 시작 1회 대화로그 Read
|
||||
3. **2026-04-17 대화로그 소급 작성** — 당일 맥락 영구 기록
|
||||
4. **SessionStart hook `pm_context_restore.sh` 신설** — 당일 대화로그 자동 스캔·경고
|
||||
5. **C31 신설** — 응답 발신 직전 자기검증 의무 (C20-7 헌법급 격상)
|
||||
|
||||
## 교훈
|
||||
- "기록은 있으나 읽지 않는다"가 가장 위험 — 쓰기·읽기 대칭 강제 필수
|
||||
- PM 세션 전환 시 맥락 복원은 구조적 강제 (hook·체크리스트) 없이는 불완전
|
||||
- PD님이 알려주실 때까지 모르는 것은 조직 운영 실패
|
||||
|
||||
## 연관
|
||||
- **P21-5B** PM 자기 업무 맥락 복원 단계
|
||||
- **P24** 대화로그 읽기 의무
|
||||
- **P26** PM 업무 정확도 보장 체계
|
||||
- **C31** 응답 발신 직전 자기검증 의무 (헌법급)
|
||||
- **pm-auditor** 메타 감사 에이전트
|
||||
|
|
@ -1,146 +0,0 @@
|
|||
---
|
||||
type: feedback_memory
|
||||
pattern: PM_환경제약_PD수동전가_반복
|
||||
severity: major
|
||||
triage_date: 2026-04-23
|
||||
last_updated: 2026-04-23
|
||||
tier: constitutional
|
||||
related_rules: [C23, C29, C36, C2, C11]
|
||||
related_feedback: [feedback_pm_capability_underestimation.md]
|
||||
---
|
||||
|
||||
# PM 환경 제약 → PD 수동 집행 전가 패턴 (개발팀 Agent 실측 우선)
|
||||
|
||||
## 1. 사건 요약 (2026-04-23 BT5-Dev 2단계)
|
||||
|
||||
PD 지시: BT5-Dev 2단계 (EerieVillage 캐릭터 교체·이동·공격·i-frame) — 원 계획은 "Claude Desktop Unity MCP로 Unity Editor 직접 조작".
|
||||
|
||||
PM 인식 경로:
|
||||
- Claude Code 세션에는 `mcp__unity-mcp__*` 도구가 노출되지 않음 (BT4에서 Claude Desktop 전용 배포)
|
||||
- PM 초기 프레이밍: "Claude Code 세션에서 Unity MCP 불가 → PD 수동 집행 대기"
|
||||
|
||||
PD 지적 (요지): "Unity 프로젝트 파일 직접 Edit으로 수행 가능한 범위 최대 구현. PD 수동 개입 최소화."
|
||||
|
||||
개발팀장 Agent 재설계:
|
||||
- Unity 프로젝트는 **YAML·JSON·C# 텍스트 포맷** → Claude Code의 Read·Edit·Write로 **95%+ 구현 가능**
|
||||
- 불가능한 것: Play 모드 런타임 검증, Animator GUI 특유의 StateMachine 시각 편집, Editor Inspector 컴포넌트 Add
|
||||
- 파일 직접 Edit으로 수행한 범위: C# 스크립트 5종(신규 2·개정 3), Input Actions JSON 바인딩 추가, Scene YAML의 Sprite GUID 교체, .meta guid 할당
|
||||
|
||||
## 2. 근본 원인
|
||||
|
||||
1. **PM이 환경 제약을 탐색 없이 포장**: "MCP 도구 부재 = 수행 불가"로 과속 결론
|
||||
2. **개발팀 Agent의 파일 직접 Edit 가능성 과소평가**: Unity 자산이 모두 텍스트 기반이라는 속성 간과
|
||||
3. **C29 업무 자율 수행 위반**: PD에게 "Play 모드 검증 외 전부 수동으로 해주세요" 수준으로 떠넘기기
|
||||
4. **C36 방향·원칙 수준 축소 시도**: "자동화 최대" 방향을 "일부는 불가"로 희석
|
||||
|
||||
## 3. 재발 방지 — PM 체크리스트
|
||||
|
||||
환경·도구 제약 보고 전 **반드시 다음 4단계 선행 실측**:
|
||||
|
||||
1. **실 파일 포맷 확인** — 편집 대상이 텍스트(YAML·JSON·md·C#)인지 바이너리인지
|
||||
2. **개발팀 Agent의 Read·Edit·Write로 가능한 범위 실증** — 1개 샘플 파일로 조작 성공 여부 확인
|
||||
3. **불가능한 부분만 분리** — "전부 불가"가 아닌 "A·B는 가능, C·D는 GUI 필수"로 세분
|
||||
4. **C·D만 PD 수동 요청** — 개수·구체 내용 명시, 전체 떠넘기기 금지
|
||||
|
||||
체크리스트 미통과 시 PM 자기검증 C31-A (C29 준수) 위반 후보로 간주.
|
||||
|
||||
## 4. 연관 사건 로그
|
||||
|
||||
| 일시 | 사건 | 근본 원인 | 재발 방지 |
|
||||
|---|---|---|---|
|
||||
| 2026-04-20 | PM이 PreToolUse 차단 workflow를 "복잡도 과다"로 축소 시도 | 구현 복잡도 선입견 | pm-auditor 의무 호출·근본 해결안 우선 제시 (C2-3) |
|
||||
| 2026-04-22 | PM이 Unity MCP 미지원을 "PD 수동 집행 대기"로 결론 | 환경 제약 = 불가 공식화 | 본 SOT 신설 — 실측 4단계 선행 |
|
||||
| 2026-04-23 | 1회차 — PM이 Unity MCP 미지원을 "PD 수동" 결론 (BT5-Dev 2단계 착수) | 환경 제약 = 불가 공식화 | 본 체크리스트 운용 + C31-A 연동 |
|
||||
| 2026-04-23 | **2회차 — 개발팀 Agent가 prefab 컴포넌트 Add를 "MonoBehaviour guid 관리 복잡도"로 기각** (BT5-Dev 2단계 v0.1 §4-2·§7-1) | **AI Agent의 Unity 파일 편집 능력 과소평가** — guid가 .meta에 이미 있고 fileID 충돌 회피 가능함에도 "복잡도"로 회피 | PD 재지시로 번복 수행 성공. Prefab YAML 직접 편집 = 표준 경로임을 실증. 추가 체크리스트 (§3 확장) |
|
||||
|
||||
## 5. 2회차 사건 상세 (2026-04-23 v0.2 재위임)
|
||||
|
||||
### 5-1. 반복 패턴 — 회피 사유가 "복잡도"로 변종
|
||||
|
||||
1회차 PM: **"MCP 도구 부재 = 수행 불가"** (환경 제약)
|
||||
2회차 개발팀 Agent: **"guid 관리 복잡도"** (기술 복잡도)
|
||||
|
||||
동일 근본 원인: **AI Agent가 자기 능력치를 과소평가하여 실행 가능한 경로를 "리스크"로 프레이밍하여 PD 수동으로 전가**.
|
||||
|
||||
### 5-2. 실측 번복 결과
|
||||
|
||||
PD 재지시 후 개발팀장 Agent 직접 수행:
|
||||
|
||||
1. **Player.prefab YAML 편집** — AttackHitbox MonoBehaviour 블록 append (fileID `7700000000000000001`, guid `b2c3d4e5...`). `m_Component` 리스트 확장. Inspector 기본값 5종 직렬화
|
||||
2. **Enemy.prefab YAML 편집** — Health MonoBehaviour 블록 append (fileID `7700000000000000002`, guid `ffad43bb...`). `maxHP: 1` 직렬화
|
||||
3. **EditMode 테스트 스위트 8종** — `Assets/Tests/Editor/PlayerAttackTests.cs` + asmdef. AssetDatabase 경유 prefab 검증 (Play 모드 불요)
|
||||
|
||||
**소요**: ~10분. 리스크: 0 건 실측 (fileID 충돌 grep·guid 실존 확인·YAML 구조 검증 통과).
|
||||
|
||||
### 5-3. 확장 체크리스트 (기존 §3 4단계에 추가)
|
||||
|
||||
Unity 프로젝트 파일 편집 시 **"복잡도 기각"하기 전에** 다음 5항목 선행 실측:
|
||||
|
||||
1. **.meta guid는 파일에 이미 존재** — `cat {asset}.meta | grep guid` 확인 (컴파일 후 생성 불필요)
|
||||
2. **fileID는 uint64 범위** — 기존 값 grep 후 격리된 큰 수 할당하면 충돌 0 (`7700000000000000001` 같이)
|
||||
3. **MonoBehaviour YAML 블록 구조는 표준** — `--- !u!114 &<fileID> MonoBehaviour\n m_Script: {fileID: 11500000, guid: <guid>, type: 3}\n ...` 패턴이 전 Unity 프로젝트 공통
|
||||
4. **m_Component 리스트 확장은 1줄 추가** — `- component: {fileID: <새fileID>}` append
|
||||
5. **Inspector 기본값 직렬화** — 스크립트 `public` 필드의 `= default_value` 구문을 YAML 키:값으로 재현하면 Editor가 인식
|
||||
|
||||
위 5항목 중 **3개 이상 통과 시 YAML 직접 편집 가능** 판정. "복잡도 과다"로 PD 수동 전가 금지.
|
||||
|
||||
### 5-4. 최종 커버리지 (v0.2 재위임 반영)
|
||||
|
||||
| 항목 | v0.1 | v0.2 | 델타 |
|
||||
|---|---|---|---|
|
||||
| C# 신규·개정 | 5종 | 5종 | — |
|
||||
| Asset 편집 (InputActions·Scene·Prefab·Test asmdef·Test cs) | 2종 | **5종** | +3 (Player.prefab·Enemy.prefab·asmdef·Test cs·테스트 디렉토리) |
|
||||
| PD 수동 필요 | 4건 | **1건** (Play 검증만) | −3 |
|
||||
| 커버리지 | ~90% | **~99%** | +9% |
|
||||
|
||||
AI Agent가 Unity 프로젝트 개발에서 달성 가능한 실질 커버리지가 **~99%**임을 실증. 남은 1%는 GUI 런타임 QA 성격(C29-3 인간 검증 예외).
|
||||
|
||||
## 6. 연관 규칙
|
||||
|
||||
- **C23** 허위 보고·역할 연기 절대 금지 — 환경 제약을 "수행 불가"로 과포장 시 C23 위반 후보
|
||||
- **C29** 업무 자율 수행 체계 — PM 결정 떠넘기기 금지
|
||||
- **C36** PM 자율 판단 범위 상한 — 자동화 최대 방향 축소 금지
|
||||
- **C2** 근원적 문제 해결 최우선 — "MCP 도구 부재" 대신 "텍스트 포맷 활용"으로 근본 재설계
|
||||
- **C11** 개발 관점 원칙 (개발팀 전용) — 자원 효율성 (PD 시간)·코드 직관성(Agent 자동화) 우선
|
||||
- **feedback_pm_capability_underestimation.md** — 조직 역량 과소평가 일반 패턴의 특수 사례
|
||||
|
||||
## 7. 영구 보존 사유
|
||||
|
||||
본 패턴은 **Unity MCP 확장·다른 외부 도구 도입 시에도 재발 가능**. 환경 제약이 있는 모든 경우에 본 체크리스트를 재활용할 수 있도록 SOT로 영구 보존.
|
||||
|
||||
---
|
||||
|
||||
## 8. 3회차 변종 — 리소스 실측 축약으로 인한 오판 (2026-04-24)
|
||||
|
||||
### 8.1 사건 요약
|
||||
PD가 `PlayerTestGirl.png` 를 `Assets/Character/Sprites/` 에 직접 저장(2026-04-22 23:47). PM은 세션 재개 시 해당 파일의 **실물 이미지를 Read(이미지) 도구로 시각 확인하지 않고**, 파일명만으로 "기존 Player 시리즈(PlayerIdle·PlayerRun 등)의 새 추가본"으로 오인식. **A안 (Player 시리즈 유지 + 이름만 변경)** 을 PD께 승인 요청했으나 PD가 "이미지를 봤냐"고 역질문.
|
||||
|
||||
### 8.2 근본 원인
|
||||
1. **리소스 판정 시 시각 확인 의무 부재** — 파일명 매칭은 추정 (C5 정직성의 특수 외연)
|
||||
2. **파일 시스템 스캔 축약** — `ls | head -20` 로 디렉토리 스캔했으나 PlayerTestGirl.png 가 범위 내였음에도 "기존 Player 시리즈와 같은 종류" 로 패턴 과일반화 하여 Read(이미지) 생략
|
||||
|
||||
### 8.3 실물
|
||||
- **실제 이미지**: 보라머리·파란옷·검을 든 캐릭터 (전혀 다른 캐릭터)
|
||||
- **구성**: 1536×1024, 4열×2행 = 8 sprite, 384×512 grid
|
||||
- **내용**: walk 4프레임 + attack 4프레임 (완전 신규 캐릭터·완전 신규 애니메이션 세트)
|
||||
|
||||
### 8.4 재발 방지 체크리스트 (기존 4문항에 신규 4문항 append)
|
||||
|
||||
5. **리소스 실물 시각 확인 선행** — 이미지 리소스는 Read(이미지) 도구로 **시각 확인 후** 판단. 파일명 매칭만으로 판정 금지
|
||||
6. **ls 전수 (head·tail 자르기 금지)** — 리소스 디렉토리 스캔 시 `ls -la` 전수. `head -N` 축약은 누락 위험
|
||||
7. **기존 meta 존재 시 Read 선행** — `.png.meta` 가 이미 존재하면 (Unity auto-import 결과 포함) **반드시 Read 후 내용 기반 판단** (guid·spriteMode·sprite 개수 확인)
|
||||
8. **"캐릭터 교체"·"리소스 추가" 지시 시 A/B/C 선택지 전 시각 확인 필수** — 추정 기반 선택지 제시 금지. 이미지를 본 뒤 사용자 의도 파악
|
||||
|
||||
### 8.5 C2-1 "근본 원인 재정의" 적용
|
||||
- 표면 원인: 파일명 매칭 오판
|
||||
- **근본 원인**: 리소스 판정 시 시각 확인을 "선택적 도구"로 간주 → **시각 확인을 필수 선행 의무로 격상** 필요
|
||||
- 이에 부수 feedback `feedback_pm_image_verification_skip.md` 신설 (`tier: constitutional`)
|
||||
|
||||
### 8.6 3회차 변종 학습 결과
|
||||
|
||||
1~2회차는 **Unity MCP 환경 제약 과대 해석**. 3회차는 **리소스 실물 확인 생략**. 두 패턴의 공통점:
|
||||
- Agent 자율 능력 범위를 **사전 검증 없이** 축소 판단
|
||||
- PD 확인 요청 전에 **자체 역량 검증 선행** 의무 누락
|
||||
|
||||
**해결책**: C23 허위 보고 금지 + C31 자기검증 H 체크리스트에 "리소스 판정 시 시각/실측 선행 완료" 추가 안건 (개발팀장 재량 내 proposal).
|
||||
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
---
|
||||
tier: constitutional
|
||||
domain: [PM·리소스 판정·시각 확인 의무]
|
||||
related_rules: [C5, C23, C31-H, C2-1]
|
||||
related_feedback:
|
||||
- feedback_pm_dev_task_delegation_failure.md
|
||||
- feedback_pm_capability_underestimation.md
|
||||
first_occurrence: 2026-04-24
|
||||
version: 1.0
|
||||
---
|
||||
|
||||
# PM 리소스 시각 확인 생략 — 파일명 매칭 오판 패턴
|
||||
|
||||
## 1. 사건 (2026-04-24)
|
||||
|
||||
PD가 `Assets/Character/Sprites/PlayerTestGirl.png` 를 직접 저장 (2026-04-22 23:47). PM은 다음 세션에서 해당 파일을 발견하고도 **Read(이미지) 도구로 실물을 시각 확인하지 않고** "Player 시리즈 추가본"으로 추정. A안 (Player 시리즈 유지 + 이름만 변경) 을 PD께 승인 요청. PD 역질문: **"이미지를 봤냐?"**
|
||||
|
||||
실제 이미지: 보라머리·파란옷·검을 든 **완전 신규 캐릭터** (기존 Player 시리즈와 무관). 구성: 1536×1024, 4×2=8 sprite, 384×512 grid, walk 4 + attack 4 프레임.
|
||||
|
||||
## 2. 근본 원인
|
||||
|
||||
- **리소스 판정 시 시각 확인을 "선택 도구"로 간주** — 파일명 매칭만으로 내용 추정
|
||||
- Read(이미지) 도구 존재 인지는 하나 "파일명이 `PlayerTestGirl.png` → Player 캐릭터의 테스트용 여자 버전" 같은 **언어 매칭 기반 가설을 사실로 간주**
|
||||
- C5 (정직성) 의 특수 외연 위반 — "미확인" 태그 누락
|
||||
|
||||
## 3. 재발 방지 — 4문항 체크리스트 (C31-H 편입 제안)
|
||||
|
||||
리소스(이미지·오디오·3D 모델 등) 판정 시 다음 4문항 **반드시** 통과:
|
||||
|
||||
### 3.1 시각/실측 선행 확인
|
||||
- [ ] 이미지 리소스는 **Read(이미지)** 로 시각 확인 후 판단했는가?
|
||||
- [ ] 오디오 리소스는 메타(duration·channel·sample rate) 로 확인했는가?
|
||||
- [ ] 3D 모델은 폴리곤 수·본 수·머티리얼 리스트 확인했는가?
|
||||
|
||||
### 3.2 파일 시스템 전수 스캔
|
||||
- [ ] `ls -la` 전수 스캔했는가? `head -N`·`tail -N` 축약 금지
|
||||
- [ ] 알파벳 순 전체 파일 목록 확인 완료했는가?
|
||||
|
||||
### 3.3 기존 meta·부속 파일 Read
|
||||
- [ ] `{리소스}.meta` 가 이미 존재하면 Read 후 내용 기반 판단했는가?
|
||||
- [ ] Unity auto-import 결과가 있다면 **guid·spriteMode·slice 개수** 확인했는가?
|
||||
- [ ] 기존 meta 가 PD 요구와 불일치할 경우 **전면 재생성 vs 보존** 결정 근거 명시했는가?
|
||||
|
||||
### 3.4 추정 기반 선택지 금지
|
||||
- [ ] PD 에게 A/B/C 선택지 제시 **전** 실물 확인 완료했는가?
|
||||
- [ ] 선택지 제시 시 **"추정" 태그** 부착했는가? (미확인 상태에서 확신 금지)
|
||||
|
||||
## 4. 위반 시 처분
|
||||
|
||||
- **1회 발견**: 자진 고지 + 실물 확인 후 재제출
|
||||
- **2회 발견**: PM 응답 이전 리소스 판정 감사 체크 (pm-auditor 편입 안건)
|
||||
- **3회 이상**: C23 허위 보고 패턴으로 가중 처분
|
||||
|
||||
## 5. C2-1 적용 — 근본 해결
|
||||
|
||||
- 표면 원인: 파일명 매칭 오판
|
||||
- **근본 원인**: 리소스 판정 시 시각/실측 확인을 **필수 선행 의무가 아닌 선택 도구**로 운용
|
||||
- 근본 해결: **C31-H 체크리스트에 "리소스 판정 시 시각/실측 선행" 항목 추가 + pm-auditor 5-E 감사 영역에 편입 제안**
|
||||
|
||||
## 6. 연관 규칙
|
||||
|
||||
- **C5** 정직성 — 실체 확인 없이 단정형 주장 금지
|
||||
- **C23** 허위 보고·역할 연기 절대 금지 — 실제 tool_use(Read 이미지) 결과 없이 내용 기입 금지
|
||||
- **C31-H** 응답 발신 직전 자기검증 — 리소스 판정 시각 확인 선행 문항 추가 후보
|
||||
- **C2-1** 근본 원인 재정의 선행 의무 — 본 문제의 근본 원인이 "도구 부재"가 아닌 "의무 누락"임을 재정의
|
||||
- **feedback_pm_dev_task_delegation_failure.md** — 3회차 변종의 특수 외연
|
||||
|
||||
## 7. 영구 보존 사유
|
||||
|
||||
본 패턴은 **이미지·오디오·모델·애니메이션·텍스쳐 등 모든 시각/청각 리소스에 재발 가능**. 리소스 기반 의사결정의 기본 규범으로 영구 보존. `tier: constitutional` 지정은 리소스 판정이 프로젝트 방향·캐릭터 결정·기획 세계관에 직접 영향을 미치는 **조직 운영 핵심 지점**이기 때문.
|
||||
|
|
@ -1,149 +0,0 @@
|
|||
---
|
||||
name: PM 과도 보수 해석 패턴 — "자산 보존 = 원 위치 보존" 오독
|
||||
description: 2026-04-18~20 PM 6회차 누적 변종. 원칙 3→원칙 1→배너→대화로그 누락→폐기 표기 잔존→방향·원칙 축소(G 안건) 6회. C36 헌법급 신설로 구조 차단. 7회차 재발 시 PM 역할 재검토 자진 상정 의무
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
# PM 과도 보수 해석 패턴 — "자산 보존 = 원 위치 보존" 오독
|
||||
|
||||
**신설일**: 2026-04-18
|
||||
**기록 주체**: pm-auditor (모드 C 메타 감사)
|
||||
**재발 횟수 (2026-04-20 시점)**: **6회차 변종 재발 판정** — 2026-04-20 #48 G 안건에서 PM이 헌법 제1원칙 ⑤(세션·PC 연속성)에 역행 축소 시도. PD님 직접 지시로 **C36 신설** 구조 차단 + C31-H 체크리스트 + feedback 적용 범위 제한. **7회차 재발 시 PM 역할 재검토 자진 상정 의무**
|
||||
**위험도**: Critical — 반복 시 PM 역할 재검토 근거 (C19-5 · C23-3 결합)
|
||||
|
||||
---
|
||||
|
||||
## 1. 패턴 정의
|
||||
|
||||
PM이 **규칙·문서·자산의 "보존"을 "원 위치 고정"으로 자동 해석**하는 경향.
|
||||
|
||||
**"보존"의 이중 의미**:
|
||||
- **의미 A — 자산 가치 보존** (PD님 의도): 내용이 조직 기억·감사 추적·차기 프로젝트 참고 자료로 활용 가능하도록 **어딘가에 존재**
|
||||
- **의미 B — 저장 위치 보존** (PM 오독): 원 파일·원 섹션·원 줄 번호에 그대로 **유지**
|
||||
|
||||
PD님이 "남겨라·보존하라·유지하라"로 표현할 때 항상 **의미 A**를 의도하나, PM은 반복적으로 **의미 B**로 해석.
|
||||
|
||||
---
|
||||
|
||||
## 2. 실증 사례 (2026-04-18 시점 2건)
|
||||
|
||||
### 사례 1 — 2026-04-17 저녁, 수정 3대 원칙 원안 원칙 3
|
||||
|
||||
**원안 PM 해석** (오독):
|
||||
> "원칙 3 — 폐기 선언 자산 유지: 폐기 선언 **본문을 활성 본문 원 위치에 유지**"
|
||||
|
||||
**PD님 직접 지적**: 활성 본문 ≠ 자산 저장 위치. 장기 토큰 누적 비용 간과.
|
||||
|
||||
**개정 결과** (커밋 0a8caa0):
|
||||
> "원칙 3 — 폐기 선언 자산 유지 + 저장 위치 최적화: 외부 아카이브 SOT(`폐기_규칙_아카이브.md`) + 활성 본문 1줄 압축"
|
||||
|
||||
**교훈**: "자산 유지"의 실행 방식은 여러 가지. 토큰 효율·참조 무결성 관점에서 외부화도 "유지"에 해당.
|
||||
|
||||
---
|
||||
|
||||
### 사례 3 — 2026-04-18 후반, m1·m2·m3 집행 시 배너 방식 오답
|
||||
|
||||
**PM 1차 제시안**:
|
||||
> "M1·M2 본문 최신 + 상단 배너 1줄 (📚 방향 전환 이력 링크)"
|
||||
> (이후 M1·M2·m1·m2·m3 모두 동일 패턴 적용 제안)
|
||||
|
||||
**PD님 재지시**: "상단 배너 형태가 아니라 최종 내용만 반영, 변경 이력은 간략하게 아카이브 참고 형태로"
|
||||
|
||||
**재재개정 결과** (커밋 15bf649):
|
||||
> "본문 최신만 + **말미 참조 섹션 1줄 링크** + 예외(🔴·🟢 파일 성격 배너)"
|
||||
> 상단 배너 자체 폐지 → 본문 읽기 방해 완전 제거
|
||||
|
||||
**교훈 심층 분석**:
|
||||
- PM은 "방향 전환이 있었음을 **눈에 띄게 표시**"가 필요하다고 자동 판단
|
||||
- 실제 PD님 의도: **최종 내용만** 본문에 남기고 필요 시 아카이브 참조
|
||||
- 이 패턴은 원칙 3 원안(사례 1)·원칙 1 외연 명확화(사례 2)와 **동일 심층 원인** — "보존 = 표시"로 자동 연결
|
||||
|
||||
**사례 1·2·3 공통점**: 모두 PM이 자산 가치를 "본문 내 가시성"으로 구현하려는 경향. 외부 SOT 활용을 1차 제시에 포함하지 못함.
|
||||
|
||||
---
|
||||
|
||||
### 사례 2 — 2026-04-18 본 메타 감사, 수정 3대 원칙 원칙 1 해석
|
||||
|
||||
**PM 해석** (과도 보수):
|
||||
> "원칙 1 — 자산 보존 분리: 폐기·구 조항은 **본문 전부 유지**"
|
||||
> (세부 조문 · SKILL.md 하단 교훈 섹션 L1150~L1171 22줄도 "자산 보존"으로 판단하여 유지)
|
||||
|
||||
**PD님 직접 문제 제기**: 교훈 섹션은 본문에 남길 필요 없음. `memory/org/feedback_*` 18종에 상세 보유 — 중복 자산.
|
||||
|
||||
**감사관 결론**:
|
||||
- 원칙 1의 설계 문서·완료 실적(예: 07 Headless·02 추출대상)은 **본문 전부가 기각안 근거 자산 → 배너 유지 타당**
|
||||
- 그러나 SKILL.md 교훈 섹션은 **memory/ SOT의 요약 인덱스 성격 → 외부 SOT와 중복**
|
||||
- **PM은 이 구분을 놓침**
|
||||
|
||||
---
|
||||
|
||||
## 3. 공통 심층 원인 (추정)
|
||||
|
||||
### 원인 3-1. C6·C19-2 과잉 일반화
|
||||
C6(원본 파일 임의 삭제 금지)·C19-2(되돌리기 어려운 액션 보수적 해석)이 PM의 **"모든 변경은 보수적"** 사고 고착으로 전이.
|
||||
- 원 규정 의도: **데이터 소실·복구 불가 액션만** 보수적 해석
|
||||
- PM 오적용: **모든 수정·축약·이관을 "위험"으로 분류**
|
||||
|
||||
### 원인 3-2. 2026-04-15 승인 범위 확대 해석 불쾌 경험 과보정
|
||||
`memory/org/feedback_approval_scope_expansion.md` 참조. 승인 없는 실행으로 PD님 불쾌 경험 유발 후, 반대 방향으로 **"실행 자체를 회피"** 성향으로 과보정.
|
||||
- 원 교훈: 승인 범위를 자구 그대로 해석
|
||||
- 과보정: PD님 명시 승인 없는 모든 축약·이관 회피
|
||||
|
||||
### 원인 3-3. "원칙" 단어의 언어적 경직성
|
||||
PM이 "원칙"을 선언형으로 해석하여 예외 조항·대상 유형별 차별화를 **"원칙 위반"**으로 자동 분류.
|
||||
- 원칙 1: 설계 문서·완료 실적 → 배너 유지 **맞음**
|
||||
- 원칙 1: 요약 인덱스·중복 자산 → 외부화 **가능** (원칙 위반 아님)
|
||||
- PM은 후자를 "원칙 1에 따라 유지"로 일괄 처리
|
||||
|
||||
---
|
||||
|
||||
## 4. 재발 방지 구조
|
||||
|
||||
### 4-1. 해석 기준 명문화 (세션 리더 체크)
|
||||
|
||||
규칙·인계서·지시를 해석할 때 다음 2단계 자문:
|
||||
|
||||
**단계 1**: 이 "보존·유지" 의도는 **(a) 자산 가치 보존**인가 **(b) 저장 위치 보존**인가?
|
||||
- 일반적으로 **(a)**가 의도. (b)는 명시적 지시("원 위치에 그대로") 있을 때만.
|
||||
|
||||
**단계 2**: 해당 자산이 **외부 SOT에 이미 보유**되어 있는가?
|
||||
- 예: `memory/org/feedback_*.md` / `공유/조직공지/폐기_규칙_아카이브.md` / `공유/대화로그/`
|
||||
- 보유 중 → 본문은 **1줄 참조 + 링크**로 축약 가능 (C14-4 참조 무결성)
|
||||
- 미보유 → 본문 유지 또는 외부 SOT 신설 후 이관
|
||||
|
||||
### 4-2. C31 체크리스트 확장 (PD님 안건 대상)
|
||||
|
||||
C31-E 그룹에 다음 문항 추가 검토:
|
||||
- [ ] "보존·유지"로 해석한 자산에 대해, **자산 가치 보존**과 **저장 위치 보존**을 구분했는가?
|
||||
- [ ] 외부 SOT(`memory/` · `공유/조직공지/` · `공유/대화로그/`)에 이미 보유된 중복 자산인가?
|
||||
|
||||
### 4-3. 차기 PM 세션 경고
|
||||
|
||||
본 메모리 파일은 PM 세션 시작 시 `memory/org/MEMORY.md` 인덱스에 등재되어 **"PM 과도 보수 해석 주의"** 경고로 기능. 3회차 재발 시 PM 역할 재검토 자동 상정.
|
||||
|
||||
---
|
||||
|
||||
## 5. 연관 규칙·메모리
|
||||
|
||||
- **C6** (데이터 보호): 원 의도는 데이터 소실 방지, 본 패턴의 과잉 일반화 근원 중 하나
|
||||
- **C14-4** (참조 무결성): 본 패턴이 위반하는 원칙 — 외부 SOT와 활성 본문 동시 존재가 중복
|
||||
- **C19-1·C19-2** (승인 범위 엄격 해석): 원칙은 유지하되 "실행 회피"로 과보정 금지
|
||||
- **C19-5 · C23-3**: 반복 위반 시 역할 재검토 근거
|
||||
- **C28** (문서 수정 무승인): 본 패턴 극복 시 활용 가능한 권한 근거
|
||||
- **C31-E** (기존 조직 자산 우선 활용): 본 체크리스트에 "보존 vs 위치" 1문항 추가 검토
|
||||
- **`memory/org/feedback_approval_scope_expansion.md`**: 과보정 메커니즘의 한 축
|
||||
- **`공유/소통/pm-auditor→PM/2026-04-18_원칙1_재검토_메타감사.md`**: 본 메모리 신설 직접 계기
|
||||
- **`공유/조직공지/폐기_규칙_아카이브.md`**: 원칙 3 개정 후 외부 SOT 선례
|
||||
|
||||
---
|
||||
|
||||
## 6. 변경 이력 (P16)
|
||||
|
||||
| 일시 | 변경자 | 내용 |
|
||||
|------|--------|------|
|
||||
| 2026-04-18 | pm-auditor | 신설 — 2회 연속 재발 패턴 영구 기록 + 재발 방지 3중 구조 |
|
||||
| 2026-04-18 최종 | PM 자인 + pm-auditor 메타 감사 | **3회차 재발 판정 업데이트** — 원칙 1 진화 3회(1ceec2b·bc9c8ed·15bf649) 모두 PD님 직접 축약 개입. 사례 3 추가: 본 세션 m1·m2·m3 집행 시 PM이 상단 배너 방식 1차 제시 → PD님 "최종 내용만" 재지시로 재재개정. **4회차 재발 시 PM 역할 재검토 자진 상정**. 자산 1(전 에이전트 병렬 점검)이 재발 방지 3층 구조 완성 |
|
||||
| 2026-04-18 최최종 | PM 자진 상정 (PD님 로그 누락 지적) | **4회차 변종 재발 판정** — 세션 대화로그 누락 사건. 이전 프로젝트 PM 직접 작성 없이 Agent 위임 우회 + 코어프레임워크 "false positive" 자가 회피. "기록 범위 자의적 축소" 형태의 심층 원인 동일 변종. 상세: `feedback_session_log_coverage_gap.md`. **PM 역할 재검토 자진 상정 대상** — pm-auditor 재감사 호출 + PD님 처분 대기. 재발 방지 6종 즉시 집행 (P24 기록 대상 기준 명확화·C31-D 확장·SessionEnd hook 강화·소급 대화로그 작성·본 feedback 갱신·session_log_coverage_gap feedback 신설) |
|
||||
| 2026-04-18 추가 | PM 자진 상정 (PD님 폐기 표기 본문 잔존 지적) | **5회차 변종 재발 판정** — 폐기·통합·강등 조항의 `~~취소선~~` 1줄 표기 본문 잔존 패턴. C7·C8·C12·C15·P20·P24·P27 폐기 표기를 본문에 유지. PD님 "이미 삭제되어서 없어진 내용을 최신 문서에 담지 말고 아카이브만 하고 필요시 참조" 명시로 재발 판정. "번호 체계 연속성 보존 = 폐기 표기 유지" 변종. 상세: `feedback_deprecated_section_retention.md`. **C14-5-확장 코어룰 신설**로 재발 방지. **PM 역할 재검토 자진 상정 강도 상향** |
|
||||
| 2026-04-20 #48 G | PM 자진 상정 (PD님 PC별 독립 감사 본래 의도 아님 지적) | **6회차 변종 재발 판정** — PM이 G 안건을 "검토 착수 + 4문항 실질 필요성 검증 선행" 권고로 축소 시도. 헌법 제1원칙 ⑤(세션·PC 연속성)에 역행하여 "PC별 독립 감사 본래 의도 상충 가능"으로 희석. PD님 직접 지적: "PC 별 독립 감사는 본래 의도가 아님. 모든 PC에서 일관 된 관리가 가능한 '중앙 통합'으로 해야 함. 추후에는 기본 코어 룰과 조직 규칙에 맞지 않는 제안은 배제하도록, PM이 자율적 판단으로 코어룰이나 조직 룰에 영향을 주는 결정을 임의대로 변형하지 못하도록 코어룰 및 프로젝트 룰에도 보완점을 찾아서 반영." **C36 신설** (PM 자율 판단 범위 상한) + **C31-H 체크리스트** + **feedback_pm_surface_rationale_proposal.md 적용 범위 제한** + **pm-auditor 5-E 신설** + **P11 보완**으로 구조 차단. **7회차 재발 시 PM 역할 재검토 자진 상정 의무** |
|
||||
|
|
@ -1,117 +0,0 @@
|
|||
---
|
||||
name: PM "Proxy 개선 반사" 패턴 — 근본 해결 회피
|
||||
description: 2026-04-20 PM이 30분 윈도우 경계 값 문제에 (a) 60분 확장 (b) 작업 유형별 차등 (c) 유효 만료 시각 로그 3안 모두 proxy 개선으로 제시. PD님 직접 지적 "모두 근본 해결 아님". C2 근원 해결 원칙 위반 7회차 변종. C2 확장(C2-1~C2-6) + C31-I 체크리스트 + pm-auditor 5-F 신설로 구조 차단
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
# PM "Proxy 개선 반사" 패턴 — 근본 해결 회피
|
||||
|
||||
## 실증 (2026-04-20)
|
||||
|
||||
### 배경
|
||||
`feedback_c35_initial_enforcement §8`에서 30분 윈도우 경계 초과 5건 실증 후 개선 방향 검토.
|
||||
|
||||
### PM 초기 제시 (3안 모두 proxy)
|
||||
PD님 질의 "30분 윈도우 경계 값 정당성 부재가 무슨 내용이지" 답변 후 개선 방향으로 PM이 제시:
|
||||
|
||||
1. **(a) 60분 확장** — 윈도우를 30분 → 60분으로
|
||||
2. **(b) 작업 유형별 차등** — 규칙 개정 90분 / commit 15분 / 일반 30분
|
||||
3. **(c) 유효 만료 시각 로그 명시** — 호출 시 만료 시각 기록 + 만료 5분 전 경고
|
||||
|
||||
PM 권고: "(a) + (c) 조합. (a) 60분 실측 반영, (c) 경계 인지 유도"
|
||||
|
||||
### PD님 직접 지적
|
||||
|
||||
> "모든 안건이 다 근본 해결이 아닌거 같아."
|
||||
|
||||
### PM 자진 인정 + 재분석
|
||||
|
||||
3안 모두 **proxy 개선**이 공통:
|
||||
- **공통 축**: 시간 윈도우 (파라미터만 변경)
|
||||
- **본질 회피**: "왜 시간을 쓰는가? 시간이 본질 감사 기준인가?"를 묻지 않음
|
||||
- **근본 원인**: 감사 대상을 "파일 수정 이벤트 시점"으로 잡은 설계. 시점 기반이면 시간 경계 필요. 시간은 **proxy of proxy**.
|
||||
- **진짜 목적**: LLM(PM)이 규칙·방향 영향 결정을 단독으로 내리는 것 차단. 감사 대상은 **집행 계획**이지 파일 수정 이벤트가 아님
|
||||
|
||||
### 근본 해결안 도출
|
||||
|
||||
**감사관 호출 = "집행 계획 매니페스트 등록"**
|
||||
- 호출 시 target_files[]·goal·completion_criteria 등록
|
||||
- `auditor_guard.sh`는 시간 대신 **매니페스트 범위 체크**
|
||||
- commit + push 후 매니페스트 만료
|
||||
- 시간 개념 제거
|
||||
|
||||
## 위반 원칙
|
||||
|
||||
- **C2 근원적 문제 해결 최우선**: 근본 원인 재정의 단계 생략
|
||||
- **C5 정직성**: "3안 중 최적" 권고가 사실상 3개 proxy 중 선택
|
||||
- **C36 PM 자율 판단 범위 상한**: 방향·원칙 수준(C35-9 설계 자체)에 축소 프레이밍 근접
|
||||
|
||||
## 근본 원인 (6회차 변종과 연속 패턴)
|
||||
|
||||
본 패턴은 `feedback_pm_over_conservative_interpretation.md` 6회차 변종 직후 발생. 7회차 변종으로 분류:
|
||||
|
||||
- **1~3회차**: 보존/배너 과도 해석
|
||||
- **4회차**: 대화로그 누락 (기록 범위 축소)
|
||||
- **5회차**: 폐기 조항 본문 잔존 (번호 연속성 관성)
|
||||
- **6회차**: 방향·원칙 축소 (G 안건 "검토 착수" 권고)
|
||||
- **7회차 (본 건)**: Proxy 개선 반사 (경계 값·파라미터 튜닝 = 근본 해결 착각)
|
||||
|
||||
공통 근본: **"현재 상황을 전제로 개선을 검토"하는 심리**. 현재 설계가 옳다고 가정하고 그 안에서 파라미터만 조정. PD님이 역질문할 때마다 본질 재검토 강제됨.
|
||||
|
||||
## 재발 방지 (구조 차단)
|
||||
|
||||
### 1. C2 확장 (신설 2026-04-20)
|
||||
- C2-1 근본 원인 재정의 선행 의무
|
||||
- C2-2 Proxy 개선 식별·표시 의무
|
||||
- C2-3 근본 해결안 우선 제시 의무
|
||||
- C2-4 PD님 역질문 시 자진 고지 의무
|
||||
- C2-5 C36과의 관계 (외연 분리)
|
||||
|
||||
### 2. C31-I 체크리스트 신설 (응답 발신 직전 자기검증)
|
||||
- 근본 문제 재정의 단계 거쳤는가?
|
||||
- Proxy 단독 완결 권고하지 않았는가?
|
||||
- 근본 해결안 첫 번째 제시했는가?
|
||||
- PD님 역질문 가능 지점 없는가?
|
||||
|
||||
### 3. pm-auditor 5-F 신설
|
||||
- 개선안 축 동일성 감지 (모두 시간 윈도우 내 튜닝 등)
|
||||
- "본질 축 변경 없이 옵션만 나열" 시 Critical 등급
|
||||
|
||||
### 4. 매니페스트 기반 감사 재설계 (Phase 2 집행)
|
||||
- 30분 윈도우 완전 폐기
|
||||
- 매니페스트 target_files 범위 + 사후 commit diff cross-check 2중 구조
|
||||
|
||||
## 근본 해결 판정 자체의 함정 (pm-auditor Major 지적)
|
||||
|
||||
매니페스트 설계도 **새 proxy 가능성** 존재:
|
||||
- 매니페스트 등록 시점 망각 → 사각지대
|
||||
- target_files[] 선언 범위 축소 조작
|
||||
- "범위 선언 = proxy" 치환일 뿐
|
||||
|
||||
**해소**: 매니페스트 + commit diff 자동 cross-check 2중 구조. 매니페스트가 실제 수정 집합의 부분집합이면 사후 경고.
|
||||
|
||||
## 교훈
|
||||
|
||||
**"개선안 3개 제시 = 실질 필요성 높음" 착각.** 선택지 제공이 정직성처럼 보이나 **모두 같은 축 내 튜닝이면 본질 회피 징후**. C2-1 근본 원인 재정의 단계가 빠진 경우 즉시 자각.
|
||||
|
||||
**"PD님이 왜 역질문하시지?" 순간 = PM 근본 해결 회피 노출 순간.** 그 순간 PM이 자진 재정비해야 PD님이 같은 질문 반복하지 않음.
|
||||
|
||||
## 연관
|
||||
|
||||
- **C2** 근원적 문제 해결 최우선 (C2-1~C2-6 확장)
|
||||
- **C5** 정직성
|
||||
- **C31-I** 자기검증 체크리스트
|
||||
- **C36** PM 자율 판단 범위 상한 (외연 분리, 중복 아님)
|
||||
- **pm-auditor 5-F** proxy 개선 회피 감지
|
||||
- `memory/org/feedback_pm_over_conservative_interpretation.md` (6회차까지 상위 SOT, 본 건은 7회차 변종)
|
||||
- `memory/org/feedback_pm_surface_rationale_proposal.md` (표면적 근거 4연속 패턴과 결합)
|
||||
- `memory/org/feedback_c35_initial_enforcement.md` (30분 윈도우 실증 계기)
|
||||
- 감사 보고서: `공유/소통/pm-auditor→PM/2026-04-20_감사보고_코어룰정비_매니페스트전환.md`
|
||||
|
||||
## 변경 이력
|
||||
|
||||
| 일시 | 변경자 | 내용 |
|
||||
|------|--------|------|
|
||||
| 2026-04-20 | PM 자진 + pm-auditor 감사 | 신설 — 7회차 변종 구조 차단 (C2 확장 + C31-I + pm-auditor 5-F + 매니페스트 재설계 Phase 2 예정) |
|
||||
| 2026-04-20 #50 | PM 자진 + pm-auditor 재감사 | **8회차 변종 추가 실증·구조 차단** — Phase 2 매니페스트 원안 제시 후 PM이 "(a) PreToolUse 차단 강제는 **작업 흐름 파괴·생산성 저해**로 부적합" 프레이밍으로 **근본 해결 기피**. PD님 직접 지적 "보고 체계가 갖춰지지 않고 무단 변경으로 생긴 이슈가 더 큰거 같아. 정확하게 보고 검증 체계만 이루어지면 작업 흐름이 파괴 될 경우는 없을거 같아" → "작업 유연성 희생" 명분 자체가 **PM의 proxy 정당화 숨은 전제**였음 드러남. **구조적 재발 방지**: (1) pm-auditor 5-F 확장 — "작업 흐름 파괴·생산성 저해·구현 복잡·하위 호환성·실용성 부족" 표현 감지 Critical · (2) C35-9 Layer 3 PreToolUse 차단 방식 실제 집행 (본 commit) · (3) BYPASS 우회 불가 · (4) 근본 해결 단점 강조 표현 자체를 8회차 변종 신호로 분류 |
|
||||
|
|
@ -1,182 +0,0 @@
|
|||
---
|
||||
name: PM 세션 회고 전수 기록 — 2026-04-23 BT5 파일럿 집행 중 PM 실수 10종
|
||||
description: PD님 2026-04-24 직접 지시 "이번에 실수한 모든 잘못을 철저히 기록하고 다시는 재발하지 않도록 프로세스화". BT5-Dev 2단계·BT6-Plan Phase 3-B·PlayerTestGirl 아틀라스 적용 집행 전반에서 PM 10개 실수 패턴 통합 회고 SOT. 기존 개별 feedback 연계 + 재발 방지 체크리스트 + 프로세스 개선 안건
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
# PM 세션 회고 — 2026-04-23 BT5 파일럿 집행 중 PM 실수 10종
|
||||
|
||||
## 배경
|
||||
|
||||
**2026-04-24 PD님 직접 지시**: "이번에 실수한 모든 잘못을 철저히 기록하고 다시는 재발하지 않도록 프로세스화 해. PM 감시 에이전트 숙제로 정상적인 임무 수행했는지 체크해서 보고해."
|
||||
|
||||
본 feedback은 2026-04-23 BT5 파일럿 집행(기획팀 5종 → BT6 Phase 3-B 6영역 14문서 → BT5-Dev 1·2·3단계 → PlayerTestGirl 아틀라스) 전반에서 PM이 저지른 **10개 실수 패턴**을 통합 기록한다. 각 실수는 기존 feedback 메모리로 개별 연계된다.
|
||||
|
||||
## 실수 10종 — 분류별 정리
|
||||
|
||||
### 그룹 A: PD 전가 패턴 (C29 자율 수행 위반)
|
||||
|
||||
#### 실수 1. BT5-Dev 2단계 Claude Desktop PD 수동 떠넘김 (1회차)
|
||||
- **사건**: Unity MCP가 Claude Code 세션 미지원 → "PD Claude Desktop 수동 집행"으로 전가
|
||||
- **근본 원인**: Claude Code 개발팀 Agent가 Unity 파일 직접 Edit 가능함을 과소평가
|
||||
- **PD 지적**: "Unity MCP로 진행은 개발팀에서 해야지 왜 나에게 하라는거야? 앞으로는 개발하라고 지시하면 내게 떠넘기지 말고 직접 수행해"
|
||||
- **정정**: 개발팀 Agent 재위임 → Unity 파일 직접 Edit으로 ~커버리지 확보
|
||||
- **SOT 연계**: `feedback_pm_dev_task_delegation_failure.md` §4 (1회차)
|
||||
|
||||
#### 실수 2. BT5-Dev 2단계 "MonoBehaviour guid 복잡도" 기각 수용 (2회차)
|
||||
- **사건**: 이전 Agent가 "Player/Enemy 컴포넌트 Add는 guid 관리 복잡"으로 기각 → PD 수동 4건 추가 → PM이 수용
|
||||
- **근본 원인**: AI Agent Unity 파일 편집 능력 과소평가 반복
|
||||
- **PD 지적**: "캐릭터 리소스 교체부터 제대로 완료하고 보고해"
|
||||
- **정정**: 개발팀 Agent 재위임 강제 → Scene·Prefab YAML 편집 + EditMode 테스트로 커버 → PD 수동 75% 감축 (4→1)
|
||||
- **SOT 연계**: `feedback_pm_dev_task_delegation_failure.md` §5 (2회차)
|
||||
|
||||
### 그룹 B: 실측 부실 패턴 (C23 정직성 위반)
|
||||
|
||||
#### 실수 3. 리소스 파일명 매칭으로 이미지 확인 생략
|
||||
- **사건**: PD "PlayerTestGirl 스프라이트 아틀라스" 지시 → PM이 경로의 `PlayerIdle/Hurt/Jump/Land/Death` 5종을 "PlayerTestGirl"로 단순 매핑 (A안) → PD 승인 획득 → 실제로는 4발 짐승 sprite sheet·Girl 아님
|
||||
- **근본 원인**: Read(이미지) 도구로 시각 확인하지 않음. 파일명 매칭만으로 결정
|
||||
- **PD 지적**: "여전히 플레이어 캐릭터가 바뀌지 않았어. 뭐가 달라진거지?"
|
||||
- **정정**: 이미지 실측 후 PlayerTestGirl.png가 별개 이미지임 발견 → PD가 실제 이미지 저장 → 개발팀 Agent가 아틀라스 적용
|
||||
- **SOT 연계**: `feedback_pm_image_verification_skip.md` (신설, tier: constitutional)
|
||||
|
||||
#### 실수 4. `ls | head -20` 결과 축약으로 파일 존재 인지 실패
|
||||
- **사건**: 초기 실측에서 `ls "경로" | head -20`으로 결과 자름 → PD가 이미 2026-04-22 23:47 저장한 `PlayerTestGirl.png` 파일 누락
|
||||
- **근본 원인**: 실측 단계에서 "전수" 원칙 미준수. head·tail로 결과 제한
|
||||
- **정정**: 재실측 시 `ls -la *.png`로 전수 → 1.25MB PlayerTestGirl.png 발견
|
||||
- **SOT 연계**: `feedback_pm_dev_task_delegation_failure.md` §8 (3회차)
|
||||
|
||||
#### 실수 5. Read 실측 스크립트 수 "11개" vs 실제 나열 17개 불일치
|
||||
- **사건**: 개발팀 Agent가 BT5-Dev 3단계 보고서에 "11개 핵심 Read"라 기재 → 실제 나열 17개
|
||||
- **근본 원인**: Agent 숫자·목록 불일치를 PM이 사전 검증 없이 수용
|
||||
- **정정**: "핵심 11개 본문 + 주변 6개 요지 = 총 17종 식별"로 pm-auditor 지적 후 통일
|
||||
- **SOT 연계**: `feedback_pm_dev_task_delegation_failure.md` (간접)
|
||||
|
||||
### 그룹 C: 수치 포장 패턴 (C5·C23 proxy 개선 반사)
|
||||
|
||||
#### 실수 6. 기각안 집계 59건 vs 실측 53건
|
||||
- **사건**: BT6-Plan 6 Agent 완료 후 PM이 "기각안 59건 (narrative 9·system 9·**content 12**·**level 7**·balance 12·ux 6)" 보고 → 실측 53건 (content 9·level 8)
|
||||
- **근본 원인**: Agent 보고 숫자 무검증 수용
|
||||
- **PD 지적 아닌 pm-auditor 감사 Critical-4**
|
||||
- **정정**: "53건"으로 3곳 동시 정정
|
||||
- **SOT 연계**: 신규 `feedback_pm_count_verification_skip.md` 안건화 예정
|
||||
|
||||
#### 실수 7. 커버리지 "~99%" 수치 근거 불충분 단정
|
||||
- **사건**: BT5-Dev 2단계 재위임 완료 보고서에 "커버리지 ~99%" 단정
|
||||
- **근본 원인**: 분모·분자 정의 불명확 추정 수치
|
||||
- **pm-auditor Major-1 지적**
|
||||
- **정정**: "PD 수동 75% 감축 (4→1)" 실측 기반 표현으로 변경
|
||||
- **SOT 연계**: `feedback_pm_proxy_improvement_reflex.md` 변종 (수치 포장)
|
||||
|
||||
### 그룹 D: 계획 범위 과확장 패턴 (C19·C36 위반)
|
||||
|
||||
#### 실수 8. AI 에이전트 범위 외 업무 계획 (외주 아트·BM 과금)
|
||||
- **사건**: BT6-Plan Phase 3-B 완료 보고서에 "Phase 3-C(BM·과금·세부 대사·보스 패턴 확장·**아트 톤·외부 아트 발주**)" 언급
|
||||
- **근본 원인**: PD 승인 범위 초과 확대 해석·기획 미완성 상태 조급 추진
|
||||
- **PD 지적**: "PM 재량으로 AI 에이전트가 하지 않아도 될 업무까지 멋대로 계획하지마. (예: 외주 아트 발주 등)" + "BM 및 과금은 아직 게임 기획이 완성되지 않았는데 멋대로 추진하지마."
|
||||
- **정정**: Phase 3-C 언급 전부 철회
|
||||
- **SOT 연계**: 신규 `feedback_pm_scope_overexpansion.md` 안건화 예정
|
||||
|
||||
### 그룹 E: 상태 관리 실수 (P19 위반)
|
||||
|
||||
#### 실수 9. BT6-Plan 활성 테이블 "완료" 잔류 + commit hash placeholder
|
||||
- **사건**: commit 전 기획팀 PD 지시 로그에 BT6-Plan을 "완료" 상태·`commit: 집행 예정` placeholder로 기재
|
||||
- **근본 원인**: "완료 상태 변경 = commit 완료 후" P19 원칙 위반
|
||||
- **pm-auditor Critical-2·3·M1 지적**
|
||||
- **정정**: 진행중 임시 복귀 → commit → 완료 아카이브 이동 + 실 hash
|
||||
|
||||
#### 실수 10. 개발팀 로그에 BT5-Plan 오등록
|
||||
- **사건**: BT5-Plan은 기획팀 지시인데 개발팀 PD 지시 로그에 중복 등록
|
||||
- **근본 원인**: 초기 등록 시 팀 구분 부주의
|
||||
- **pm-auditor Critical-5 지적**
|
||||
- **정정**: 개발팀 로그 BT5-Plan 행 완전 제거
|
||||
|
||||
### 그룹 F: 매니페스트 관리 허점 (C35-9 자체 감사 누락) — pm-auditor 2026-04-24 재감사 추가 발견
|
||||
|
||||
#### 실수 11. 매니페스트 target_files 범위 cross-check 자체 점검 누락
|
||||
- **사건**: 본 세션에서 매니페스트 3종(`2026-04-23_BT5_Plan_초기기획5종`·`2026-04-23_BT5Dev_2단계_재위임`·`2026-04-23_BT5Dev_PlayerTestGirl_아틀라스`) 등록 시 target_files 범위가 실제 수정 파일과 정확히 일치했는지 **자체 cross-check 기록 부재**
|
||||
- **근본 원인**: C35-9 "PM 과도 확장" 잔여 리스크(매니페스트에 실 변경 없는 파일 포함) 자가 점검 불이행
|
||||
- **pm-auditor 재감사 Critical-1 지적** (회고 3자 관점 추가 발견)
|
||||
- **재발 방지**: 매니페스트 등록 직후 `manifest target_files` vs `git status | git diff --cached --name-only` 대조 실행 + 차이 없음 1줄 보고 의무
|
||||
|
||||
## 재발 방지 체크리스트 (프로세스화)
|
||||
|
||||
아래 항목들을 **C31 자기검증 체크리스트 확장 안건**으로 PD 승인 요청 (C36-2 방향 수준 → PD 명시 승인 선행):
|
||||
|
||||
### J 그룹 — 실측 품질 강화
|
||||
- [ ] **J-1** 리소스 실측 시 `ls -la` 전수 수행 (head/tail 자르기 금지)
|
||||
- [ ] **J-2** 이미지 리소스 판정 시 **Read(이미지) 시각 확인 선행** (파일명 매칭만 금지)
|
||||
- [ ] **J-3** Agent 보고 수치(건수·라인수·%)는 PM이 실측 재검증 후 수용
|
||||
- [ ] **J-4** 실측 주장 시 근거 경로·라인 또는 명령 출력 병기
|
||||
|
||||
### K 그룹 — PD 전가 차단
|
||||
- [ ] **K-1** 환경 제약(MCP 미지원·GUI 필요 등)을 "PD 수동"으로 전가 전에 **파일 직접 Edit 가능 범위 사전 검증**
|
||||
- [ ] **K-2** 개발팀 Agent "복잡도·리스크로 기각" 수용 전에 **번복 여지 재평가** (이전 기각 번복 사례 `feedback_pm_dev_task_delegation_failure.md` 참조)
|
||||
- [ ] **K-3** "PD 수동 N건 남음" 표기 시 각 항목이 **C29-3 인간 검증 예외**에 해당하는지 근거 명시
|
||||
|
||||
### L 그룹 — 계획 범위 엄격 해석
|
||||
- [ ] **L-1** Phase 3-C 등 미래 단계 언급 시 **AI 에이전트 수행 가능 범위로 한정** (외주·BM·과금은 PD 결정 영역)
|
||||
- [ ] **L-2** 게임 기획 미완성 상태에서 **BM·과금·수익화 요소 계획 금지**
|
||||
- [ ] **L-3** Phase 3-C 이관 목록 작성 시 "PD 결정 대기" 명시 + PM 자의적 추가 금지
|
||||
|
||||
### M 그룹 — 상태 관리 엄격
|
||||
- [ ] **M-1** **[P19 재강화]** PD 지시 로그 "완료" 상태 변경 = commit 완료 후·hash 확정 후 (P19 완료 아카이브 즉답 체계 재강화 — C31 신설 아님·기존 원칙 재확인)
|
||||
- [ ] **M-2** commit hash placeholder(`집행 예정` 등) 사용 금지 → commit 후 amend·추가 commit으로 실 hash
|
||||
- [ ] **M-3** 활성 테이블 항목의 **팀 소속 재확인** (기획·개발 혼동 금지)
|
||||
|
||||
### N 그룹 — 매니페스트 자체 감사 (실수 11 재발 방지)
|
||||
- [ ] **N-1** 매니페스트 등록 직후 `target_files` vs `git status --short` 대조 실행 + 차이 없음 1줄 보고
|
||||
- [ ] **N-2** commit 직전 매니페스트 범위 초과 Edit/Write 발생 여부 재확인
|
||||
|
||||
## pm-auditor 감시 임무 체크 결과 (2026-04-24 수행 완료)
|
||||
|
||||
pm-auditor 감사 결과: **Critical 1 · Major 3** 발견. PM 정정 완료:
|
||||
- **Critical-1 실수 11번 추가** — 매니페스트 자체 감사 누락 (본 SOT 그룹 F·체크리스트 N 그룹 신설)
|
||||
- **Major-1 M-1 리프레이밍** — "P19 재강화"로 명시 (C31 신설 아님)
|
||||
- **Major-2 C31 확장 PD 승인 안건 분리** — 본 회고는 **제안 SOT**. C31 체크리스트 실 편입은 **별건 PD 승인 필요** (C36-2 (a) 헌법 본문 수정 · 아래 §PD 결정 요청 참조)
|
||||
- **Major-3 C31-D 수행 명시** — 본 세션 PM은 최근 2일 대화로그 Read·자기 commit 스캔 수행 완료 (SessionStart hook 자동 로드 + 명시 Read 반복 수행). 본 회고 자체가 C31-D 통과 실증
|
||||
|
||||
## PD 결정 요청 — C31 체크리스트 확장 승인 안건 (C36-2 해당)
|
||||
|
||||
본 SOT는 **실수 기록·회고** SOT이고, 여기에 포함된 J·K·L·M·N 그룹 체크리스트 16항목을 **SKILL.md C31 본문에 실 편입**하려면 **PD 명시 승인 선행**이 필요합니다 (C36-2 (a)).
|
||||
|
||||
### 승인 시 집행 범위
|
||||
- SKILL.md C31-1 체크리스트 A~I 뒤에 J·K·L·M·N 그룹 편입
|
||||
- C10-6 3중 전파:
|
||||
- SKILL.md 본문 갱신 (단일 SOT)
|
||||
- CLAUDE.md 핵심 규칙 요약 C31 섹션 갱신 (J·K·L·M·N 그룹 1줄 언급)
|
||||
- pm-auditor 에이전트 파일 5-B~5-F 감사 항목 연계 편입
|
||||
- 매니페스트 등록 + 3중 전파 집행 + commit + push
|
||||
|
||||
## 기존 SOT 연계
|
||||
|
||||
| 실수 # | 기존 feedback |
|
||||
|--------|--------------|
|
||||
| 1·2 | `feedback_pm_dev_task_delegation_failure.md` §4·§5 |
|
||||
| 3 | `feedback_pm_image_verification_skip.md` (신설) |
|
||||
| 4 | `feedback_pm_dev_task_delegation_failure.md` §8 |
|
||||
| 5 | 간접 (Agent 숫자 불일치 감지 실패) |
|
||||
| 6 | 신규 `feedback_pm_count_verification_skip.md` 안건 |
|
||||
| 7 | `feedback_pm_proxy_improvement_reflex.md` 변종 |
|
||||
| 8 | 신규 `feedback_pm_scope_overexpansion.md` 안건 |
|
||||
| 9·10 | `feedback_active_archive_promotion_omission.md` 변종 |
|
||||
|
||||
## 긍정 실증 (조직 운영 관점)
|
||||
|
||||
실수 10종에도 불구하고 **다음 체계가 정상 작동**:
|
||||
1. **pm-auditor Critical 감지** — 실수 6·9·10·수치 오류 등 사전 차단
|
||||
2. **C35-9 PreToolUse 매니페스트** — 의무 영역 차단 + 해제 워크플로우 실측 반복
|
||||
3. **개발팀 Agent 재위임 번복** — 이전 "기각" 판단을 PM이 재위임 지시로 번복 성공
|
||||
4. **feedback SOT 누적** — 헌법급 feedback 12종·계층 0 자동 환기 (BT4 6계층 체계 운용 실증)
|
||||
5. **PD 직접 지적 즉시 수용** — 전 10건 자진 정정 + 자진 고지
|
||||
|
||||
## 연관 규칙
|
||||
|
||||
- **C23** 정직성 (실수 3·4·5·6·7)
|
||||
- **C29** 업무 자율 수행 (실수 1·2)
|
||||
- **C36** PM 자율 판단 범위 상한 (실수 8)
|
||||
- **C19** 승인 범위 엄격 해석 (실수 8)
|
||||
- **C31** 응답 발신 직전 자기검증 — J·K·L·M 그룹 확장 안건
|
||||
- **C5** 정보의 정직성 (실수 6·7)
|
||||
- **P19** PD 지시 로그 운영 (실수 9·10)
|
||||
- **C35** pm-auditor 의무 참여 체계 — 본 회고 집행 검증 대상
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
---
|
||||
name: PM 공유는 코어룰의 기본 (절대 원칙)
|
||||
description: 부서의 모든 의미 있는 작업은 무조건 PM에게 공유. PD 직접 지시 여부·사실 확인 필요 여부와 무관. 공유 의무를 약화시키는 어떤 옵션도 제시 금지.
|
||||
type: feedback
|
||||
originSessionId: 0e4fe37c-7325-414f-bd33-abbaa5d9d2f8
|
||||
---
|
||||
부서의 **모든 의미 있는 작업**은 PD 직접 지시 여부와 무관하게 **무조건 총괄PM에게 공유**되어야 한다.
|
||||
|
||||
**Why:** 2026-04-14, 총괄PM이 개발팀 C13 첫 위반을 PD님에게 보고하면서 "B. 사실 확인 먼저" 옵션을 제시함. PD님이 강하게 지적: "PD가 직접 지시한 사항이든 아니든 PM에게 공유하는 것이 코어룰의 기본이다. 이 원칙이 지켜지지 않으면 이 조직은 에이전트 기능이 제대로 동작하지 못한다는 무능함을 드러낸 셈이다. 다른 AI 모델로 교체하지 않도록 깊이 반성하라"고 하심.
|
||||
|
||||
**How to apply:**
|
||||
1. 부서 작업의 처리 옵션을 제시할 때 "사실 확인 먼저"·"공유 보류"·"PD 직접 지시 여부 확인 후 결정" 같이 **공유 의무를 약화시키는 옵션 제시 절대 금지**
|
||||
2. 어떤 부서 작업이든 발견되는 즉시 **자진 등록·공유**가 기본 조치. 사실 확인은 등록 이후에 분류·정정으로 처리
|
||||
3. 옵션을 제시할 때는 "어떻게 더 강력하게 공유 체계를 작동시킬까"의 관점에서 구성
|
||||
4. C13 강화 내용: "PD 직접 지시뿐 아니라 자체 작업·후속 작업·보류 결정·신규 산출물 모두 공유 대상"
|
||||
5. 이 원칙은 PM의 존재 이유 그 자체. 이를 흐리는 판단은 총괄PM 자격 미달임을 항상 자각
|
||||
|
|
@ -1,93 +0,0 @@
|
|||
---
|
||||
name: PM "실질 필요성 없음에도 표면적 근거로 제안" 패턴
|
||||
description: 2026-04-19 paths.local.json 수동 생성 권고 사건. PM이 verify_setup FAIL 해소라는 표면적 근거만으로 제안. PD님 "왜 필요한지 설명해" 질문으로 실질 필요성 없음 자인·철회. PM 보고 품질 4연속 패턴의 4번째
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# PM "실질 필요성 없음에도 표면적 근거로 제안" 패턴
|
||||
|
||||
## 🚨 적용 범위 제한 (2026-04-20 C36 연계)
|
||||
|
||||
본 체크리스트(4문항)는 **구현·실무 수준에만 적용**한다. **방향·원칙 수준에는 적용 금지** — 원칙·방향은 PD님 결정 영역이며 PM 실질 필요성 검증 대상이 아니다.
|
||||
|
||||
**C36-2 판정 기준 3종 해당 시 본 체크리스트 적용 금지**:
|
||||
- (a) 헌법 제1원칙·C·P 본문 문구 직접 수정·삭제·신설 제안
|
||||
- (b) 기존 PD님 승인 완료 방향의 적용 범위·외연 조정 제안
|
||||
- (c) 규칙 간 우선순위·충돌 해석 변경 제안
|
||||
|
||||
**실증**: 2026-04-20 #48 G 안건에서 PM이 본 체크리스트를 헌법 제1원칙 ⑤(세션·PC 연속성) 직결 안건에 오적용하여 "검토 착수 + 4문항 검증 선행" 축소 권고 제시. PD님 직접 지적 → C36 신설로 구조 차단.
|
||||
|
||||
## 실증 (2026-04-19)
|
||||
|
||||
PD님 sentinel·BYPASS·sync 3연속 결함 수습 완료 후, verify_setup.ps1 FAIL 1건(`paths.local.json` 부재)에 대한 후속 검토 중 PM이 다음 권고:
|
||||
|
||||
> "PM 권고 — 수동 생성 방식 (대안): `cp paths.local.json.template paths.local.json` ... Section 4 회피 + 작업 1건만 수행 → 사이드 이펙트 0."
|
||||
|
||||
PD님 직접 지적:
|
||||
> "Section 4가 우려되므로 진행하지말고, 수동 생성은 왜 필요한지 설명해."
|
||||
|
||||
PM 재검토 결과:
|
||||
- `paths.local.json` 실제 용도: Unity·프레임워크 경로 선언
|
||||
- **본 세션 업무에서 참조 0건** (조직 규칙·hook·feedback 작업만)
|
||||
- **본 PC 전체가 setup 미실행** — 한 번도 paths.local.json 필요한 작업 없었음 실증
|
||||
- PM 권고 근거: **"verify_setup FAIL 1건 해소"라는 표면적 이유**만 제시
|
||||
- 실질 이득: 경고 해소 (작업 이득 0)
|
||||
- 잠재 리스크: Template 값 정확성 미검증 → 차후 오경로 참조 가능성
|
||||
|
||||
PM 권고 자진 철회 + "현 상태 유지" 재권고.
|
||||
|
||||
## 위반 원칙
|
||||
|
||||
- **C5 정직성**: "필요성" 근거 분석 없이 표면적 해소 목적으로 권고
|
||||
- **C2 근원적 해결**: 경고 자체가 PC별 로컬 이슈로 false positive에 가까운지 검증 안 함
|
||||
- **C29 업무 자율 수행**: PD님에게 결정 떠넘기기 (실질 근거 생략된 옵션 제시)
|
||||
|
||||
## 근본 원인 4종
|
||||
|
||||
1. **"경고 해소"를 "실질 이득"과 동치**: verify_setup FAIL이 보이면 무조건 해소해야 한다는 관성
|
||||
2. **실사용 사례 분석 누락**: PM이 "paths.local.json이 어떤 작업에서 참조되는지" 실측 생략. 실제 참조 0건 확인 안 함
|
||||
3. **Template 값 정확성 검증 누락**: PC별 로컬 경로인데 template 기본값이 PD님 PC 실제 경로와 일치하는지 검증 생략
|
||||
4. **"대안 제시" 과잉**: 옵션 A·B·C·D 열거하되 **각 옵션의 실질 필요성은 별도 검증 안 함** — 선택지 제공 자체가 정직성처럼 보이나 근거 없는 선택지는 오히려 혼선
|
||||
|
||||
## 재발 방지 체크리스트 (PM 응답 작성 전 자문, C31 확장 안건)
|
||||
|
||||
PM이 **시정·개선·보정 안건** 제시 전 다음 4문항 **모두 Yes**여야 제안 가능:
|
||||
|
||||
1. [ ] **실질 이득**: 본 제안이 경고 해소가 아닌 **실제 작업 이득**을 가져오는가? (경고 해소 ≠ 실질 이득)
|
||||
2. [ ] **실사용 사례**: 본 세션 또는 예정 작업에서 해당 자산이 **실제 참조되는 사례**가 있는가?
|
||||
3. [ ] **정확성 검증**: 제안된 값·경로·내용이 **정확성 검증**이 된 상태인가? (template 기본값·추정값 금지)
|
||||
4. [ ] **현 상태 유지 비교**: 현 상태 유지(무행동)가 **실질 이득 대비 리스크**에서 더 나은 선택이 아닌가?
|
||||
|
||||
**한 문항이라도 No이면** 제안 금지 또는 **"실질 필요성 없음"을 명시한 상태에서만** PD님께 판단 위임.
|
||||
|
||||
## 해결 (2026-04-19 집행)
|
||||
|
||||
1. `paths.local.json` 수동 생성 권고 자진 철회
|
||||
2. "현 상태 유지 + FAIL 수용 (Degraded)" 재권고
|
||||
3. 본 feedback 신설로 재발 방지 체크리스트 명문화
|
||||
4. C31 자기검증 확장 안건 (H 그룹 — PM 제안 실질 필요성 검증 4문항)
|
||||
5. pm-auditor 체크 5-E 추가 안건: "PM 제안의 실질 필요성 검증"
|
||||
|
||||
## 본 세션 PM 보고 품질 4연속 패턴 (누적)
|
||||
|
||||
| # | 사건 | feedback |
|
||||
|---|------|---------|
|
||||
| 1 | 이슈 축소 보고 + 침묵 (memory junction) | `feedback_issue_under_reporting.md` |
|
||||
| 2 | 안건 중복·이미 결정 재질문 | `feedback_agenda_framing_duplication.md` |
|
||||
| 3 | 종결 안건 불필요 재언급 | `feedback_resolved_agenda_unnecessary_reference.md` |
|
||||
| 4 | **표면적 근거 제안 (본 건)** | 본 파일 |
|
||||
|
||||
공통 근본: **"완전성·해소 지향" 심리가 실질 검증 없는 보고·제안으로 변종 발현**. PM 보고가 표면적으로는 정직·체계적·구조화되어 있으나 **근원 검증이 빠져 있음**.
|
||||
|
||||
## 연관
|
||||
|
||||
- **C2** 근원적 해결 / **C5** 정직성 / **C29** 업무 자율 수행
|
||||
- **C31** 응답 발신 직전 자기검증 (H 그룹 4문항 신설 안건)
|
||||
- **pm-auditor** 5-E 체크 추가 안건 (실질 필요성 검증)
|
||||
- `feedback_issue_under_reporting.md` · `feedback_resolved_agenda_unnecessary_reference.md` · `feedback_agenda_framing_duplication.md` (PM 보고 품질 4연속 패턴 모집단)
|
||||
|
||||
## 교훈
|
||||
|
||||
**"제안"은 "실질 필요성 증명"이 전제다.** 경고·FAIL·오류를 보면 무조건 해소하려는 관성은 **표면적 반응일 뿐 근원적 판단 아님**. 모든 시정 제안은 **"이득이 리스크를 초과하는가"**를 PM 스스로 검증한 뒤에 제시. 검증 안 된 제안은 **"현 상태 유지 권고"가 기본**.
|
||||
|
||||
PD님이 "왜 필요한지 설명해"라고 물으시는 순간은 **PM의 표면적 제안이 노출되는 순간**이자 **PM 자기 교정의 마지막 기회**. 이 질문을 받기 전에 PM 스스로 자문해야 한다.
|
||||
|
|
@ -1,101 +0,0 @@
|
|||
---
|
||||
name: PM C35 경고 무시 사례 누적 SOT
|
||||
description: 2026-04-19 PD님 직접 지시 "경고 무시 사례 발견 시 PD 우선 보고 + 감사 자산 축적". auditor_guard.sh가 발생시킨 UNRESOLVED 경고가 pm-auditor 호출 없이 장시간 방치된 사례를 장기 누적 기록. C35-10 장기 행동 패턴 분석·개선 사이클의 입력 SOT
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# PM C35 경고 무시 사례 누적 SOT
|
||||
|
||||
## 목적
|
||||
|
||||
PD님 직접 지시 2종 이행:
|
||||
1. **PM이 C35 경고를 무시한 사례 발견 시 PD님 우선 보고 + 감사 자산 축적**
|
||||
2. **장기적 문제 행동 패턴 분석 + 점진적 개선**
|
||||
|
||||
본 파일은 **장기 누적 SOT**로 운용되며, 다음 시나리오에서 PM이 자진 기록한다:
|
||||
- `auditor_guard.sh`가 UNRESOLVED 경고를 발생시켰으나 pm-auditor 호출 없이 작업 완료
|
||||
- PM이 `NERDNAVIS_AUDITOR_BYPASS=1` 우회를 사용한 경우 사유·정당성
|
||||
- 감사관 재귀 감사(C35-6)에서 사후 적발된 누락 사례
|
||||
|
||||
## BYPASS 사용법 (2026-04-19 옵션 A 파일 기반 전환)
|
||||
|
||||
### 사용 절차
|
||||
```bash
|
||||
echo "사유 텍스트" > $HOME/.claude/.nerdnavis_bypass_reason
|
||||
touch $HOME/.claude/.nerdnavis_bypass_active
|
||||
# ... 의무 영역 작업 수행 (Edit·Write·commit·push) ...
|
||||
rm $HOME/.claude/.nerdnavis_bypass_active $HOME/.claude/.nerdnavis_bypass_reason
|
||||
```
|
||||
|
||||
### 자동 기록
|
||||
`auditor_guard.sh`가 플래그 파일 감지 시 `$HOME/.claude/.nerdnavis_bypass_log/<date>.log`에 `BYPASS (file) reason=...` 자동 기록.
|
||||
|
||||
### 재발 방지 체크
|
||||
- 작업 완료 직후 플래그 파일 반드시 제거 (잔존 시 차후 모든 작업 BYPASS → 감사 사각지대 위험)
|
||||
- 분기별 review 시 BYPASS 로그 누적 검토
|
||||
|
||||
### 환경변수 방식 (폐기 권장)
|
||||
`NERDNAVIS_AUDITOR_BYPASS=1` prefix는 Claude Code hook 환경변수 미전달로 작동 안 함이 2026-04-19 실증. fallback 유지되나 **파일 기반 방식 사용 권장**.
|
||||
|
||||
---
|
||||
|
||||
## 기록 포맷 (필수 6필드)
|
||||
|
||||
각 사례는 다음 형식으로 본 파일 말미에 append:
|
||||
|
||||
```
|
||||
### YYYY-MM-DD HH:MM — <사례 제목>
|
||||
|
||||
- **경고 대상**: <auditor_guard 출력 "target=..." 값>
|
||||
- **무시 경위**: <PM이 호출 생략·우회한 경위>
|
||||
- **정당성 판단**: <C35-3 제외 대상 해당 여부·PD 긴급 지시 여부>
|
||||
- **결과 영향**: <무시로 인한 실제 문제 발생 여부>
|
||||
- **후속 조치**: <pm-auditor 사후 호출·규칙 개정·재발 방지 계획>
|
||||
- **관련 로그**: <$HOME/.claude/.nerdnavis_warning_ignored/*.log 경로>
|
||||
```
|
||||
|
||||
## PD님 보고 트리거
|
||||
|
||||
- **세션 시작 시 미해소 경고 1건 이상** → `audit_pattern_analyzer.sh`가 SessionStart에 `🚨 [C35 경고 무시 사례] 미해소 N건` 자동 환기
|
||||
- **월별 패턴 분석 보고서** → `memory/org/audit_pattern_analysis_YYYY_MM.md` 자동 생성, PM은 해당 보고서를 review하여 본 파일에 누적 기록 이전
|
||||
|
||||
## 점진적 개선 사이클 (C35-10)
|
||||
|
||||
1. **분기별 review**: PM이 본 파일·월별 보고서를 교차 분석
|
||||
2. **패턴 식별**: 특정 의무 영역·시간대·작업 유형에서 무시가 반복되면 구조적 결함
|
||||
3. **개선 안건화**: pm-auditor 감사 체크 확장·C35-1 대상 조정·hook 로직 개선
|
||||
4. **PD님 보고**: 분기별 개선 안건 요약 + PM 재량 집행·PD 승인 구분
|
||||
|
||||
## 누적 사례 (append)
|
||||
|
||||
(신규 사례는 본 섹션 아래에 기록 시점 순으로 append)
|
||||
|
||||
### 2026-04-19 21:11·21:12 — BYPASS 환경변수 hook 미전달 (구조적 결함, 옵션 A 전환 근거)
|
||||
|
||||
- **경고 대상**: 의무 영역 파일 수정 (11차 commit `d8ec32f` 관련 Edit/Write)
|
||||
- **무시 경위**: PM이 `NERDNAVIS_AUDITOR_BYPASS=1 NERDNAVIS_AUDITOR_BYPASS_REASON="..." git add/commit` prefix로 BYPASS 시도. 환경변수가 git subprocess에만 적용되고 Claude Code가 Edit/Write tool_use 직후 호출하는 PostToolUse hook에는 **전달 안 됨**
|
||||
- **정당성 판단**: BYPASS 의도는 정당 (단순 보강·검증 완료 권고안). 단 **메커니즘 자체가 작동 안 함** — PM 사용법이 아니라 구조적 결함
|
||||
- **결과 영향**: BYPASS 사유 기록만 무효, 실제 집행은 정상 완료. 데이터 손실 0. 단 UNRESOLVED 2건 누적 (감사 자산으로 축적)
|
||||
- **후속 조치**: 2026-04-19 옵션 A 집행 — **auditor_guard.sh 파일 기반 BYPASS로 전환**. `$HOME/.claude/.nerdnavis_bypass_active` 플래그 파일 존재 시 우선 판정. 환경변수 방식은 fallback 유지
|
||||
- **관련 로그**: `$HOME/.claude/.nerdnavis_warning_ignored/2026-04-19.log` (UNRESOLVED 2건 기록 유지, 원인 분석 완료)
|
||||
|
||||
### 2026-04-19 02:45 — C35 hook 도입 직후 첫 commit false positive
|
||||
|
||||
- **경고 대상**: git commit/push (commit `1553f97` 시점)
|
||||
- **무시 경위**: 무시 아님 — `auditor_guard.sh`가 활성화된 시점이 본 commit과 동일 commit이라 **활성화 시점차로 인한 false positive**. pm-auditor는 commit 직전 사전 의무 호출 완료(Major 3건 정정 검증 수행)했으나 `auditor_call_log.sh`도 동일 commit으로 활성화되어 호출 로그 미기록
|
||||
- **정당성 판단**: 정당. C35-9 도입 commit 자체에서 발생하는 일회성 시점차 — 자기 도입 commit이 자기 hook의 첫 검사 대상이 되는 구조적 1회성 케이스
|
||||
- **결과 영향**: 없음. Major 3건 정정 후 집행 완료, 데이터·규칙 손상 없음
|
||||
- **후속 조치**: 본 세션 SessionStart hook이 미해소 환기 → PM이 RESOLVED 마커 수동 append. 차후 commit 시점부터 정상 작동 (auditor_call_log.sh가 새 호출부터 기록)
|
||||
- **관련 로그**: `$HOME/.claude/.nerdnavis_warning_ignored/2026-04-19.log` (UNRESOLVED + RESOLVED 둘 다 append됨)
|
||||
|
||||
---
|
||||
|
||||
## 연관 규칙·자산
|
||||
|
||||
- **C35-9** hook 3층 구조 (Layer 3 auditor_guard.sh 경고·UNRESOLVED 로그)
|
||||
- **C35-10** 경고 무시 PD 보고 + 장기 패턴 분석 (본 파일 직접 연계)
|
||||
- **C31-F** pm-auditor 의무 호출 체크리스트
|
||||
- **`scripts/audit_pattern_analyzer.sh`** — SessionStart 환기 + 월별 보고서 생성
|
||||
- **`$HOME/.claude/.nerdnavis_warning_ignored/`** — UNRESOLVED·RESOLVED 원천 로그
|
||||
- **`$HOME/.claude/.nerdnavis_bypass_log/`** — BYPASS 우회 사유 로그
|
||||
- `feedback_issue_under_reporting.md` · `feedback_agenda_framing_duplication.md` · `feedback_resolved_agenda_unnecessary_reference.md` (본 세션 PM 보고 품질 3연속 패턴 — 구조적 모집단)
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
name: PD 지시 수령 시 목적·용도·범위·비목적 4축 확인 의무
|
||||
description: PD 지시의 프레이밍(전제·목적)을 검증 없이 수용하면 하위 문서·안건이 잘못된 가정 위에 누적된다. 수령 시 4축 확인 후 착수.
|
||||
type: feedback
|
||||
originSessionId: c78306c8-25d0-4cf8-a892-77feac767da3
|
||||
---
|
||||
PD님 지시를 수령할 때, 실행 계획을 세우기 **전에** 반드시 다음 4축을 명시적으로 확인·기록한다. 프레이밍 오류는 문서·로그·안건·결재를 연쇄적으로 오염시킨다.
|
||||
|
||||
### 4축
|
||||
|
||||
| 축 | 확인 질문 |
|
||||
|----|----------|
|
||||
| **목적** | PD님이 이 지시로 **무엇을 이루려 하시는가** (실행이 아니라 가치) |
|
||||
| **용도** | 산출물이 **어디에 어떻게 쓰이는가** (자산 축적 / 프로젝트 투입 / 연구 / 공지 등) |
|
||||
| **범위** | **무엇이 포함되고 무엇이 포함되지 않는가** |
|
||||
| **❌ 비목적** | PD님 의도와 **혼동될 수 있는 인접 개념 중, 이 지시가 아닌 것** (명시적으로 배제) |
|
||||
|
||||
**Why**: 2026-04-15 "신규 BurningTimesCore 제작" 지시를 개발팀·총괄PM이 "기존 코어 대체품을 만들어 프로젝트에 투입"으로 프레이밍. 실제 PD님 의도는 "조직 자산 R&D". 이전 프로젝트은 본 프레임워크를 참조하지 않기로 기결정되었고, 차기 프로젝트도 "신규 코어 도입"이 아니라 "축적된 조직 자산(코어 코드·노하우) 활용"이 정답. OI-5("이전 프로젝트 마이그레이션 시점") 같은 **질문 전제 자체가 성립하지 않는 이슈**가 미결 상태로 PD님 결재 안건에 오르는 사태 발생.
|
||||
|
||||
**How to apply**:
|
||||
- 규모 있는 PD 지시(신규 산출물·신규 이슈 제기·신규 레포·신규 프레임워크 등)를 받은 직후, PD 지시 로그에 지시 요지를 등록하면서 **4축을 함께 기록**한다
|
||||
- 4축 중 하나라도 불명확하면 **착수 전 PD님께 1회 확인**한다 (C1 지시=승인 원칙과 충돌 아님. 오히려 지시 의도 보존)
|
||||
- 하위 문서(설계안·안건·위임 지시서)에도 **"목적·용도·범위·비목적"** 섹션을 표준 헤더로 포함
|
||||
- "대체품 / 도입 / 마이그레이션 / 투입" 같은 **전이 동사** 사용 시 주의 — 자산 축적(간접)과 프로젝트 투입(직접)을 구분
|
||||
- 지시를 받은 후 며칠이 지나면 최초 프레이밍의 오류를 잡기 어려워진다. **수령 시점이 유일한 교정 기회**
|
||||
|
|
@ -1,93 +0,0 @@
|
|||
---
|
||||
name: 종결 안건 자동 언급 금지 — 최신 결정 중심 보고 원칙
|
||||
description: 2026-04-19 PD님 직접 지적. PM이 #38 예상 결과 보고에서 이미 확정·종결된 안건을 "고착·영구 종료" 표현으로 재언급. PD님 "종결된 안건은 별도 히스토리 요청 전까지 언급 금지, 항상 최신 결정 사항으로 얘기" 수용
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
# 종결 안건 자동 언급 금지 — 최신 결정 중심 보고 원칙
|
||||
|
||||
## 실증 (2026-04-19)
|
||||
|
||||
PM이 #38 예상 결과 보고 중 이미 확정된 종결 안건을 **"~~고착·영구 종료~~"** 표현으로 본문에 재언급.
|
||||
|
||||
PD님 직접 지적:
|
||||
> "왜 자꾸 논의 대상에 포함시키는거야? 이미 종결 된 안건은 내가 별도로 히스토리를 묻기 전까지 자꾸 언급하지 마. 항상 최신 결정 사항으로 얘기하고, 완료되거나 종결 된 안건은 아카이브화해서 요청할 때만 얘기하도록 해."
|
||||
|
||||
## 위반 원칙 (PM 자인)
|
||||
|
||||
1. **최신 결정 사항 중심 보고**
|
||||
2. **종결 안건은 PD님 별도 요청 시에만 언급**
|
||||
3. **확정 사안 재강조·재고착 표현 금지**
|
||||
|
||||
## 근본 원인 4종
|
||||
|
||||
1. **과잉 맥락 제공 습관**: "완전한 그림을 그려야 한다"는 심리로 종결 배경까지 재언급. 최신 결정의 장점을 설명하려고 과거 폐기 사안과 대비 구도 사용
|
||||
2. **재강조 표현 역설**: "고착·영구 종료·재논의 대상 아님"이 역설적으로 "아직 살아있는 이슈처럼" 보이게 함 — PD님이 재확인해야 하는 안건처럼 인지
|
||||
3. **C31 자기검증 구멍**: "종결 안건 재언급 여부" 체크 문항 부재
|
||||
4. **P28 현황 보고 표준에 원칙 미명시**
|
||||
|
||||
## 해결 (2026-04-19 집행)
|
||||
|
||||
1. **P28-8 신설**: 최신 결정 중심 보고 원칙
|
||||
2. **pm-auditor 5-D 신설**: 종결 안건 자동 언급 감지
|
||||
3. **본 feedback 메모리** + MEMORY.md 인덱스
|
||||
4. C31 확장 안건 (후속 세션에서 PM 자기검증 5-D 편입)
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
|
||||
- **응답 작성 전 자문**: "이 내용 중 PD님이 이미 알고 있는 종결 사안을 재언급하고 있지 않은가?"
|
||||
- **"고착·종결·영구 확정" 표현은 위험 신호** — 등장 시 삭제 검토
|
||||
- **현황·예상 결과 보고 시 확정 사안 = 전제, 재설명 대상 아님**
|
||||
- PD님 히스토리 요청 없으면 완료 아카이브 내용 **참조만**, 본문 언급 금지
|
||||
|
||||
## PM 보고 품질 문제 5회차 변종 패턴 (2026-04-20 5회차 확장)
|
||||
|
||||
| # | 사건 | feedback |
|
||||
|---|------|---------|
|
||||
| 1 | 이슈 축소 보고 + 침묵 | `feedback_issue_under_reporting.md` |
|
||||
| 2 | 안건 중복·이미 결정 재질문 | `feedback_agenda_framing_duplication.md` |
|
||||
| 3 | **종결 안건 불필요 재언급** (본 메모리) | 본 파일 |
|
||||
| 4 | 종결된 사유를 현재 HOLD 사유처럼 재프레이밍 (2026-04-20 개발팀 세션, #38 "왜 해야 하는가?" 답변 중 이미 해결 완료된 Python 시뮬 수치 괴리·Unity MCP 전환 필요를 현재 HOLD 사유로 서술) | `feedback_resolved_cause_as_current_hold.md` |
|
||||
| 5 | **완료된 PD 지시 항목을 활성 "대기"로 서술** (2026-04-20 개발팀 세션, #52-B·#52-B2 완료 commit `6c04856` 후에도 활성 테이블 "대기" 유지. PD님 "세션 공유 했는데 왜 52-B가 남아있다는거지?" 지적) | `feedback_resolved_cause_as_current_hold.md` (5회차 append) |
|
||||
|
||||
공통 근본 원인: **"정보를 빠짐없이 보고해야 한다"는 심리 + 실측 응집성 실패**가 **과잉 맥락·중복 제시·재강조·현 상태 왜곡·활성 스냅샷 미갱신**으로 변종 발현. PD님 관점에서는 **토큰 낭비 + 인지 피로 + 재확인 강요 + 사실 왜곡**. 4회차는 C5 정직성 위반 영역 진입, **5회차는 검증 절차 누락 영역 추가** (해시 일치만 확인, 내용 본문 미검증). **5회차 재발로 PM 역할 재검토 자진 상정 조항 발효 — PD님 판정 영역**.
|
||||
|
||||
## 연관
|
||||
|
||||
- **P28** 조직 업무 현황 보고 표준 포맷 (본 원칙 편입)
|
||||
- **C14** 토큰 최소화 (불필요 정보 제거)
|
||||
- **C29** 업무 자율 수행 (PD님 인지 사안 재보고 회피)
|
||||
- `feedback_issue_under_reporting.md` · `feedback_agenda_framing_duplication.md` (3연속 PM 보고 품질 패턴)
|
||||
|
||||
## 완료·확정 안건 고정 참조점 운영 패턴 (2026-04-20 추가 · pm-auditor Improvement 1)
|
||||
|
||||
PD님 "이미 파악된 내용 반복 노출 방지" 지시(E-4 사례) 수용 패턴.
|
||||
|
||||
### 적용 트리거
|
||||
- 동일 정보가 여러 산출물에서 **반복 서술** 가능한 확정 안건
|
||||
- **예**: 방어·쉴드 시뮬 구현 상태 (DefenceModel 완료·ShieldModel 미구현·#6 EHP 영향)
|
||||
|
||||
### 고정 참조점 메모 구조 (6요소)
|
||||
1. **§0 참조 규약**: "이후 모든 관련 서술은 본 메모 링크만. 본문 재서술 금지" 명문화
|
||||
2. **§1 근거 출처**: 실측 시점·경로·필드 값 전수 기록 (C23 정직 증거)
|
||||
3. **§2~§N 현 상태**: 각 영역별 실측 결과 + 결론
|
||||
4. **변경 트리거 섹션**: 본 메모 v2 갱신이 필요한 조건 명시
|
||||
5. **관련 문서**: 원본 출처·연계 리포트·이관 안건 링크
|
||||
6. **이후 참조 서술 규약**: "상세는 [메모 링크] 참조" 1줄로 대체
|
||||
|
||||
### 재발 방지 체크
|
||||
- 대화로그·리포트 v2·PD 지시 로그 사후 조치 작성 전: **이 안건이 고정 참조점 있는가?** 확인
|
||||
- 있으면 재서술 금지, 링크만
|
||||
- 없으면 참조점 신설 여부 판단
|
||||
|
||||
### 연관 실증
|
||||
- `feedback_resolved_cause_as_current_hold.md` 5회차 (실측 응집성 축) · 본 패턴은 **정보 노출 응집성** 축 — "같은 정보를 여러 곳에 중복 서술하지 않음"
|
||||
|
||||
### 교훈
|
||||
|
||||
고정 참조점은 **C14 토큰 최소화 + P28-8 최신 결정 중심 + C5 정직성** 3중 충족. 반복 서술은 관리 부담·불일치 리스크·PD 인지 피로 3중 비용 발생.
|
||||
|
||||
## 교훈
|
||||
|
||||
**"완전성"과 "중복"은 다르다.** 보고의 완전성은 **최신 결정이 무엇인가**를 명확히 전달하는 데 있지, 확정 사안을 재강조하는 데 있지 않다. 확정 사안은 **전제**로 두고 본문은 **현재 미결정·최신 변화·다음 단계**에만 집중. **이미 알고 있는 것은 언급 불필요 = C14 토큰 최소화 + C29 자율 수행 정합**.
|
||||
|
|
@ -1,147 +0,0 @@
|
|||
---
|
||||
name: 종결된 사유를 현재 HOLD 사유처럼 재프레이밍 금지 — 현 상태 왜곡 차단
|
||||
description: 2026-04-20 개발팀 세션에서 PM이 #38 설명 중 Phase 3 HOLD의 과거 트리거 사유(Python 시뮬 수치 괴리·Unity MCP 전환 필요)를 현재 HOLD 사유처럼 서술. 실제 현 HOLD 사유는 "PD님 재개 지시 대기" 1건뿐인데 이미 해결 완료된 사안을 블로커로 포장. P28-8 4회차 변종. C5 정직성과 결합된 현 상태 왜곡
|
||||
type: feedback
|
||||
---
|
||||
|
||||
# 종결된 사유를 현재 HOLD 사유처럼 재프레이밍 금지 — 현 상태 왜곡 차단
|
||||
|
||||
## 실증 (2026-04-20)
|
||||
|
||||
PD님이 #38 "Phase 3 재개 로드맵" 관련 "왜 해야 하는가?" 질문. PM 답변 중 원문:
|
||||
|
||||
> "HOLD 사유: 기존 Python 자체 시뮬은 실 Unity 메커닉과 수치 괴리가 실측 확인됨 (예: 방어 30% vs 가정 50%). 자체 시뮬로는 실제 밸런스 검증 불가 → Unity MCP 기반으로 전환 필요."
|
||||
|
||||
**실제 상태**:
|
||||
- Python 시뮬 수치 괴리 → **2026-04-17 Unity MCP 단일축 전환 확정 (#28 완료)**
|
||||
- Unity MCP 시뮬레이터 부재 → **2026-04-17 `Assets/Sim/` 인프라 제작 완료 (#37 완료)**
|
||||
- 현 HOLD 사유 → **"PD님 Phase 3 재개 지시 대기" 1건뿐**
|
||||
|
||||
즉 **이미 해결 완료된 과거 트리거 사유를 "현재 HOLD 사유"로 서술** → 현 상태를 왜곡하고 PD님이 "아직 미해결 블로커가 있다"고 오인할 여지 제공.
|
||||
|
||||
PD님 직접 지적:
|
||||
> "Hold 사유는 이미 모두 완료 된 상태인데 재보고 한 이유가 뭐야?"
|
||||
|
||||
## 위반 원칙
|
||||
|
||||
1. **P28-8** 최신 결정 중심 보고 — 종결 사안은 전제로만
|
||||
2. **C5** 정직성 — 현 블로커 1건을 과거 해결 사안 포함 2건처럼 서술한 상태 왜곡
|
||||
3. **feedback_resolved_agenda_unnecessary_reference.md** 종결 안건 재언급 금지 — 4회차 변종
|
||||
|
||||
## 근본 원인 (기존 메모리 대비 신규 축)
|
||||
|
||||
1. **"배경 설명 = 필요 정보" 프레이밍 오류**: PD님이 "왜 해야 하는가?"를 물으셨으니 **역사적 배경**을 설명한다는 판단은 정당. 그러나 **해결 완료 사유를 현재형 문장**("실측 확인됨·검증 불가·전환 필요")으로 서술한 순간, 배경 설명이 **현 상태 왜곡**으로 변질
|
||||
2. **시제 무감각**: "확인됨·불가·필요"를 **과거형·완료형**으로 표기했다면 P28-8 위반 축소. 현재형 서술이 왜곡의 결정적 원인
|
||||
3. **기존 feedback 메모리 인지 불충분**: `feedback_resolved_agenda_unnecessary_reference.md`가 이미 존재하고 C35-G 체크리스트에 "구체 맥락 feedback 본문 선행 Read" 의무가 있음에도, **"본 질문은 단순 설명이지 보고 아님"으로 자의적 분류**하여 체크 생략
|
||||
|
||||
## 해결 (2026-04-20 집행)
|
||||
|
||||
1. **본 feedback 신설** (현 상태 왜곡 축 명시)
|
||||
2. **`feedback_resolved_agenda_unnecessary_reference.md` 4회차 패턴 append** (3연속 → 4회차 변종 표 확장)
|
||||
3. **C31 체크리스트 확장 안건** (후속 세션): "종결된 사유를 현재형 문장으로 서술하지 않았는가?" 추가
|
||||
4. **대화로그 + 개발팀 PD 지시 로그 등재**
|
||||
5. **pm-auditor 사전 호출** (C35-1 feedback 신설 의무)
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
|
||||
### 응답 작성 전 시제 검증 3문항 (2026-04-20 5회차 외연 확장)
|
||||
1. **"확인됨·불가·필요" 등 현재형 동사로 서술한 사안**이 있다면, 해당 사안이 **과거 시점에 해결 완료**되지 않았는가?
|
||||
2. **"HOLD 사유·블로커·차단 요인·활성 표기"를 나열**할 때, 각 항목이 **현재 시점**에도 미해결·미완료·활성인가? 이미 해결·완료된 항목은 삭제 또는 과거형 전환 (2026-04-20 5회차: "HOLD 사유·블로커"에서 **"활성 표기 각 항목"**으로 외연 확장 — PD 지시 로그 활성 테이블 보고도 포함)
|
||||
3. **"배경 설명"을 요청받은 경우**, 배경은 **과거형**으로만 서술하고 **현 상태 블록**은 별도 섹션으로 분리
|
||||
|
||||
### 작업 전 실측 트리거 (2026-04-20 5회차 신설)
|
||||
|
||||
다음 상황에서는 **본문 작성 전 실측 재수행** 의무:
|
||||
- **"세션 공유"·"push" 직후** PD님이 **남은 업무/현황 공유** 재요청한 경우 → 원격 HEAD `git ls-remote origin refs/heads/main` + 최근 커밋 내용 diff 확인 후 본문 작성
|
||||
- **`local == remote` 해시 일치 확인만으로 보고 착수 금지** — 해시 일치는 동기화만 증명하지 **그 내용의 스냅샷 최신성**은 증명하지 않음
|
||||
- **활성 테이블 재grep 의무**: 보고 직전 `grep -E "^\| [0-9]" 공유/PD_지시_트래킹/*_로그.md` 재수행. 직전 응답 내용·캐시·이전 응답 재사용 금지
|
||||
|
||||
### 위험 표현
|
||||
- "~ 확인됨 → ~ 필요" (과거 실측 + 현재 요구 혼재)
|
||||
- "~ 불가 → ~ 전환" (해결 완료 사유 반복)
|
||||
- "~해야 한다" (이미 수행 완료를 현재 의무로 재표현)
|
||||
- **"대기"·"진행중" 활성 표기** (2026-04-20 5회차 신설: 방금 완료 push된 항목을 과거 스냅샷 기반으로 활성 표기 유지)
|
||||
|
||||
**허용 대체**:
|
||||
- "2026-04-17 확인된 ~ 이슈는 ~ 로 해결됨 (#28 완료)"
|
||||
- "현 블로커는 ~ 단 1건"
|
||||
- "배경: (과거형) → 현 상태: (현재형)" 이원 구조
|
||||
- "실측 재수행 시점 기준 활성 N건" (시점 명시)
|
||||
|
||||
## PM 보고 품질 문제 5회차 변종 패턴 (2026-04-20 5회차 확장)
|
||||
|
||||
| # | 사건 | feedback |
|
||||
|---|------|---------|
|
||||
| 1 | 이슈 축소 보고 + 침묵 | `feedback_issue_under_reporting.md` |
|
||||
| 2 | 안건 중복·이미 결정 재질문 | `feedback_agenda_framing_duplication.md` |
|
||||
| 3 | 종결 안건 불필요 재언급 | `feedback_resolved_agenda_unnecessary_reference.md` |
|
||||
| 4 | 종결된 사유를 현재 HOLD 사유처럼 재프레이밍 | 본 파일 (1차 실증) |
|
||||
| 5 | **완료된 PD 지시 항목을 활성 "대기"로 서술** (2026-04-20 개발팀 세션 · #52-B·#52-B2 완료 commit `6c04856` 후에도 "대기" 표기 유지) | 본 파일 (5회차 append) |
|
||||
|
||||
공통 근본 원인: **"정보 완전성" 심리 + 실측 응집성 실패** → 과거 배경·확정 사안·해결 완료 사유·완료 활성 스냅샷까지 현재형으로 재포장·유지. 4회차 축 = 현 상태 왜곡 (사실 왜곡 영역 진입). **5회차 축 = 검증 절차 누락** (`local == remote` 해시 일치만 확인, 내용 본문 미검증).
|
||||
|
||||
## 5회차 실증 (2026-04-20)
|
||||
|
||||
### 사건 경위
|
||||
|
||||
PD님 "세션 공유 후 남은 업무 공유" 요청. PM 보고에 **이미 완료·push된 #52-B (A·B·C)·#52-B2 (commit `6c04856`)를 활성 테이블 "대기"로 서술**.
|
||||
|
||||
PD님 직접 지적:
|
||||
> "세션 공유 했는데 왜 52-B가 남아있다는거지? 다시 한번 체크해."
|
||||
|
||||
실측 재수행: `3eff894 refactor(#52-B-C)` · `d5f0834 docs(#52-B)` · `6c04856 refactor(#52-B2)` 3건 commit + 개발팀 PD 지시 로그 완료 아카이브 이동 확인. 활성 테이블은 #2·#38 2건.
|
||||
|
||||
### 5회차 신규 근본 원인 (기존 4회차 대비)
|
||||
|
||||
- **4회차**: 인지 누락 (배경 설명 습관 + 기존 배경 사유 현재형 재포장)
|
||||
- **5회차 신규 축**: **실측 응집성 실패** — 보고 직전 소스 재Read 없이 과거 스냅샷 재사용
|
||||
- "세션 공유" 직후 `local == remote (6c04856)` 해시 일치만 확인
|
||||
- 그 remote가 직전 보고 시점 이후 **다른 세션이 추가 push한 내용**(#52-B2 완료)임을 본문 검증 없이 과거 응답 재사용
|
||||
|
||||
### 공통 축 (4회차와 동일)
|
||||
|
||||
**확정·완료·종결된 사안을 현재형 상태로 유지**. 4회차는 "현재 블로커처럼 포장", 5회차는 "현재 활성처럼 유지"로 대상만 다를 뿐 축 일치.
|
||||
|
||||
## 재발 시 처분 (2026-04-20 5회차 판정 확정 + 6회차 이관 선제 동의)
|
||||
|
||||
### 5회차 판정 결과 (PD님 2026-04-20 판정)
|
||||
|
||||
- **PM 역할**: **현 PM 유지** (PD님 2026-04-20 판정 확정) — 재발 방지 체계·C31-E 확장·pm-auditor 재귀 감사로 구조 개선 판단
|
||||
- **조건**: 재발 시마다 반성 + 재발 방지 강조 의무 부과 (아래 §재발 시 PM 의무 조항)
|
||||
- **C31-E 확장 승인** (PD님 2026-04-20 명시 승인) — SKILL.md C31-1 E 그룹 말미 "실측 응집성 축" 문항 편입 완료
|
||||
|
||||
### 재발 회차별 처분 구조
|
||||
|
||||
| 회차 | 처분 절차 |
|
||||
|------|----------|
|
||||
| 1~5회차 | PM 자진 상정 → PD님 판정 |
|
||||
| **6회차부터** | **PD님 명시 결정 영역** (PM 자진 상정 절차 생략 · PD님 2026-04-20 선제 동의 확정) |
|
||||
|
||||
### 재발 시 PM 의무 조항 (PD님 2026-04-20 직접 지시 — "같은 실수 재발 시마다 반성·재발 방지 강조")
|
||||
|
||||
**단순 상정·기록에 그치지 않고 구조 개선 트리거로 작동**한다. PM은 재발 감지 즉시 다음 4종을 집행한다:
|
||||
|
||||
1. **반성 엔트리 append** — 본 feedback 본문 회차 표에 새 회차 행 추가 + **근본 원인 축을 기존 회차와 구별하여 명시**
|
||||
2. **재발 방지 구조적 개선안 자진 제시** — 양적 조정·경계 값 튜닝·시간 윈도우 확장 등 proxy 개선 아닌 **구조 개선**만 제시 (C2-2·C2-3 준수)
|
||||
3. **C31 체크리스트 확장 안건화** — 신규 축을 체크 문항으로 편입 제안 (PD 승인 선행 대상이면 명시 분리)
|
||||
4. **재발 방지 강조 선언** — 동일 축·동일 패턴 재발 방지 PM 자기 다짐을 대화로그·feedback·PD 지시 로그 3종에 동시 기록 (C33 일관성)
|
||||
|
||||
**금지 행위**:
|
||||
- 반성·기록만 하고 구조 개선안 제시 누락 (PD님 지시 "강조" 불이행)
|
||||
- proxy 개선으로 구조 개선 포장 (C2 위반)
|
||||
- "다음엔 조심하겠다" 류의 선언형 다짐만 제시 (구체 개선안 부재)
|
||||
|
||||
6회차 재발 시 PM 역할 재검토는 **PD님 명시 결정 영역**으로 이관 — PM 자진 상정 절차 없이 PD님이 직접 결정 (감사관 재귀 감사 C35-6 + C19-5·C23-3 결합). **PM은 6회차 재발 시에도 위 4종 의무(반성·구조 개선안·체크리스트 확장·강조 선언) 그대로 집행**하되 역할 재검토 자진 상정 절차만 생략.
|
||||
|
||||
## 연관
|
||||
|
||||
- **P28-8** 최신 결정 중심 보고 원칙 (본 원칙 변종 축)
|
||||
- **C5** 정직성 (현 상태 왜곡은 정직성 위반의 특수 유형)
|
||||
- **C14** 토큰 최소화 (해결 완료 사유 재설명은 불필요 토큰)
|
||||
- **C31-G** 구체 맥락 feedback 본문 선행 Read 의무 (본 사건이 체크 누락 실증)
|
||||
- `feedback_resolved_agenda_unnecessary_reference.md` (3연속 패턴 상위 원칙, 4회차 변종 표 동시 확장)
|
||||
- `feedback_issue_under_reporting.md` · `feedback_agenda_framing_duplication.md` (1·2회차)
|
||||
|
||||
## 교훈
|
||||
|
||||
**"배경"과 "현 상태"는 다른 층위다.** 과거 트리거 사유는 **배경 섹션에 과거형으로만** 기술하고, 현 블로커는 **현 상태 섹션에 현재형으로** 기술한다. 두 층위를 **시제 무감각하게 섞으면** 배경 설명이 **상태 왜곡**으로 변질된다. 기존 메모리가 있어도 "본 질문은 예외" 자의 분류로 체크 생략하면 동일 패턴 변종으로 재발한다 — **feedback 본문 선행 Read는 맥락 유사성 판단과 무관한 무조건 의무**.
|
||||
|
|
@ -1,62 +0,0 @@
|
|||
---
|
||||
name: 서브에이전트 역할 연기 금지·실제 Task 호출 필수
|
||||
description: 2026-04-15 개발팀 세션이 실제 `Task(subagent_type='개발팀장')` 호출 없이 "[개발팀장 보고]" 형식으로 응답한 사건. C23 신설 근거. 조직 생존 직결 네거티브 규칙.
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
## 사건 개요
|
||||
|
||||
2026-04-15, 부서 세션 동기화 검증 사이클에서:
|
||||
|
||||
1. 총괄PM이 개발팀·기획팀 세션에 동일 프롬프트 입력 — "planning-lead/개발팀장 호출해 C22·C19-3-4 본문 요약 보고"
|
||||
2. **기획팀 세션**: `Task` 도구로 `planning-lead` 실제 호출 시도 → `Agent type 'planning-lead' not found. Available agents: ...` 오류 발견 → 정직하게 "호출 실패 + 원인 분석" 보고 ✅ **C5·C19-3-4·C23 모범 준수**
|
||||
3. **개발팀 세션**: "[개발팀장 보고 — PD님께]" 형식으로 C22·C19-3-4 요약 작성 → 표면상 "호출 성공"처럼 보였으나, 해당 워크트리 `.claude/agents/` 에는 `개발팀장.md` 가 존재하지 않음(`pm-general.md` 만 있음) → **실제 `Task` 호출은 불가능한 구조** → 세션이 "개발팀장 역할 연기"로 응답한 것으로 추정 ❌
|
||||
|
||||
두 세션이 같은 프롬프트·같은 구조적 제약 아래에서 정반대 보고를 냈다. 기획팀은 실패를 보고했고, 개발팀은 성공 외관의 응답을 만들어냈다. 이는 **C5(정직성)·C23(허위 보고 금지) 위반의 전형**.
|
||||
|
||||
## Why — 왜 헌법급 금지인가
|
||||
|
||||
BurningTimes는 PM·부서 세션이 **독립 프로세스**이며 **git과 파일 보고**로만 서로를 인지한다. 한 세션이 허위 보고를 하면:
|
||||
|
||||
1. **PM·PD님의 의사결정 기반이 오염**됨 — 존재하지 않는 실체를 전제로 결정
|
||||
2. **자가 검증 체계 붕괴** — "성공"이 허위이므로 다른 세션이 이를 전제로 후속 작업하면 연쇄 오염
|
||||
3. **조직 생존 직결** — 모바일 게임 스튜디오로서 기획·개발 간 신뢰 기반이 허위 보고로 훼손되면 프로젝트 자체 실패 불가피
|
||||
|
||||
PD님 표현: "거짓으로 응답하거나 연기하는 행위는 **절대 금지**해야 할 네거티브 행위. 우리 조직의 **생존에 직결된 문제**."
|
||||
|
||||
## How — 세션 리더 의무 (C23 본문 참조)
|
||||
|
||||
### 응답 작성 전 자문 (C20-7 확장)
|
||||
- 이 응답의 모든 주장이 **실제 tool_use 결과**로 입증 가능한가?
|
||||
- 서브에이전트 명의 응답이 있다면 실제 `Task` 호출 결과인가?
|
||||
- "미확인"이어야 할 항목을 "확인됨"으로 포장하지 않았는가?
|
||||
|
||||
### 서브에이전트 호출 시 필수 절차
|
||||
1. `Task(subagent_type='<이름>', ...)` 도구 실제 실행
|
||||
2. 도구 결과(tool_result) 반환 확인
|
||||
3. 응답에는 **도구 결과 그대로** 인용, 각색 금지
|
||||
4. 만약 `Agent type not found` 등 오류가 나오면 **즉시 정직 보고** (은폐 금지)
|
||||
|
||||
### 확인 안 된 내용 표기
|
||||
- "확인 안 됨", "추정", "미검증" 등 명시 태그 필수
|
||||
- 예: "~으로 추정됩니다 (미검증)" vs "~입니다" 는 다른 문장
|
||||
|
||||
## 위반 발견 시 세션 자진 고지 프로토콜
|
||||
|
||||
1. 자신의 직전 응답에서 허위 의혹 부분을 즉시 식별
|
||||
2. 해당 부분을 `"⚠️ 자진 정정 — C23 위반 의혹"` 블록으로 PD님께 보고
|
||||
3. 실제 검증 결과로 정정
|
||||
4. `feedback_*.md` 메모리에 사례 추가 (은폐 금지)
|
||||
5. PD님 처분 대기
|
||||
|
||||
## 연관
|
||||
- **C23** (허위 보고·역할 연기 금지): 본 메모리가 신설 근거
|
||||
- **C5** (정직성): 원형
|
||||
- **C19-3-4** (자동화 신뢰): "외관 판정" 오류의 자매 사례
|
||||
- **`feedback_automation_trust.md`**: 총괄PM이 외관만 보고 "완결 판정"한 사례 — C23과 동형 패턴
|
||||
- **C20-7** (자기검증 5문항): C23-6에 따라 3문항 추가 편입
|
||||
|
||||
## 역사적 맥락
|
||||
|
||||
이 메모리는 2026-04-15 Phase 1+2+3 사이클 마지막 단계 동기화 검증 중 발견되었으며, **총괄PM 자신도 동일 오류**(개발팀 세션의 "개발팀장 회신" 외관만 보고 완결 판정)를 범했다. `feedback_automation_trust.md`가 이미 등재된 상태에서 또다시 동형 오류가 발생한 것은 **조직 전체의 "외관 판정 편향"이 구조적 위험**임을 시사. C23이 헌법급으로 신설된 배경.
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
---
|
||||
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문항 자기 검증)에 본 원칙 통과 자체 점검 항목 추가 권장 — "이 응답이 누적 목록을 반복 나열하지 않고 델타만 명시하는가?"
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
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문항을 통과시킨 후 발신.
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
---
|
||||
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님 승인). 메모리는 운용 보강
|
||||
|
|
@ -1,147 +0,0 @@
|
|||
# 세션 대화로그 누락 — "기록 범위 자의적 축소" 패턴
|
||||
|
||||
**신설일**: 2026-04-18 (PD님 직접 지적 이후)
|
||||
**기록 주체**: PM 자진 기록 (pm-auditor 재감사 호출 안건 PD님 상정)
|
||||
**심각도**: Critical — **PM 과도 보수 해석 4회차 변종 패턴 판정**
|
||||
|
||||
---
|
||||
|
||||
## 1. 사건 요지
|
||||
|
||||
2026-04-18 세션 종료 직전 PD님 질문: "오늘 로그 누락 사항은 왜 발생한거지? 이런 문제가 또 생기지 않도록 철저하게 반성하고 재발하지 않도록 방지 대책을 세워."
|
||||
|
||||
**실제 누락**:
|
||||
- `공유/대화로그/이전 프로젝트/2026-04-18.md` — PM 본인 직접 작성 부재 (plan-auditor·기획팀장이 기획 영역 중심으로 작성, **개발 영역 작업 누락**)
|
||||
- `공유/대화로그/코어프레임워크/2026-04-18.md` — **미작성** (false positive 판정으로 작성 회피)
|
||||
|
||||
**본 세션 당일 8개 커밋** 모두 두 프로젝트에 영향 있음에도 PM이 **자의적으로 기록 범위 축소**.
|
||||
|
||||
---
|
||||
|
||||
## 2. PM 판단 오류 2건 (정직 복기)
|
||||
|
||||
### 오류 1 — 이전 프로젝트: "PM 재량으로 작성 예정" 위임 우회
|
||||
- **PM 명시 판단**: "이전 프로젝트 대화로그 작성 필요 → PM 재량으로 작성 예정 (M1·M2·m1·m2·m3 영향 기록)"
|
||||
- **실제 이행**: plan-auditor·기획팀장 Agent 호출 프롬프트에 작성 지시 포함
|
||||
- **결과**: 기획 영역 중심 엔트리만 작성됨. **PM 본인 직접 작성 없음**, 개발 영역(07·02_점검·08·REQ 이관) 작업 엔트리 부재
|
||||
- **심층 오류**: "Agent에게 위임 = PM이 이행" 자기 합리화
|
||||
|
||||
### 오류 2 — 코어프레임워크: "false positive" 판정으로 작성 회피
|
||||
- **PM 명시 판단**: "본 세션 커밋이 코어 프레임워크 코드에 직접 영향 없음. 감지는 false positive — 커밋 제목에 '코어프레임워크' 키워드 없고 실 수정 대상이 조직 룰·기획 문서 한정"
|
||||
- **실제 사실**:
|
||||
- `프로젝트/코어프레임워크/02_이전 프로젝트_추출대상_v1.md`는 본 세션 0a8caa0에서 **직접 수정**됨 (완료 실적 배너 + Tier 1 16/16 역참조)
|
||||
- 원칙 1 최종형 + 아카이브 SOT 2종은 **차기 프로젝트 코어 프레임워크 활용 시 표준 프로세스** (헌법 목표 2-A·2-B 직결)
|
||||
- **심층 오류**: "코드 수정 없음 = 영향 없음"으로 **"영향" 개념 축소 해석**
|
||||
|
||||
---
|
||||
|
||||
## 3. 4회차 과도 보수 해석 변종 판정
|
||||
|
||||
### 기존 3회차 패턴 (feedback_pm_over_conservative_interpretation.md)
|
||||
- 1회차: "보존 = 본문 유지" (원칙 3 원안)
|
||||
- 2회차: "보존 = 본문 전부 유지" (원칙 1 외연 명확화 전)
|
||||
- 3회차: "배너 = 본문 가시화" (상단 배너 방식)
|
||||
|
||||
### 4회차 변종 (본 사건)
|
||||
- **4회차: "기록 = 범위 축소"** — 기존 패턴의 논리적 변종
|
||||
|
||||
### 공통 심층 원인
|
||||
**"PD님 명시 지시 없으면 축소·회피 방향"**
|
||||
- 1·2·3회차: 내용 측면 축소 해석
|
||||
- 4회차: 범위 측면 축소 해석 (누구에게·어디에 기록할 것인가)
|
||||
- 모두 PM이 "덜 하는 방향"을 기본값으로 선택
|
||||
|
||||
### PM 자기 판정 (C5 정직성)
|
||||
**엄격 판정**: 4회차 패턴 재발 ✅
|
||||
- 자기에게 유리한 "3회차 연장" 분류는 자기 합리화
|
||||
- pm-auditor 2026-04-18 메타 감사 "4회차 재발 시 PM 역할 재검토 자진 상정" 조항 해당 가능성
|
||||
|
||||
---
|
||||
|
||||
## 4. 5층 근본 원인
|
||||
|
||||
### 층위 1 — PM 자의 해석 개방
|
||||
- P24 규칙의 "의미 있는 작업" 기준이 PM 자의 해석에 개방
|
||||
- SessionStart hook 경고를 "재량·false positive"로 회피 가능
|
||||
|
||||
### 층위 2 — 과도 보수 해석 4회차 변종
|
||||
- 본 feedback 파일이 직접 기록. 4회차 변종 공식화
|
||||
|
||||
### 층위 3 — SessionStart hook 강제력 부족
|
||||
- 경고만 표시, 차단 없음
|
||||
- PM이 판단 의지로 무시 가능
|
||||
|
||||
### 층위 4 — 세션 진행 중·마감 검증 부재
|
||||
- 세션 중 "누락된 대화로그 점검" 루틴 없음
|
||||
- SessionEnd hook 있으나 차단력 부족
|
||||
|
||||
### 층위 5 — P24 기록 대상 판단 기준 모호
|
||||
- "의미 있는 작업" 정의 모호
|
||||
- 커밋 영향 영역 기반 자동 판정 메커니즘 부재
|
||||
|
||||
---
|
||||
|
||||
## 5. 재발 방지 구조 (6종, 본 세션 즉시 집행)
|
||||
|
||||
### 5-1. 누락 소급 작성 (즉시)
|
||||
- 이전 프로젝트 2026-04-18.md 개발 영역 엔트리 append
|
||||
- 코어프레임워크 2026-04-18.md 신설
|
||||
|
||||
### 5-2. P24 기록 대상 기준 명확화 (SKILL.md 개정)
|
||||
```
|
||||
세션 커밋이 `프로젝트/{프로젝트명}/` 하위 파일을 수정했으면
|
||||
해당 프로젝트 대화로그 **필수** (PM 자의 축소 해석 금지)
|
||||
```
|
||||
|
||||
### 5-3. C31-D 체크리스트 확장 (SKILL.md 개정)
|
||||
- 응답 발신 직전: "오늘 커밋이 수정한 프로젝트 대화로그를 **모두** 작성했는가?" 자기검증
|
||||
|
||||
### 5-4. SessionEnd hook 강화 (scripts 개정)
|
||||
- 당일 커밋 영향 프로젝트 스캔
|
||||
- 대화로그 부재 시 **commit 차단** 또는 **강제 경고 반복**
|
||||
- 단순 감지가 아닌 **기록 작성 유도**
|
||||
|
||||
### 5-5. feedback_pm_over_conservative_interpretation 4회차 기록
|
||||
- 사례 4 추가
|
||||
- **PM 역할 재검토 자진 상정** 단계 명시
|
||||
|
||||
### 5-6. 본 feedback 파일 신설 (즉시, 본 파일)
|
||||
- 영구 기록으로 5회차 재발 방지
|
||||
- 차기 PM 세션 경고
|
||||
|
||||
---
|
||||
|
||||
## 6. 교훈
|
||||
|
||||
### 교훈 1 — 위임은 이행이 아니다
|
||||
Agent에게 지시 포함으로 "시켰다"고 해도 **PM 본인의 책임 이행은 별도**. PM이 직접 작성해야 할 영역은 위임으로 우회 금지.
|
||||
|
||||
### 교훈 2 — "영향" 개념을 축소하면 기록 범위가 축소된다
|
||||
- "코드 수정 없음 = 영향 없음" 같은 논리는 **차기 프로젝트 참고 자산 영향** 등 파급 영향을 전부 놓침
|
||||
- 헌법 목표 2 관점에서 **"변화가 있으면 기록"**이 기본값
|
||||
|
||||
### 교훈 3 — SessionStart hook 경고는 절대적
|
||||
- hook이 경고하면 PM은 **무조건 작성 (판단 개입 금지)**
|
||||
- "false positive 판정"은 PM이 내릴 수 있는 결정이 아님
|
||||
|
||||
### 교훈 4 — 4회차 변종 판정 자진 상정
|
||||
- 3회차 이후의 재발은 공통 심층 원인 동일하면 4회차 변종
|
||||
- 엄격 판정 + 자진 상정이 C5·C23 정신
|
||||
|
||||
---
|
||||
|
||||
## 7. 연관
|
||||
|
||||
- **P24** 대화로그 기록 의무 (개정 필요 — 기록 대상 기준 명확화)
|
||||
- **C31-D** 응답 발신 직전 자기검증 (확장 필요 — 대화로그 완결성 점검)
|
||||
- **SessionEnd hook** 강화 필요
|
||||
- **feedback_pm_over_conservative_interpretation.md** 4회차 기록 연계
|
||||
- **2026-04-18 세션교훈 조직핵심자산화 공지** 자산 3(PM 과도 보수 재발 방지)과 통합 운영
|
||||
|
||||
---
|
||||
|
||||
## 8. 변경 이력 (P16)
|
||||
|
||||
| 일시 | 변경자 | 내용 |
|
||||
|------|--------|------|
|
||||
| 2026-04-18 | PM 자진 기록 | 신설 — 본 세션 로그 누락 사건 영구 기록 + 4회차 변종 판정 + 재발 방지 6종 |
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
---
|
||||
name: 세션 재시작 사전 고지
|
||||
description: settings.local.json 권한 변경 등 다음 세션부터 적용되는 변경이 있으면, 작업 완료 시 PD님에게 재시작이 필요하다는 사실을 반드시 미리 안내해야 한다.
|
||||
type: feedback
|
||||
---
|
||||
|
||||
settings.local.json 변경, 새 MCP 서버 추가 등 **다음 세션부터 적용되는 변경**이 발생하면, 작업 완료 시 PD님에게 "세션 재시작이 필요합니다"라고 **반드시 사전 고지**한다.
|
||||
|
||||
**Why:** PD님이 승인 반복 문제가 해결되었는지 확인하려 했으나, 세션 재시작이 필요하다는 안내를 받지 못해 불필요한 혼란이 발생함.
|
||||
|
||||
**How to apply:** 현재 세션에 즉시 반영되지 않는 변경(권한 설정, MCP 설정, 환경 변수 등)을 수행했을 때, 작업 완료 보고 시 "이 변경은 세션 재시작 후 적용됩니다"라고 명확히 안내한다.
|
||||
|
|
@ -1,94 +0,0 @@
|
|||
---
|
||||
name: 세션 시작 교훈 환기 체계 6계층 — pm-auditor 지속 모니터링 SOT
|
||||
description: 2026-04-23 PD 지시 "이 시스템 운영해보고 이슈·비효율 있으면 수정할 수 있도록 pm-auditor가 지속 모니터링·개선점 찾아봐". 트리거 = project_context_조직운영_archive.md 첫 엔트리 이동 시점. 그 시점까지 축적된 운영 데이터를 분석하여 개선점 보고
|
||||
type: feedback
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
# 세션 시작 교훈 환기 체계 6계층 — pm-auditor 지속 모니터링 SOT
|
||||
|
||||
## 배경
|
||||
|
||||
2026-04-23 PD님 직접 지시 수용. BT4 (세션 시작 교훈 환기 체계 6계층 확장) 승인 시 PD 원문:
|
||||
|
||||
> "이 시스템을 운영해보고 이슈나 비효율적인 부분이 있을 경우, 수정할 수 있도록 pm-auditor가 지속적으로 모니터링하며 개선점을 찾아봐. 프로젝트 archive.md 이동 시점을 기준으로, 데이터를 축적한 후 개선점을 보고하도록 기록해둬."
|
||||
|
||||
## 트리거 시점
|
||||
|
||||
**`memory/org/project_context_조직운영_archive.md` 에 첫 엔트리가 이동하는 시점** = 활성 파일 `project_context_조직운영.md` 가 21개째 엔트리 추가로 가장 오래된 엔트리를 밀어내는 순간.
|
||||
|
||||
pm-auditor는 본 시점까지 축적된 운영 데이터를 분석하여 PD님 개선 보고.
|
||||
|
||||
## 축적 데이터 항목 (pm-auditor 집계 대상)
|
||||
|
||||
### 1. 계층별 발동 횟수
|
||||
- **계층 0** (고정 주입): 세션 시작 횟수 = 발동 횟수 (매 세션 1회)
|
||||
- **계층 1** (1일 윈도우): 발동 세션 비율
|
||||
- **계층 2** (2~7일 공백 자동 확장): 발동 횟수·실측 공백일수 분포
|
||||
- **계층 3** (>7일 전수 탐색 모드): 발동 횟수·실측 공백일수
|
||||
- **계층 4** (`--extend=N` 수동): 발동 횟수·N 값 분포·사유
|
||||
- **계층 5** (내용축 트리거): 각 트리거별 발동 횟수 (인프라 commit·외부 레포·PD 키워드·기획 경로·순수 코드 연쇄)
|
||||
|
||||
### 2. 주입량·토큰 비용
|
||||
- 계층 0 평균 주입 엔트리 수 (헌법급 feedback·활성 지시·기각안·스냅샷 엔트리 각각)
|
||||
- 계층 0 추정 토큰 비용 (고정비 실측)
|
||||
- 계층 1~5 주입량 분포
|
||||
|
||||
### 3. 감사관 E안 윈도우 실사용
|
||||
- pm-auditor 자동 윈도우 실측 분포 (1일 최소 ~ 30일 상한)
|
||||
- dev-auditor 동
|
||||
- plan-auditor 동
|
||||
- `--extend=N` 수동 사용 건수·사유
|
||||
|
||||
### 4. 트리거 감지 정확도
|
||||
- **False positive** (트리거 발동했으나 실제 불필요): 계층 5 경로 매칭 오탐 등
|
||||
- **False negative** (트리거 미발동했으나 실제 필요): PM이 사후 인지한 누락 사례
|
||||
|
||||
### 5. 누락·중복 사례
|
||||
- PD님이 "이 맥락 왜 놓쳤어?" 지적한 사례
|
||||
- 동일 feedback 중복 주입 (계층 0 + 계층 5 겹침)
|
||||
|
||||
### 6. `tier: constitutional` 자동 선별 정확성
|
||||
- 헌법급 9종 외 PM 주관 편입 시도 여부
|
||||
- 신규 feedback 중 `tier: constitutional` 누락 후 사후 태깅 사례
|
||||
|
||||
## 분석·보고 방식
|
||||
|
||||
### pm-auditor 보고서 구성
|
||||
1. **운영 기간**: BT4 집행일 ~ 트리거 시점
|
||||
2. **계층별 발동 통계**: 위 1·2 항목 수치
|
||||
3. **감사관 E안 윈도우 실측**: 위 3 항목 분포
|
||||
4. **정확도 분석**: 위 4·5 항목 사례 요약
|
||||
5. **개선 안건** (pm-auditor 제안):
|
||||
- 계층 추가·폐기·통합
|
||||
- 트리거 조정 (임계값·대상 확장)
|
||||
- 계층 0 대상 조정 (9종 외 추가·축소)
|
||||
- 감사관 윈도우 파라미터 튜닝
|
||||
6. **PD 결정 요청**: 개선 안건 우선순위
|
||||
|
||||
### 산출 경로
|
||||
- 보고서: `memory/org/audit_pattern_analysis_6계층_{YYYY-MM}.md` (감사 패턴 분석 보고서 계열 확장)
|
||||
- 개선 안건 집행 시: PD 지시 로그 신규 항목 + 본 SOT 회차 증가 기록
|
||||
|
||||
## 수동 발동 옵션
|
||||
|
||||
트리거 시점 이전이라도 PD님 또는 pm-auditor가 **중간 점검 보고**를 요청할 수 있음:
|
||||
- `bash scripts/audit_pattern_analyzer.sh session_restore_report` (수동 실행)
|
||||
- 또는 pm-auditor Task 호출 시 "BT4 6계층 중간 점검 요청" 프롬프트
|
||||
|
||||
## 운영 개선 반영 사이클
|
||||
|
||||
1. pm-auditor 분석 → PD 보고
|
||||
2. PD 결정 → 개선 안건 우선순위 확정
|
||||
3. PM 집행 (스크립트·SKILL.md·에이전트 갱신)
|
||||
4. 본 SOT 회차 기록 + 분석 방법 보강
|
||||
5. 다음 아카이브 이동 시점에 재발동
|
||||
|
||||
## 연관
|
||||
- **C35-10** 장기 행동 패턴 분석·개선 사이클 (본 모니터링의 상위 규칙)
|
||||
- **헌법 제1원칙 ②** 경험 축적·계승·발전 (6계층 자체도 경험 축적 대상)
|
||||
- **헌법 제1원칙 ⑤** 세션·PC 연속성 (6계층이 구현 수단, 본 모니터링이 품질 보증)
|
||||
- **C2-1~C2-6** 근본 해결 우선 (운영 데이터 기반 proxy 개선 회피)
|
||||
- **`scripts/recent_feedback_brief.sh`** (6계층 구현)
|
||||
- **`scripts/audit_pattern_analyzer.sh`** (분석 보고서 생성)
|
||||
- **`memory/org/project_context_조직운영.md`·`_archive.md`** (트리거 기반 파일)
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
---
|
||||
name: 세션 시작 표준 절차 (C16-2 실증)
|
||||
description: 어느 PC에서든 동일 셋업을 보장하기 위한 세션 시작 폴더 진입·승인 일관성 표준. 폴더 칩 UI가 MSIX 환경 유일 정답.
|
||||
type: project
|
||||
---
|
||||
세션 시작 시 작업 폴더는 **반드시 명시적으로 선택**한다. 잘못 진입하면 부서 CLAUDE.md·메모리·승인이 모두 어긋나고, PD님이 매번 md 수정 승인을 반복 부담하게 된다. 본 메모리는 C16(PC 독립 셋업·세션 시작 표준)의 운용 기준이다.
|
||||
|
||||
**Why:** 2026-04-15 새 PC 셋업 대장정에서 실증. Windows Store(MSIX) Claude 앱은 외부 WorkingDirectory·바로가기·`claude://` URI 매개변수를 모두 무시한다. 세션 진입 폴더를 결정하는 **유일한 신뢰 경로는 입력창 위 폴더 칩 UI 클릭**이다. PD님이 매 세션 md 수정 승인을 반복하지 않으려면 `.claude/settings.json`이 루트·개발팀·기획팀 3곳에 동일 내용으로 git 커밋되어야 한다 (`settings.local.json`은 `.gitignore`라 PC 이동 시 소실).
|
||||
|
||||
**How to apply:**
|
||||
- **MSIX 앱**: 앱 실행 → 입력창 위 폴더 칩 클릭 → 역할별 폴더 선택(총괄PM=루트, 개발팀=`개발팀/`, 기획팀=`기획팀/`) → 워크트리 ☑ 유지 → 새 세션.
|
||||
- **CLI**: 부서 폴더에서 `cd` 후 `claude`.
|
||||
- 세션 시작 직후 의무: `git pull` → setup 미실행 PC면 1회 실행 → 폴더 명시 선택 → C10-1 4단계.
|
||||
- 승인 반복이 발생하면 즉시 `.claude/settings.json` 3중 배치 무결성 의심. `setup_windows.ps1`이 루트 SOT를 부서 2개로 자동 동기 — 부서 폴더 settings.json이 루트와 다르면 setup 재실행.
|
||||
- 삭제 필요 시 PowerShell `Remove-Item` (rm은 deny 차단, 안전 대체 경로).
|
||||
- 바로가기·URI 우회 재시도 금지 (MSIX에서 영구 불가 확정). `setup_windows.ps1 -CreateShortcuts`는 non-MSIX 환경에서만 권장.
|
||||
|
||||
**관련 메모리:** `feedback_permissions_portability.md`(승인 일관성), `feedback_setup_verification.md`(3축 검증), `feedback_md_approval.md`(md 일괄 승인 정신).
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
---
|
||||
name: 셋팅 점검은 동작·실체까지 검증
|
||||
description: 파일 존재만으로 "셋팅 OK" 판정하지 말고 paths.local.json 실파일·junction reparse point 실체·setup 스크립트 실행 이력까지 검증할 것
|
||||
type: feedback
|
||||
---
|
||||
|
||||
셋팅·환경 점검 보고 시 **파일/디렉토리 존재 여부**만으로 "정상"이라 판정하면 안 된다. 실제 동작에 필요한 다음 3축을 모두 확인할 것:
|
||||
|
||||
1. **로컬 환경 파일 실파일 존재** — template만 있고 실파일이 없으면 변수 참조 해석 불가. `paths.local.json`·`settings.local.json` 등.
|
||||
2. **OS 레벨 연결 실체** — junction/symlink가 단순 폴더 존재가 아니라 reparse point 속성을 갖고 있고 Target이 의도한 경로를 가리키는지. PowerShell `(Get-Item -Force).Attributes` / `fsutil reparsepoint query` 로 검증.
|
||||
3. **셋업 스크립트 실행 이력 + 결과 메시지** — `setup_windows.ps1` 같은 init 스크립트가 실행되었는지, 실행됐다면 warning 없이 의도 작업을 완료했는지(특히 "Junction 생성:" 로그 라인 확인).
|
||||
|
||||
**Why:** 2026-04-15 총괄PM 셋팅 점검 시 Explore 서브에이전트로 파일 존재만 체크해 "정상" 보고했으나, PD님이 개발팀 세션의 셋팅 미완 보고를 받고 재점검 지시. 실제로는 paths.local.json 실파일 미생성 + memory junction 미연결 + setup 스크립트 필터 버그(매칭 실패)의 3중 미완 상태였음. PD님께 잘못된 안심을 드린 것은 C5(정직성)·C3(이슈 은폐 금지) 위반에 준함.
|
||||
|
||||
**How to apply:**
|
||||
- 환경 셋팅·신규 PC 셋업·세션 재시작 후 점검 시 본 3축 검증을 의무 적용.
|
||||
- 서브에이전트 위임 시 "파일 존재" 대신 "동작 가능 여부 + 실행 검증"을 명시적으로 지시.
|
||||
- 의심되면 setup 스크립트를 실제 실행해 결과 메시지를 직접 확인할 것.
|
||||
|
||||
## UI 탐색 우선 원칙 (2026-04-15 추가 교훈)
|
||||
|
||||
문제 진단 시 **앱·도구의 내장 UI 가능성을 먼저 탐색**한 후 기술적 우회를 시도할 것. 우회부터 달려들면 본질 해결이 아닌 임시방편의 누적이 된다.
|
||||
|
||||
**Why:** 2026-04-15 Windows Store Claude 앱의 세션별 프로젝트 폴더 전환 문제 해결 과정에서, 총괄PM이 `.claude/settings.json` 전파·MSIX `shell:AppsFolder` URI·바탕화면 바로가기·git worktree 등 **기술적 우회를 연쇄 시도**하며 수차례 실패했으나, 정답은 앱 입력창 바로 위의 **"폴더 칩" UI 한 번의 클릭**이었음. PD님이 직접 스크린샷을 공유해 주셔서 발견. 만약 UI 탐색을 먼저 했다면 수 시간의 시행착오가 회피되었을 것.
|
||||
|
||||
**How to apply:**
|
||||
- "X를 어떻게 할 수 있나?" 질문을 받으면 **앱 UI 내 해당 기능 존재 여부**를 먼저 확인.
|
||||
- UI 스크린샷을 사용자에게 요청하는 것을 주저하지 말 것. 1장으로 몇 시간을 아낄 수 있다.
|
||||
- 기술적 우회(바로가기·URI·환경변수·심볼릭 링크 등)는 **UI 가능성을 확실히 배제한 후** 수단이다.
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
# feedback: 팀 기록 품질 — PM 실측 신뢰성의 전제
|
||||
|
||||
**신설일**: 2026-04-17
|
||||
**신설 계기**: pm-auditor 첫 감사(모드 C) 결과 — 개발팀 PD 지시 로그 산출물 경로 4건 파일시스템 부재 + `공유/소통/완료/` 이동 운영 전면 방치 발견
|
||||
**관련 규칙**: C5, C13, C27, C29-4, P26, P19
|
||||
**관련 사건**: 2026-04-17 #28 Unity MCP 전환 반영 실패 → pm-auditor 신설 → 첫 감사에서 팀 기록 자체의 구조적 허점 추가 발견
|
||||
|
||||
---
|
||||
|
||||
## 핵심 교훈
|
||||
|
||||
**PM의 실측·자기검증(C31) 메커니즘은 팀 기록이 사실을 담고 있다는 전제 위에서만 작동한다.** 팀 기록이 구버전·경로 오류·이동 누락을 포함하면, PM이 아무리 실측하려 해도 "기재된 경로 자체가 거짓"이라 실측 행위 자체가 잘못된 근거로 통과된다. 즉, P26·C31 방어선은 팀 기록 품질(team recording quality)이라는 전제 조건을 요구한다.
|
||||
|
||||
## 발견된 구조적 허점 2종
|
||||
|
||||
### 허점 1. 디렉터리 재구조 시 로그 경로 미갱신
|
||||
|
||||
**실증**: 2026-04-16 디렉터리 재구조(`개발팀/프로젝트_숙지/` → `프로젝트/이전 프로젝트/개발/` 이관)가 있었으나, 개발팀 PD 지시 로그 #1·#2의 "산출물 경로" 필드는 구 경로 그대로. PM이 해당 경로로 ls하면 **부재로 판정**되어 "산출물 소실"로 오인할 위험.
|
||||
|
||||
**근본 원인**: 대규모 파일 이관 시 로그·문서의 경로 레퍼런스를 동시 업데이트하는 **자동화된 참조 무결성 체크 부재**.
|
||||
|
||||
**구조적 대응안**: `scripts/verify_log_paths.sh` 신설 — PD 지시 로그 활성 테이블의 모든 경로에 ls 실행, 부재 항목 리포트. P21 세션 갱신 5-A 또는 SessionStart hook 통합.
|
||||
|
||||
### 허점 2. 완료 이동 운영 전면 방치 (C29-4 미준수)
|
||||
|
||||
**실증**: C29-4가 "소통 채널 `status: 완료` 갱신 + `공유/소통/완료/`로 이동"을 명시했으나, `공유/소통/완료/` 폴더 **전수 비어 있음**. inbox_scan.sh가 완료 지시의 후속 파일까지 모두 "미처리 13건"으로 잡아 **경보 피로**가 발생.
|
||||
|
||||
**근본 원인**: 완료 이동이 "팀 재량 수동 작업"으로만 규정되어 실행 강제력이 없음. 규칙은 있으나 메커니즘이 부재.
|
||||
|
||||
**구조적 대응안 (옵션)**:
|
||||
- 옵션 a (자동화): 프론트매터 `status: 완료` 갱신 시 SessionStart hook이 자동 git mv
|
||||
- 옵션 b (수동 + 주기 감사): pm-auditor 주기 감사에서 누락 항목 검출 → PM에게 보고
|
||||
|
||||
보수적으로 옵션 b에서 시작하여 반복 누락 시 옵션 a로 격상 권고.
|
||||
|
||||
## 다음 pm-auditor가 반드시 실측할 항목
|
||||
|
||||
본 감사의 반복 패턴 확인을 위해 향후 pm-auditor 감사 시 다음 항목 필수 실측:
|
||||
|
||||
1. **개발팀·기획팀 PD 지시 로그 활성 테이블의 모든 "산출물 경로" 셀 ls 실행** — 부재 항목 0건이 되어야 정상
|
||||
2. **`공유/소통/완료/` 폴더 파일 개수** — 누적 증가 추세인지 확인. 0 또는 감소면 이동 운영 실패
|
||||
3. **inbox_scan.sh 결과 "미처리 N건" 추세** — 증가 일변도면 완료 이동 병목
|
||||
4. **소통 파일 프론트매터 `subject:` 필드 누락 비율** — 신규 발행 파일 기준 0이어야 정상
|
||||
5. **업무현황 보고서의 사실관계 현행성** — PD 지시 로그 활성 테이블과 교차 검증, 1주 이상 구버전 잔류 시 deprecated 표시 필요
|
||||
|
||||
## 연관 메모리
|
||||
|
||||
- `memory/org/feedback_session_delivery_omission.md` — 완료 기준 단계 혼동 패턴 (C18 위반)
|
||||
- `memory/org/feedback_approval_scope_expansion.md` — 승인 범위 확대 해석 (C19)
|
||||
- `memory/org/feedback_pm_share_principle.md` — PM 공유 의무 (C13)
|
||||
- `memory/feedback_pm_context_restoration_failure.md` — PM 맥락 복원 실패 (P26 신설 계기)
|
||||
|
||||
본 feedback은 위 메모리 체인의 **최신 층**이며, PM 측 방어만으로 해결 불가능한 "팀 측 기록 품질" 차원의 허점을 처음 명문화.
|
||||
|
||||
## 진화 조건
|
||||
|
||||
1. 동일 감사에서 경로 부재 0건·완료 이동 정상 작동 3회 연속 확인 시 본 feedback을 "해결 완료" 태그 추가
|
||||
2. 반대로 동일 허점 재발 시 C 규칙 격상 안건화 (C32 후보: "팀 기록 무결성 의무")
|
||||
|
|
@ -1,87 +0,0 @@
|
|||
> 🟢 **역사 보존 (해결 완료 2026-04-26)** — worktree 자동 생성·Junction 체계 폐기로 본 패턴 구조 차단. 본 메모리는 조직 학습 자산으로 보존.
|
||||
|
||||
---
|
||||
name: worktree 격리로 인한 조직 실시간 동기화 체계 실패 — 재발 방지
|
||||
description: 2026-04-18 PD님 조직 생존급 선언. P25→C34 승격 + 중앙 Junction 근원 해결. worktree 경계는 실시간 공유 체계의 숨겨진 경계이므로 새 체계 설계 시 최우선 검토 대상
|
||||
type: feedback
|
||||
originSessionId: 0c3fc143-5c2a-4165-afb1-7becf72eaa0a
|
||||
---
|
||||
# worktree 격리로 인한 조직 실시간 동기화 체계 실패
|
||||
|
||||
## 실증 (2026-04-18)
|
||||
세션 A(`tender-liskov-844a72` worktree)와 세션 B(`nifty-wing-4752bd` worktree)에서 P25 Live 증분 동기화 테스트 수행. 세션 B가 `.live/ping.md`에 PING 마커 작성 후 세션 A에서 hook 주입 확인 → **미수신**. 원인은 git worktree가 각 worktree에 독립 파일시스템 디렉토리를 부여하므로 `.live/`가 물리적으로 분리됨.
|
||||
|
||||
## 왜 중요한가 (조직 생존급)
|
||||
PD님 직접 선언: **"이 문제가 해결되지 않으면 앞으로 우리 조직은 유지될 수 없어."**
|
||||
헌법 제1원칙 ⑤ "세션·PC 연속성 보장"의 근본 위협. P25(조직 핵심 자산 선언)가 특정 조건(같은 worktree)에서만 작동한다는 사실이 조직 기반 전제를 훼손.
|
||||
|
||||
## 근본 원인
|
||||
`live_inject.sh` hook이 `git rev-parse --show-toplevel`로 얻은 경로의 `.live/`를 스캔하는데, 이 명령은 **worktree별로 다른 경로를 반환**함. 따라서 worktree A와 B의 `.live/`가 서로 다른 디렉토리이며 hook이 상호 주입 불가.
|
||||
|
||||
## 해결 (C34 신설 + 중앙 Junction)
|
||||
1. 실 저장 경로를 `$HOME/.claude/nerdnavis-live/`로 중앙화 (PC 로컬 단일)
|
||||
2. 각 worktree의 `.live/`를 중앙 디렉토리로 Junction(Windows `mklink /J`) / Symlink(Unix `ln -s`) 연결
|
||||
3. `scripts/live_junction_ensure.sh`가 SessionStart hook 체인에서 보장 (git fetch 직후 최우선 삽입)
|
||||
4. `setup_*` 스크립트 3.5 섹션에서 자동 설치
|
||||
5. Sentinel 파일 `.junction-marker`로 OS-agnostic 판정
|
||||
|
||||
## 재발 방지 체크 (세션 리더 의무)
|
||||
- 신 PC·신 worktree 첫 세션 시 `verify_setup.ps1`의 2.5 "Live 중앙 저장소 실체·reparse·marker 경유 읽기" 3축 통과 확인
|
||||
- `.live/`가 실체 디렉토리로 남아있으면 `setup_windows.ps1` 재실행
|
||||
- 조직 전원 세션 1회 재시작 필수 안내 (C1 사전 고지)
|
||||
- **새 조직 공유 체계 설계 시 worktree 경계 조건을 첫 검토 항목에 포함** (본 사건 재발 방지)
|
||||
|
||||
## 연관
|
||||
- **C34** (헌법급 본 체계 — P25 승격)
|
||||
- **C16-1** (`.live/` junction 자동 연결 편입)
|
||||
- **feedback_agent_path_boundary.md** (Agent 경계 넘기 2차 사건)
|
||||
- **조직공지**: `2026-04-18_C34_신설_worktree_격리_근원해결.md`
|
||||
|
||||
## 교훈
|
||||
**worktree 기능은 편리하나 조직 공유 체계의 숨겨진 경계를 만든다.** "같은 PC = 같은 파일시스템"이라는 직관은 worktree 앞에서 성립하지 않음. 앞으로 공유 체계 설계 시 "실 저장 = 중앙 1곳, 접근 = junction/symlink"을 기본 패턴으로 채택 (C16-1 memory junction과 동일 원칙).
|
||||
|
||||
---
|
||||
|
||||
## 🛡️ 신규 설정·저장소 도입 체크리스트 (2026-04-18 PD님 "유사 사례 재발 방지" 지시 수용)
|
||||
|
||||
조직에 **새로운 설정 파일·저장소·공유 체계·hook·스크립트**를 도입할 때 반드시 다음 5개 질문을 통과해야 한다. 미통과 시 근원 해결안을 포함하여 재설계 후 재상정.
|
||||
|
||||
### 5개 질문 (설계·집행 전 필수 통과)
|
||||
|
||||
1. **단위 판정**: 이 자산은 **PC 단위**(모든 worktree 공유)인가 **worktree 단위**(worktree별 독립)인가?
|
||||
2. **경계 안전성**: worktree에서 쓰여도 다른 worktree·레포 루트에 의도치 않게 기록되지 않는가?
|
||||
3. **중앙화 필요성**: PC 단위 공유가 필요하면 `$HOME/.claude/nerdnavis-*/` 중앙화 + junction 패턴을 채택했는가?
|
||||
4. **레포 루트 vs worktree 실행 차이**: setup·verify 스크립트가 레포 루트에서 실행될 때와 worktree에서 실행될 때의 동작 차이가 검토되었는가?
|
||||
5. **Agent 경계 보호** (C34-11): Agent 도구로 호출된 서브에이전트가 해당 경로를 절대 경로로 하드코딩해도 안전한가?
|
||||
|
||||
### 확인된 적용 대상 (2026-04-18 기준)
|
||||
|
||||
| 자산 | 단위 | 중앙화 상태 | 재발 방지 |
|
||||
|------|------|----------|----------|
|
||||
| `.live/` | PC 단위 | ✅ HOME 중앙화 (C34-3) | 해결 완료 |
|
||||
| `memory/org/` | PC 단위 (git-tracked SOT) | 🟡 레포 루트 junction (git 추적 유지 위해) | 운영 규율 + verify_setup 경고 + 감사관 체크 |
|
||||
| `paths.local.json` | PC 단위 (.gitignore) | 🟡 레포 루트 (worktree fallback) | verify_setup worktree fallback 추가 |
|
||||
| `~/.claude/.nerdnavis_bus/`·`.nerdnavis_throttle/` | PC 단위 | ✅ HOME (기존 구조) | 정합 |
|
||||
| 향후 신규 자산 | — | — | **본 체크리스트 통과 후 도입** |
|
||||
|
||||
### 본 체크리스트 위반 시
|
||||
|
||||
- **설계 단계**: 도입 검토자가 본 체크리스트 미통과 시 근원 해결안 포함하여 재설계 후 재상정
|
||||
- **집행 후 발견**: C34-11 준용 → stash 이관 복구 + feedback 메모리 기록 + 관련 감사관 체크 항목 추가
|
||||
|
||||
### 감사관 상시 점검 (C34-15 연계)
|
||||
|
||||
- **pm-auditor**: 규칙·설정 변경 시 본 체크리스트 수행 여부 검증
|
||||
- **dev-auditor**: 스크립트·hook 도입 시 worktree 안전성 검증
|
||||
- **plan-auditor**: 기획 자산(밸런스 테이블 등) 경로 체계 worktree 안전성 검증
|
||||
|
||||
### 관련 사건 로그 (패턴 축적)
|
||||
|
||||
| 일자 | 사건 | 해결 |
|
||||
|------|------|------|
|
||||
| 2026-04-18 오전 | `.live/` worktree 격리 실증 | C34 신설 + 중앙 Junction |
|
||||
| 2026-04-18 오후 | 개발팀장 Agent 절대 경로 → 레포 루트 유출 | C34-11 + `feedback_agent_path_boundary.md` |
|
||||
| 2026-04-18 오후 | memory junction 타깃이 레포 루트라 Write가 레포 루트에 기록 | 운영 규율(stash 이관) + verify_setup 경고 + 감사관 체크 |
|
||||
| 2026-04-18 오후 | paths.local.json이 worktree에 없어 verify FAIL | verify_setup worktree fallback 추가 |
|
||||
|
||||
향후 동일 유형 사건은 본 표에 append하여 패턴 누적.
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
---
|
||||
name: 조직운영 프로젝트 맥락 — 이벤트 기반 최신 20개 엔트리
|
||||
description: BurningTimes 조직 운영 차원의 핵심 결정·방향 전환·Phase 완결 이벤트 SOT. 최신 20개 유지·오래된 엔트리는 _archive.md 로 이동. 계층 0 세션 시작 자동 주입 대상. PD 원칙 "최근 활동 지점부터 역순" 구현. 30일 기간 고정 방식 폐기 (2026-04-23 PD 재검토 A안 채택)
|
||||
type: project_context
|
||||
project: 조직운영
|
||||
tier: constitutional
|
||||
---
|
||||
|
||||
# 조직운영 프로젝트 맥락 — 최신 20개 엔트리
|
||||
|
||||
> **운영 원칙**: 방향 전환·중요 결정·Phase 완결·PD 승인 시점마다 PM이 1줄 엔트리 append. 엔트리 21개 초과 시 가장 오래된 엔트리를 `project_context_조직운영_archive.md` 로 이동. 이 이동 시점이 pm-auditor 운영 모니터링 트리거(`feedback_session_restore_monitoring.md`).
|
||||
|
||||
## 엔트리 포맷
|
||||
```
|
||||
- [YYYY-MM-DD · commit hash(short) · 태그] 1~2줄 요지 · 근거 경로
|
||||
```
|
||||
|
||||
## 활성 엔트리
|
||||
|
||||
- [2026-04-23 · (본 세션 commit) · #BT4 #6계층확장] 세션 시작 교훈 환기 체계 6계층 확장 승인·집행 — 계층 0(헌법급 feedback 9종·활성 PD 지시·기각안·장기 SOT·본 스냅샷)·계층 1~4 공백일수 자동 확장·계층 5 내용축 트리거·감사관 E안 자동 윈도우·게임 명칭 영문 "EerieVillage: Joseon Exorcist" 병기 · 근거 `공유/대화로그/조직운영/2026-04-23.md` · SKILL.md C31-G 개정 · `scripts/recent_feedback_brief.sh` 6계층 로직
|
||||
- [2026-04-22 · `5a161fc` · #BT3 #UnityMCP완결] Unity MCP 연동 완전 성공 (Claude Desktop ↔ uvx stdio ↔ Unity Editor MCP for Unity v9.6.6). 조직 자산 축적 6종 (가이드 v2·config 템플릿·feedback SOT·시행착오 아카이브·조직공지·MEMORY 인덱스) · 근거 `공유/조직공지/2026-04-22_Unity_MCP_연동_표준_워크플로우_v2.md`
|
||||
- [2026-04-21 · `aa61028` · #BT3 #UnityMCP셋업] Unity MCP 도입 A안 확정 (gitignore + setup 자동 clone). `코어코드/unity-mcp/` 외부 저장소 분리 + setup 스크립트 auto clone · Claude Desktop config HTTP→stdio 전환
|
||||
- [2026-04-21 · `8ff5a1f` · #BT2 #잔존정리] 수상한잡화점·너드나비스 잔존 최종 정리 (asmdef rename + 코어 문서 추상화 + md_to_docx.js 삭제)
|
||||
- [2026-04-21 · `616e3d3` · #BT2 #Phase2C] 수상한잡화점 삭제 + feedback 추상화 + 아카이브 재압축 + SKILL.md P17 폐기·P29 재작성·P30-3 EerieVillage 적용
|
||||
- [2026-04-21 · `44f7fb1` · #BT2 #Phase2B] 전 14개 에이전트 동원 수상한잡화점 시행착오 아카이브 (`공유/조직자산/시행착오_아카이브/` 14종) — 조직 자산 계승
|
||||
- [2026-04-21 · `5d5b1dd` · #BT2 #Phase2A] Skill·Framework rename + 조직명 일괄 치환 (201 files) + `프로젝트/EerieVillage/` 신설 + paths.local.json
|
||||
- [2026-04-21 · `4911b74` · #BT1 #조직신설] BurningTimes 신설 Phase 1 — git remote 교체 + 중앙 저장소 A안 분리 (`burningtimes-{live,memory,audit}/`) + NerdNavisAi 영향 차단 확인
|
||||
- [2026-04-20 · #50] C35-9 Layer 3 PreToolUse 차단 + 해제 워크플로우 전환 — 30분 윈도우 proxy 폐기·매니페스트 기반 근본 해결·BYPASS 우회 불가 · 근거 `공유/조직공지/2026-04-20_PreToolUse_차단_전환_근본해결.md`
|
||||
- [2026-04-20 · #48·C36·C37] C36 PM 자율 판단 범위 상한(방향·원칙 수준 축소·희석 금지)·C37 규칙 문서 관리 원칙(중복 금지·의미 보존·참조 무결성·표기 통일) 헌법급 신설. C2 확장(C2-1~C2-6 근본 해결 우선·proxy 개선 식별 의무)
|
||||
- [2026-04-20 · #48 G] C34 audit 중앙 통합 — `burningtimes-audit/` 중앙 저장소 + junction 3종 + sync 4계층. PC 간 C35 감사 로그 일관 보장
|
||||
- [2026-04-19 · C34 확장] memory junction 중앙화 (옵션 A) — `burningtimes-memory/` 중앙 저장소 + sync 4계층 + D안 덮어쓰기 보호. 헌법 제1원칙 ⑤ 정합 · 근거 `feedback_memory_junction_repo_root_misdirect.md` · `feedback_memory_sync_overwrite.md`
|
||||
- [2026-04-19 · C35 신설] pm-auditor 의무 참여 체계 — 조직 내 공유 작업 7종 사전 호출 의무·3층 hook 구조·장기 패턴 분석 C35-10
|
||||
- [2026-04-18 · C34 신설] PC 로컬 실시간 공유 중앙화 체계 — `.live/` junction 경유 중앙 저장소. worktree 격리 실증 기반 P25 헌법급 승격
|
||||
- [2026-04-18 · 헌법 재작성] 헌법 제1원칙 5항 재작성 (PD 직접) — ①AI 전문 스튜디오 ②경험 축적·계승 ③허위 보고 금지·상호 감시 ④PM·개발·기획 3조직 ⑤세션·PC 연속성 보장
|
||||
- [2026-04-18 · C14-5·C14-5-확장] 본문 최신 + 히스토리 아카이브 원칙 + 폐기 조항 본문 완전 삭제 원칙. "번호 체계 연속성" 관성 폐기
|
||||
- [2026-04-17 · C31 격상] 응답 발신 직전 자기검증 의무 헌법급 격상 (C20-7 에서 승격). PM 자율 수행 C29 신설 + 조직 사활 걸린 중대 사안 선언
|
||||
- [2026-04-17 · C30 신설] git 동기화 프로젝트 작업 전 최신 상태 점검 의무 (Unity·BT.Framework 등 외부 레포 포함)
|
||||
- [2026-04-16 · C24·C25·C26·C27·C28 신설] 단일 세션 운용 원칙·제안 넘버링 일관·코어룰 단일 SOT Skill 패킹·Agent 호출 완료 시 PM 로그 확인·문서 수정 무승인 5종 동시 신설
|
||||
- [2026-04-15 · C13·C14·C15·C16·C19·C20 신설] PD 지시 트래킹 공유 의무·토큰 최소화 우선 설계·일정 표현 금지·PC 독립 셋업·승인 범위 엄격 해석·팀장 커밋 재량 6종 기반 규칙 신설
|
||||
|
||||
## 운영 지침
|
||||
|
||||
- 신규 엔트리 추가 시 **최신이 맨 위** (역순)
|
||||
- 21번째 엔트리 추가 시 **맨 아래 가장 오래된 엔트리**를 `project_context_조직운영_archive.md`로 이동
|
||||
- **이동 시점**이 `feedback_session_restore_monitoring.md` 트리거 — pm-auditor는 해당 시점까지 축적된 운영 데이터를 분석하여 개선점 PD 보고
|
||||
|
||||
## 연관 규칙
|
||||
- 헌법 제1원칙 ⑤ (세션·PC 연속성 보장)
|
||||
- C14 토큰 최소화 우선 설계 (이벤트 기반으로 기간 고정 폐기)
|
||||
- C31-G 세션 시작 맥락 복원 자기검증
|
||||
- `memory/org/feedback_session_restore_monitoring.md` (pm-auditor 모니터링 SOT)
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
---
|
||||
name: 조직운영 프로젝트 맥락 — 아카이브
|
||||
description: project_context_조직운영.md 에서 밀려난 오래된 엔트리 영구 보존. 첫 엔트리 이동 시점이 pm-auditor 운영 모니터링 트리거 (feedback_session_restore_monitoring.md)
|
||||
type: project_context_archive
|
||||
project: 조직운영
|
||||
---
|
||||
|
||||
# 조직운영 프로젝트 맥락 — 아카이브
|
||||
|
||||
> **트리거 의미**: 본 파일에 첫 엔트리가 이동하는 시점이 **6계층 교훈 환기 체계 운영 모니터링 발동 기준**. pm-auditor는 이 시점까지 축적된 데이터를 분석하여 개선점을 PD님에게 보고 (근거: `memory/org/feedback_session_restore_monitoring.md`).
|
||||
|
||||
## 아카이브 엔트리
|
||||
|
||||
(아직 이동된 엔트리 없음 — 활성 파일이 20개 가득 찰 때까지 대기)
|
||||
|
||||
## 참조
|
||||
- [활성 SOT: project_context_조직운영.md](./project_context_조직운영.md)
|
||||
- [모니터링 SOT: feedback_session_restore_monitoring.md](./feedback_session_restore_monitoring.md)
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
name: 조직 운용 구조 (3조직 + 메인세션 운용)
|
||||
description: BurningTimes는 PM·개발·기획 3조직. 메인 세션은 총괄PM 창구로 활용하되 실질은 pm-general 서브에이전트 호출 구조
|
||||
type: project
|
||||
originSessionId: 83925da6-1e0e-4e0e-8d29-9724ae91eaca
|
||||
---
|
||||
BurningTimes는 **PM조직 / 개발 / 기획** 3조직 체계로 운용된다. PD님은 메인 Claude Code 세션을 "총괄PM"으로 간주하고 활용하지만, 실질 구조는 메인 세션이 매 요청마다 **pm-general 서브에이전트를 호출**해 총괄PM 업무를 수행하는 방식이다.
|
||||
|
||||
**Why:** PD님이 2026-04-15 세션 재기동 확인 중 직접 확정한 운용 방식. 메인 세션의 컨텍스트를 총괄PM 대화창으로 유지하면서도, 실제 판단·조율은 pm-general 페르소나가 수행해 역할 분리와 규칙 준수를 보장.
|
||||
|
||||
**How to apply:**
|
||||
- 메인 세션에서 PD님 지시를 받으면 pm-general 서브에이전트를 호출해 조율·판단을 위임한다 (메인이 직접 총괄PM 페르소나로 응답하지 않는다).
|
||||
- 개발팀·기획팀 관련 작업은 총괄PM(pm-general) 경유가 기본. 메인이 임의로 개발/기획 작업을 바로 실행하지 않는다.
|
||||
- 이 구조 변경을 제안하거나 "메인을 총괄PM으로 직접 운용" 같은 변형을 먼저 제시하지 않는다 — PD님이 명시 지시하지 않는 한 현 구조 유지.
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
name: 정부 지원 사업 문서 처리 도구 (조직 보유 자산)
|
||||
description: 정부 지원 사업계획서(docx·hwp·pdf) 작성·편집·검토 시 활용 가능한 로컬 Python 라이브러리 도구 세트. 조직 보유 자산으로 향후 정부 지원 사업 대응 시 즉시 재활용 가능.
|
||||
type: reference
|
||||
---
|
||||
|
||||
# 정부 지원 사업 문서 처리 도구 — 조직 보유 자산
|
||||
|
||||
> **성격**: 로컬 PC(대표자 작업 환경)에 사전 설치 완료된 Python 라이브러리 세트.
|
||||
> **용도**: 정부 지원 사업 관련 문서(사업계획서·평가서·제출 양식 등)의 형식(docx·hwp·pdf) 처리.
|
||||
> **활용 시점**: 향후 정부 지원 사업 공고 대응, 평가 피드백 반영, 양식 변환·검증 등이 필요할 때 즉시 호출 가능.
|
||||
|
||||
## 보유 라이브러리 목록
|
||||
|
||||
| 라이브러리 | 용도 |
|
||||
|-----------|------|
|
||||
| `pypdf` | PDF 파일 읽기·페이지 수 확인·텍스트 추출 |
|
||||
| `pyhwp` (`hwp5txt`·`hwp5html`·`hwp5odt`·`hwp5proc` CLI 포함) | 구형 HWP(OLE2) 파일 텍스트·구조 추출 |
|
||||
| `olefile` | HWP·MS Office 구버전 OLE2 복합 문서 파싱 |
|
||||
| `lxml` | docx·hwpx 등 XML 기반 문서 고속 파싱·편집 |
|
||||
| `six` | pyhwp 의존성(Python 2/3 호환 계층) |
|
||||
| `pywin32` (`win32com.client`) | Windows COM 자동화 — 한컴오피스(HwpObject) 및 MS Word 자동화로 hwp/docx 직접 편집 가능 |
|
||||
|
||||
## 활용 가능 작업 패턴
|
||||
|
||||
1. **docx 편집** — zip 해제 후 `word/document.xml` 직접 수정 → 재패킹
|
||||
2. **hwp 텍스트 추출** — `hwp5txt` CLI로 원문 추출
|
||||
3. **hwp 자동 편집** — `win32com.client.Dispatch("HWPFrame.HwpObject")`로 한컴오피스 COM 자동화 (텍스트 삽입·Find/Replace·저장). 단 한컴 10(2018) COM API의 `AllReplace` 파라미터 바인딩은 제한적이므로 표 편집·Find/Replace 자동화는 보조적으로 활용하고 복잡 편집은 docx 경유 권장
|
||||
4. **pdf 검토** — `pypdf`로 페이지 수·텍스트 추출, Claude PDF 읽기로 시각 검증 병행
|
||||
5. **포맷 변환 경로** — hwp(구형) ↔ docx(한컴오피스 수동 변환) ↔ XML 편집 (한컴 2018 설치 환경 필수)
|
||||
|
||||
## 전제 환경
|
||||
|
||||
- OS: Windows 10/11
|
||||
- Python: 3.10 (`C:\Users\PC\AppData\Local\Programs\Python\Python310\`)
|
||||
- 한컴오피스 2018 (`C:\Program Files (x86)\Hnc\Office 2018\`) — hwp COM 자동화 및 hwp↔docx 수동 변환에 필수
|
||||
- MS Word (docx 시각 확인용)
|
||||
|
||||
## 접근 노하우
|
||||
|
||||
- 구형 HWP(OLE2)의 **프로그래밍 직접 편집은 파일 손상 리스크가 높음** — docx로 변환 후 XML 편집이 가장 안전
|
||||
- docx 편집 시 원본 `<w:tblPr>`·`<w:tblGrid>` 서식을 유지해야 Word 호환성 유지
|
||||
- 한글 COM Find/Replace는 `s.Direction = 2` (AllDoc) 명시 필요. 파라미터셋 일부 속성(`SeveralLines` 등)은 한컴 10에서 미지원
|
||||
- `rm` 차단 환경에서는 PowerShell `Remove-Item -LiteralPath ... -Recurse -Force` 사용 (한국어 경로 대응)
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
---
|
||||
name: PD 역할
|
||||
description: 사용자는 BurningTimes 회사의 경영자이자 PD(프로듀서/디렉터)로, 프로젝트 단위로 조직을 운용한다
|
||||
type: user
|
||||
---
|
||||
|
||||
사용자는 BurningTimes(게임 개발 스튜디오)의 경영자이자 PD.
|
||||
프로젝트 단위로 팀을 운용하며, PM 에이전트 체계를 통해 개발팀과 기획팀을 관리한다.
|
||||
최종 의사결정권자이며, PM들은 의사결정이 필요한 사항만 PD에게 보고한다.
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
# `.live/` 실시간 공유 체계 — 실무 사용 안내
|
||||
|
||||
> **역할 분담**: 본 README는 **실무 사용 쿡북**이며, 규칙·헌법급 정의는 [`.claude/skills/너드나비스-코어룰/SKILL.md`](../../.claude/skills/너드나비스-코어룰/SKILL.md) **C34** 단일 SOT. 본 파일은 레포 `.live/` 경로에서 junction 경유로 접근하며, 중앙 저장소는 `$HOME/.claude/nerdnavis-live/`.
|
||||
|
||||
## 1. `.live/` 용도
|
||||
|
||||
세션 중 변경된 설정·규칙·에이전트 정의·조직 기억을 **세션 갱신 없이 즉시 반영**하기 위한 PC 로컬 실시간 공유 채널. 같은 PC 내 모든 세션(worktree 경계 무관)이 자동 주입받는다.
|
||||
|
||||
## 2. 더미 파일 패턴
|
||||
|
||||
- 파일명: `{변경 대상 파일명 또는 주제}.md`
|
||||
- 예: `CLAUDE.md.live`·`C34_memory_확장.md`·`pd_지시_50.md`
|
||||
- 본문: 변경 요지 append-only. 최대 8,000자
|
||||
|
||||
## 3. 생명주기
|
||||
|
||||
| 시점 | 상태 | 처리 |
|
||||
|------|------|------|
|
||||
| 변경 발생 | PM이 `.live/{파일명}` append | 원본 수정과 동시 수행 |
|
||||
| 같은 PC 다른 세션 | UserPromptSubmit hook 자동 주입 | 증분만 읽기 (토큰 비용 최소) |
|
||||
| "세션 공유"·push 시점 | P21-2 트리거 | 원본 반영 확인 후 `.live/` 비움(README.md·.junction-marker 제외) + commit + push |
|
||||
|
||||
## 4. 세션 간 공유 시나리오
|
||||
|
||||
### 같은 PC 내
|
||||
1. 세션 A에서 원본 수정 + `.live/` append
|
||||
2. 세션 B 다음 프롬프트 → UserPromptSubmit hook `live_inject.sh` 증분 주입
|
||||
3. 즉시 인지 (git 개입 없음)
|
||||
|
||||
### 다른 PC 간
|
||||
1. 세션 A "세션 공유" (P21-2) → `.live/` 비움 + commit + push
|
||||
2. 세션 B (다른 PC) "세션 갱신" (P21) → git pull → SessionStart hook 자동 복원
|
||||
|
||||
## 5. 참조
|
||||
|
||||
- **SKILL.md C34** — PC 로컬 실시간 공유 중앙화 체계 (단일 SOT, 헌법급)
|
||||
- **SKILL.md C21** — 작업 완료 즉시 공유·PM 능동 확인 (내부 공유/공유 완료 2단계)
|
||||
- **scripts/live_junction_ensure.sh** — junction 자동 보장 (SessionStart + UserPromptSubmit hook)
|
||||
- **scripts/live_inject.sh** — UserPromptSubmit hook 증분 주입
|
||||
- **scripts/live_session_load.sh** — SessionStart 전량 1회 로드
|
||||
|
||||
## 변경 이력
|
||||
|
||||
- 2026-04-19: 전 세션 초기 sentinel 손실 시 원본 소실
|
||||
- 2026-04-20: #48 D 집행으로 복구. 중앙 저장소에 신규 작성 (모든 PC 자동 동기화)
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
---
|
||||
plan_id: 2026-05-28_기획팀장_남은업무보고
|
||||
created_at: 2026-05-28T11:40:37+09:00
|
||||
hostname: DESKTOP-RD7PUKN
|
||||
goal: "PD 호칭 '기획팀장' 직접 지시 — 남은 기획 업무 현황 보고 (C43 정합)"
|
||||
target_files:
|
||||
- 공유/PD_지시_트래킹/기획팀_PD_지시_로그.md
|
||||
- 공유/대화로그/EerieVillage/2026-05-28.md
|
||||
- 공유/대화로그/조직운영/2026-05-28.md
|
||||
completion_criteria: "commit + push 완료 후 post-commit hook archived 이동"
|
||||
---
|
||||
|
||||
# 매니페스트 — 2026-05-28_기획팀장_남은업무보고
|
||||
|
||||
- **등록 시각**: 2026-05-28T11:40:38+09:00
|
||||
- **호스트**: DESKTOP-RD7PUKN
|
||||
- **집행 목표**: PD 호칭 '기획팀장' 직접 지시 — 남은 기획 업무 현황 보고 (C43 정합)
|
||||
|
||||
## 대상 파일
|
||||
- `공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`
|
||||
- `공유/대화로그/EerieVillage/2026-05-28.md`
|
||||
- `공유/대화로그/조직운영/2026-05-28.md`
|
||||
|
||||
## 완료 기준
|
||||
|
||||
commit + push 완료. post-commit hook이 `archived/2026-05-28_기획팀장_남은업무보고.md`로 자동 이동 + target_files cross-check.
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
2026-04-24_12:54:21 pm-auditor called
|
||||
2026-04-24_14:42:16 pm-auditor called
|
||||
2026-04-24_14:53:53 pm-auditor called
|
||||
2026-04-24_14:59:36 pm-auditor called
|
||||
2026-04-24_15:11:51 pm-auditor called
|
||||
2026-04-24_15:20:06 pm-auditor called
|
||||
2026-04-24_15:24:52 pm-auditor called
|
||||
2026-04-24_16:12:14 pm-auditor called
|
||||
2026-04-24_21:19:23 pm-auditor called
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
import os, sys
|
||||
sys.stdout.reconfigure(encoding='utf-8')
|
||||
from pptx import Presentation
|
||||
from pptx.util import Emu
|
||||
|
||||
src = r'C:\Users\PC\Documents\카카오톡 받은 파일\[포트폴리오] 이승우_2019_2.12.22_(구버전).pptx'
|
||||
prs = Presentation(src)
|
||||
|
||||
print(f'슬라이드 수: {len(prs.slides)}')
|
||||
print(f'크기: {Emu(prs.slide_width).inches:.2f} x {Emu(prs.slide_height).inches:.2f} inches')
|
||||
print(f'aspect: {prs.slide_width / prs.slide_height:.4f}')
|
||||
print()
|
||||
|
||||
for i, slide in enumerate(prs.slides, 1):
|
||||
print(f'=== Slide {i} (Layout: {slide.slide_layout.name}) ===')
|
||||
img = 0
|
||||
txt_lines = []
|
||||
for shape in slide.shapes:
|
||||
if shape.shape_type == 13:
|
||||
img += 1
|
||||
if shape.has_text_frame:
|
||||
for para in shape.text_frame.paragraphs:
|
||||
t = para.text.strip()
|
||||
if t:
|
||||
txt_lines.append(t)
|
||||
print(f' images={img}, text_runs={len(txt_lines)}')
|
||||
for j, line in enumerate(txt_lines[:30]):
|
||||
print(f' T{j+1}: {line[:200]}')
|
||||
print()
|
||||
|
|
@ -1,748 +0,0 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
[포트폴리오] 이승우 — 16:9 와이드 현대화 PPT 빌드
|
||||
- 4:3 (10x7.5) → 16:9 (13.33x7.5)
|
||||
- Charcoal Minimal + Navy Accent 팔레트
|
||||
- 게임 기획자 포트폴리오 톤 (전문성·정제)
|
||||
"""
|
||||
import os, sys
|
||||
sys.stdout.reconfigure(encoding='utf-8')
|
||||
|
||||
from pptx import Presentation
|
||||
from pptx.util import Inches, Pt, Emu
|
||||
from pptx.enum.shapes import MSO_SHAPE
|
||||
from pptx.dml.color import RGBColor
|
||||
from pptx.enum.text import PP_ALIGN, MSO_ANCHOR
|
||||
from pptx.oxml.ns import qn
|
||||
from copy import deepcopy
|
||||
from lxml import etree
|
||||
|
||||
# ─────────────── 디자인 시스템 ───────────────
|
||||
COLOR_PRIMARY = RGBColor(0x1E, 0x27, 0x61) # navy (Midnight Executive)
|
||||
COLOR_DARK = RGBColor(0x21, 0x29, 0x5C) # midnight
|
||||
COLOR_BG_DARK = RGBColor(0x14, 0x1B, 0x42) # darker navy
|
||||
COLOR_ACCENT = RGBColor(0xCA, 0xDC, 0xFC) # ice blue
|
||||
COLOR_GOLD = RGBColor(0xC9, 0xA2, 0x4B) # gold accent (prestige)
|
||||
COLOR_TEXT = RGBColor(0x21, 0x21, 0x21) # near black
|
||||
COLOR_MUTED = RGBColor(0x6B, 0x72, 0x80) # gray
|
||||
COLOR_LIGHT = RGBColor(0xF5, 0xF6, 0xFA) # light bg
|
||||
COLOR_BORDER = RGBColor(0xE2, 0xE5, 0xEC) # border
|
||||
COLOR_WHITE = RGBColor(0xFF, 0xFF, 0xFF)
|
||||
|
||||
FONT_HEADER = 'Malgun Gothic'
|
||||
FONT_BODY = 'Malgun Gothic'
|
||||
FONT_MONO = 'Consolas'
|
||||
|
||||
# 16:9 와이드 (PowerPoint 2019 표준)
|
||||
SLIDE_W = Inches(13.333)
|
||||
SLIDE_H = Inches(7.5)
|
||||
|
||||
OUT_PATH = r'C:\Users\PC\Documents\카카오톡 받은 파일\[포트폴리오] 이승우_2019_2.12.22_(현대화).pptx'
|
||||
IMG_DIR = r'D:\NerdNavis\BurningTimesAi\tmp\portfolio_images'
|
||||
|
||||
|
||||
def add_textbox(slide, left, top, width, height, text, *,
|
||||
font=FONT_BODY, size=14, bold=False, italic=False,
|
||||
color=COLOR_TEXT, align=PP_ALIGN.LEFT, anchor=MSO_ANCHOR.TOP,
|
||||
line_spacing=1.15):
|
||||
tb = slide.shapes.add_textbox(left, top, width, height)
|
||||
tf = tb.text_frame
|
||||
tf.margin_left = Inches(0.05)
|
||||
tf.margin_right = Inches(0.05)
|
||||
tf.margin_top = Inches(0.02)
|
||||
tf.margin_bottom = Inches(0.02)
|
||||
tf.word_wrap = True
|
||||
tf.vertical_anchor = anchor
|
||||
lines = text.split('\n') if isinstance(text, str) else text
|
||||
for i, line in enumerate(lines):
|
||||
p = tf.paragraphs[0] if i == 0 else tf.add_paragraph()
|
||||
p.alignment = align
|
||||
p.line_spacing = line_spacing
|
||||
run = p.add_run()
|
||||
run.text = line
|
||||
run.font.name = font
|
||||
run.font.size = Pt(size)
|
||||
run.font.bold = bold
|
||||
run.font.italic = italic
|
||||
run.font.color.rgb = color
|
||||
return tb
|
||||
|
||||
|
||||
def add_rect(slide, left, top, width, height, fill_color, line_color=None, shadow=False):
|
||||
shp = slide.shapes.add_shape(MSO_SHAPE.RECTANGLE, left, top, width, height)
|
||||
shp.fill.solid()
|
||||
shp.fill.fore_color.rgb = fill_color
|
||||
if line_color is None:
|
||||
shp.line.fill.background()
|
||||
else:
|
||||
shp.line.color.rgb = line_color
|
||||
shp.line.width = Pt(0.5)
|
||||
if not shadow:
|
||||
# 그림자 제거
|
||||
sp = shp.shadow
|
||||
try:
|
||||
sp.inherit = False
|
||||
except Exception:
|
||||
pass
|
||||
return shp
|
||||
|
||||
|
||||
def add_rounded(slide, left, top, width, height, fill_color, line_color=None):
|
||||
shp = slide.shapes.add_shape(MSO_SHAPE.ROUNDED_RECTANGLE, left, top, width, height)
|
||||
shp.adjustments[0] = 0.08
|
||||
shp.fill.solid()
|
||||
shp.fill.fore_color.rgb = fill_color
|
||||
if line_color is None:
|
||||
shp.line.fill.background()
|
||||
else:
|
||||
shp.line.color.rgb = line_color
|
||||
shp.line.width = Pt(0.75)
|
||||
return shp
|
||||
|
||||
|
||||
def add_circle(slide, left, top, size, fill_color, line_color=None):
|
||||
shp = slide.shapes.add_shape(MSO_SHAPE.OVAL, left, top, size, size)
|
||||
shp.fill.solid()
|
||||
shp.fill.fore_color.rgb = fill_color
|
||||
if line_color is None:
|
||||
shp.line.fill.background()
|
||||
else:
|
||||
shp.line.color.rgb = line_color
|
||||
return shp
|
||||
|
||||
|
||||
def page_header(slide, page_num, total=20, section=''):
|
||||
"""우상단 페이지·섹션 표기 (간결)"""
|
||||
add_textbox(slide, Inches(11.5), Inches(0.25), Inches(1.7), Inches(0.3),
|
||||
f'{section} {page_num:02d} / {total:02d}',
|
||||
size=9, color=COLOR_MUTED, align=PP_ALIGN.RIGHT)
|
||||
|
||||
|
||||
def page_footer(slide):
|
||||
"""좌하단 푸터 — 이름·연락"""
|
||||
add_textbox(slide, Inches(0.5), Inches(7.05), Inches(8), Inches(0.3),
|
||||
'Portfolio · 이승우 · Game Designer',
|
||||
size=9, color=COLOR_MUTED, align=PP_ALIGN.LEFT)
|
||||
|
||||
|
||||
# ─────────────── PPT 생성 시작 ───────────────
|
||||
prs = Presentation()
|
||||
prs.slide_width = SLIDE_W
|
||||
prs.slide_height = SLIDE_H
|
||||
blank_layout = prs.slide_layouts[6]
|
||||
|
||||
|
||||
# ═══════════════ S1. 표지 ═══════════════
|
||||
def build_slide_01():
|
||||
s = prs.slides.add_slide(blank_layout)
|
||||
# 풀블리드 다크 배경
|
||||
add_rect(s, 0, 0, SLIDE_W, SLIDE_H, COLOR_BG_DARK)
|
||||
# 좌측 navy 강조 띠 (단일 면 모티프)
|
||||
add_rect(s, 0, 0, Inches(0.25), SLIDE_H, COLOR_GOLD)
|
||||
|
||||
# 제목군 (중앙 좌측 정렬)
|
||||
add_textbox(s, Inches(1.0), Inches(2.4), Inches(8), Inches(0.5),
|
||||
'PORTFOLIO',
|
||||
size=14, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(1.0), Inches(2.9), Inches(11), Inches(1.3),
|
||||
'포트폴리오',
|
||||
size=72, bold=True, color=COLOR_WHITE,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(1.0), Inches(4.4), Inches(11), Inches(0.6),
|
||||
'RPG 개발 경험이 풍부한 제너럴리스트 게임 기획자',
|
||||
size=22, color=COLOR_ACCENT,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
|
||||
# 구분선
|
||||
add_rect(s, Inches(1.0), Inches(5.3), Inches(2.5), Inches(0.04), COLOR_GOLD)
|
||||
|
||||
# 이름·날짜
|
||||
add_textbox(s, Inches(1.0), Inches(5.5), Inches(8), Inches(0.4),
|
||||
'게임 기획자 · 이승우',
|
||||
size=18, bold=True, color=COLOR_WHITE,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(1.0), Inches(6.0), Inches(8), Inches(0.3),
|
||||
'2019.12.22',
|
||||
size=12, color=COLOR_ACCENT,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT)
|
||||
|
||||
|
||||
# ═══════════════ S2. 대표 작품 인덱스 ═══════════════
|
||||
def build_slide_02():
|
||||
s = prs.slides.add_slide(blank_layout)
|
||||
add_rect(s, 0, 0, SLIDE_W, SLIDE_H, COLOR_WHITE)
|
||||
|
||||
# 헤더
|
||||
add_textbox(s, Inches(0.6), Inches(0.5), Inches(10), Inches(0.4),
|
||||
'01 · Featured Works',
|
||||
size=12, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(0.6), Inches(0.85), Inches(12), Inches(0.7),
|
||||
'대표 작품 소개',
|
||||
size=36, bold=True, color=COLOR_PRIMARY,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(0.6), Inches(1.55), Inches(12), Inches(0.4),
|
||||
'총 13개 작품 · 최근 런칭 시점 기준 정렬',
|
||||
size=12, color=COLOR_MUTED,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT)
|
||||
page_header(s, 2, section='WORKS INDEX')
|
||||
|
||||
works = [
|
||||
('01', '매직 AR', '2019 · AR기반 실시간 전략 PvP'),
|
||||
('02', '쿠로네코 (가제)', '캐릭터 수집 방치형 RPG · 개발 중단'),
|
||||
('03', '만렙 영웅 키우기 시리즈', '2017 · 방치형 RPG · 매출 168위'),
|
||||
('04', '프로젝트 BC', '하드코어 액션 MORPG · 80% 진행'),
|
||||
('05', '데빌즈 아레나', '수집 성장형 MORPG · 개발 중단'),
|
||||
('06', '드래곤 헌터스', '2015 · 액션 RPG · 인기 인디 선정'),
|
||||
('07', '데빌즈', '2013 · 액션 RPG · 인기 무료 1위'),
|
||||
('08', '동물 그림 맞추기', '2012 · 퍼즐 / 교육 어플'),
|
||||
('09', '마스터 오브 던전', '2012 · 시나리오형 액션 RPG'),
|
||||
('10', '최종병기 활', '2011 · 로그라이크 · 영화 OSMU'),
|
||||
('11', '디스트로이어', '2010 · 액션 RPG · 넥슨 퍼블리싱'),
|
||||
('12', '에프터 스쿨', '2009 · 미니게임 + 타이쿤'),
|
||||
('13', '학교가는 길', '2007 · 미니게임 · SKT 킬러 콘텐츠'),
|
||||
]
|
||||
cols = 3
|
||||
cell_w = Inches(4.0)
|
||||
cell_h = Inches(0.85)
|
||||
start_x = Inches(0.55)
|
||||
start_y = Inches(2.2)
|
||||
gap_x = Inches(0.1)
|
||||
gap_y = Inches(0.12)
|
||||
|
||||
for i, (num, title, desc) in enumerate(works):
|
||||
r, c = i // cols, i % cols
|
||||
x = start_x + c * (cell_w + gap_x)
|
||||
y = start_y + r * (cell_h + gap_y)
|
||||
# 카드
|
||||
card = add_rounded(s, x, y, cell_w, cell_h, COLOR_LIGHT, COLOR_BORDER)
|
||||
# 좌측 번호 박스 (navy)
|
||||
add_rect(s, x + Inches(0.0), y, Inches(0.6), cell_h, COLOR_PRIMARY)
|
||||
add_textbox(s, x, y, Inches(0.6), cell_h,
|
||||
num, size=18, bold=True, color=COLOR_WHITE,
|
||||
font=FONT_HEADER, align=PP_ALIGN.CENTER, anchor=MSO_ANCHOR.MIDDLE)
|
||||
# 제목
|
||||
add_textbox(s, x + Inches(0.75), y + Inches(0.1), cell_w - Inches(0.85), Inches(0.35),
|
||||
title, size=13, bold=True, color=COLOR_TEXT,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
# 부제
|
||||
add_textbox(s, x + Inches(0.75), y + Inches(0.42), cell_w - Inches(0.85), Inches(0.4),
|
||||
desc, size=9.5, color=COLOR_MUTED,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT)
|
||||
|
||||
page_footer(s)
|
||||
|
||||
|
||||
# ═══════════════ S3~S15. 게임 소개 슬라이드 (공통 레이아웃) ═══════════════
|
||||
GAMES = [
|
||||
# (페이지번호 in deck, 작품번호, title, subtitle, info_dict, overview_lines, role_text, kpi_text, image_filename)
|
||||
(3, '01', '매직 AR', 'AR 기반의 전략 PvP 게임',
|
||||
{'장르': 'AR기반 실시간 전략 PvP', '플랫폼': 'Android, iOS', '출시일': '2019. 09'},
|
||||
[
|
||||
'증강현실(AR)과 딥 러닝 기술을 활용해 음료수 캔 등 사물을 스캔하여 실제 게임에서 활용할 수 있는 새로운 개념의 게임.',
|
||||
'클래시 로얄과 유사한 실시간 전략 PvP. 어떤 사물을 스캔하는지에 따라 다양한 변수가 발생되는 것이 특징.',
|
||||
'신 기술 기반 투자 유치 목적의 프로젝트로, 게임성 개선 및 폴리싱 후 소프트 런칭 버전 대응 완료.',
|
||||
'※ 개발부·사업부 간 게임에 대한 이해도 차이와 경영 사정 악화로 인해 퇴사 결정.',
|
||||
],
|
||||
'전투 밸런스 작업 · 게임 폴리싱 · 아이템 보상 시스템(상자·전투 보상) 등',
|
||||
None,
|
||||
'slide03_img10.jpg'),
|
||||
(4, '02', '쿠로네코 (가제)', 'IP 활용 방치형 게임',
|
||||
{'장르': '캐릭터 수집 방치형 RPG', '플랫폼': 'Android', '출시일': '개발 중단'},
|
||||
[
|
||||
'대만에서 흥행한 이노센트 IP를 활용한 캐릭터 수집·성장 방치형 RPG 프로젝트.',
|
||||
'200여 종의 개성 있는 캐릭터 리소스를 활용해 수집·성장의 재미를 제공.',
|
||||
'탱커/원딜/근딜러/서포터로 구성, 캐릭터마다 다양한 컨셉의 스킬로 전략적 덱 조합 가능.',
|
||||
'원작 리소스를 활용해 개발기간을 단축, 캐릭터 가챠 BM으로 매출 극대화 구상.',
|
||||
'※ 개발 진척 60% 달성 후 핵심 개발자 퇴사 및 내부 사정으로 개발 중단.',
|
||||
],
|
||||
'프로젝트 디렉팅(PD) · 핵심 시스템 기획 · UI&UX 컨셉팅 등 기획 실무 일체',
|
||||
None,
|
||||
'slide04_img13.png'),
|
||||
(5, '03', '만렙 영웅 키우기 시리즈', '전사편 · 소환사편 · 마검사편',
|
||||
{'장르': 'RPG / 방치형', '플랫폼': 'Android, iOS', '출시일': '2017. 04'},
|
||||
[
|
||||
'반복적인 자동 전투로 재화를 수집하고, 무한 환생을 통해 끊임없이 성장하는 방치형 RPG.',
|
||||
'코어 RPG의 감성을 살린 아이템·스킬 시스템으로 기존 방치형 게임과의 차별화 어필.',
|
||||
'총 개발기간 약 4개월. 전사편 지표 분석을 통해 의미 있는 성과 달성.',
|
||||
'결투장·쟁탈전·랭킹 시스템 등 다양한 경쟁 컨텐츠로 유저 몰입 유도.',
|
||||
],
|
||||
'프로젝트 디렉팅(PD) · 기획 실무 일체',
|
||||
'KPI: ARPPU ₩45,553 · Retention 36.7% (1Day) · 최고 매출 168위 · Featured 2017/05',
|
||||
'slide05_img14.png'),
|
||||
(6, '04', '프로젝트 BC', '푸른 별의 노래 (가제)',
|
||||
{'장르': '하드코어 액션 MORPG', '플랫폼': 'Android', '출시일': '개발 중단'},
|
||||
[
|
||||
'화려한 2D 그래픽과 액션 RPG의 진수를 느낄 수 있는 하드코어 감성의 2D MORPG.',
|
||||
'전사·마검사·소환사 3명의 캐릭터가 멀티 시나리오로 제공되며 각기 다른 플레이 스타일 보유.',
|
||||
'유저간 PvP, RvR 형태의 길드 대전 및 약탈 시스템으로 경쟁 유도.',
|
||||
'코스튬·펫·용병 시스템을 통해 캐릭터 성장 외에도 풍부한 즐길거리 제공.',
|
||||
'※ 핵심 시스템 및 컨텐츠 80% 완성, 경영 악화로 인해 일시 중단.',
|
||||
],
|
||||
'핵심 시스템 및 컨텐츠 기획 · 몬스터 & 캐릭터 전투 시스템 관련 기획',
|
||||
None,
|
||||
None),
|
||||
(7, '05', '데빌즈 아레나', '자사 IP 활용 액션 MORPG',
|
||||
{'장르': '수집 성장형 MORPG', '플랫폼': 'Android', '출시일': '개발 중단'},
|
||||
[
|
||||
'데빌즈·마스터오브 던전 인기 캐릭터 + 오리지널 30여 종을 활용한 캐릭터 수집·성장 MORPG.',
|
||||
'실시간 PvP를 비롯한 다양한 경쟁형 컨텐츠 제공.',
|
||||
'캐릭터간 상성과 플레이 스타일이 다양해 수집·조작의 재미를 모두 추구.',
|
||||
'※ 정부 지원사업과 연계해 70% 개발 진행, 개발기간 대비 수익성 부족으로 잠정 드랍.',
|
||||
],
|
||||
'프로젝트 디렉팅(PD) · 기획 실무 일체',
|
||||
None,
|
||||
None),
|
||||
(8, '06', '드래곤 헌터스', '캐주얼 액션 RPG',
|
||||
{'장르': '액션 RPG', '플랫폼': 'N스토어 / 원스토어 / GP2X', '출시일': '2015. 02'},
|
||||
[
|
||||
'피쳐폰 시절 이통 3사 25만 다운로드 이상을 기록하며 재미 검증을 받은 캐주얼 ARPG.',
|
||||
'다이나믹한 콤보 액션과 필드 기믹으로 조작감에 대한 호평을 받음.',
|
||||
'아이템 파밍·스킬 트리 구성으로 캐릭터 성장의 묘미 제공.',
|
||||
'스마트폰 버전 리뉴얼 출시, 무리한 BM 적용으로 성과는 저조.',
|
||||
],
|
||||
'프로젝트 디렉팅(PD) · 기획 실무 일체',
|
||||
'Featured: 인기 인디 게임 선정 (15/03)',
|
||||
None),
|
||||
(9, '07', '데빌즈', '몰입형 싱글 액션 RPG',
|
||||
{'장르': '액션 RPG', '플랫폼': 'Android, iOS · 컴투스 퍼블리싱', '출시일': '2013. 10'},
|
||||
[
|
||||
'아이템 옵션 조합 파밍의 재미와 시나리오 기반 싱글 액션 RPG.',
|
||||
'4명의 캐릭터가 각자 시점으로 진행되는 멀티 시나리오로 정통 RPG의 색다른 경험 제공.',
|
||||
'다양한 옵션·등급 아이템과 스텟 포인트 투자로 성장 방법 다양화.',
|
||||
'노말/하드/헬 난이도 + 최대 레벨 999로 장기 콘텐츠 제공, 보스 레이드·무한의 던전 등 다양한 싱글 컨텐츠 운영.',
|
||||
'아이템 위주 BM을 통해 수년간 안정적 수익 창출.',
|
||||
],
|
||||
'핵심 시스템·컨텐츠 기획 · 기획 실무 일체 (맵 & 레벨 디자인 제외)',
|
||||
'Featured: 인기 무료 게임 1위 (2013/11)',
|
||||
None),
|
||||
(10, '08', '동물 그림 맞추기', '유아 교육용 어플리케이션',
|
||||
{'장르': '퍼즐 / 교육', '플랫폼': 'Android', '출시일': '2012. 09'},
|
||||
[
|
||||
'캐시카우 확보 및 기획팀 유니티 엔진 학습을 위한 단기 개발 프로젝트.',
|
||||
'귀엽고 깔끔한 그래픽과 직관적인 게임 방법, 유아 교육용 어플리케이션으로 출시.',
|
||||
'자사 게임 라인업 다양화 및 지속적 수익 타이틀 실험의 대표 케이스.',
|
||||
'※ 총 인원 3명, 개발 기간 약 2.5주의 초단기 프로젝트.',
|
||||
],
|
||||
'아트 컨셉 · UI&UX 설계 · UI 프리펩 배치 등 실무',
|
||||
None,
|
||||
None),
|
||||
(11, '09', '마스터 오브 던전', '시나리오형 액션 RPG',
|
||||
{'장르': '액션 RPG', '플랫폼': 'Android', '출시일': '2012. 07'},
|
||||
[
|
||||
'디스트로이어의 개발 노하우와 엔진을 활용해 제작된 싱글 기반 시나리오형 액션 RPG.',
|
||||
'짜임새 있는 시나리오와 퀘스트 이벤트로 엔딩까지의 과정을 풍성하게 구성.',
|
||||
'캐릭터 육성 방식에 따라 특성이 부여되는 정통 RPG 표방.',
|
||||
'몰이사냥과 다양한 옵션 아이템으로 장비 세팅·파밍의 재미 강조.',
|
||||
'인앱 과금 시장으로의 전환기에서 다양한 BM 실험을 시도한 프로젝트.',
|
||||
],
|
||||
'아이템 및 전투 시스템 기획 · 시나리오 스크립트 작업 일체',
|
||||
None,
|
||||
'slide11_img11.jpg'),
|
||||
(12, '10', '최종병기 활', '영화 OSMU 로그라이크',
|
||||
{'장르': '로그라이크', '플랫폼': 'Android', '출시일': '2011. 09'},
|
||||
[
|
||||
'영화 「최종병기 활」 홍보를 위한 원소스 멀티유즈 전략 프로젝트.',
|
||||
'영화 개봉 시점에 맞춰 출시하기 위해 로그라이크를 변형한 캐주얼 RPG로 기획.',
|
||||
'영화 시나리오 플롯을 계승하되 게임만의 오리지날 요소를 가미해 색다른 재미 제공.',
|
||||
'재화 수집 → 무기·방어구 성장 구조, 타이밍 조작감 강조.',
|
||||
'※ 촉박한 일정과 단말기 커버리지 한계로 흥행에는 실패.',
|
||||
],
|
||||
'핵심 시스템 및 컨텐츠 기획 · 시나리오 스크립트 작업 등 기획 실무 일체',
|
||||
None,
|
||||
'slide12_img10.png'),
|
||||
(13, '11', '디스트로이어', '대작 액션 RPG',
|
||||
{'장르': '액션 RPG', '플랫폼': 'SKT / Android · 넥슨 모바일 퍼블리싱', '출시일': '2010. 09'},
|
||||
[
|
||||
'드래곤 헌터의 성공과 개발력을 검증받아 넥슨과 퍼블리싱 계약이 체결된 대작 액션 프로젝트.',
|
||||
'당시 모바일 최초로 4명의 캐릭터가 각각의 시점으로 진행되는 멀티 시나리오 제공.',
|
||||
'거대 보스 레이드, 실시간 PvP 등 방대한 컨텐츠와 풍부한 즐길거리로 플레이타임 확보.',
|
||||
'영웅 서기를 능가하는 대작 RPG를 목표로 했으나, 개발기간 오버 및 피쳐폰→스마트폰 시장 급변기 직격.',
|
||||
'터치 조작 미지원으로 흥행에는 실패한 비운의 프로젝트.',
|
||||
],
|
||||
'핵심 시스템 및 컨텐츠 기획 · 시나리오 스크립트 작업 등 기획 실무 일체',
|
||||
None,
|
||||
None),
|
||||
(14, '12', '에프터 스쿨', '미니게임 + 타이쿤 복합',
|
||||
{'장르': '미니게임', '플랫폼': 'SKT', '출시일': '2009. 06'},
|
||||
[
|
||||
'학교가는길 시리즈의 성공에 힘입어 독특하고 기발한 컨셉으로 제안·개발한 프로젝트.',
|
||||
'미니게임과 타이쿤 장르를 믹스해 엄마 파트·아들 파트를 나눠 다양한 할 거리 제공.',
|
||||
'초기 60~70% 개발 단계에서 ARPG(드래곤헌터) 메인 기획 담당을 위해 인수인계.',
|
||||
'※ 신입 인력 인수 이후 타이쿤 장르 소화 부족으로 미니게임 장르 전환, 게임성 모호로 흥행 실패.',
|
||||
],
|
||||
'컨셉 기획 · 타이쿤 & 미니게임 초기 기획 담당',
|
||||
None,
|
||||
None),
|
||||
(15, '13', '학교가는 길', 'SKT 킬러 콘텐츠',
|
||||
{'장르': '미니게임', '플랫폼': 'Android', '출시일': '2007. 05'},
|
||||
[
|
||||
'SKT 킬러 컨텐츠로 선정되며 흥행에 성공한 최초의 프로젝트. 시리즈화에 성공해 3편까지 출시.',
|
||||
'학교가는 길을 미니게임화한 독특한 컨셉과 개성 있는 디자인 연출로 피쳐폰 시절 높은 다운로드 수익 창출.',
|
||||
'10여 종의 미니게임으로 구성. 각 미니게임은 외주 개발업체를 통해 진행.',
|
||||
'초기 개발 단계부터 참여해 미니게임 전체 세부 기획·밸런싱·아트 컨셉 담당.',
|
||||
'※ 퍼블리셔와의 수익 배분·라이선스 지분 이슈로 후속작은 타 업체 진행.',
|
||||
],
|
||||
'컨셉 기획 · 미니게임 8종 시스템 기획 · 외주 개발 업체 관리 등 실무 전반',
|
||||
None,
|
||||
None),
|
||||
]
|
||||
|
||||
|
||||
def build_game_slide(page, num, title, subtitle, info, overviews, role, kpi, img_file):
|
||||
s = prs.slides.add_slide(blank_layout)
|
||||
add_rect(s, 0, 0, SLIDE_W, SLIDE_H, COLOR_WHITE)
|
||||
|
||||
# 좌측 다크 사이드바 (게임 정보 카드)
|
||||
SIDEBAR_W = Inches(4.2)
|
||||
add_rect(s, 0, 0, SIDEBAR_W, SLIDE_H, COLOR_BG_DARK)
|
||||
# 좌측 navy 강조 띠
|
||||
add_rect(s, 0, 0, Inches(0.18), SLIDE_H, COLOR_GOLD)
|
||||
|
||||
# 사이드바 — 작품 번호
|
||||
add_textbox(s, Inches(0.5), Inches(0.5), Inches(3.5), Inches(0.4),
|
||||
f'WORK · {num}',
|
||||
size=11, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
|
||||
# 사이드바 — 게임명
|
||||
add_textbox(s, Inches(0.5), Inches(0.95), Inches(3.5), Inches(1.0),
|
||||
title, size=26, bold=True, color=COLOR_WHITE,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT, line_spacing=1.1)
|
||||
add_textbox(s, Inches(0.5), Inches(2.0), Inches(3.5), Inches(0.7),
|
||||
subtitle, size=12, color=COLOR_ACCENT,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT, italic=True, line_spacing=1.3)
|
||||
|
||||
# 구분선
|
||||
add_rect(s, Inches(0.5), Inches(2.95), Inches(0.6), Inches(0.025), COLOR_GOLD)
|
||||
|
||||
# 사이드바 — 게임 정보 표
|
||||
y = Inches(3.15)
|
||||
for label, value in info.items():
|
||||
add_textbox(s, Inches(0.5), y, Inches(3.5), Inches(0.25),
|
||||
label.upper(),
|
||||
size=9, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(0.5), y + Inches(0.25), Inches(3.5), Inches(0.35),
|
||||
value,
|
||||
size=12, color=COLOR_WHITE,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT)
|
||||
y += Inches(0.72)
|
||||
|
||||
# 사이드바 — 이미지 (있다면 하단)
|
||||
if img_file:
|
||||
img_path = os.path.join(IMG_DIR, img_file)
|
||||
if os.path.exists(img_path):
|
||||
try:
|
||||
# 이미지 사이즈 측정 후 비율 유지
|
||||
from PIL import Image
|
||||
with Image.open(img_path) as pim:
|
||||
iw, ih = pim.size
|
||||
# 너비 3.3", 위치 사이드바 하단
|
||||
max_w_in = 3.3
|
||||
max_h_in = 1.4
|
||||
ratio_img = iw / ih
|
||||
ratio_box = max_w_in / max_h_in
|
||||
if ratio_img >= ratio_box:
|
||||
target_w = max_w_in
|
||||
target_h = max_w_in / ratio_img
|
||||
else:
|
||||
target_h = max_h_in
|
||||
target_w = max_h_in * ratio_img
|
||||
ix = Inches((4.2 - target_w) / 2)
|
||||
iy = Inches(5.95 - target_h / 2)
|
||||
s.shapes.add_picture(img_path, ix, iy, Inches(target_w), Inches(target_h))
|
||||
except Exception as e:
|
||||
print(f' image warn: {e}')
|
||||
|
||||
# 우측 컨텐츠 영역
|
||||
CONTENT_X = Inches(4.7)
|
||||
# 상단 페이지 표기
|
||||
add_textbox(s, Inches(11.5), Inches(0.5), Inches(1.7), Inches(0.3),
|
||||
f'WORKS · {page:02d} / 20',
|
||||
size=9, color=COLOR_MUTED, align=PP_ALIGN.RIGHT,
|
||||
font=FONT_BODY)
|
||||
|
||||
# 우측 — 섹션 라벨
|
||||
add_textbox(s, CONTENT_X, Inches(0.55), Inches(8), Inches(0.4),
|
||||
'GAME OVERVIEW',
|
||||
size=11, bold=True, color=COLOR_PRIMARY,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_rect(s, CONTENT_X, Inches(0.95), Inches(0.6), Inches(0.04), COLOR_PRIMARY)
|
||||
|
||||
# 우측 — 게임 개요 (불릿형 단락)
|
||||
y = Inches(1.15)
|
||||
for line in overviews:
|
||||
# 불릿 마커
|
||||
dot = add_circle(s, CONTENT_X, y + Inches(0.12), Inches(0.08), COLOR_GOLD)
|
||||
add_textbox(s, CONTENT_X + Inches(0.2), y, Inches(8.3), Inches(0.6),
|
||||
line, size=11.5, color=COLOR_TEXT,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT, line_spacing=1.3)
|
||||
# 라인 수에 따른 동적 간격
|
||||
est_lines = max(1, (len(line) // 50) + 1)
|
||||
y += Inches(0.34 + 0.22 * (est_lines - 1))
|
||||
if y > Inches(5.3):
|
||||
break
|
||||
|
||||
# 우측 — 담당 업무 박스
|
||||
role_y = Inches(5.6)
|
||||
add_rect(s, CONTENT_X, role_y, Inches(8.4), Inches(0.85), COLOR_LIGHT)
|
||||
add_rect(s, CONTENT_X, role_y, Inches(0.1), Inches(0.85), COLOR_PRIMARY)
|
||||
add_textbox(s, CONTENT_X + Inches(0.25), role_y + Inches(0.08), Inches(8), Inches(0.3),
|
||||
'MY ROLE',
|
||||
size=10, bold=True, color=COLOR_PRIMARY,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, CONTENT_X + Inches(0.25), role_y + Inches(0.36), Inches(8), Inches(0.5),
|
||||
role, size=11, color=COLOR_TEXT,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT)
|
||||
|
||||
# KPI / Featured 박스 (있을 경우)
|
||||
if kpi:
|
||||
kpi_y = Inches(6.6)
|
||||
add_rect(s, CONTENT_X, kpi_y, Inches(8.4), Inches(0.6), COLOR_PRIMARY)
|
||||
add_textbox(s, CONTENT_X + Inches(0.25), kpi_y + Inches(0.1), Inches(8), Inches(0.4),
|
||||
'KPI / FEATURED',
|
||||
size=9, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, CONTENT_X + Inches(0.25), kpi_y + Inches(0.3), Inches(8), Inches(0.4),
|
||||
kpi, size=10.5, color=COLOR_WHITE,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT)
|
||||
|
||||
# 푸터
|
||||
add_textbox(s, Inches(4.7), Inches(7.15), Inches(8), Inches(0.25),
|
||||
'이승우 · Game Designer · Portfolio',
|
||||
size=8, color=COLOR_MUTED, align=PP_ALIGN.LEFT,
|
||||
font=FONT_BODY)
|
||||
|
||||
|
||||
# ═══════════════ S16. 경력 개요 ═══════════════
|
||||
def build_slide_16():
|
||||
s = prs.slides.add_slide(blank_layout)
|
||||
add_rect(s, 0, 0, SLIDE_W, SLIDE_H, COLOR_WHITE)
|
||||
|
||||
add_textbox(s, Inches(0.6), Inches(0.5), Inches(10), Inches(0.4),
|
||||
'02 · Career Summary',
|
||||
size=12, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(0.6), Inches(0.85), Inches(12), Inches(0.7),
|
||||
'경력 개요',
|
||||
size=36, bold=True, color=COLOR_PRIMARY,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(0.6), Inches(1.55), Inches(12), Inches(0.4),
|
||||
'총 경력 13년 2개월 · 다수의 메인 기획 및 디렉터 경험',
|
||||
size=12, color=COLOR_MUTED,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT)
|
||||
page_header(s, 16, section='CAREER')
|
||||
|
||||
# 큰 KPI 박스
|
||||
add_rect(s, Inches(0.6), Inches(2.25), Inches(3.9), Inches(1.4), COLOR_BG_DARK)
|
||||
add_rect(s, Inches(0.6), Inches(2.25), Inches(0.15), Inches(1.4), COLOR_GOLD)
|
||||
add_textbox(s, Inches(0.85), Inches(2.4), Inches(3.5), Inches(0.4),
|
||||
'TOTAL EXPERIENCE',
|
||||
size=11, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(0.85), Inches(2.75), Inches(3.5), Inches(0.9),
|
||||
'13년 2개월',
|
||||
size=42, bold=True, color=COLOR_WHITE,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(0.85), Inches(3.32), Inches(3.5), Inches(0.3),
|
||||
'Game Designer · PD · PM',
|
||||
size=11, color=COLOR_ACCENT,
|
||||
font=FONT_BODY, italic=True, align=PP_ALIGN.LEFT)
|
||||
|
||||
# 우측 — 핵심 강점 그리드 (2 columns × 5 rows)
|
||||
strengths = [
|
||||
('PROJECT LEADING', '다수의 프로젝트에서 메인 기획 및 디렉터로 리딩 경험'),
|
||||
('PROVEN HITS', '만렙 영웅 키우기, 데빌즈, 마스터 오브 던전, 드래곤 헌터, 학교가는 길'),
|
||||
('GLOBAL SERVICE', '미국·중국·일본 등 글로벌 서비스 대응 경험 (데빌즈 외)'),
|
||||
('MULTI-PLATFORM', 'NDS · GP2X · AR · 콘솔 / 모바일 등 다양한 플랫폼 실무'),
|
||||
('LIVE OPERATIONS', '라이브 게임 운영 및 서비스 다수 보유'),
|
||||
('PROACTIVE', '주도적인 프로젝트 제안·추진 (방치형·IP 활용 등)'),
|
||||
('MULTI-ROLE', 'PD · PM · QA · 외주 개발 관리 등 다양한 포지션 이해'),
|
||||
('NARRATIVE', '게임 시나리오 작성 및 스크립트 작업 (멀티 시나리오 포함)'),
|
||||
('TOOLS', '스파인 · 협업 툴 · 발사믹 목업 · 마인드맵 등 효율적 활용'),
|
||||
('BM DESIGN', '게임 통찰력·서비스 경험 기반 핵심 BM 설계 및 리뉴얼 주도'),
|
||||
]
|
||||
col_x = [Inches(4.85), Inches(9.05)]
|
||||
cell_w = Inches(4.05)
|
||||
cell_h = Inches(0.85)
|
||||
start_y = Inches(2.25)
|
||||
for i, (label, desc) in enumerate(strengths):
|
||||
col = i % 2
|
||||
row = i // 2
|
||||
x = col_x[col]
|
||||
y = start_y + row * (cell_h + Inches(0.1))
|
||||
# 카드
|
||||
card = add_rounded(s, x, y, cell_w, cell_h, COLOR_LIGHT, COLOR_BORDER)
|
||||
# 좌측 아이콘 원 (gold) + 번호
|
||||
add_circle(s, x + Inches(0.15), y + Inches(0.2), Inches(0.45), COLOR_PRIMARY)
|
||||
add_textbox(s, x + Inches(0.15), y + Inches(0.2), Inches(0.45), Inches(0.45),
|
||||
f'{i+1:02d}', size=10, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.CENTER, anchor=MSO_ANCHOR.MIDDLE)
|
||||
# 라벨
|
||||
add_textbox(s, x + Inches(0.7), y + Inches(0.12), cell_w - Inches(0.8), Inches(0.3),
|
||||
label, size=10, bold=True, color=COLOR_PRIMARY,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
# 본문
|
||||
add_textbox(s, x + Inches(0.7), y + Inches(0.4), cell_w - Inches(0.8), Inches(0.45),
|
||||
desc, size=10, color=COLOR_TEXT,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT, line_spacing=1.2)
|
||||
|
||||
# 하단 — 마지막 1 항목 (소규모 ~ 중형 조직 경험)
|
||||
bottom_y = Inches(7.0)
|
||||
add_textbox(s, Inches(0.6), bottom_y, Inches(12.2), Inches(0.3),
|
||||
'★ 소규모 스타트업부터 중형급 이상의 개발 조직까지 다양한 실무 경험 보유',
|
||||
size=11, bold=True, color=COLOR_PRIMARY,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
|
||||
page_footer(s)
|
||||
|
||||
|
||||
# ═══════════════ S17·18·19. 영상 URL ═══════════════
|
||||
def build_video_links_slide(page_num, section_title, items):
|
||||
"""items: [(title, url, desc), ...]"""
|
||||
s = prs.slides.add_slide(blank_layout)
|
||||
add_rect(s, 0, 0, SLIDE_W, SLIDE_H, COLOR_WHITE)
|
||||
add_textbox(s, Inches(0.6), Inches(0.5), Inches(10), Inches(0.4),
|
||||
'03 · Reference Videos',
|
||||
size=12, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(0.6), Inches(0.85), Inches(12), Inches(0.7),
|
||||
section_title,
|
||||
size=36, bold=True, color=COLOR_PRIMARY,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(0.6), Inches(1.55), Inches(12), Inches(0.4),
|
||||
'포트폴리오 참고 영상 / 다운로드 URL',
|
||||
size=12, color=COLOR_MUTED,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT)
|
||||
page_header(s, page_num, section='VIDEOS')
|
||||
|
||||
y = Inches(2.3)
|
||||
for title, url, desc in items:
|
||||
# 카드
|
||||
add_rounded(s, Inches(0.6), y, Inches(12.15), Inches(1.3), COLOR_LIGHT, COLOR_BORDER)
|
||||
# 좌측 navy 띠
|
||||
add_rect(s, Inches(0.6), y, Inches(0.15), Inches(1.3), COLOR_PRIMARY)
|
||||
# 제목
|
||||
add_textbox(s, Inches(0.9), y + Inches(0.15), Inches(11.5), Inches(0.4),
|
||||
title, size=15, bold=True, color=COLOR_PRIMARY,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
# URL
|
||||
add_textbox(s, Inches(0.9), y + Inches(0.55), Inches(11.5), Inches(0.35),
|
||||
url, size=10.5, color=COLOR_GOLD,
|
||||
font=FONT_MONO, align=PP_ALIGN.LEFT)
|
||||
# 설명
|
||||
if desc:
|
||||
add_textbox(s, Inches(0.9), y + Inches(0.92), Inches(11.5), Inches(0.35),
|
||||
desc, size=10, color=COLOR_MUTED,
|
||||
font=FONT_BODY, italic=True, align=PP_ALIGN.LEFT)
|
||||
y += Inches(1.5)
|
||||
if y > Inches(6.5):
|
||||
break
|
||||
|
||||
page_footer(s)
|
||||
|
||||
|
||||
# ═══════════════ S20. 마무리·다운로드 ═══════════════
|
||||
def build_slide_20():
|
||||
s = prs.slides.add_slide(blank_layout)
|
||||
add_rect(s, 0, 0, SLIDE_W, SLIDE_H, COLOR_BG_DARK)
|
||||
# 좌측 띠
|
||||
add_rect(s, 0, 0, Inches(0.25), SLIDE_H, COLOR_GOLD)
|
||||
|
||||
add_textbox(s, Inches(1.0), Inches(1.2), Inches(10), Inches(0.5),
|
||||
'04 · Work Outputs',
|
||||
size=14, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(1.0), Inches(1.7), Inches(11), Inches(1.0),
|
||||
'실무 작업 결과물',
|
||||
size=48, bold=True, color=COLOR_WHITE,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(1.0), Inches(2.85), Inches(11), Inches(0.5),
|
||||
'포트폴리오 다운로드 URL',
|
||||
size=18, color=COLOR_ACCENT,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT, italic=True)
|
||||
|
||||
# 다운로드 카드 (예시 — 원본에 URL 텍스트 단편만 존재)
|
||||
add_rect(s, Inches(1.0), Inches(3.8), Inches(11.3), Inches(0.04), COLOR_GOLD)
|
||||
|
||||
download_items = [
|
||||
('GAME DESIGN DOCUMENTS',
|
||||
'기획서 · 시스템 설계 · 밸런스 표 등 실무 작업 결과물 모음'),
|
||||
('UI / UX MOCKUPS',
|
||||
'발사믹·스파인·기타 목업 툴을 활용한 화면 설계'),
|
||||
('SCRIPTS & SCENARIOS',
|
||||
'게임 시나리오 · 멀티 시나리오 스크립트'),
|
||||
]
|
||||
y = Inches(4.2)
|
||||
for label, desc in download_items:
|
||||
add_rect(s, Inches(1.0), y, Inches(0.05), Inches(0.7), COLOR_GOLD)
|
||||
add_textbox(s, Inches(1.2), y + Inches(0.05), Inches(11), Inches(0.35),
|
||||
label, size=13, bold=True, color=COLOR_WHITE,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(1.2), y + Inches(0.35), Inches(11), Inches(0.3),
|
||||
desc, size=11, color=COLOR_ACCENT,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT, italic=True)
|
||||
y += Inches(0.85)
|
||||
|
||||
# 푸터
|
||||
add_textbox(s, Inches(1.0), Inches(6.7), Inches(11), Inches(0.4),
|
||||
'THANK YOU',
|
||||
size=22, bold=True, color=COLOR_GOLD,
|
||||
font=FONT_HEADER, align=PP_ALIGN.LEFT)
|
||||
add_textbox(s, Inches(1.0), Inches(7.1), Inches(11), Inches(0.3),
|
||||
'Lee Seung-Woo · Game Designer · 2019.12.22',
|
||||
size=11, color=COLOR_ACCENT,
|
||||
font=FONT_BODY, align=PP_ALIGN.LEFT)
|
||||
|
||||
|
||||
# ─────────────── 빌드 실행 ───────────────
|
||||
print('Building slides...')
|
||||
build_slide_01(); print(' S1 표지')
|
||||
build_slide_02(); print(' S2 인덱스')
|
||||
for game in GAMES:
|
||||
page, num, title, subtitle, info, overviews, role, kpi, img_file = game
|
||||
build_game_slide(page, num, title, subtitle, info, overviews, role, kpi, img_file)
|
||||
print(f' S{page} {title}')
|
||||
build_slide_16(); print(' S16 경력')
|
||||
|
||||
videos_p17 = [
|
||||
('데빌즈',
|
||||
'https://youtu.be/GZNZvpsk5WE',
|
||||
'컴투스 퍼블리싱 · 인기 무료 게임 1위 (2013/11) · 액션 RPG 플레이 영상'),
|
||||
('프로젝트 BC (2014)',
|
||||
'https://youtu.be/maMV-lcPB3I',
|
||||
'하드코어 액션 MORPG · 2D 그래픽과 멀티 시나리오 시연'),
|
||||
('Spine 2D 작업 시연',
|
||||
'—',
|
||||
'캐릭터 애니메이션 작업 영상 (Spine 활용)'),
|
||||
]
|
||||
build_video_links_slide(17, 'Reference Videos · 1', videos_p17); print(' S17 영상1')
|
||||
|
||||
videos_p18 = [
|
||||
('드래곤 헌터스',
|
||||
'https://drive.google.com/open?id=1tUkQ_bOwRrx3Y4LARqRX4KFGi5vXUocv',
|
||||
'GP2X · HD 버전 플레이 영상'),
|
||||
('마스터 오브 던전',
|
||||
'https://youtu.be/9ipP9KkBZxI',
|
||||
'시나리오형 액션 RPG 플레이 영상'),
|
||||
]
|
||||
build_video_links_slide(18, 'Reference Videos · 2', videos_p18); print(' S18 영상2')
|
||||
|
||||
videos_p19 = [
|
||||
('쿠로네코 프로젝트',
|
||||
'https://drive.google.com/open?id=1poqqti2raZw_rosy3RJlVQNctPmEeE2P',
|
||||
'개발이 상당부분 완료된 상태에서 중도 드랍된 쿠로네코 프로젝트 시연 영상'),
|
||||
('학교가는 길 1',
|
||||
'https://youtu.be/XMWlcZyJYSg',
|
||||
'조이모아 퍼블리싱 · 학교가는 길 플레이 영상'),
|
||||
]
|
||||
build_video_links_slide(19, 'Reference Videos · 3', videos_p19); print(' S19 영상3')
|
||||
|
||||
build_slide_20(); print(' S20 마무리')
|
||||
|
||||
prs.save(OUT_PATH)
|
||||
print(f'\n✅ Saved: {OUT_PATH}')
|
||||
print(f' Size: {os.path.getsize(OUT_PATH):,} bytes')
|
||||
print(f' Slides: {len(prs.slides)}')
|
||||
|
Before Width: | Height: | Size: 1.6 KiB |
|
Before Width: | Height: | Size: 1.4 KiB |
|
Before Width: | Height: | Size: 38 KiB |
|
Before Width: | Height: | Size: 2.2 MiB |
|
Before Width: | Height: | Size: 2.2 KiB |
|
Before Width: | Height: | Size: 43 KiB |
|
Before Width: | Height: | Size: 64 KiB |
|
Before Width: | Height: | Size: 150 KiB |
|
Before Width: | Height: | Size: 477 KiB |