v0.0.1: add workflow for collaboration agreement

.github/ISSUE_TEMPLATE/Chore.yml

@@ -0,0 +1,18 @@
+name: Chore - 잡일 처리
+description: 환경 설정, 파일 정리 등 기타 해야할 일들
+title: "[Chore] "
+type: Chore
+body:
+  - type: textarea
+    attributes:
+      label: 배경 및 목적
+      placeholder: 작업의 필요와 목적을 설명해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 작업 목록
+      placeholder: |
+        - [ ] A 구현
+        - [ ] B 구현

.github/ISSUE_TEMPLATE/Docs.yml

@@ -0,0 +1,18 @@
+name: Docs - 문서 수정
+description: 문서 수정 및 보완
+title: "[Docs] "
+type: Docs
+body:
+  - type: textarea
+    attributes:
+      label: 배경 및 목적
+      placeholder: 문서 수정의 필요와 목적을 설명해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 작업 목록
+      placeholder: |
+        - [ ] A 구현
+        - [ ] B 구현

.github/ISSUE_TEMPLATE/Feat.yml

@@ -0,0 +1,32 @@
+name: Feat - 기능 추가
+description: 새로운 기능 개발
+title: "[Feat] "
+type: Feat
+body:
+  - type: textarea
+    attributes:
+      label: 배경 및 목적
+      placeholder: 기능의 필요와 목적을 설명해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 기능 명세
+      placeholder: 기능의 상세 동작 내용을 기술해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 성공 기준
+      placeholder: 기능이 성공적으로 구현되었음을 판단할 기준을 기술해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 작업 목록
+      placeholder: |
+        - [ ] A 구현
+        - [ ] B 구현

.github/ISSUE_TEMPLATE/Fix.yml

@@ -0,0 +1,39 @@
+name: Fix - 버그 수정
+description: 버그 상황을 재현하고 수정
+title: "[Fix] "
+type: Fix
+body:
+  - type: textarea
+    attributes:
+      label: 발생 환경
+      placeholder: 버그가 발생한 환경(운영체제, 브라우저 등)을 기술해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 재현 단계
+      placeholder: 버그를 재현하기 위한 구체적인 단계를 기술해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 버그 발생시 결과
+      placeholder: 버그가 발생했을 때의 구체적인 결과를 기술해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 예상 결과
+      placeholder: 버그가 없을 때 기대되는 정상적인 결과를 기술해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 작업 목록
+      placeholder: |
+        - [ ] A 구현
+        - [ ] B 구현

.github/ISSUE_TEMPLATE/Ops.yml

@@ -0,0 +1,18 @@
+name: Ops - 운영 작업
+description: 배포, 자동화 등 운영 관련 작업
+title: "[Ops] "
+type: Ops
+body:
+  - type: textarea
+    attributes:
+      label: 배경 및 목적
+      placeholder: 작업의 필요와 목적을 설명해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 작업 목록
+      placeholder: |
+        - [ ] A 구현
+        - [ ] B 구현

.github/ISSUE_TEMPLATE/Ref.yml

@@ -0,0 +1,18 @@
+name: Ref - 리팩토링
+description: 코드 스타일, 이름변경, 구조 변경 등 기능 변경이 없는 코드작업
+title: "[Ref] "
+type: Ref
+body:
+  - type: textarea
+    attributes:
+      label: 배경 및 목적
+      placeholder: 작업의 필요와 목적을 설명해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 작업 목록
+      placeholder: |
+        - [ ] A 구현
+        - [ ] B 구현

.github/ISSUE_TEMPLATE/Test.yml

@@ -0,0 +1,25 @@
+name: Test - 테스트
+description: 기능, 시스템의 테스트 작업
+title: "[Test] "
+type: Test
+body:
+  - type: textarea
+    attributes:
+      label: 테스트 대상
+      placeholder: 테스트 대상(기능, 시스템 등)을 설명해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 테스트 방법 및 로직
+      placeholder: 테스트를 수행할 방법과 로직을 기술해주세요.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: 작업 목록
+      placeholder: |
+        - [ ] A 구현
+        - [ ] B 구현

.github/pull_request_template.md

@@ -0,0 +1,26 @@
+## 관련 이슈
+
+<!-- 예: Closes #123, #321 -->
+
+- 이슈 번호 작성
+
+## 변경 사항
+
+- 이 PR에서 변경된 내용을 간단히 작성
+
+## 배경
+
+- 왜 이 변경이 필요한지
+- 관련 논의나 이슈가 있다면 링크
+
+## 구현 상세
+
+- 주요 구현 방식
+- 리뷰 시 봐주면 좋은 포인트
+
+## 체크리스트
+
+- [ ] 로컬에서 정상 동작 확인
+- [ ] 테스트 코드 추가/수정 (해당 시)
+- [ ] 문서 업데이트 (해당 시)
+- [ ] 불필요한 코드/주석 제거

.github/workflows/ci.yml

@@ -0,0 +1,19 @@
+name: Markdown Lint
+
+on:
+  pull_request:
+    branches: [dev]
+  push:
+    branches: [dev]
+
+jobs:
+  markdownlint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Run markdownlint
+        uses: DavidAnson/markdownlint-cli2-action@v16
+        with:
+          globs: |
+            **/*.md

.gitignore

@@ -9,7 +9,6 @@ Thumbs.db
 *.swo
 
 # 빌드 결과물 및 바이너리 무시
-bin/
 build/
 dist/
 *.o
@@ -26,3 +25,5 @@ logs/
 tmp/
 temp/
 *.tmp
+
+.envrc

bin/project

@@ -0,0 +1,25 @@
+#!/bin/bash
+
+# Project Utility CLI
+# Usage: project <command>
+CTX=act
+
+if ! docker context inspect "$CTX" >/dev/null 2>&1; then
+  docker context create "$CTX"
+fi
+
+COMMAND=$1
+shift
+
+case "$COMMAND" in
+    ci)
+        echo "Simulating Dev CI (act)..."
+        docker context use "$CTX"
+        act pull_request -W .github/workflows/ci.yml --container-architecture linux/amd64
+        docker context use default
+        ;;
+    *)
+        echo "Usage: project {ci}"
+        exit 1
+        ;;
+esac

docs/workflows/CI-coverage.md

@@ -0,0 +1,137 @@
+# CI Scope Guide
+
+이 문서는 본 프로젝트에서 사용하는 **기본 CI 범위와 흐름**를 안내합니다.
+본 프로젝트 전반에서 공통으로 사용하는 CI 흐름을 설명하기 위한 문서입니다.
+과도한 자동화보다는 협업 안정성과 확인 흐름을 명확히 하는 것을 목표로 합니다.
+
+---
+
+## 3줄 요약
+
+- 각 단계에서 테스트 진행됨: 로컬 커밋 (자동) > 로컬 빌드(수동) > dev 병합(자동) > main 병합(수동)
+- 통과 못 하는건 개인 잘못 아님. 자잘한건 애초에 자동으로 수정해줌
+- 로컬에서 미리 시뮬레이션 돌리면 실패 확률 줄어듬
+
+---
+
+## 1. CI 운영의 기본 방향
+
+- CI는 통과를 위한 장벽이 아니라, 문제를 조기에 발견하고 공통 기준을 제공하기 위한 보조 수단입니다.
+- 로컬 → dev 병합 → main 병합 단계로 갈수록 확인 범위를 점진적으로 강화합니다.
+- 초기 단계에서는 문서 품질과 협업 안정성에 필요한 최소 범위만 자동화합니다.
+- 모든 단계는 팀원이 쉽게 이해하고 재현할 수 있는 구성을 지향합니다.
+
+---
+
+## 2. 단계별 CI 흐름 개요
+
+```text
+Local (Pre-commit)
+  └─ 개인 작업 중 즉시 확인
+
+PR → dev
+  └─ 팀 단위 통합 전 기본 검증
+
+PR → main
+  └─ 기준선 확정 전 최종 검증
+```
+
+---
+
+## 3. 단계별 상세 설명
+
+### 3.1. 로컬 커밋 단계: Pre-commit 기반 확인
+
+로컬 단계에서는 각 팀원이 커밋 전에 최소한의 품질 검사를 수행하도록 유도합니다.
+이 단계의 목적은 CI 실패를 사전에 줄이고, 반복적인 수정 비용을 낮추는 것입니다.
+
+#### 3.1.1 적용 시점
+
+- `git commit` 실행 시 자동으로 동작합니다.
+- 직접 실행하여 수동 점검 용도로 사용할 수도 있습니다.
+
+#### 3.1.2 확인 범위
+
+- 언어 기본 문법 및 스타일 검사
+- 불필요한 공백, 줄 끝 공백, 파일 끝 개행 여부 확인
+- 명백한 형식 오류 위주로만 검사합니다.
+
+> 로컬 pre-commit 단계에서는 규칙 위반을 엄격히 막기보다는, 빠른 피드백 제공을 우선합니다.
+> 커밋 실행시 취소될 수 있습니다. 이 경우 출력 로그에 어디가 문제가 되는지 나오니, 해당 부분을 수정해주세요
+> 기본적으로는 자동으로 고치도록 되어있습니다. 다시 파일을 추가해서 커밋하면 됩니다.
+
+---
+
+### 3.2 로컬 빌드 단계: 수동 테스트
+
+이 단계의 목적은 빌드 실패로 인한 작업 중단과 디버깅 문제를 최소화하기 위함입니다.
+해당 단계는 개발 담당자에게 그 권한과 책임이 전적으로 위임됩니다. 즉, 권장하나 강제하지 않습니다.
+
+#### 3.2.2 확인 범위
+
+- 로컬 단계에서 브랜치를 최종적으로 푸시하고 PR을 올리기 전 수동으로 테스트합니다.
+
+#### 3.2.2 적용시점
+
+- PR을 올리기 전, 담당자가 로컬에서 수동으로 테스트합니다.
+- 구현 기능의 세부 기능들에 대한 유닛테스트를 진행합니다.
+- 빌드 및 헬스 체크, 기본 기능이 동작하는지 스크립트를 통해 검증합니다.
+
+---
+
+### 3.3. PR → dev 단계: 통합 전 기본 검증
+
+dev 브랜치는 팀 작업이 처음으로 합쳐지는 통합 지점입니다.
+이 단계의 CI는 여러 사람의 변경 사항이 함께 들어와도 문제없이 유지되는지를 확인하는 데 목적이 있습니다.
+
+#### 3.3.1. 적용 시점
+
+- 모든 작업 브랜치(`feat/*`, `fix/*` 등)에서 `dev` 브랜치로 PR이 생성되거나 업데이트될 때 Github Action으로 실행됩니다.
+- PR 열리자마자 머지하면 가끔 스킵되기도 하니 반드시 열고 기다려 주세요.
+- 로컬에서 act를 통해 시뮬레이션 해볼 수 있습니다. 레포별 bin/project에 해당 로직을 구현해둘 예정입니다.
+
+#### 3.3.2. 확인 범위
+
+- 로컬 pre-commit 단계에서 수행하는 검사 전체
+- 세부 기능별 유닛 테스트
+
+> dev 단계 CI는 팀 내부 합의를 기준으로 한 "기본 품질선"을 유지하는 역할을 합니다.
+
+---
+
+### 3.4. PR → main 단계: 기준선 확정 검증
+
+main 브랜치는 외부 공개 및 장기 기준선 역할을 하는 브랜치입니다.
+따라서 이 단계에서는 가장 안정적인 상태인지 확인하는 것을 목표로 합니다.
+
+#### 3.4.1 적용 시점
+
+- dev 브랜치에서 main 브랜치로 PR이 생성되거나 업데이트될 때 Github Action으로 실행됩니다.
+- PR 열리자마자 머지하면 가끔 스킵되기도 하니 반드시 열고 기다려 주세요.
+- 로컬에서 act를 통해 시뮬레이션 해볼 수 있습니다. 레포별 bin/project에 해당 로직을 구현해둘 예정입니다.
+
+### 5.2 확인 범위
+
+- dev 단계 CI에서 수행하는 검사 전체
+- 빌드 또는 렌더링에 영향을 주는 치명적 오류 여부 확인
+- 필수 파일(README, 주요 안내 문서 등) 누락 여부 확인
+- 컴포넌트별 유닛 테스트
+- 컴포넌트별 통신 테스트
+- 통합 End 2 End 테스트
+
+> main 단계 CI는 실패 시 병합을 중단시키는 최종 안전장치 역할을 합니다.
+
+---
+
+## 6. CI 실패 시 대응 원칙
+
+- CI 실패는 개인의 실수가 아니라, 흐름 상 발견된 문제로 간주합니다.
+- 실패 원인을 먼저 확인하고, 필요한 경우 커밋을 추가하여 수정합니다.
+- 히스토리를 수정하기 위한 rebase나 force push는 shared 브랜치(dev, main)에서는 사용하지 않습니다.
+
+---
+
+## 7. 적용 범위 및 확장에 대한 안내
+
+- 본 문서의 CI 범위는 프로젝트 **전 레포(Main/Core/FE/BE/Ops)에 공통으로 적용되는 기본 기준**입니다.
+- 각 구현 레포(Core/FE/BE/Ops)는 이 기준을 바탕으로, 필요에 따라 추가적인 CI 단계를 정의할 수 있습니다.