이 저장소는 application -> domain -> engine 계층을 유지하는 것을 가장 중요한 규칙으로 둡니다.
PR은 작은 단위로 나누고, 기본적으로 어떤 issue를 해결하는지 분명하게 남겨 주세요.
- 기본 작업 흐름은
issue -> branch -> PR -> merge입니다. - 작업을 시작하기 전에 먼저 관련 GitHub issue가 이미 있는지 확인합니다.
- 관련 issue가 없고 현재 정책상 issue 생성을 생략할 수 없는 작업이면, 새 issue를 한글로 등록한 뒤 작업을 시작합니다.
- 새 task가 기존 Epic 아래에 들어가야 하는 범위라면, issue를 만든 뒤 GitHub native
sub-issue로 연결합니다. - 연결 후에는 Project view의
Parent issue,Sub-issues progress에서 보이는지 확인합니다. - 다만
docs/,uml/,AGENTS.md,CONTRIBUTING.md, PR/issue template, PR 정책 워크플로처럼 문서 또는 기여 정책만 다루는 변경은 별도 issue 없이 진행할 수 있습니다. src/application/에 한정된 UI/앱 조립 변경은 별도 issue 없이 진행할 수 있습니다. 새 application 파일을 앱 타깃에 연결하기 위한CMakeLists.txt변경도 이 예외에 포함할 수 있습니다.- 위 예외에 해당하는 변경이 해당 경로에만 한정된다면 유지보수자는
main에 직접 commit/push할 수 있습니다. - 문서/정책 변경과 application 예외를 벗어난 코드/빌드 변경이 섞이면 예외를 쓰지 않고 일반 PR 흐름으로 진행합니다.
- 가능하면 하나의 PR은 하나의 issue만 해결합니다.
- 서로 다른 계층을 동시에 크게 건드리는 PR은 피합니다.
- 구조, 빌드, 의존성 규칙이 바뀌면 관련 문서를 함께 업데이트합니다.
- 새 work item은 GitHub issue form으로 생성합니다.
- 새 issue를 만들 때는 한국어로 작성합니다.
Epic은 여러 task를 묶는 상위 계획에 사용합니다.Implementation Task는Engine,Domain,Application,Build같은 코드/빌드 작업에 사용합니다.Lightweight Task는Docs,Chore,Analysis같은 작은 작업에 사용합니다.- 제목은 저장소 관례에 맞춰
EPIC- short title또는Task-short title형식을 유지합니다. - GitHub issue 번호(
#12같은 값)는 생성 후 자동으로 붙습니다. 제목에는 숫자를 직접 적지 않습니다. - task가 기존 Epic 범위에 속하면 parent epic을 적고 native
sub-issue관계까지 연결합니다. - parent/sub-issue 관계를 연결한 뒤 Project view의
Parent issue,Sub-issues progress에서 바로 보이는지 확인합니다. - Sprint와 Area는 issue 생성 시 바로 정합니다.
- issue form의
Area와 GitHub Project의Area옵션이 일시적으로 다를 수 있습니다. 현재 Project 보드에Build옵션이 없으면 issue 자체에는Build를 유지하고, 보드에는 가장 가까운 기존 영역으로 배치한 뒤 본문에 의도를 남깁니다. - 구조나 의존성에 영향을 주는 issue는 본문에 계층 영향과 검증 계획을 남깁니다.
PR 제목은 아래 형식을 따릅니다.
[Area] short summary
허용되는 Area 값:
EngineDomainApplicationDocsBuildAnalysisChore
예시:
[Engine] implement generation-safe entity registry
[Docs] clarify build presets and architecture notes
모든 PR은 아래 내용을 포함해야 합니다.
- 변경 요약
- 연결된 issue 또는 issue 예외 사유
- 변경이 속한 영역
- 아키텍처 규칙 점검 결과
- 빌드/테스트 검증 결과 또는 미실행 사유
- 남은 리스크나 후속 작업
- docs/policy-only PR이고 변경 경로가
docs/,uml/,AGENTS.md,CONTRIBUTING.md, PR/issue template,pr-policy.yml에만 한정되면Related Issue에는None (docs/policy-only PR)를 사용합니다. - application-only PR이고 변경 경로가
src/application/및 필요한 앱 타깃 연결용CMakeLists.txt에 한정되면Related Issue에는None (application-only PR)를 사용합니다.
PR 작성 시 아래 항목을 항상 점검합니다.
engine에domain또는application의존성을 추가하지 않았는가domain에 Qt UI 코드를 추가하지 않았는가application이 UI와 도메인 조립 책임을 벗어나지 않았는가- include 경로가
src/루트 기준(application/...,domain/...,engine/...)을 따르는가
가능하면 아래 명령으로 검증합니다.
cmake --preset windows-debug
cmake --build --preset build-debug
ctest --preset test-debugApplication layer를 제외한 빠른 검증이 필요하면 아래 프리셋을 사용합니다.
cmake --preset windows-debug-no-app
cmake --build --preset build-engine-debug
cmake --build --preset build-engine-domain-debug
cmake --build --preset build-no-app-debug
ctest --preset test-no-app-debugwindows-debug/windows-release첫 configure는vcpkg가qtbase를 설치하는 동안 몇 분 이상 걸릴 수 있습니다.- 현재 manifest는
qtbase기본 feature를 끄고widgets만 요청하므로, 불필요한 SQL/PostgreSQL 플러그인까지 끌어오지 않도록 유지합니다.
로컬 import stack 검증이 필요하면 기본 경로를 유지한 채 아래 옵션을 추가합니다.
cmake --preset windows-debug-no-app `
-DSAFECROWD_ENABLE_IMPORT_STACK=ON `
-DSAFECROWD_IMPORT_STACK_ROOT=C:/sdk/import-stack `
-DSAFECROWD_IFCOPENSHELL_ROOT=C:/sdk/IfcOpenShell
cmake --build --preset build-engine-domain-debugSAFECROWD_ENABLE_IMPORT_STACK는 기본값이OFF이며, CI와 Sprint 1 기본 경로는 그대로 유지합니다.SAFECROWD_IMPORT_STACK_ROOT는 공통 prefix 용도이고,SAFECROWD_LIBDXFRW_ROOT,SAFECROWD_IFCOPENSHELL_ROOT,SAFECROWD_CLIPPER2_ROOT,SAFECROWD_BOOST_ROOT,SAFECROWD_RECAST_ROOT로 개별 경로를 덮어쓸 수 있습니다.- 현재 smoke check는
libdxfrw,IfcOpenShellparser 헤더,Clipper2,Boost.Geometry,Recast,Detour의 include/lib 경로를 configure 단계에서 확인합니다.
실행하지 못했다면 PR 본문에 이유를 남깁니다.
- 코드/빌드 변경은
main에 직접 push하지 않고 PR로 반영합니다. 단, issue 예외에 해당하는 application-only 변경은 유지보수자가 PR 또는 직접 push로 반영할 수 있습니다. docs/,uml/,AGENTS.md,CONTRIBUTING.md, PR/issue template, PR 정책 워크플로처럼 문서/정책만 다루는 변경은 유지보수자가main에 직접 push할 수 있습니다.- 머지는 squash merge를 기본으로 사용합니다.
- PR 체크가 실패한 상태에서는 머지하지 않습니다.