Sprint 03 — 방치(Idle) 시스템 사전 조사 리서치

작성: 2026-04-21 (code-lead) · 근거: prestige_system_spec.md v1.0 APPROVED / sprint-01-w2-importer-design.md v1.0 APPROVED / sprint-02-w2-prestige-tech-sketch.md v1.0 APPROVED / 메모리 project_game_direction_idle_rpg.md, feedback_codelead_review_compile_verify.md 문서 상태: v1.0 APPROVED (PD 승인 2026-04-21) — Sprint 03 착수 시 본 문서 §1~§9 이행 필수 범위: Sprint 03 (2026-06-01~ 예정) 착수 전 기술 옵션 비교 + Open Question + TodoWrite 스케치

PD 승인 결정표 (2026-04-21)

부수 Q6 (부활 초기화 타이밍) → Sprint 04 부활 시스템 설계 때 일괄 결정.

TodoWrite 10건 예상 공수 13.25h (1인 파트타임 11~15h 예산 + 리뷰 후 컴파일 회귀 버퍼 1.5~2h). §9 체크리스트 11개 PR 머지 전 자체 완료 필수.

0. TL;DR (PD 1분)

• 핵심 질문: 오프라인 10시간 후 복귀한 유저에게 "드롭 + 마일스톤 + PP" 를 어떻게 계산해 돌려줄 것인가.
• 권장 전략: 옵션 C (하이브리드) — 구간 집계(평균 처치율 × 경과시간) + 마지막 1시간만 이벤트 리플레이. 드롭 표현력과 성능의 현실적 타협점.
• 틱 주기: 온라인 방치 = 1초 고정 IdleTicker.Update() 누산. 오프라인 = 앱 포커스 복귀 시 1회 Catch-up 계산.
• DateTime 신뢰: Sprint 03 로컬 전용 구간에선 로컬 DateTime.UtcNow 전제 + 역전 가드만. 본격 서버 검증은 Phase 5 Firebase 도입 후.
• 아키텍처: GodBlade.Runtime.Idle 서브 네임스페이스. IdleTicker (MonoBehaviour, 앱 수명) + IdleRewardCalculator (순수 C# static) + IdleSaveService (JSON).
• Sprint 02 W2 OnIdleReward 훅의 유일한 발화자 = IdleTicker.FlushCatchUp().
• Open Question 5개 (§6). Sprint 03 TodoWrite 10건 W1/W2 각 5 (§7). 리스크 3건 (§8). 체크 11개 (§9).

1. 방치 시스템 요구사항 정의

1.1 온라인 방치 vs 오프라인 방치

운영 원칙: "온라인 틱 vs 오프라인 Catch-up" 을 동일한 계산기(IdleRewardCalculator)로 처리. 온라인은 elapsedSec=1 을 매초 호출, 오프라인은 elapsedSec=Δ 를 1회 호출. 수식 두 벌 운영 금지.

1.2 틱 주기 트레이드오프

결정: 매 1초 IdleTicker MonoBehaviour 에서 Update() + 내부 accumulator deltaTimeFloat 누산 → 1.0f 넘을 때만 1틱 발화. InvokeRepeating(1f) 는 Time.timeScale 변화 시 중단 이슈 + 게임 일시정지 통합 어려움으로 비권장.

1.3 "몇 시간 만에 돌아왔을 때" 계산 방식

• 입력: elapsedSec, maxFloor, prestigeBonus(IdleRateMul), idleCapHours (프레스티지 아이템 #25 IdleCapHoursFlat — FlatStat 별도 경로 via PrestigeCalculator.GetIdleCapHours(state)) <!-- D8 검증 2026-04-21 반영 -->
• 출력: IdleRewardBundle { kills: List<KillEvent>, gold: long, exp: long, ppGained: long, milestonesReached: List<int> }
• 세부 전략은 §2 3옵션 비교에서 결정.

1.4 Unity 6 시간 API 검토

결정:

• 온라인 틱 누산 = Time.unscaledDeltaTime (일시정지 영향 회피)
• 경과 시간 측정 = DateTime.UtcNow - lastTickUtc (초 단위 차)
• 백그라운드 진입 시점 = OnApplicationPause(true) 에서 마지막 틱 시각 저장
• 포커스 복귀 시점 = OnApplicationPause(false) 에서 Catch-up 호출

2. 오프라인 보상 계산 전략 — 3개 옵션 비교

2.1 공통 입력

inputs:
  elapsedSec       (long)              // DateTime 차 (cap 적용 후)
  maxFloor         (int)               // 현재 최고 도달층
  dropTable        (DropRateTableSO)   // Sprint 01 W2 자산
  milestoneCatalog (MilestoneRewardCatalogSO)
  prestigeBonus    (PrestigeCalculator.BuildSummary — Sprint 02 W2 자산)
  rngSeed          (uint)              // 결정론 재현을 위한 시드

공통 제약:

• idleCapHours (프레스티지 #24, 기본 8h Lv당 +1h, 소프트캡 Lv5 → 13h 상한 영역) 초과분은 드롭.
• 드롭 버킷 Lookup은 Sprint 01 W2 Dictionary<(floorBucket, mobKind, grade), float> 재사용 — 신규 Lookup 구조 없음.

2.2 옵션 A — 이벤트 리플레이 (초당 시뮬)

for sec in 0..elapsedSec:
  if sec % killsPerSec == 0:
    KillEvent k = SimulateKill(currentFloor, rng)
    dropTable.RollDrops(k, rng)   // 등급 drop 굴림
    if ShouldAutoAdvanceFloor(...):
      floor++
      CheckMilestone(floor)
  accumulator.Add(k)

• 장점: 온라인 틱 코드 재활용 가능 (동일 로직). 드롭 분포 완전 정확. "방치 로그" UI에 시간대별 이벤트 표현 가능.
• 단점: 10h × 3600sec × 초당 1킬 = 36,000 회 RollDrops — 수백 ms ~ 1s+ CPU 스파이크. 24h 캡 시 86,400회 — 체감 프리즈 위험.
• 성능 측정 필요: Unity 6 모바일 Mono에서 Dictionary Lookup + System.Random.NextDouble 기준, 36,000회 ≈ 100~300ms 예상 (중급 기기). 허용 범위지만 여유 없음.

2.3 옵션 B — 집계 공식 (평균 처치율 × 경과시간)

killsTotal   = killsPerSec × elapsedSec
goldTotal    = killsTotal × avgGoldPerKill(currentFloor) × prestigeBonus.GoldMul
expTotal     = killsTotal × avgExpPerKill(currentFloor) × prestigeBonus.ExpMul
drops        = ExpectedDrops(killsTotal, dropTable, currentFloor, mobKind)  // 확률 × 횟수
ppGained     = floor((elapsedSec / 3600) × maxFloor × 0.05 × prestigeBonus.IdleRateMul)

• 장점: O(1) 계산. 10시간·24시간·48시간 모두 동일 1ms.
• 단점:
• 드롭 표현력 상실 — "레어 1개, 에픽 0개" 같은 정수 결과가 평균 개수(예: 0.37개)로 표현됨 → 반올림 or 확률 추첨 한번으로 해결해야.
• 마일스톤 "방치 중 돌파" 시퀀스를 잡기 어려움 (언제 100→101→102 도달?) — 별도 FloorProgressEstimator 로 수식화 필요.
• "방치 동안 층 자동 진행 허용" 여부 (§6 Q3) 에 따라 복잡도 극심 차이.

2.4 옵션 C — 하이브리드 (구간 샘플링 + 마지막 구간 리플레이) 권장

cappedSec = min(elapsedSec, idleCapHours × 3600)

// Phase 1: 첫 구간 = 공식으로 집계 (cappedSec - 3600 초)
if cappedSec > 3600:
  bulkSec   = cappedSec - 3600
  bulkBundle = AggregateFormula(bulkSec, dropTable, milestoneCatalog, prestigeBonus)

// Phase 2: 마지막 1시간 = 이벤트 리플레이 (최대 3600회)
tailSec      = min(cappedSec, 3600)
tailBundle   = ReplayEvents(tailSec, dropTable, ..., rng)

// 합산
finalBundle = bulkBundle + tailBundle

• 장점:
• 리플레이 횟수 상한 3,600회 고정 — 10h든 24h든 성능 동일.
• 마지막 구간은 이벤트 로그로 "방치 보고서" UI 표현 가능 ("최근 1시간 동안 에픽 2개 획득" 등).
• Bulk 구간은 집계 수식 → 긴 방치에도 즉시 응답.
• 단점:
• 구현 복잡도 옵션 A·B 합산 → 테스트 커버리지 2배.
• 마일스톤 돌파 타이밍은 여전히 추정 (Phase 1 집계에서 "이 1시간 구간 동안 105→108층" 식 추정).
• 적합성: 1인 파트타임 + 모바일 타겟 + 방치형 핵심 체험 ("돌아왔는데 짜잔!") 모두 만족. Sprint 03 권장.

2.5 각 옵션의 드롭·마일스톤·PP 처리 차이

2.6 권장 — 옵션 C (하이브리드)

근거:

1. 1인 파트타임 관점에서 옵션 B는 단순 구현이지만 "방치 보고서" UI에 콘텐츠가 없어 방치형 게임 체감이 죽는다.
2. 옵션 A는 24h 캡 시 86,400회 루프 — 저사양 기기 리스크 + 복귀 프리즈.
3. 옵션 C는 리플레이 횟수 상한 고정(3,600) + 드롭 표현력 유지. 구현 복잡도는 Sprint 03 11~15h 예산에서 수용 가능.
4. Sprint 04+ 저사양 디바이스 옵션으로 "tail=0" (완전 옵션 B) 전환이 쉬움 (파라미터 하나로 토글).

3. 타임스탬프 관리 & 치팅 방지

3.1 로컬 DateTime 신뢰 가능한가

• 모바일 유저는 설정 > 일반 > 날짜 및 시간 을 임의로 변경 가능 → 8시간 → 24시간 조작 시도 가능.
• Sprint 03 범위에선 Firebase Timestamp 동기 불가 (Phase 5+). 따라서 로컬 시계 전적 신뢰 + 보수적 이상 탐지.

3.2 Sprint 03 로컬 방어 체크리스트

3.3 치팅 허용 입장

• 현재 방침: 로컬 치팅은 부분 허용 (싱글·방치형, 글로벌 랭킹 없음). 대응은 Steam Anti-cheat + Firebase Phase 5 서버 시각 검증.
• Sprint 03 구현은 역전 가드 1개 + 30일 Warn 1개 만. 과도한 감지 로직 금지 (UX 해침).

3.4 저장할 타임스탬프 필드

IdleSaveDto {
  int  schemaVersion      = 1
  long lastTickUtcMs      // DateTime.UtcNow.Ticks / 10000 (ms 단위)
  long lastFocusExitUtcMs // OnApplicationPause(true) 시 갱신
  int  lastKnownMaxFloor  // 오프라인 동안 층 변화 없음 가정
  uint rngSeed            // 결정론 재현
  long savedAtUtcMs       // 디버그
}

3.5 장치 재부팅 / 시간대 변경

• DateTime.UtcNow 는 장치 재부팅 생존 (OS가 RTC 유지).
• 시간대 변경은 UTC 기준이므로 무영향.
• 단, 유저가 "기기 초기화 + 날짜 변경" 하면 감지 불가 → Phase 5+ 서버 시각으로 위임.

4. IdleTicker 런타임 아키텍처 스케치

4.1 클래스 배치

GodBlade.Runtime / Assets/_Project/Scripts/Runtime/Idle/
  IdleTicker.cs                 // MonoBehaviour 싱글턴, 앱 수명 동행
  IdleRewardCalculator.cs       // 순수 C# static, §2 옵션 C 구현
  IdleRewardBundle.cs           // 누산 결과 struct (kills/gold/exp/pp/milestones)
  IdleSaveService.cs            // JSON 저장·로드
  IdleSaveSchema.cs             // DTO (§3.4)
  IdleConstants.cs              // 상수 (초당 킬수 기준값, 캡 등)

네임스페이스: GodBlade.Runtime.Idle (Sprint 02 W2 GodBlade.Runtime.Prestige 와 평행).

4.2 클래스 책임

// — IdleTicker.cs — (MonoBehaviour, DontDestroyOnLoad)
namespace GodBlade.Runtime.Idle {
  public sealed class IdleTicker : MonoBehaviour {
    // 주입 의존
    PlayerPrestigeState _prestige;            // Sprint 02 W2
    DropRateTableSO     _drop;                // Sprint 01 W2
    MilestoneRewardCatalogSO _milestone;      // Sprint 01 W2
    int _currentMaxFloor;

    // 내부 상태
    float _accumUnscaled;                     // Time.unscaledDeltaTime 누산
    DateTime _lastTickUtc;

    // Unity 콜백
    void Awake()  { /* singleton + DontDestroyOnLoad */ }
    void Start()  { BootstrapFromSave(); }
    void Update() { TickOneSecondIfElapsed(); }
    void OnApplicationPause(bool paused);     // true → save + stamp, false → CatchUp
    void OnApplicationQuit() { FlushSave(); }

    // 핵심 메서드
    void TickOneSecondIfElapsed();            // accum ≥ 1f 시 OnlineTick 호출
    void OnlineTick(float deltaSec);          // IdleRewardCalculator.Accumulate(1초)
    public IdleRewardBundle FlushCatchUp();   // 포커스 복귀 시 Δ만큼 Hybrid 계산
    public event Action<IdleRewardBundle> OnIdleReward;  // Sprint 02 W2 예약 훅의 실제 발화자
  }
}

// — IdleRewardCalculator.cs — (순수 static)
namespace GodBlade.Runtime.Idle {
  public static class IdleRewardCalculator {
    public static IdleRewardBundle Calculate(
      long elapsedSec,
      int maxFloor,
      DropRateTableSO drop,
      MilestoneRewardCatalogSO milestone,
      in PrestigeCalculator.BuildSummary prestigeBonus,
      int idleCapHours,
      uint rngSeed);
    // 내부적으로 §2.4 옵션 C 하이브리드 수행
  }

  public readonly struct IdleRewardBundle {
    public readonly long ElapsedSec;
    public readonly long GoldGained;
    public readonly long ExpGained;
    public readonly long PpGained;
    public readonly int  KillsTotal;
    public readonly IReadOnlyList<(int floor, Grade grade, int count)> DropsCompact;
    public readonly IReadOnlyList<int> MilestonesReached;  // 배치 발화용
  }
}

4.3 갱신 타이밍 비교

4.4 초기화 시점

1. 게임 부팅 (Start()): IdleSaveService.Load() → _lastTickUtc 복원. 즉시 FlushCatchUp() 1회 호출 → OnIdleReward 1회 발화.
2. 스테이지 진입: _currentMaxFloor 갱신. 틱은 계속 진행 (스테이지 전환은 IdleTicker 생명에 영향 없음).
3. 포커스 복귀 (OnApplicationPause(false)): 현 시각 ↔ _lastTickUtc Δ 계산 → FlushCatchUp().
4. 씬 전환: DontDestroyOnLoad 로 유지. 초기화 반복 금지.

4.5 이벤트 발화 순서 (§6 Sprint 02 W2 계약 준수)

FlushCatchUp() 내부 순서:

1. elapsed 계산 + cap 적용 + 역전 가드
2. IdleRewardCalculator.Calculate(...)  → IdleRewardBundle
3. 순서 (배치 발화):
   a. bundle.MilestonesReached.ForEach(floor => MilestoneGranter.Award(floor))   // Sprint 01 W2 채널 B
      └─ floor==100 시 PlayerPrestigeState.Unlock() 내부 연쇄 (Sprint 02 W2 계약)
      └─ floor==200 시 PrestigePpAccumulator.GrantMilestone(200) 연쇄
   b. bundle.KillsTotal / DropsCompact → 인벤토리 수령 (Sprint 04+ 인벤토리 시스템 확정 후. Sprint 03은 로그만)
   c. PrestigePpAccumulator.GrantIdleDrip(elapsed, maxFloor)
   d. OnIdleReward?.Invoke(bundle)  // 최종 집계 이벤트 — UI가 "방치 보고서" 모달로 소비
4. IdleSaveService.Save()  // lastTickUtc 갱신

불변식: OnIdleReward 발화 시점엔 Milestones·Drops·PP 모두 이미 적용된 상태. UI는 후처리 표시만.

4.6 OnIdleReward 와 PrestigePpAccumulator.GrantIdleDrip 관계

• PP 발화자 분리:
• GrantIdleDrip(elapsed, maxFloor) → PlayerPrestigeState.AddPermanentPp(amount) 호출 (실제 PP 적립)
• OnIdleReward(bundle) → UI 알림용 집계 이벤트
• 순서: 적립 먼저 (c 단계), UI 알림 나중 (d 단계). UI 가 "이번 방치로 +N PP" 표시할 때 이미 State 반영 완료.
• 왜 분리: Sprint 02 W2 PrestigePpAccumulator 가 PP 수식 소유권 (§3.3 계산 공식). IdleTicker 는 그 호출자일 뿐. 이중 관리 금지.

5. Sprint 01/02 자산과의 정합성 10축 교차표

결론: 구조적 충돌 0건. 단 축 4 (IdleRateMul 필드 존재), 축 8 (GetIdleCapHours 신규 헬퍼) 두 건은 Sprint 02 W2 구현 완료 시점에 재확인.

6. Sprint 03 착수 전 Open Questions (PD / game-designer)

부수 질문 (PD 판단 선택, 답 없어도 Sprint 03 착수 가능):

• Q6 (선택): 부활 횟수(프레스티지 Defense 탭 #19) 초기화 타이밍 — 스테이지 재입장 시? 세션 시작 시? 24h 1회? → Sprint 04 부활 시스템 설계 때 일괄 결정, Sprint 03 범위 아님.

7. Sprint 03 예상 TodoWrite (W1/W2 × 5건 = 10건)

형식: [번호] <내용> (담당, 예상 h, 의존) — 1인 파트타임 11~15h 예산 기준 · 방치 시스템 Smoke Test 통과까지 CP 태그 = §9 체크리스트

W1 — 기반 인프라 + 온라인 틱

• [#01] GodBlade.Runtime.Idle 네임스페이스 + IdleConstants.cs + IdleRewardBundle.cs struct 작성 (code-lead, 0.75h, 의존: 없음). CP-I2 네임스페이스 충돌 확인.
• [#02] IdleSaveSchema.cs DTO + IdleSaveService.cs Save/Load/Migrate 구현 (code-lead, 1.5h, 의존: #01). 경로 account/<accountId>/idle.v1.json · schemaVersion=1. CP-I3 저장 회로.
• [#03] IdleRewardCalculator.cs 옵션 C 하이브리드 Phase 1(Bulk 집계 공식) 구현 (code-lead, 2h, 의존: #01, Sprint 02 W2 PrestigeCalculator.BuildSummary). CP-I4 공식 일치.
• [#04] IdleRewardCalculator.cs Phase 2(Tail 3,600초 리플레이) 구현 + RNG 시드 결정론 (code-lead, 1.5h, 의존: #03). CP-I5 결정론 테스트 재현.
• [#05] IdleTicker.cs MonoBehaviour + OnApplicationPause 훅 + singleton + DontDestroyOnLoad (code-lead, 1.5h, 의존: #02, #04). CP-I1 Unity.ResourceManager 참조.

W2 — 통합 + 테스트 + Smoke

• [#06] PrestigePpAccumulator.GrantIdleDrip 실배선 (Sprint 02 W2 시그니처만 존재) + PlayerPrestigeState.AddPermanentPp 호출 (code-lead, 0.75h, 의존: #05, Sprint 02 W2). CP-I6 이중 적립 방지.
• [#07] IdleTicker.FlushCatchUp 내부 이벤트 발화 순서 구현 (Milestones 배치 → Drops 로그 → PP 적립 → OnIdleReward 알림) (code-lead, 1.5h, 의존: #06). CP-I7 순서 검증.
• [#08] IdleTickerTests.cs + IdleRewardCalculatorTests.cs Edit-mode 테스트 7개 (역전 가드 / 캡 적용 / 옵션 C 결정론 / 마일스톤 배치 / Save 라운드트립 / PP 누적 / 30일 Warn) (code-lead, 2h, 의존: #07). GodBlade.Tests.Editor.asmdef references 확인.
• [#09] Smoke Test — 시뮬 모드로 10h elapsed 입력 → PP ≈ 50 + Debug.Log 드롭 내역 1건 이상 확인 (code-lead, 0.75h, 의존: #08). 초월모드 Smoke Test 후속 포맷 재사용.
• [#10] §9 컴파일러 시뮬레이션 11개 체크 + Unity Console 새 에러 0 + PR 머지 (code-lead, 1h, 의존: #01~#09). Sprint 00 회귀 2건 재발 금지.

합계 예상 공수: 13.25h (범위 11~15h 내). 1.5~2h 여유 = code-lead 리뷰 후 Unity 첫 컴파일 회귀 대응 버퍼 (메모리 feedback_codelead_review_compile_verify.md 원칙).

정비 (PM)

• D+7 중간 점검 + D+14 회고 + Sprint 04 킥오프 — Sprint 01/02 패턴 그대로, 본 문서 범위 외.

8. 리스크 & 블로킹 예상 3건

8.1 모바일 OS 백그라운드 제한 (특히 iOS 30초 Suspend)

• 증상: iOS 는 앱이 백그라운드 진입 후 약 30초 내 Suspend. 이후 Update() 정지. OnApplicationPause(true) 는 Suspend 직전 호출 보장이 약함 (Unity 버전·OS 조합 변수).
• 리스크: 유저가 백그라운드로 돌린 후 30초 뒤 앱이 Suspend → 10분 뒤 다시 열면 OnApplicationPause(false) 가 먼저 호출됨. 이때 _lastTickUtc 가 Suspend 직전이 아니라 앱 진입 시점이면 오프라인 계산 누락.
• 완화:
• OnApplicationPause(true) 호출 시 즉시 IdleSaveService.Save() + lastTickUtc = DateTime.UtcNow flush.
• OnApplicationPause(false) 는 재계산만 수행 (Save는 재진입 후 1틱 지나야 다시).
• 추가 안전망: Update() 내부에서 1분에 1회 Save flush (1분 미만 차이면 iOS Suspend에도 큰 손실 없음).
• Sprint 03 범위 내 해소 가능. 전담 테스트: 실제 iOS 실기 테스트는 Phase 3+ 빌드 파이프라인 가능 후 재확인 (CP-I8 체크리스트 이월).

8.2 DateTime.UtcNow 치팅 — 로컬 검증 한계

• 증상: 유저가 시스템 시각을 +24h 조작하면 idleCapHours 기본 8h 캡을 돌파하지 못해도 "8h 치 보상 매번 재획득" 가능 (앱 재시작마다).
• 리스크: 싱글·방치·랭킹 없음 정책상 허용 가능하지만, Steam 도입 시 업적·과금 회귀 우려.
• 완화:
• Sprint 03: 로컬 DateTime.UtcNow 신뢰 + 역전 가드만.
• Sprint 05+ Firebase: ServerValue.TIMESTAMP 로 최종 검증. IdleSaveService.Load 가 서버 시각 주입받도록 시그니처 확장 준비 (Load(string accountId, DateTime? serverUtcNow = null)).
• 현 Sprint 범위 = 로컬 방어만. PD 승인 필요 (Q에는 올리지 않음 — 기존 정책 일관).

8.3 옵션 C 리플레이 RNG 결정론 실패 시 테스트 불가능

• 증상: System.Random 은 Next() 호출 순서가 결정론적이지만, Dictionary 순회 순서 의존 시 플랫폼·런타임 간 편차 가능.
• 리스크: IdleRewardCalculatorTests 가 Unity 에디터에서 Green이어도 모바일 빌드에서 Red.
• 완화:
• 테스트는 rngSeed 고정 + 순회 순서 결정론 보장을 위해 Dictionary 순회 대신 List<DropRateRow> 인덱스 순 탐색 강제. (Sprint 01 W2 _lookup 은 O(1) 조회 용도만, 리플레이 시 iteration 은 rows 사용).
• 테스트 케이스는 "RNG 1234 seed + 10층 3600초 → 드롭 정확히 이 배열" 식 hard-coded assert.
• §9 CP-I5 에 강제 체크 포함.

9. 컴파일러 시뮬레이션 체크리스트

9.1 Sprint 00 회귀 2건 재발 경고 (유지)

• [CS0246] Unity.ResourceManager 누락 — IdleTicker 가 Addressables 로 DropRateTableSO / MilestoneRewardCatalogSO / PrestigeItemCatalogSO 참조 시 발생 가능.
• [CS1061] InternalsVisibleTo 중복 — GodBlade.Runtime 어셈블리 내 다른 파일에 이미 존재하면 신규 IdleTicker.cs 에 재선언 금지.

9.2 방치 특화 체크포인트 (신규)

9.3 PR 머지 전 절차 (Sprint 01/02 패턴)

1. Unity 6 에디터 파일 저장
2. Console 새 에러 0 확인 (Warning 허용, Error 금지)
3. Edit-mode 테스트 7개 Green
4. Addressables Build → Build Player Content 성공
5. Smoke Test (#09) 통과 — Debug.Log("[Idle] +50 PP, elapsed=36000s") 확인

10. 문서 메타

• 본 문서: 약 10쪽 (마크다운 렌더 기준)
• 섹션 9개 + 메타 = 10개
• §9 체크포인트: 11개 (Sprint 00 회귀 2 + 방치 특화 11 = 13 중 Sprint 00 회귀 부분은 유지 경고 형태로 통합, 신규 체크 11건 카운트)
• §6 Open Question: 5개 (+ 부수 1건)
• §7 TodoWrite: 10건 (W1 5 + W2 5)
• §8 리스크: 3건
• 실구현 코드: 0 줄 (설계 시그니처·의사코드만)

(끝 — DRAFT v0.1, PD 결정 대기)