@decencia/ch-cli 1.3.4 → 1.4.0

package/skill/2t-decencia-channel-sprint-builder-v2/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: 2t-decencia-channel-sprint-builder-v2
+description: |
+  [2t][v2] 소통채널 Sprint 구성 가이드.
+  spec의 epic·tasks·points를 활용한 스프린트 산정과 자동 배치 원칙.
+  Use when:
+  (1) sprint를 구성할 때,
+  (2) Story Point 합산 기반 sprint 용량 산정이 필요할 때,
+  (3) Epic·도메인·의존성을 함께 고려해 spec을 sprint에 배분할 때.
+version: 1.4.0
+---
+
+<!-- ch-version-gate -->
+## ⚠️ 시작 전 필수 — 버전 게이트 (생략 금지)
+
+이 스킬로 **어떤 작업이든 수행하기 전에 가장 먼저** 아래를 실행한다:
+
+```bash
+ch check
+```
+
+- exit code 0(통과)이 **아니면 즉시 중단**한다. 출력에 안내된 업데이트 명령(`npm install -g @decencia/ch-cli@latest` 또는 `ch setup-skill`)을 사용자에게 전달하고, 갱신이 끝나기 전까지 **이 스킬의 어떤 단계도 진행하지 않는다.**
+- `ch`가 미설치/미인증이어도 먼저 `ch check`를 시도한다. (네트워크 불가 시 ch check는 통과시키되 경고를 남긴다.)
+
+구버전 스킬·CLI 사용을 막기 위한 게이트다. 건너뛰지 말 것.
+
+
+# Sprint Builder — Epic × Story Point 기반 배분
+
+## 0. Read-before-Write
+
+```bash
+ch specs list --json > /tmp/specs.json    # 모든 spec과 tasks/points 확보
+ch sprints list --json > /tmp/sprints.json
+# 분석 후
+ch sprints create --name "Sprint 1" --start 2026-06-01 --end 2026-06-14 --specs <id1>,<id2>
+```
+
+## 1. 산정 절차
+
+1. 모든 spec을 `ch specs list --json`로 수집.
+2. 각 spec의 `epic`, `tasks[].points` 추출.
+3. spec 단위 totalPoints = Σ tasks.points (points 없는 task는 1로 가정 또는 skip — 정책 결정).
+4. Sprint 용량(예: 30 SP / 2주) 설정 후, 다음 순서로 채우기:
+   - **의존성** (PRD/spec.dbTableRefs 분석): DB 테이블 신규 생성 spec → 그걸 참조하는 spec 순.
+   - **Epic 단위 묶음**: 같은 Epic은 한 sprint에 몰아주는 게 컨텍스트 비용 ↓.
+   - **도메인 균형**: 한 sprint에 너무 한쪽 도메인(user/admin)에 치우치지 않게.
+5. 남는 SP는 다음 sprint로 carry-over.
+
+## 2. 계획 확인 단계 (사용자 컨펌)
+
+자동 배치 후 다음 표를 사용자에게 제시하고 컨펌:
+
+```
+Sprint 1 (06-01 ~ 06-14, 용량 30 SP)
+| Epic | Spec | Points |
+|---|---|---|
+| 인증 | 로그인 | 5 |
+| 인증 | 회원가입 | 3 |
+| 대시보드 | 메인 대시보드 | 8 |
+| ... | ... | ... |
+합계: 28 SP / 30 SP
+```
+
+컨펌 후 `ch sprints create` 실행.
+
+## 3. workStatus 활용
+
+각 spec.workStatus에 현재 진행 상황이 적혀 있으면 우선순위 산정에 반영:
+- "블로커" 키워드 → sprint 보류 후보
+- "완료 임박" → 현 sprint 마무리 후보
+
+## 4. 흔한 함정
+
+- points 없는 task가 많으면 산정 부정확 → spec 작성 시 모든 task에 points 부여 권장(0/1/2/3/5/8).
+- Sprint에 spec 추가 후 spec 내 tasks를 늘리면 sprint SP 합이 변동 — sprint 재산정 필요.
+- Sprint와 spec.workStatus는 별개. Sprint 진행 상황은 sprint 자체 status로, spec별 메모는 workStatus로.

package/skill/2t-decencia-channel-sqa-v2/SKILL.md

@@ -0,0 +1,422 @@
+---
+name: 2t-decencia-channel-sqa-v2
+description: |
+  [2t][v2] 소통채널 SQA 운영 가이드.
+  시트 구성 2축(A. 명세별 기능 TC — §4.3 영역별 TC 번들 라이브러리에서 도출 / B. 비기능 4축 표준 40개),
+  §4.3은 명세 영역(접근권한/목록/폼/삭제/상태전이/UI일반/백엔드/규칙/내보내기/차트)마다
+  Functional·Publishing·Frontend·Backend 카테고리를 한 묶음으로 제공하는 누적 라이브러리.
+  Use when:
+  (1) SQA 시트를 새로 작성하거나 항목을 보강할 때,
+  (2) spec.tasks에서 추출한 검증 항목을 SQA 시트에 등록할 때,
+  (3) 보안/성능/접근성/호환성 비기능 TC를 시트에 채워야 할 때,
+  (4) 명세 영역별 완성형 TC 번들(퍼블리싱/프론트/백엔드 디센시아 운영 관점 포함)을 가져다 쓸 때,
+  (5) 새 명세 작업 중 반복 패턴을 발견해 영역별 번들을 보강할 때,
+  (6) Sprint 종료 전 spec별 SQA 통과 여부를 점검할 때.
+version: 1.4.0
+---
+
+<!-- ch-version-gate -->
+## ⚠️ 시작 전 필수 — 버전 게이트 (생략 금지)
+
+이 스킬로 **어떤 작업이든 수행하기 전에 가장 먼저** 아래를 실행한다:
+
+```bash
+ch check
+```
+
+- exit code 0(통과)이 **아니면 즉시 중단**한다. 출력에 안내된 업데이트 명령(`npm install -g @decencia/ch-cli@latest` 또는 `ch setup-skill`)을 사용자에게 전달하고, 갱신이 끝나기 전까지 **이 스킬의 어떤 단계도 진행하지 않는다.**
+- `ch`가 미설치/미인증이어도 먼저 `ch check`를 시도한다. (네트워크 불가 시 ch check는 통과시키되 경고를 남긴다.)
+
+구버전 스킬·CLI 사용을 막기 위한 게이트다. 건너뛰지 말 것.
+
+
+# SQA — spec.tasks 와의 통합
+
+## 0. Read-before-Write
+
+시트 항목(item) 단위 CRUD는 이제 CLI로 모두 지원된다(§3.5). 항상 `ch sqa get <sheetId> --json`으로 현재 항목 목록·id를 먼저 받고 수정한다. 항목 수정/삭제/순서변경은 `id`를 키로 지정하므로 최신 id 확보가 선행되어야 한다.
+
+## 1. 핵심 규칙
+
+> **spec의 완료 조건 = 그 spec에 연결된 SQA 항목이 모두 통과**
+
+별도 acceptanceCriteria 필드 없음. spec.tasks의 완료(체크박스)는 개발 진척 표시이고, **공식 완료는 SQA**가 판정한다.
+
+## 2. spec.tasks → SQA 항목 매핑
+
+spec.tasks 작성 시 다음 패턴 권장:
+- Task: 개발자가 끝낼 단위 작업 (예: "로그인 폼 UI 구현")
+- SQA 항목: QA가 검증할 시나리오 (예: "잘못된 비밀번호 5회 시 잠금")
+
+**1:N 관계**: 1개 task가 여러 SQA 항목을 유발할 수 있음. SQA 항목 작성 시 `relatedSpec` + (자유) `relatedTask` 메모로 추적.
+
+## 3. 신규 SQA 작성 워크플로우
+
+0. **시트 생성** (없으면 먼저):
+   ```bash
+   # --date 생략 시 오늘로 자동 채움 (서버 DTO가 performDate 필수)
+   ch sqa create --name "Sprint 1 SQA" --date 2026-06-01
+   ```
+1. **spec.tasks를 가져온다**:
+   ```bash
+   ch specs get <specId> --json | jq '.tasks'
+   ```
+2. 각 task의 description(있다면)과 logic.businessRules 참고하여 검증 항목 도출.
+3. SQA 시트에 항목 추가 (§3.5 CLI 명령 사용).
+4. 항목 작성 시 `relatedSpec`에 specId 명시(생략 시 미연결).
+
+## 3.5 시트 항목(item) CRUD — CLI 완전 지원
+
+시트 항목은 시트 문서의 `items[]` 배열에 임베드된다. 항목 단위 CRUD가 모두 CLI로 지원된다(ch-cli 1.3.3+).
+
+```bash
+# 단건 추가 ( --spec 생략 가능 → 미연결 항목 )
+ch sqa add-item <sheetId> --test "잘못된 비밀번호 5회 시 잠금" --spec <specId>
+
+# 일괄 추가 — JSON 배열 또는 { "items": [...] }
+#   items.json: [ { "testItem": "...", "relatedSpec": "<specId>" }, { "testItem": "..." } ]
+ch sqa add-items <sheetId> --file items.json
+
+# 항목 수정 ( --test / --spec 중 지정한 것만 변경, --spec "" 로 연결 해제 )
+ch sqa update-item <sheetId> <itemId> --test "수정된 항목명" --spec <specId>
+
+# 항목 삭제 ( 삭제 후 order 1..N 자동 재정렬 )
+ch sqa delete-item <sheetId> <itemId>
+
+# 순서 변경 ( 현재 모든 itemId를 빠짐없이·중복없이 나열 )
+ch sqa reorder-items <sheetId> --order item-0-...,item-1-...,item-2-...
+ch sqa reorder-items <sheetId> --file order.json   # ["id1","id2",...] 또는 { "order":[...] }
+```
+
+- `<itemId>`는 `ch sqa get <sheetId> --json`의 `items[].id`. 항상 최신값을 먼저 확보(§0).
+- 시트 항목 CRUD는 **시트 템플릿**을 바꾼다. 이미 `start-run`으로 스냅샷된 진행 중 Run에는 소급 적용되지 않는다.
+- 항목 결과(Pass/Fail) 입력은 Run 쪽: `ch sqa check <runId> <itemId> --result yes|no --note ...` / `check-bulk`.
+
+## 4. SQA 시트 구성 표준 — 무엇을 넣어야 하는가
+
+명세별 E2E 항목만 넣고 끝내지 말 것. SQA 시트는 다음 **2축**으로 구성한다.
+
+| 축 | 단위 | 출처 / 도출 방법 | 비고 |
+|---|---|---|---|
+| A. 명세별 기능 TC | spec 1개당 | spec.ui/logic/tasks를 읽고 **§4.3 영역별 TC 번들 라이브러리**에서 해당 영역들을 골라 명세 맥락으로 구체화 | spec당 보통 5~15개 |
+| B. 비기능 4축 표준 TC | 시트 1개당 묶음 | 표준(OWASP/Core Web Vitals/WCAG/호환성)을 그대로 등록 | **시트당 40개** (보안 12 + 성능 10 + 접근성 10 + 호환성 8) |
+
+축 B는 spec 단위가 아니므로 `relatedSpec`을 비워두거나 "common"/"standard" 가상 specId로 일관 관리.
+
+§4.3 라이브러리에는 **Functional/Publishing/Frontend/Backend 카테고리가 영역별로 한 묶음**으로 들어 있다. 별도 시트가 아니라 각 명세 A축 항목으로 풀어 쓴다.
+
+## 4.1 시트 구성 권장 비율
+
+| 우선순위 | 비중 | 기준 |
+|---|---|---|
+| High | 60% | 핵심 비즈니스 플로우, 권한/인증, 데이터 무결성, 보안 핵심 |
+| Medium | 30% | 부가 기능, 성능, 접근성, 호환성 |
+| Low | 10% | UI 디테일, 반응형, 에지 케이스 |
+
+## 4.2 비기능 4축 표준 TC (40개)
+
+모든 SQA 시트에 아래 항목을 포함한다. "ISO/IEC 25010 + OWASP Top 10:2025 + WCAG 2.2 AA + Core Web Vitals" 기반.
+
+### 4.2.1 Security — OWASP Top 10:2025 (12개)
+
+| # | subType | TC 항목 | 근거 |
+|---|---|---|---|
+| 1 | access-control | 비인가 역할로 관리자 페이지 접근 시 차단/리다이렉트 | A01 |
+| 2 | access-control | 권한별 API 엔드포인트 403 반환 | A01 |
+| 3 | config | 보안 헤더(CSP, X-Frame-Options, X-Content-Type) 설정 | A02 |
+| 4 | config | 에러 응답에 스택트레이스/디버그 정보 미노출 | A02 |
+| 5 | input-validation | `<script>` 삽입 시 이스케이프 처리 (XSS) | A03 |
+| 6 | input-validation | NoSQL/SQL 인젝션 패턴 필터링 | A03 |
+| 7 | input-validation | 서버사이드 유효성 검증 (클라이언트 우회 방지) | A03 |
+| 8 | auth-security | 만료 토큰으로 API 호출 시 401 | A07 |
+| 9 | auth-security | 로그인 실패 N회 시 잠금/지연 | A07 |
+| 10 | auth-security | 세션 만료 후 재인증 요구 | A07 |
+| 11 | data-protection | 모든 통신 HTTPS 강제 | A08 |
+| 12 | supply-chain | `npm audit` / 의존성 취약점 스캔 통과 | A06 |
+
+### 4.2.2 Performance — Core Web Vitals + ISO 25010 (10개)
+
+| # | subType | TC 항목 | 기준 |
+|---|---|---|---|
+| 1 | loading | LCP ≤ 2.5s | CWV |
+| 2 | loading | FCP ≤ 1.8s | CWV |
+| 3 | interactivity | INP ≤ 200ms | CWV |
+| 4 | visual-stability | CLS < 0.1 | CWV |
+| 5 | server-response | TTFB ≤ 800ms | CWV |
+| 6 | server-response | API P95 ≤ 500ms | ISO 25010 |
+| 7 | resource | 이미지 최적화 (WebP/AVIF, lazy load) | ISO 25010 |
+| 8 | resource | JS 번들 gzip ≤ 200KB | ISO 25010 |
+| 9 | caching | 정적 자산 Cache-Control 헤더 | ISO 25010 |
+| 10 | memory | SPA 장시간 사용 시 메모리 누수 없음 | ISO 25010 |
+
+### 4.2.3 Accessibility — WCAG 2.2 Level AA (10개)
+
+| # | subType | TC 항목 | 근거 |
+|---|---|---|---|
+| 1 | perceivable | 의미 있는 이미지에 alt 제공 | WCAG 1.1.1 |
+| 2 | color-contrast | 일반 텍스트 대비 4.5:1 이상 | WCAG 1.4.3 |
+| 3 | color-contrast | 대형 텍스트(18pt+) 대비 3:1 이상 | WCAG 1.4.3 |
+| 4 | keyboard | Tab/Enter/Esc로 주요 기능 사용 가능 | WCAG 2.1.1 |
+| 5 | keyboard | 포커스 표시(outline) 시각적으로 확인 가능 | WCAG 2.4.7 |
+| 6 | operable | Skip to content 링크 제공 | WCAG 2.4.1 |
+| 7 | understandable | 페이지별 고유 `<title>` | WCAG 2.4.2 |
+| 8 | understandable | 모든 폼 input에 `<label>` 연결 | WCAG 1.3.1 |
+| 9 | understandable | 폼 에러 위치/내용 식별 가능 | WCAG 3.3.1 |
+| 10 | touch-target | 터치 타겟 최소 24×24px | WCAG 2.5.8 |
+
+### 4.2.4 Compatibility — 크로스 브라우저/디바이스 (8개)
+
+| # | subType | TC 항목 |
+|---|---|---|
+| 1 | browser | Chrome 최신 2버전 정상 동작 |
+| 2 | browser | Safari 최신 2버전 정상 동작 |
+| 3 | browser | Edge 최신 버전 정상 동작 |
+| 4 | browser | Firefox 최신 버전 정상 동작 |
+| 5 | mobile | iOS Safari 정상 동작 |
+| 6 | mobile | Android Chrome 정상 동작 |
+| 7 | responsive | 375 / 768 / 1440 레이아웃 정상 |
+| 8 | responsive | 가로/세로 회전 시 레이아웃 유지 |
+
+## 4.3 명세별 기능 TC 도출 가이드 (A축) — 영역별 TC 번들 라이브러리
+
+**이 섹션의 최종 목표**: 각 "명세 영역"마다 그대로 갖다 쓸 수 있는 **완성형 TC 번들**을 누적해 라이브러리로 키운다. 신규 명세를 만나면 해당 영역의 번들에서 골라 명세 맥락으로만 구체화하면 된다. (현재는 기반 단계 — 골격 + 일부 영역 시범 채움. 누락 영역은 시간이 지나며 보강한다.)
+
+### 사용 절차
+
+1. spec.ui/logic/tasks를 읽어 그 spec이 속한 **명세 영역**을 1~N개 식별 (예: "지점 관리 화면" = 접근권한 + 목록 + 등록/수정 폼 + 삭제).
+2. 각 영역 번들의 항목을 가져와 그 명세의 도메인 단어로 구체화. 추상 문구 그대로 박지 말 것.
+   - 추상: "Update시 모달창이나 수정 페이지로 데이터가 제대로 전달 되는가?"
+   - 명세별: "지점 수정 모달 진입 시 기존 지점명·지역·전화 필드가 prefill됨"
+3. 명세 성격상 해당 안 되는 항목은 스킵 (예: API spec엔 퍼블리싱·반응형 항목 적용 X).
+4. `relatedSpec`은 해당 명세 specId (A축이므로 항상 명시).
+
+### 번들 구성 원칙
+
+각 영역 번들은 다음 카테고리를 한 묶음으로 제공한다 — 별도로 흩어놓지 않는다.
+- **Functional** — 영역 본질의 정상/비정상 경로
+- **Publishing** — 디자인 시스템·아이콘·이미지·패딩·반응형
+- **Frontend** — 상태 전달·refresh·permission·필터·네비게이션
+- **Backend** — RLS/firestore.rules, 클라이언트 직접 CRUD 원칙
+
+→ 한 영역의 번들만 펼쳐도 "그 영역 명세를 쓸 때 검토해야 할 모든 관점"이 한 곳에 있다.
+
+**명세 복잡도별 권장 TC 수**:
+- 단순(조회만): 5~8개
+- 보통(CRUD): 8~12개
+- 복잡(다기능): 12~20개
+
+---
+
+### 4.3.1 [영역] 접근 권한 / 인증
+**Trigger**: spec.logic에 역할/권한 분기, 보호된 라우트, 로그인 게이트 언급이 있을 때.
+
+| 카테고리 | TC 후보 |
+|---|---|
+| Functional | 허용 역할로 접근 → 정상 렌더링 |
+| Functional | 비허용 역할로 접근 → 403 또는 리다이렉트 |
+| Functional | 비로그인 상태 접근 → 로그인 페이지로 리다이렉트 |
+| Functional | 로그인 후 원래 가려던 페이지로 복귀 (returnTo) |
+| Frontend | 기본 페이지(로그인 전, 로그인 후)가 제대로 설정되어 있는가? — 명세에 맞춰 구체화 |
+| Backend | 권한별 API 엔드포인트 호출 시 서버에서 403 검증 |
+
+### 4.3.2 [영역] 목록 화면 (List)
+**Trigger**: spec.ui에 테이블/카드 그리드/리스트, 검색/필터/정렬/페이징 언급.
+
+| 카테고리 | TC 후보 |
+|---|---|
+| Functional | 데이터 정상 조회 및 N개 표시 |
+| Functional | 빈 상태(0건) → 빈 상태 안내 표시 |
+| Functional | 검색어 입력 → 매칭 결과만 표시 |
+| Functional | 필터 적용 → 조건 일치 결과만 표시 |
+| Functional | 정렬 토글 → 해당 컬럼 기준 오름/내림차순 |
+| Functional | 페이징/무한스크롤 → 다음 페이지 정상 로딩 |
+| Publishing | 정확한 아이콘을 사용하고 있는가? (정렬·필터·액션 아이콘 일치) |
+| Publishing | 화면 크기가 변하는 환경에서도 반응형으로 레이아웃이 잘 구성되어 있는가? |
+| Publishing | 화면 상하좌우 패딩이 Design system의 규정을 준수하고 있는가? |
+| Frontend | 본인의 데이터만 제대로 필터링해서 쿼리하고 있는가?(타 유저 데이터 노출 차단) |
+
+### 4.3.3 [영역] 등록/수정 폼
+**Trigger**: spec.ui에 입력 폼, 모달, 등록/수정/저장 액션 언급.
+
+| 카테고리 | TC 후보 |
+|---|---|
+| Functional | 정상값 입력 + 저장 → 성공 후 목록에 반영 |
+| Functional | 필수 필드 빈값으로 저장 → 오류 메시지 표시 |
+| Functional | 형식 오류(이메일/숫자/날짜) → 인라인 검증 메시지 |
+| Functional | 저장 중 네트워크 오류 → 재시도 안내 + 사용자 입력 보존 |
+| Frontend | Update시 모달창이나 수정 페이지로 데이터가 제대로 전달 되는가? (prefill 확인) |
+| Frontend | CRUD 관련 작업 시 변경된 사항이 보이는 페이지에 바로바로 반영되는가?(목록 refresh) |
+| Frontend | CRUD 작업 시 permission 관련 조치는 되어있는가? (UI 버튼 노출 + 서버 검증 양쪽) |
+| Publishing | 버튼간, 요소간 패딩 정책이 잘 적용되어 있는가? (저장/취소 버튼 간격) |
+
+### 4.3.4 [영역] 삭제
+**Trigger**: spec.ui/logic에 삭제 액션/휴지통/소프트 삭제 언급.
+
+| 카테고리 | TC 후보 |
+|---|---|
+| Functional | 삭제 클릭 → 확인 다이얼로그 표시 |
+| Functional | 확인 → 삭제 후 목록에서 제거 + 토스트 |
+| Functional | 취소 → 변경 없음 |
+| Frontend | CRUD 관련 작업 시 변경된 사항이 보이는 페이지에 바로바로 반영되는가?(목록 refresh) |
+| Backend | 테이블별 RLS 설정이 제대로 되어있는가? — 본인 소유만 삭제 가능 |
+
+### 4.3.5 [영역] 상태 전이 (Workflow)
+**Trigger**: spec.logic에 상태 머신(예: 대기 → 진행 → 완료), 승인 플로우 언급.
+
+| 카테고리 | TC 후보 |
+|---|---|
+| Functional | 허용 전이 → 상태 변경 성공 |
+| Functional | 비허용 전이 → 차단 + 안내 |
+| Functional | 전이 이력 기록 (감사 로그) |
+| Backend | 전이 권한이 서버에서도 검증되는가? (클라이언트 우회 방지) |
+
+### 4.3.6 [영역] 화면(UI) 일반 — 모든 화면 spec에 공통 적용
+**Trigger**: spec.ui가 정의된 모든 화면 명세.
+
+| 카테고리 | TC 후보 |
+|---|---|
+| Publishing | 정확한 아이콘을 사용하고 있는가? |
+| Publishing | 정확한 이미지를 사용하고 있는가? |
+| Publishing | 아이콘 및 이미지의 해상도는 적절하게 설정되어 있는가? |
+| Publishing | Design system과 UI component들이 빠짐없이 구현되어 있는가? |
+| Publishing | 실제로 구현된 화면들이 Design system을 준수하고 있는가? |
+| Publishing | 실제로 구현된 화면들이 UI component를 적극적으로 활용하고 있는가? |
+| Publishing | 화면 크기가 변하는 환경에서도 반응형으로 레이아웃이 잘 구성되어 있는가? |
+| Publishing | 화면 상하좌우 패딩이 Design system의 규정을 준수하고 있는가? |
+| Publishing | 버튼간, 요소간 패딩 정책이 잘 적용되어 있는가? |
+| Frontend | 화면간 네비게이팅이 적절하게 연결되어 있는가? |
+| Frontend | (모바일의 경우) 키보드가 올라왔을때 콘텐츠들이 가려져서 사용하지 못하게 되는 경우가 있는가? |
+
+> 화면 spec이라면 §4.3.6에서 해당되는 항목을 1차로 깔고, 그 위에 영역별(4.3.1~4.3.5) 번들을 얹는다.
+
+### 4.3.7 [영역] 백엔드 / 데이터 접근
+**Trigger**: spec에 dbTableRefs 또는 API/저장소 동작 정의.
+
+| 카테고리 | TC 후보 |
+|---|---|
+| Backend | 테이블별 RLS 설정이 제대로 되어있는가? (Firestore: rules) |
+| Backend | Storage에도 RLS 설정이 되어 있는가? (Firestore: Storage Rules) |
+| Backend | 기본적인 CRUD작업을 프론트에서 하도록 되어있는가?(서버에서 처리하게 되면 RLS가 의미 없어짐) |
+| Backend | 본인의 데이터만 제대로 필터링해서 쿼리하고 있는가?(다른 유저에 종속된 데이터 혹은 보여서는 안되는 데이터 조회시도) — 서버 사이드 |
+
+### 4.3.8 [영역] 비즈니스 규칙
+**Trigger**: spec.logic.businessRules에 도메인 규칙이 정의되어 있을 때.
+
+| 카테고리 | TC 후보 |
+|---|---|
+| Functional | 각 규칙의 **정상 경로** 1개 — 예: "5회 미만 실패 → 로그인 가능" |
+| Functional | 각 규칙의 **비정상/경계 경로** 1개 — 예: "5회째 실패 → 잠금" |
+| Functional | 규칙 충돌/우선순위 — 둘 이상 규칙이 동시에 충족될 때 의도된 결과 |
+
+### 4.3.9 [영역] 내보내기 / 보고서
+**Trigger**: spec.logic에 엑셀/PDF/CSV export 또는 인쇄 기능.
+
+| 카테고리 | TC 후보 |
+|---|---|
+| Functional | 내보내기 클릭 → 파일 다운로드 완료 |
+| Functional | 파일 내용이 화면 표시 데이터와 일치 |
+| Functional | 권한 없는 사용자 → 내보내기 버튼 비활성/차단 |
+
+### 4.3.10 [영역] 차트 / 시각화
+**Trigger**: spec.ui에 그래프/차트/대시보드 KPI 카드 언급.
+
+| 카테고리 | TC 후보 |
+|---|---|
+| Functional | 데이터 정상 시 차트 렌더링 |
+| Functional | 데이터 0건 시 "데이터 없음" 안내 |
+| Functional | 집계 결과가 원본 합과 일치 |
+
+---
+
+> **라이브러리 확장 규칙**: 새 명세 작업하다가 위 번들에 없는 패턴이 반복적으로 등장하면 → 그 영역의 번들에 항목 추가하거나 새 영역 §4.3.N 신설. 한 번 적은 항목은 다음 명세에서 그대로 재사용 가능해야 한다.
+
+## 4.4 TC 작성 규칙
+
+### 항목 문장
+한 문장으로, 주어 없이, **동작 + 결과** 형태.
+
+```
+좋은 예: "필수 필드 빈값으로 저장 클릭 시 오류 메시지 표시"
+좋은 예: "비허용 역할로 접근 시 403 또는 리다이렉트"
+나쁜 예: "지점 관리 테스트" (너무 모호)
+나쁜 예: "로그인 확인"
+```
+
+### relatedSpec
+- A축(§4.3 영역별 번들에서 도출한 모든 항목): 반드시 해당 명세의 specId 명시
+- B축(비기능 4축 표준 40개): 비워두거나 "common"/"standard" 가상 specId 사용 — 프로젝트 정책 결정 후 일관 적용
+
+### Windows CRLF 주의
+파일 기반 입력 시 `\r`이 specId 끝에 붙어 연결이 깨진다. heredoc 권장, 부득이 파일이면 `tr -d '\r'`로 정제.
+
+## 4.5 스펙 커버리지 검증
+
+항목 등록 후 반드시 실행 — A축에서 누락된 spec이 없는지 확인. 통과 못 하면 `start-run` 금지.
+
+```bash
+ch specs list --json --per-page 100 | node -e "
+  const specs = JSON.parse(require('fs').readFileSync(0,'utf8')).data.map(s=>s.id);
+  const sheet = JSON.parse(require('child_process').execSync('ch sqa get <sheetId> --json'));
+  const linked = [...new Set((sheet.data||sheet).items.map(i=>i.relatedSpec).filter(Boolean))];
+  const missing = specs.filter(id => !linked.includes(id));
+  if (missing.length) { console.error('누락된 스펙:', missing.length, missing); process.exit(1); }
+  else console.log('OK:', specs.length, '개 스펙 커버 완료');
+"
+```
+
+누락된 spec이 있으면 해당 spec의 content를 다시 읽고 TC를 추가한 후 재검증.
+
+## 5. spec 완료 점검 절차
+
+```bash
+# 1) spec에 연결된 SQA 항목 조회 → 해당 spec의 항목이 든 시트의 Run summary 확인
+ch sqa summary <runId>
+# 2) 모두 "통과(Pass)" 상태인지 확인
+# 3) 통과 → spec.status 를 "완료"로 갱신
+ch specs update <specId> --status 완료 --no-version
+```
+
+수동으로 status를 바꾸기 전에 SQA 통과 여부를 반드시 확인.
+
+## 6. workStatus와의 분담
+
+- **spec.workStatus**: 개발자의 진행 메모, 블로커, 의사결정 로그.
+- **SQA 항목.note**: QA의 검증 결과/재현 단계.
+- 둘은 분리 유지. workStatus에 SQA 결과를 복붙하지 말 것.
+
+## 7. 결함 보고 규칙 (Run의 항목 note)
+
+`check --result no --note ...` 시 note에 다음을 포함.
+
+```
+[심각도] Critical / Major / Minor
+[현상] 실제 발생한 문제
+[기대] 기대했던 결과
+[재현] 재현 절차
+[환경] 브라우저/해상도/계정
+```
+
+## 8. 시트 작성 완료 자가 점검 체크리스트
+
+- [ ] A축: 모든 spec에 최소 3개 이상 TC가 있는가? (§4.5 커버리지 통과)
+- [ ] A축 항목 작성 시 §4.3 영역별 번들(Functional/Publishing/Frontend/Backend)을 명세 성격에 맞게 적용했는가?
+- [ ] B축: 보안 12 / 성능 10 / 접근성 10 / 호환성 8 — 40개 모두 포함?
+- [ ] High 우선순위 TC가 60% 이상인가?
+- [ ] 정상 경로 + 비정상 경로(에러) 모두 커버?
+- [ ] 빈 상태(데이터 없음) 테스트 포함?
+- [ ] TC 항목이 "동작+결과" 한 문장인가? (§4.3 번들의 추상 문구도 명세별 구체 시나리오로 변환됐는가?)
+- [ ] specId에 CRLF `\r` 미포함? (파일 입력 시 필수)
+- [ ] `start-run` 후 스펙 페이지 "관련 SQA" 탭 연결 표시 확인?
+- [ ] 이번 명세 작업 중 §4.3 번들에 없는 반복 패턴을 발견했다면, 번들에 추가했는가? (라이브러리 확장)
+
+## 9. 흔한 함정
+
+- spec.tasks를 전부 done 처리해도 SQA 통과 안 됐으면 spec.status는 완료로 바꾸지 않음.
+- **명세별 E2E만 넣고 끝내지 말 것** — §4.3 번들에서 Publishing/Frontend/Backend 카테고리 누락, §4.2 비기능 4축 미등록이 가장 흔한 실수.
+- §4.3 번들을 **별도 시트 묶음으로 등록**하지 말 것 — 각 명세의 A축 항목으로 풀어 써야 한다. 추상 문구 그대로 박아넣지 말 것.
+- 항목 단위 CRUD(§3.5)는 **시트 템플릿**만 변경 — 진행 중 Run에는 반영 안 됨. Run 항목 결과는 `check`/`check-bulk`로.
+- `update-item`/`delete-item`/`reorder-items`는 `itemId` 키 기반 → 반드시 `ch sqa get --json`으로 최신 id 확보 후 실행(stale id 주의).
+- `reorder-items`의 `--order`는 현재 모든 항목 id를 빠짐없이·중복없이 나열해야 함. 일부만 주면 400.
+- `ch sqa create`는 서버 DTO상 `performDate`가 필수 — CLI에서 `--date` 생략하면 오늘 날짜로 자동 채워지지만, 명시적 날짜가 필요하면 `--date YYYY-MM-DD` 지정.
+- 신규 프로젝트에 SQA 시트가 없는 상태에서 spec을 완료 처리하면 추적 불가 — 신규 프로젝트는 SQA 시트 초기 생성 권장.
+- B축(비기능 표준) 항목의 `relatedSpec`을 명세별 spec과 섞어 넣으면 §4.5 커버리지 검증이 잘못 통과될 수 있음 — B축은 빈 값 또는 "common"으로 일관.