최우선 규칙 (모든 규칙보다 위)

0순위: 모든 가이드·문서·결정·진행 기록·화면 점검은 이 wiki 보관함에 저장·관리한다. 세션 시작 때 홈과 이 문서부터 읽고, 일할 때마다 진행 로그·결정 기록을 갱신한다.
질문은 설치 가능한 APK 를 먼저 건넨 뒤에만. 사용자가 폰에 설치해 써 보며 답할 수 있게. 캡처도 함께 보여 주고 "이렇게 하면 / 저렇게 하면" 화면 비교로만 묻는다.
암호 비트 수·키 구조·함수 설계 같은 내부 기술 질문 금지. 내가 정하고 결과에 적는다.
책임 회피성 질문 금지 ("물었으니 사용자 책임").
방법론: 화면 먼저 → 화면 보고 사용자가 답 → 그 답에 따라 내부 아키텍처를 바꾼다.
묻지 말고 끝까지 진행. 목표는 APK. 멈춰서 대기하지 않는다.
"목업" 같이 일반사용자들이 사용하지 않는 단어는 일체사용하지 않는다 특희 일본 에서 넘어온 알지못하는 이상한 단어 그리고 중국에서 만드 이상한 단은 일체 사용하지 않는다

일하는 규칙

모든 답변 한글. 고친 파일은 일부 발췌가 아니라 처음부터 끝까지 완본으로 보여 준다. "목업" 대신 "화면 설계".
사용자는 솔루션 개발자: 구조가 기능보다 먼저, 화면과 내부 분리.
모듈화 필수. 모듈은 다른 모듈을 고치지 않고 빼고 끼울 수 있어야 한다. tool/check_modules.py 가 의존 방향 검사(새 모듈은 ALLOW 표에 등록).
소스 파일 300~400줄, 최대 700줄.
모듈별 시험(tool/test_module.sh <모듈>). 시험이 끝난 모듈은 다시 만들지 않고 그 위에 쌓는다.
한 번에 한 플랫폼(지금은 안드로이드). 다른 플랫폼은 사용자가 지정할 때 platform_<이름> 모듈만 새로 붙인다.
단계마다 되묻지 말고 정해서 진행, 결정은 결과와 02 결정 기록에 적는다. 멈춰서 대기하지 않는다. (되돌릴 수 없는 파괴적 작업만 먼저 묻는다.)
고치면 해당 모듈 시험 → 마지막에 전체 시험과 check_modules.py.
새 기능은 (1) 순수 모듈 또는 서비스 + 시험 → (2) 화면. 화면을 바꾸면 캡처해서 06 화면 점검에 붙인다.
끝낼 때 한글로: 무엇이 바뀌었나, 무엇을 돌려 확인했나, 확인 못 한 것은 무엇인가. 그리고 진행 로그/2026-10-26 갱신.
저장소: 평소 Gitea 에 커밋·푸시, GitLab 은 하루 한 번 메이저 업그레이드 때만(원격 미등록).