craftlisted

# craft nereus:common 규칙을 따른다. 담당 에이전트: gameplay-engineer. **엔진과 무관하다** — 엔진별 금지 문자열은 `layers.json` 에 데이터로 있다. 워크플로·TDD 절차·게이트는 **nereus 코어가 소유한다**. 여기는 게임플레이 코드의 **판단**만 담는다. ## 0. 이 스킬이 생긴 이유 스택 스킬들이 똑같이 이렇게 적어놓았다 — **"로직을 엔진 객체에서 떼어내는 설계가 곧 1단 커버리지다."** 그리고 **어떻게 떼는지는 어디에도 없었다.** "spec 에서 태스크로 쪼갠다"로 넘겼는데 넘긴 곳에 아무것도 없었다. 그 자리를 채운다. ## 1. 코어 루프를 먼저 한 문장으로 쓴다 코어 루프는 플레이어가 **한 번에 겪는 가장 작은 완결 단위**다. 한 문장으로 못 쓰면 아직 게임이 아니라 기능 목록이다. ``` <무엇을 본다> → <무엇을 결정한다> → <무엇이 돌아온다> → <무엇이 남는다> ``` 네 칸이 다 차야 한다. | 빈 칸 | 증상 | |---|---| | 결정이 없다 | 플레이가 아니라 재생이다. 스킵해도 같은 결과면 결정이 아니다 | | 돌아오는 게 없다 | 잘했는지 못했는지 모른다. 피드백은 연출이 아니라 정보다 | | 남는 게 없다 | 다음 판을 할 이유가 없다. 남는 것이 진행도든 숙련이든 있어야 한다 | **루프를 확정하기 전에 경제·레벨·UI 를 설계하지 않는다.** 루프가 바뀌면 전부 버린다. 루프는 `balance` · `level` 도메인의 입력이지 산출물이 아니다. ## 2. 계층 경계 — 엔진에서 로직을 떼는 방법 ### 왜 엔진 객체 안에 규칙이 들어가면 **규칙을 검증하려고 엔진을 켜야 한다.** 엔진을 켜야 하는 검사는 느리고, 느린 검사는 CI 에서 빠지고, CI 에서 빠진 검사는 안 돈다. 그 결과 규칙 변경이 매번 불안정한 통합 테스트를 통과해야만 하게 된다. **밀리초 안에 도는 규칙은 실제로 테스트된다.** 그게 전부다. ### 어떻게 세 층으로 나누고, **위에서 아래로만** 참조한다. | 층 | 여기 있는 것 | 여기 없는 것 | |---|---|---| | **순수** | 수치·판정·상태 전이·시드 결정론 | 엔진 타입, I/O, 프레임워크, 플러그인, 전역 | | **바인딩** | 순수 층을 엔진 수명주기에 붙이는 코드 | 규칙 판단 | | **표현** | 화면·입력·연출 | 규칙 판단, 수치 | 바인딩 층은 **얇아야 한다.** 두꺼워지면 규칙이 새어 들어온 것이다. "이 값이 왜 이렇게 나왔지"를 바인딩 층에서 물어야 한다면 이미 경계가 무너졌다. ### 어디가 순수 층인가 — 판정 질문 > **엔진을 켜지 않고 이 코드를 호출해 결과를 단언할 수 있는가?** 못 하면 순수 층이 아니다. 옮기거나, 못 옮기는 부분을 바인딩 층으로 밀어낸다. ### 설정과 규칙을 잇는 코드는 규칙 층에 두지 않는다 원격 설정·플레이버 설정이 규칙 층에 스며들면 **플래그 하나가 규칙을 바꾸는 경로가