팀 개발 분담과 구현 경계 문서화

[SilverSupplier]

요약

• 3인 개발을 입력/인식, 게임 런타임, 튜토리얼/콘텐츠 레이어로 나누는 팀 개발 계획 문서를 추가했습니다.
• README 문서 읽기 순서와 로드맵에 새 문서 링크를 연결했습니다.
• 개인 닉네임보다 역할과 산출물 중심으로 적어, 각 담당자가 병렬로 구현할 위치를 바로 파악할 수 있게 했습니다.

왜 필요한가

• Unity 플레이어블은 최종 시연 결과물이고, Web recognizer는 입력/품질/검증 기준선입니다.
• 두 흐름을 사람별로 섞어 맡기면 충돌이 커지므로, stroke session -> recognition result -> game runtime -> feedback 경계를 먼저 고정해야 합니다.
• 특히 입력/인식 담당자가 게임 목표나 HUD를 직접 만지지 않고도 기능을 연결할 수 있어야 합니다.

변경한 경계

• Input Capture Layer
• Stroke Session Layer
• Recognition / Personalization Layer
• Game Runtime Layer
• Feedback / Tutorial / Logs Layer

각 레이어마다 담당 범위, 하지 말아야 할 것, 산출물 예시를 문서화했습니다.

PR #94와의 관계 / 머지 순서

• PR #94는 플레이어 입력/인식/게임 경계를 기술 계약으로 정리한 문서 PR입니다.
• 이번 PR은 그 방향을 실제 3인 개발 분담과 첫 스프린트 순서로 풀어쓴 문서 PR입니다.
• README 문서 읽기 순서를 둘 다 수정하므로, #94를 먼저 머지한 뒤 이 PR을 rebase해서 ARCHITECTURE_LAYERS, INPUT_LAYER_HANDOFF, RECOGNITION_CONTRACT, TEAM_DEVELOPMENT_PLAN 순서가 모두 보이게 정리하는 흐름을 권장합니다.

검증

• git diff --check
• node scripts/validate-doc-state.mjs

코드 변경은 없어서 Unity/Web 테스트는 실행하지 않았습니다.