discipline-web-houseruleslisted

# dddjango-web 하우스룰 dddjango-web이 만드는 `web/` 코드에 한정된 집안 규칙이다. **표준 파일트리·명명·격리의 사실은 `references/final.md`가 단일 출처**이고, 이 본문은 그 사실을 쓰는 결정 절차다. 판별·승격 절차는 architecture-web, 구현 표기는 implementation-ui, 보편 클린코드는 discipline-cleancode 소유. ## §1 파일트리 결정 순서 새 코드를 배치할 때 위에서부터, 결론이 나면 멈춘다. 1. **표준은 새로 만드는 코드부터 적용한다 — 기존 코드의 수정·개명·이동을 요구하지 않는다.** 적용 경계는 둘로 갈린다: 표기(파일명·접두·접미사·클래스)는 **모든 새 파일**에, 폴더 구조는 **신규 단위부터** — §2 경계 규칙. 2. **신규 단위(영역·화면 개념·client BC 폴더)는 표준 트리를 적용한다** — `references/final.md` §1을 반드시 읽는다. 생략·축소 불가 골격(final.md §3 정신 — YAGNI로 접을 수 없다): - 화면 개념 = **종류 4폴더(view·view_model·state·section) 항상 생성** — `form/`은 조건 생성(입력 form이 있는 화면만 — final.md §3). 빈 폴더 마커는 Python 패키지 `__init__.py`·HTML 전용 `.gitkeep`(final.md §3). 그 외 선택 폴더 없음. - 신규 static 골격은 `css/`·`js/`·`htmx/`·`images/` 네 폴더다. `fonts/`·`files/`는 검증된 파일이 필요할 때만 생성한다. 기능 JS/HTMX 선언은 각각 기능당 한 파일이며 평면 snake_case다(final.md §3~§5). - `widget/`은 영역 수준 — 화면 개념 폴더 안에 만들지 않는다. - `design_system/`은 foundation·component **2칸 시작** — theme·util 칸은 만들지 않는다(final.md §3). - **영구 test/ 없음** — 생성 앱의 테스트 폴더·파일을 만들지 않는다. 임시 Django 렌더·브라우저 검증을 수행하고 증적은 보존한다(final.md §3). 3. **배치 판별**: **0순위 — API 호출 코드는 판별 없이 언제나 `client/`다(final.md §5②)**. UI 조각은 판별 순서를 architecture-web §2가 단독 소유하고(상태 조립을 먼저 묻는다) 위치 답은 final.md §6이다 — 상태 조립이 필요하면 view 삼총사, 화면 전속이면 그 화면 `section/`, 영역 재사용·BC 어휘 보유면 `widget/`, BC 어휘가 없으면 `design_system/component/`. 이름은 명명 총괄표(final.md §4)에서 찾는다 — 위치·접두·접미사가 전부 정해져 있다. 4. **의미 판별 6종**(view/section, 화면 전속, BC 어휘, 영역