refactor(#52-B-C): P28 C 영역 고립 → P 섹션 이동
P28(C 섹션 내 1481) → P23 뒤·P29 앞(1042)으로 이동. P 섹션 연속 배치 복구. Before: ... P23(1032) → P29(1042) → P30 → P31 ... C30·P28(1481·C 영역 중간) After: P23(1032) → P28(1042) → P29(1125) → P30(1162) → P31(1189) P28 블록 83줄 이동. 내용 수정 없음. 줄 수 2129 유지 (diff 0). Python line 기반 정확 추출·삽입으로 의미 보존 검증 통과. C37-2·C37-5 준수. #52-B 단계 C/3 완료. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
f0f9ab9b5f
commit
3eff894238
|
|
@ -1039,6 +1039,89 @@ PD님이 **"세션 공유"**라고 지시하면, 현재 세션의 모든 변경
|
|||
| **PM 확인 필요** | 신규 시스템 제안, 기존 방향 변경, 타 부서 영향 결정 | 새 메커니즘 도입, 기존 조건 체계 재편 |
|
||||
| **PD님 확인 필요** | 핵심 밸런싱 방향 전환, 유저 경험 직접 영향, 데이터 자산 변경(C6) | 전투 공식 변경, 과금 밸런스 조정 |
|
||||
|
||||
## P28. 조직 업무 현황 보고 표준 포맷 (2026-04-17 PD님 직접 지시)
|
||||
|
||||
> PD님 또는 상위로 **조직 업무 현황 보고** 시 매 보고마다 형식이 달라지지 않도록 **항상 동일한 표준 포맷**으로 팀별 분리 제공한다. 본 규칙은 "현 남은 업무"·"업무 현황"·"현황 요약"·"남은 작업"·"조직 현황" 등 모든 관련 표현에 공통 적용한다. 매 보고 형식 변동으로 인한 인지 부담·세션 간 비교 곤란·정보 누락을 차단한다.
|
||||
|
||||
### P28-1. 필수 섹션 구조 (고정 템플릿)
|
||||
|
||||
```markdown
|
||||
## 조직 업무 현황 (YYYY-MM-DD)
|
||||
|
||||
세션 갱신 실측 완료 — 활성 지시 로그 + 최근 대화로그 + Inbox 전수 확인.
|
||||
|
||||
### 활성 업무 총 N건 ([진행중 a / 대기 b / 보류 c])
|
||||
|
||||
#### 개발팀 (M건)
|
||||
| # | 요지 | 영향 프로젝트 | 상태 | 재개 트리거 |
|
||||
|---|------|--------------|------|-------------|
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
#### 기획팀 (K건)
|
||||
| # | 요지 | 영향 프로젝트 | 상태 | 재개 트리거 |
|
||||
|---|------|--------------|------|-------------|
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
### 주요 관찰
|
||||
1. **자율 착수 가능** N건 — [구체 항목·재량 주체]
|
||||
2. **PD님 결정 대기** N건 — [구체 항목] (없으면 "없음")
|
||||
3. **차단 블로커** — [구체 항목] (없으면 "없음")
|
||||
4. **최근 완료 요약** (선택) — [라운드 종결 내역]
|
||||
|
||||
### 권고 / PD님 안건
|
||||
- PM 재량 수행 예정 사항
|
||||
- **PD님 결정 필요 안건** (없으면 "없음" 명시)
|
||||
```
|
||||
|
||||
### P28-2. 필드 규칙
|
||||
- **#**: PD 지시 로그 번호. 팀별 별도 채번 (개발·기획 혼용 금지)
|
||||
- **요지**: 1줄 핵심 요약 (25자 이내 권장). 장황 설명 지양
|
||||
- **영향 프로젝트** (필수, 2026-04-17 추가): 본 업무가 결과물·영향을 미치는 프로젝트 명시. 값 예시 — `수상한잡화점` / `코어 프레임워크` / `조직 공통` / `차기 프로젝트명`. 복수 영향 시 쉼표 구분. 프로젝트 경계가 모호한 조직 운영·규칙 개정 업무는 `조직 공통`
|
||||
- **상태**: 활성 3종만 표기(`진행중`·`대기`·`보류`). 완료 아카이브 항목은 본 테이블 배제 (P19 2분할 구조 준수)
|
||||
- **재개 트리거**: 대기·보류 시 필수 (누락 금지). 진행중은 "—" 또는 현 진행 단계
|
||||
- **주요 관찰**: 4개 항목 순서 고정. 해당 없으면 "없음" 명시 (항목 생략 금지)
|
||||
|
||||
### P28-3. 팀 분리 원칙
|
||||
- **개발팀·기획팀 섹션 분리 필수** — 빈 팀도 "활성 없음" 1줄로 표기
|
||||
- 전문 에이전트(balance/content/level/narrative/system/ux-designer)·감사관(pm/dev/plan-auditor) 작업은 **소속 팀에 귀속**하여 표기
|
||||
- 팀 경계가 애매한 PM 직접 수행 업무는 **"권고" 섹션의 "PM 재량 수행"**에 분리
|
||||
|
||||
### P28-4. 실측 응집성 요구
|
||||
- 보고 시점 실측 기반 (`scripts/verify_log_paths.sh` 선행 권장)
|
||||
- **활성 테이블만 스캔** (P19 2분할 구조) — 완료 아카이브는 배제하여 "완료된 업무가 진행중으로 보이는" 왜곡 차단 (`memory/org/feedback_log_round_completion.md`)
|
||||
- 부분 완료 상태가 애매한 경우 "라운드 완결 아카이브 규칙" 적용하여 **해당 라운드 승인분은 아카이브 이동 + 잔여는 신규 지시 분리**
|
||||
|
||||
### P28-5. 금지 표현
|
||||
- 매 보고마다 달라지는 임의 위계(원문자·★·불릿 단독)
|
||||
- 상태 외 추가 컬럼 임의 추가 (보고 목적에 따라 확장 필요 시 PD님 확인)
|
||||
- 완료 아카이브 항목을 활성 표에 포함
|
||||
- "자세한 내용은 ~ 참조" 류 외부 포인터 (핵심 정보는 본 포맷 내 수용)
|
||||
|
||||
### P28-6. 연관
|
||||
- **P19** (PD 지시 로그) — 활성 테이블 데이터 원천
|
||||
- **P21** (세션 갱신 프로토콜) — 5단계 보고 형식이 본 P28로 통일됨
|
||||
- **C25** (넘버링 일관) — 주요 관찰 섹션의 1./A./가) 위계 준수
|
||||
- **`memory/org/feedback_log_round_completion.md`** — 장기 우산 지시 아카이브 원칙
|
||||
|
||||
### P28-7. 위반 시
|
||||
- 보고 형식 임의 변경 시 즉시 P28 표준으로 재작성
|
||||
- 반복 위반 시 C31 자기검증 체크리스트에 P28 준수 항목 추가 검토
|
||||
|
||||
### P28-8. 최신 결정 중심 보고 원칙 (2026-04-19 PD님 직접 지시 신설)
|
||||
|
||||
현황 보고·예상 결과 보고·완료 보고 시 **확정·종결된 안건을 불필요하게 재언급하지 않는다**.
|
||||
|
||||
- **최신 결정 중심** 서술. 확정 사안은 **전제**로 두고 본문에서 재강조 금지
|
||||
- **"고착·영구 확정·재논의 대상 아님·영구 종료" 등 재강조 표현은 위험 신호** — 역설적으로 "아직 살아있는 이슈처럼" 인지됨. 등장 시 삭제 검토
|
||||
- **PD님 별도 히스토리 요청 없으면** 완료 아카이브 내용 본문 언급 금지 (참조 링크만 허용)
|
||||
- **예외**: PD님이 "왜 이렇게 결정됐는지" 경위·맥락·이력을 **직접 요청** 시 이력 언급 가능
|
||||
|
||||
**근거**: 2026-04-19 PD님 직접 지적 "이미 종결된 안건은 내가 별도로 히스토리를 묻기 전까지 자꾸 언급하지 마. 항상 최신 결정 사항으로 얘기하고, 완료되거나 종결된 안건은 아카이브화해서 요청할 때만 얘기하도록 해."
|
||||
|
||||
**실증 메모리**: `memory/org/feedback_resolved_agenda_unnecessary_reference.md`
|
||||
|
||||
---
|
||||
|
||||
## P29. 코어 코드 프레임워크 프로젝트 규칙 (2026-04-18 PD님 직접 지시)
|
||||
|
||||
> **적용 범위**: **코어 코드 프레임워크** 프로젝트 (`코어코드/NerdNavis.Framework/`·`프로젝트/코어프레임워크/`) 전용 규칙. 본 규칙은 프로젝트 단위 고유 규칙으로 P17(수상한잡화점 전용)과 동일 층위.
|
||||
|
|
@ -1478,89 +1561,6 @@ C20-7 자기검증 5문항에 다음 항목 추가:
|
|||
|
||||
---
|
||||
|
||||
## P28. 조직 업무 현황 보고 표준 포맷 (2026-04-17 PD님 직접 지시)
|
||||
|
||||
> PD님 또는 상위로 **조직 업무 현황 보고** 시 매 보고마다 형식이 달라지지 않도록 **항상 동일한 표준 포맷**으로 팀별 분리 제공한다. 본 규칙은 "현 남은 업무"·"업무 현황"·"현황 요약"·"남은 작업"·"조직 현황" 등 모든 관련 표현에 공통 적용한다. 매 보고 형식 변동으로 인한 인지 부담·세션 간 비교 곤란·정보 누락을 차단한다.
|
||||
|
||||
### P28-1. 필수 섹션 구조 (고정 템플릿)
|
||||
|
||||
```markdown
|
||||
## 조직 업무 현황 (YYYY-MM-DD)
|
||||
|
||||
세션 갱신 실측 완료 — 활성 지시 로그 + 최근 대화로그 + Inbox 전수 확인.
|
||||
|
||||
### 활성 업무 총 N건 ([진행중 a / 대기 b / 보류 c])
|
||||
|
||||
#### 개발팀 (M건)
|
||||
| # | 요지 | 영향 프로젝트 | 상태 | 재개 트리거 |
|
||||
|---|------|--------------|------|-------------|
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
#### 기획팀 (K건)
|
||||
| # | 요지 | 영향 프로젝트 | 상태 | 재개 트리거 |
|
||||
|---|------|--------------|------|-------------|
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
### 주요 관찰
|
||||
1. **자율 착수 가능** N건 — [구체 항목·재량 주체]
|
||||
2. **PD님 결정 대기** N건 — [구체 항목] (없으면 "없음")
|
||||
3. **차단 블로커** — [구체 항목] (없으면 "없음")
|
||||
4. **최근 완료 요약** (선택) — [라운드 종결 내역]
|
||||
|
||||
### 권고 / PD님 안건
|
||||
- PM 재량 수행 예정 사항
|
||||
- **PD님 결정 필요 안건** (없으면 "없음" 명시)
|
||||
```
|
||||
|
||||
### P28-2. 필드 규칙
|
||||
- **#**: PD 지시 로그 번호. 팀별 별도 채번 (개발·기획 혼용 금지)
|
||||
- **요지**: 1줄 핵심 요약 (25자 이내 권장). 장황 설명 지양
|
||||
- **영향 프로젝트** (필수, 2026-04-17 추가): 본 업무가 결과물·영향을 미치는 프로젝트 명시. 값 예시 — `수상한잡화점` / `코어 프레임워크` / `조직 공통` / `차기 프로젝트명`. 복수 영향 시 쉼표 구분. 프로젝트 경계가 모호한 조직 운영·규칙 개정 업무는 `조직 공통`
|
||||
- **상태**: 활성 3종만 표기(`진행중`·`대기`·`보류`). 완료 아카이브 항목은 본 테이블 배제 (P19 2분할 구조 준수)
|
||||
- **재개 트리거**: 대기·보류 시 필수 (누락 금지). 진행중은 "—" 또는 현 진행 단계
|
||||
- **주요 관찰**: 4개 항목 순서 고정. 해당 없으면 "없음" 명시 (항목 생략 금지)
|
||||
|
||||
### P28-3. 팀 분리 원칙
|
||||
- **개발팀·기획팀 섹션 분리 필수** — 빈 팀도 "활성 없음" 1줄로 표기
|
||||
- 전문 에이전트(balance/content/level/narrative/system/ux-designer)·감사관(pm/dev/plan-auditor) 작업은 **소속 팀에 귀속**하여 표기
|
||||
- 팀 경계가 애매한 PM 직접 수행 업무는 **"권고" 섹션의 "PM 재량 수행"**에 분리
|
||||
|
||||
### P28-4. 실측 응집성 요구
|
||||
- 보고 시점 실측 기반 (`scripts/verify_log_paths.sh` 선행 권장)
|
||||
- **활성 테이블만 스캔** (P19 2분할 구조) — 완료 아카이브는 배제하여 "완료된 업무가 진행중으로 보이는" 왜곡 차단 (`memory/org/feedback_log_round_completion.md`)
|
||||
- 부분 완료 상태가 애매한 경우 "라운드 완결 아카이브 규칙" 적용하여 **해당 라운드 승인분은 아카이브 이동 + 잔여는 신규 지시 분리**
|
||||
|
||||
### P28-5. 금지 표현
|
||||
- 매 보고마다 달라지는 임의 위계(원문자·★·불릿 단독)
|
||||
- 상태 외 추가 컬럼 임의 추가 (보고 목적에 따라 확장 필요 시 PD님 확인)
|
||||
- 완료 아카이브 항목을 활성 표에 포함
|
||||
- "자세한 내용은 ~ 참조" 류 외부 포인터 (핵심 정보는 본 포맷 내 수용)
|
||||
|
||||
### P28-6. 연관
|
||||
- **P19** (PD 지시 로그) — 활성 테이블 데이터 원천
|
||||
- **P21** (세션 갱신 프로토콜) — 5단계 보고 형식이 본 P28로 통일됨
|
||||
- **C25** (넘버링 일관) — 주요 관찰 섹션의 1./A./가) 위계 준수
|
||||
- **`memory/org/feedback_log_round_completion.md`** — 장기 우산 지시 아카이브 원칙
|
||||
|
||||
### P28-7. 위반 시
|
||||
- 보고 형식 임의 변경 시 즉시 P28 표준으로 재작성
|
||||
- 반복 위반 시 C31 자기검증 체크리스트에 P28 준수 항목 추가 검토
|
||||
|
||||
### P28-8. 최신 결정 중심 보고 원칙 (2026-04-19 PD님 직접 지시 신설)
|
||||
|
||||
현황 보고·예상 결과 보고·완료 보고 시 **확정·종결된 안건을 불필요하게 재언급하지 않는다**.
|
||||
|
||||
- **최신 결정 중심** 서술. 확정 사안은 **전제**로 두고 본문에서 재강조 금지
|
||||
- **"고착·영구 확정·재논의 대상 아님·영구 종료" 등 재강조 표현은 위험 신호** — 역설적으로 "아직 살아있는 이슈처럼" 인지됨. 등장 시 삭제 검토
|
||||
- **PD님 별도 히스토리 요청 없으면** 완료 아카이브 내용 본문 언급 금지 (참조 링크만 허용)
|
||||
- **예외**: PD님이 "왜 이렇게 결정됐는지" 경위·맥락·이력을 **직접 요청** 시 이력 언급 가능
|
||||
|
||||
**근거**: 2026-04-19 PD님 직접 지적 "이미 종결된 안건은 내가 별도로 히스토리를 묻기 전까지 자꾸 언급하지 마. 항상 최신 결정 사항으로 얘기하고, 완료되거나 종결된 안건은 아카이브화해서 요청할 때만 얘기하도록 해."
|
||||
|
||||
**실증 메모리**: `memory/org/feedback_resolved_agenda_unnecessary_reference.md`
|
||||
|
||||
---
|
||||
|
||||
## C31. 응답 발신 직전 자기검증 의무 (2026-04-17 PD님 직접 지시 — 조직 사활 걸린 중대 사안·헌법급)
|
||||
|
||||
> **모든 세션 리더(PM 포함)는 응답을 발신하기 직전에 본 C31 체크리스트를 통과해야 한다.** 2026-04-17 PM이 C29 신설 당일 첫 응답에서 C29를 정면 위반한 사건을 근거로, PD님이 "조직 사활 걸린 중대 문제"로 직접 선언하시며 C20-7 자기검증을 **헌법급 코어 규칙으로 격상**한 것이다. 본 규칙은 입력 보강(P21-5B·P24 읽기 의무) 대칭의 **출력 검증 강제 메커니즘**이다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue