@decencia/ch-cli 1.8.2 → 1.11.0

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

@@ -7,12 +7,12 @@ description: |
   Functional·Publishing·Frontend·Backend 카테고리를 한 묶음으로 제공하는 누적 라이브러리.
   Use when:
   (1) SQA 시트를 새로 작성하거나 항목을 보강할 때,
-  (2) spec.tasks에서 추출한 검증 항목을 SQA 시트에 등록할 때,
+  (2) spec.ui/logic에서 도출한 검증 항목을 SQA 시트에 등록할 때,
   (3) 보안/성능/접근성/호환성 비기능 TC를 시트에 채워야 할 때,
   (4) 명세 영역별 완성형 TC 번들(퍼블리싱/프론트/백엔드 디센시아 운영 관점 포함)을 가져다 쓸 때,
   (5) 새 명세 작업 중 반복 패턴을 발견해 영역별 번들을 보강할 때,
   (6) Sprint 종료 전 spec별 SQA 통과 여부를 점검할 때.
-version: 1.8.2
+version: 1.11.0
 ---
 
 <!-- ch-version-gate -->
@@ -30,7 +30,7 @@ ch check
 구버전 스킬·CLI 사용을 막기 위한 게이트다. 건너뛰지 말 것.
 
 
-# SQA — spec.tasks 와의 통합
+# SQA — spec 완료 판정 (SQA 통과 = 완료)
 
 ## 0. Read-before-Write
 
@@ -40,15 +40,16 @@ ch check
 
 > **spec의 완료 조건 = 그 spec에 연결된 SQA 항목이 모두 통과**
 
-별도 acceptanceCriteria 필드 없음. spec.tasks의 완료(체크박스)는 개발 진척 표시이고, **공식 완료는 SQA**가 판정한다.
+별도 acceptanceCriteria 필드 없음. **공식 완료는 SQA**가 판정한다 — spec에 연결된 SQA 항목이 모두 통과해야 spec.status를 완료로 올린다. spec 규모는 Story Point(`spec.points`)로 표현하고, 진행률(%)·Task 체크박스 개념은 없다.
 
-## 2. spec.tasks → SQA 항목 매핑
+## 2. spec → SQA 항목 도출
 
-spec.tasks 작성 시 다음 패턴 권장:
-- Task: 개발자가 끝낼 단위 작업 (예: "로그인 폼 UI 구현")
+SQA 항목은 spec의 ui·logic(특히 logic.businessRules)에서 도출한다. Story는 Task로 쪼개지 않으므로(`tasks`는 deprecated) 검증 단위는 개별 task가 아니라 **spec이 정의한 동작·규칙**이다.
+
+- 도출 입력: spec.ui(화면·상호작용), spec.logic(dataFlow·businessRules)
 - SQA 항목: QA가 검증할 시나리오 (예: "잘못된 비밀번호 5회 시 잠금")
 
-**1:N 관계**: 1개 task가 여러 SQA 항목을 유발할 수 있음. SQA 항목 작성 시 `relatedSpec` + (자유) `relatedTask` 메모로 추적.
+**1:N 관계**: spec 1개가 여러 SQA 항목을 유발한다. SQA 항목 작성 시 `relatedSpec`으로 spec에 연결해 추적한다.
 
 ## 3. 신규 SQA 작성 워크플로우
 
@@ -57,11 +58,11 @@ spec.tasks 작성 시 다음 패턴 권장:
    # --date 생략 시 오늘로 자동 채움 (서버 DTO가 performDate 필수)
    ch sqa create --name "Sprint 1 SQA" --date 2026-06-01
    ```
-1. **spec.tasks를 가져온다**:
+1. **spec의 ui·logic을 가져온다**:
    ```bash
-   ch specs get <specId> --json | jq '.tasks'
+   ch specs get <specId> --json | jq '{ui, logic}'
    ```
-2. 각 task의 description(있다면)과 logic.businessRules 참고하여 검증 항목 도출.
+2. spec.ui(화면·상호작용)와 logic.businessRules를 참고하여 검증 항목 도출.
 3. SQA 시트에 항목 추가 (§3.5 CLI 명령 사용).
 4. 항목 작성 시 `relatedSpec`에 specId 명시(생략 시 미연결).
 
@@ -99,7 +100,7 @@ ch sqa reorder-items <sheetId> --file order.json   # ["id1","id2",...] 또는 {
 
 | 축 | 단위 | 출처 / 도출 방법 | 비고 |
 |---|---|---|---|
-| A. 명세별 기능 TC | spec 1개당 | spec.ui/logic/tasks를 읽고 **§4.3 영역별 TC 번들 라이브러리**에서 해당 영역들을 골라 명세 맥락으로 구체화 | spec당 보통 5~15개 |
+| A. 명세별 기능 TC | spec 1개당 | spec.ui/logic을 읽고 **§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로 일관 관리.
@@ -184,7 +185,7 @@ ch sqa reorder-items <sheetId> --file order.json   # ["id1","id2",...] 또는 {
 
 ### 사용 절차
 
-1. spec.ui/logic/tasks를 읽어 그 spec이 속한 **명세 영역**을 1~N개 식별 (예: "지점 관리 화면" = 접근권한 + 목록 + 등록/수정 폼 + 삭제).
+1. spec.ui/logic을 읽어 그 spec이 속한 **명세 영역**을 1~N개 식별 (예: "지점 관리 화면" = 접근권한 + 목록 + 등록/수정 폼 + 삭제).
 2. 각 영역 번들의 항목을 가져와 그 명세의 도메인 단어로 구체화. 추상 문구 그대로 박지 말 것.
    - 추상: "Update시 모달창이나 수정 페이지로 데이터가 제대로 전달 되는가?"
    - 명세별: "지점 수정 모달 진입 시 기존 지점명·지역·전화 필드가 prefill됨"
@@ -262,14 +263,20 @@ ch sqa reorder-items <sheetId> --file order.json   # ["id1","id2",...] 또는 {
 | Backend | 테이블별 RLS 설정이 제대로 되어있는가? — 본인 소유만 삭제 가능 |
 
 ### 4.3.5 [영역] 상태 전이 (Workflow)
-**Trigger**: spec.logic에 상태 머신(예: 대기 → 진행 → 완료), 승인 플로우 언급.
+**Trigger**: db-table.stateMachines(엔티티 생애주기) 또는 spec.logic.stateTransitions(화면 전이)가 정의됨.
+
+**TC 도출**: 상태머신의 `transitions` 목록을 그대로 TC로 편다. 전이 1개 = 정상 TC 1개(허용 전이 성공), 그 반대·미정의 조합 = 차단 TC. `guard`가 있으면 경계 조건 1쌍(충족/불충족)을 추가한다.
 
 | 카테고리 | TC 후보 |
 |---|---|
-| Functional | 허용 전이 → 상태 변경 성공 |
-| Functional | 비허용 전이 → 차단 + 안내 |
+| Functional | 각 `transition`(from→to) 실행 → 상태가 to로 변경 성공 |
+| Functional | 목록에 없는 전이 시도 → 차단 + 안내 |
+| Functional | `guard`가 있는 전이 → 조건 충족 시 성공 / 불충족 시 차단 |
+| Functional | `initial` 진입 상태로 생성 / `terminal` 상태에서 추가 전이 차단 |
 | Functional | 전이 이력 기록 (감사 로그) |
-| Backend | 전이 권한이 서버에서도 검증되는가? (클라이언트 우회 방지) |
+| Backend | 전이 규칙·권한이 서버에서도 검증되는가? (클라이언트 우회 방지) |
+
+> 엔티티 상태(주문/배포 등, DB 저장)는 db-table.stateMachines에서, 화면 휘발성 상태(idle/loading 등)는 spec.logic.stateTransitions에서 도출한다.
 
 ### 4.3.6 [영역] 화면(UI) 일반 — 모든 화면 spec에 공통 적용
 **Trigger**: spec.ui가 정의된 모든 화면 명세.
@@ -412,7 +419,7 @@ ch specs update <specId> --status 완료 --no-version
 
 ## 9. 흔한 함정
 
-- spec.tasks를 전부 done 처리해도 SQA 통과 안 됐으면 spec.status는 완료로 바꾸지 않음.
+- 구현이 끝났다고 판단해도 연결된 SQA가 통과하기 전에는 spec.status를 완료로 바꾸지 않음.
 - **명세별 E2E만 넣고 끝내지 말 것** — §4.3 번들에서 Publishing/Frontend/Backend 카테고리 누락, §4.2 비기능 4축 미등록이 가장 흔한 실수.
 - §4.3 번들을 **별도 시트 묶음으로 등록**하지 말 것 — 각 명세의 A축 항목으로 풀어 써야 한다. 추상 문구 그대로 박아넣지 말 것.
 - 항목 단위 CRUD(§3.5)는 **시트 템플릿**만 변경 — 진행 중 Run에는 반영 안 됨. Run 항목 결과는 `check`/`check-bulk`로.

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

@@ -8,7 +8,7 @@ description: |
   (2) "작업 현황 적어줘", "workStatus 갱신해줘" 요청 시,
   (3) Sprint 종료 회고나 인수인계용으로 spec별 진행 상태를 정리할 때,
   (4) `ch specs update --work-status` 또는 웹 "작업 현황" 탭에서 갱신할 때.
-version: 1.8.2
+version: 1.11.0
 ---
 
 <!-- ch-version-gate -->
@@ -71,7 +71,7 @@ spec 작성 시점에는 비어 있는 게 정상. workStatus는 "방금 만든
 - 의존: spec [회원가입] 의 users 테이블 스키마 확정 필요
 
 ### D-2 (06-03)
-- 로그인 폼 UI 구현 완료 (Task: 491be2f9)
+- 로그인 폼 UI 구현 완료
 - React Hook Form + Yup
 - [DECISION] 비밀번호 표시 토글은 input 우측 아이콘으로
 
@@ -111,7 +111,7 @@ spec 작성 시점에는 비어 있는 게 정상. workStatus는 "방금 만든
 | 잘못된 위치 | 진짜 위치 |
 |---|---|
 | AC/완료 보고 ("로그인 통과 확인") | SQA 항목 |
-| 작업 정의 ("Firebase Auth 연결할 것") | tasks[].description |
+| 작업 범위 정의 ("Firebase Auth 연결할 것") | spec 본문(content/logic) |
 | 영구 도메인 규칙 ("5회 실패 시 잠금") | logic.businessRules |
 | 화면 인터랙션 ("입력 → 검증") | ui.interactionMap |
 | 컬럼 스펙 | db-tables 문서 |
@@ -169,9 +169,8 @@ workStatus는 spec마다 컨텍스트가 다르므로 한 줄짜리 일괄 갱
 
 | 필드 | 라이프사이클 | 작성자 |
 |---|---|---|
-| `tasks[]` | spec 작성 시 정의, 개발 중 토글 | 작성자(설계) + 개발자(체크박스/모달) |
-| `tasks[].description` | spec 작성 시 정의 | 작성자 |
-| `ui` / `logic` / `dbTableRefs` | spec 작성 시 정의 | 작성자 |
+| `content` / `ui` / `logic` / `dbTableRefs` | spec 작성 시 정의 | 작성자 |
+| `points` (Story Point) | spec 작성 시 규모 산정 | 작성자 |
 | **`workStatus`** | **개발 진행 중 누적** | **개발자(자기 자신)** |
 | SQA 항목 | 개발 완료 시점 검증 | QA |
 | `status` | SQA 통과 후 변경 | 작성자/리더 |