등급 1~10 확장 + 라운드 주목도 하드 캡 재구현, 문서 체계 정비
서울 PC에서 Remote-SSH로 작업하던 중 연결이 끊겨 커밋 전 상태로 유실된 2026-09-15 결정사항(등급 1~4→1~10 확장, 5장 포커 핸드, 주목도 기반 페널티, 토큰 1종 통합, 상점/규약 재작성)을 평택 로컬 체크아웃에서 전체 재구현했다. 그 과정에서 라운드/회기 구조를 오해해서 잘못 반영했던 부분을 다시 고쳤다. **데이터** - cards.csv 43개 선택지, pollution_pool.csv 재매핑 — 등급 1·3 공백을 없애고 1~10 전 구간을 채움 (평균 등급 4.14, 8결재 기준 예상 주목도 33) - pollution_pool.csv에 등급 1·3 전용 오염 카드 8개 신규 추가 (축별 2개) **게임 루프** - 라운드/회기 이층 구조 도입 → 원래 의도(라운드마다 정산·의회를 거치는 것)와 어긋난 오해로 판명, 단일 라운드 구조로 환원 - 라운드 종료 조건을 "결재 8건 고정"에서 블랙잭식 하드 캡으로 교체 — 주목도가 라운드 한도(21 + 라운드당 +5)를 넘으면 합본 기회 없이 즉시 강제 종료(버스트), 한도 밑에서는 "정산하기"로 언제든 자율 종료 가능 - CouncilScreen: 징벌 규약 5개 초과 시 목록 접기/펼치기 (§9.2 UI 요건) **문서 체계** - CLAUDE.md: 흩어진 기획 문서 7종 참조를 코어시스템 기획서 단일 참조(§ 매핑 포함)로 교체, Phase 진행 표 폐지 후 §17 체크박스를 진행 상황 원본으로 지정 - CLAUDE.md에 "결정 노트" 규칙 신설 — T-decision.md 양식 + DEVLOG 위키링크 연동 - docs/DEVLOG.md 신규 작성 (구 버전은 old/2026.09.04/ 보관) - 결정 노트 2건 작성: 등급확장-주목도시스템, 라운드-주목도-하드캡-복원 - ProjectSS_코어시스템_기획서.md §2/§4.2-B/§17/§19/§20을 현재 결정에 맞게 갱신 Playwright로 등급 1·3 카드 실등장, 라운드 번호 증가, 주목도 초과 시 버스트→ 상점 강제 전환까지 실제 브라우저에서 확인. 콘솔 에러 0건. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
kyoung5seo
co-authored by
Claude Sonnet 5
Claude Sonnet 5
parent
cde44c4f2c
commit
0a065068c1
@@ -1,7 +1,8 @@
|
||||
# Project SS — CLAUDE.md
|
||||
|
||||
> **위치:** repo root (`ProjectSS/CLAUDE.md`) — Claude Code는 root에서 실행한다.
|
||||
> **이 파일의 역할:** 규칙만 담는다. 작업 이력·진행 상황은 `docs/DEVLOG.md`, Phase 계획은 `ROADMAP.md`.
|
||||
> **이 파일의 역할:** 규칙만 담는다. 작업 이력·진행 상황은 `docs/DEVLOG.md`, 구현 로드맵은
|
||||
> `docs/ProjectSS_코어시스템_기획서.md` §17.
|
||||
> **상위 규칙:** 전역 정체성·개발 철학은 `~/.hermes/SOUL.md`, 프로젝트 정체성은 `AGENTS.md`에 있다.
|
||||
> 이 파일은 그 위에 얹히는 **코드 레벨 규칙**만 다룬다.
|
||||
|
||||
@@ -25,7 +26,10 @@ git log HEAD..origin/main # 내가 안 받은 커밋
|
||||
|
||||
## 코드 컨벤션
|
||||
|
||||
- 전체 구조·아키텍처 원칙(상태 배치, `engine/` 경계, world 스냅샷 패턴) → @docs/architecture_design.md
|
||||
- 신규 개발은 `client/src/core/` 아래에 있다 (`engine/`은 React 의존 없는 순수 로직, `components/`는 UI).
|
||||
기존 `client/src/components/`·`client/src/engine/`(구 GameScreen.jsx 중심 구조)는 참조용으로만
|
||||
남아있고 더 이상 진입점(`App.jsx`)에서 쓰이지 않는다. 코드 구조는 게임 규칙과 함께 계속
|
||||
바뀌는 중이라 별도 아키텍처 문서를 두지 않는다 — 구 `architecture_design.md`는 폐기됐다.
|
||||
- 실제 앱은 `client/` 안에 있음. npm 명령은 `cd client` 후 실행.
|
||||
- 로컬에 Node.js LTS 설치되어 `npm run dev`로 실기 검증 가능 (Playwright 플레이 확인까지 완료).
|
||||
- 플레이테스트는 리포 루트의 `playtest.bat` 더블클릭 (dev 서버 + 브라우저 자동 오픈).
|
||||
@@ -70,41 +74,72 @@ git log HEAD..origin/main # 내가 안 받은 커밋
|
||||
|
||||
코드 작성 시 항상 원본 문서를 기준으로 한다. **게임 규칙 수치를 이 파일에 복사하지 말 것.**
|
||||
|
||||
- 카드 타입별 스와이프 결과, 파라미터, 의회 액션 → @docs/Project_SS_서사형_덱빌딩_게임_시스템_기획서.md
|
||||
- 파벌 12종 우호도 조건, 엔딩 매트릭스, 세계관 → @docs/Project_SS_스토리_바이블_v3_0.md
|
||||
- 화면 전환/분기 로직 → @docs/ProjectSS_유저플로우.md
|
||||
- UI 레이아웃 → @docs/ProjectSS_텍스트_와이어프레임.md
|
||||
- 컬러/타이포/햅틱 수치 → @docs/ProjectSS_디자인_토큰.md
|
||||
- 요구사항 정의 → @docs/ProjectSS_PRD.md
|
||||
예전에 흩어져 있던 기획 문서 7종(서사형 덱빌딩 시스템 기획서·스토리 바이블·유저플로우·
|
||||
텍스트 와이어프레임·디자인 토큰·PRD·architecture_design)은 전부 아래 한 문서로 통합됐다.
|
||||
`docs/` 안에 옛 문서가 남아 보이더라도 참조하지 말 것 — 이제 유일한 원본은 이것뿐이다.
|
||||
|
||||
- 게임 규칙·수치·화면 흐름·UI 레이아웃·요구사항 전부 → @docs/ProjectSS_코어시스템_기획서.md
|
||||
- 기호 체계(축·등급) → §3 · 책상·페널티(주목도) → §4 · 합본(족보) → §5
|
||||
- 파라미터(4대 게이지) → §6 · 명분 → §7 · 경제(상점) → §8
|
||||
- 의회(규약·실적감사·13인 위원회) → §9 · 자산 → §10 · 전례(내러티브 태그) → §11
|
||||
- 노선 → §13 · 엔딩 → §15 · 텍스트 스타일 가이드 → §16
|
||||
- **구현 우선순위·진행 상황(로드맵) → §17** — Phase 계획을 대신한다, 아래 참고
|
||||
|
||||
---
|
||||
|
||||
## Phase 진행 순서
|
||||
## 구현 진행 상황
|
||||
|
||||
```
|
||||
Phase 0 [x] 환경 세팅 & 아키텍처
|
||||
Phase 1 [x] 코어 루프 프로토타입
|
||||
Phase 2 [x] 자원 경제 & 덱빌딩
|
||||
Phase 3 [x] 정치 시스템 & 스토리 페이징
|
||||
Phase 4 [x] 멀티 엔딩 & 연대기 ← 그레이박스 테스트 시작 가능
|
||||
Phase 5 [ ] 비주얼 폴리싱 & UX ← 그레이박스 테스트 완료 후에만 착수
|
||||
```
|
||||
진행 체크박스를 이 파일에 복제하지 않는다 — 여러 곳에서 따로 갱신하면 어긋나기 쉽다.
|
||||
`ProjectSS_코어시스템_기획서.md` **§17 "구현 우선순위"** 안의 체크박스가 유일한 진행 상황
|
||||
원본이다. 지금 뭐가 됐고 안 됐는지 보려면 그 절을 열어볼 것.
|
||||
|
||||
`[x]` 완료 · `[~]` 부분 완료 · `[ ]` 미착수
|
||||
|
||||
**Phase 5 착수 조건:** 외부 플레이어 그레이박스 테스트를 마치고 그 피드백을 반영한 뒤에만 시작한다.
|
||||
Phase별 상세 계획과 완료 기준은 `ROADMAP.md`, 각 Phase에서 남은 주의사항과 작업 이력은
|
||||
`docs/DEVLOG.md` 참고.
|
||||
각 항목에서 남은 주의사항과 상세 작업 이력은 `docs/DEVLOG.md` 참고. 왜 그렇게 결정했는지는
|
||||
DEVLOG에서 링크된 결정 노트(아래 "결정 노트" 절) 참고.
|
||||
|
||||
---
|
||||
|
||||
## 작업 지시 방법
|
||||
|
||||
```
|
||||
/goal Phase 5 진행해줘 # 그레이박스 테스트 완료 후에만
|
||||
/goal 구현 우선순위 3차 진행해줘 # ProjectSS_코어시스템_기획서.md §17 기준
|
||||
```
|
||||
|
||||
**작업 완료 후 반드시:**
|
||||
1. 위 **Phase 진행 순서** 블록의 체크박스를 갱신한다.
|
||||
1. `ProjectSS_코어시스템_기획서.md` **§17**의 해당 항목 체크박스를 갱신한다.
|
||||
2. `docs/DEVLOG.md` 맨 위에 무엇을 왜 바꿨는지 기록한다.
|
||||
(미해결 이슈나 디자이너 확인이 필요한 사항이 생겼으면 DEVLOG 상단 "열린 이슈"에 추가)
|
||||
(미해결 이슈나 디자이너 확인이 필요한 사항이 생겼으면 DEVLOG 상단 "열린 이슈"에 추가)
|
||||
3. 중요한 설계·밸런스 결정을 내렸다면 결정 노트를 남긴다 — 아래 "결정 노트" 절 참고.
|
||||
|
||||
---
|
||||
|
||||
## 결정 노트 (Decision Notes)
|
||||
|
||||
중요한 설계·밸런스 결정을 내렸을 때는 `docs/decisions/YYYY-MM-DD-제목.md` 파일로 따로 남긴다.
|
||||
"중요한 결정"이란 나중에 왜 이렇게 했는지 되짚어야 할 만한 것 — 여러 대안 중 하나를 고른 경우,
|
||||
기존 규칙을 뒤집은 경우, 플레이테스트 피드백에 따라 방향을 바꾼 경우 등이다. 사소한 오타 수정이나
|
||||
명백한 버그 픽스에는 필요 없다.
|
||||
|
||||
**양식** (`T-decision.md` 그대로 — 새 결정 노트는 전부 이 형식을 따른다):
|
||||
|
||||
```markdown
|
||||
---
|
||||
created: YYYY-MM-DD
|
||||
---
|
||||
%% 파일명: YYYY-MM-DD-제목. 규칙 문서엔 규칙만, 이유는 여기에 %%
|
||||
|
||||
## 결정
|
||||
-
|
||||
|
||||
## 배경
|
||||
-
|
||||
|
||||
## 검토했으나 기각한 대안
|
||||
- **대안:** 기각 이유
|
||||
|
||||
## 재검토 조건
|
||||
-
|
||||
```
|
||||
|
||||
**DEVLOG 연동:** `docs/DEVLOG.md`에 작업 항목을 적을 때, 그 작업에 해당하는 결정 노트가 있으면
|
||||
옵시디언 위키링크로 연결한다 — `[[YYYY-MM-DD-제목]]`. DEVLOG는 "무엇을 했다"는 요약만 담고,
|
||||
"왜 그렇게 했는가"의 자세한 내용은 링크를 눌러 결정 노트에서 확인하는 구조다.
|
||||
Reference in New Issue
Block a user