Datepop Ticket Workflow

주의:

• 레포 기본값은 힌트일 뿐이다.
• 실제 생성/수정 전에는 반드시 live Notion schema를 다시 조회해 유효한 옵션인지 확인한다.
• 예전 문서의 웹 프론트 같은 표현을 그대로 쓰지 말고 live schema에서 허용하는 값으로만 기록한다.

Naming Rules

• 브랜치 타입은 feat, fix만 허용한다.
• 브랜치 포맷:
  • feat/DPN-{작업키}-{short-summary}
  • fix/DPN-{작업키}-{short-summary}
• 커밋 포맷:
  • [DPN-{작업키}] {change-summary}
• PR 제목 포맷:
  • [DPN-{작업키}] {short-summary}

브랜치 slug는 ASCII 소문자와 -만 사용한다.

Branch 세부 규칙

• short-summary는 ASCII slug 사용
• 소문자만 사용
• 단어는 -로 연결
• 너무 길면 핵심 의미만 남긴다

예시:

• feat/DPN-153-banner-exposure-rule
• fix/DPN-188-login-token-refresh

Commit 예시

• [DPN-153] 홈 배너 노출 조건 추가
• [DPN-188] 로그인 토큰 갱신 오류 수정

PR Title 예시

• [DPN-153] 홈 배너 노출 조건 추가
• [DPN-188] 로그인 토큰 갱신 오류 수정

Type Mapping

• feat
  • 기능 추가
  • 기능 개선
  • 운영/개발 효율 개선
• fix
  • 버그 수정
  • 잘못된 동작 수정
  • 장애 대응
  • 예외 처리 보완

기본 매핑:

• feat -> 종류=작업
• fix -> 종류=이슈

확신이 낮으면 자동 확정하지 말고 질문한다.

Notion Safety Rules

DB 검증

• 생성 또는 수정 전 notion-fetch로 개발 작업 DB와 data source를 검증한다.
• parent.data_source_id가 live 검증되지 않으면 notion-create-pages를 호출하지 않는다.
• DB row 생성이 보장되지 않으면 standalone page fallback을 절대 허용하지 않는다.
• 작업명 title property, 필수 속성, 옵션명이 live schema와 일치하는지 확인한다.
• 티켓 생성 후 반환된 페이지를 다시 fetch해서 실제로 개발 작업 DB 소속인지 검증한다.
• 검증 실패 시 생성 성공으로 보고하지 말고 즉시 중단 후 원인을 설명한다.

중복 방지

• 새 티켓 생성 전에는 반드시 기존/유사 티켓을 검색한다.
• 유사 티켓이 있으면 새로 만들기보다 기존 티켓 보강 가능성을 먼저 제안한다.
• 검색이 실패해 중복 방지를 수행하지 못한 경우 그대로 새 티켓을 생성하지 않는다.

Person 속성

• 담당자는 사용자 명시 없이는 자동 입력하지 않는다.
• 새 티켓은 담당자가 확정되기 전까지 생성하지 않는다.
• 관찰자는 매번 질문하되 선택 입력으로 취급한다.
• person 속성은 live Notion user lookup으로 단일 매칭이 확인된 경우에만 쓴다.
• user lookup이 실패하거나 다중 매칭이면 재확인하고 확정 전까지 person 속성을 수정하지 않는다.

Notion Field Mapping

Identifier

• 티켓 표기 ID: DPN-{작업키}
• 실제 기준값: Notion 작업키

Auto-filled Properties

주의:

• 아래 매핑은 참고용이다.
• 실제 생성/수정 직전에는 반드시 live Notion schema를 fetch해서 property name과 option name을 다시 확인한다.
• 특히 환경 값은 예전 표현인 웹 프론트가 아니라 live schema의 프론트를 기준으로 검증한다.

작업명

• 입력: 작업 설명
• 규칙: 설명을 짧고 명확한 실행 단위 제목으로 정리한다.

종류

• 입력: 브랜치 타입
• 매핑:
  • feat -> 작업
  • fix -> 이슈

진행 상태

• 새 티켓 생성: 백로그
• 작업 시작: 작업 중
• PR 연결: 리뷰 중
• QA 단계: QA
• 완료: 완료

담당자

우선순위:

1. 사용자 명시 입력
2. 기존 티켓 담당자 유지
3. 사용자 확인

규칙:

• 새 티켓에서는 필수값이다.
• 실행 사용자가 누구인지 알아도 자동으로 넣지 않는다.
• 이름/이메일/self reference를 live user lookup으로 검증한 뒤 단일 매칭일 때만 반영한다.
• 매칭 실패 시 새 티켓 생성을 중단한다.

관찰자

우선순위:

1. 사용자 명시 입력
2. 기존 티켓 관찰자 유지
3. 비움

규칙:

• 매번 추가 여부를 질문한다.
• 선택값이므로 비워둘 수 있다.
• live user lookup으로 단일 매칭될 때만 반영한다.
• 매칭 실패 시 자동 추가하지 않는다.

환경

우선순위:

1. 레포 기본값
2. 작업 설명 기반 보정
3. 사용자 확인

현재 live schema 기준 허용값:

• 안드로이드
• iOS
• 프론트
• 백엔드
• 크롤링
• 데브옵스

플랫폼

우선순위:

1. 레포 기본값
2. 작업 설명 기반 보정
3. 사용자 확인

현재 live schema 기준 property key:

• \b플랫폼

Semi-auto Properties

작업순서

• 기본값: 중
• 긴급/장애/핵심 매출 영향 표현이 있으면 질문한다.

태그

• 설명에 명확한 키워드가 있을 때만 자동 선택한다.
• 애매하면 질문한다.

예상마감일

• 설명이나 입력에 일정 정보가 없으면 질문한다.

Body Template

## 배경
- 왜 필요한지

## 목표
- 어떤 결과를 원하는지

## 범위
- 포함 범위
- 제외 범위

입력에 없는 사실은 추측하지 않는다.

Interview Flow & Question Policy

Decision Order

값 결정 우선순위:

1. 사용자 명시 입력
2. live Notion schema 제약
3. 레포 기본값
4. 작업 설명의 명시적 단서
5. 기존 티켓의 현재 값
6. 사용자 확인

Interview Flow

1. 새 티켓인지 기존 티켓 보강인지 판단한다.
2. .datepop/ticket-workflow.json을 읽는다.
3. live Notion DB/data source를 fetch해서 title property, 필수 속성, 옵션을 검증한다.
4. 작업 설명을 보고 feat 또는 fix를 판정한다.
5. 자동 입력 가능한 값을 먼저 채운다.
6. 기존/유사 티켓을 검색한다.
7. 담당자를 반드시 확인하고 관찰자 추가 여부도 반드시 질문한다.
8. person 값이 필요하면 live user lookup으로 단일 매칭을 검증한다.
9. 애매한 값만 짧게 단계별 질문한다.
10. 검증이 모두 통과한 경우에만 Notion을 갱신한다.
11. 갱신 후 생성/수정된 페이지를 다시 fetch해 DB 소속과 핵심 속성 반영 여부를 검증한 뒤 결과를 반환한다.

Output

최종 결과에는 항상 아래를 포함한다.

• 티켓 ID
• 노션 반영 내용
• 브랜치명
• 커밋 메시지
• PR 제목
• 추가 확인 필요 항목

Question Policy

질문은 최소화한다.

아래 경우에만 질문한다.

• feat와 fix 판정이 애매한 경우
• 레포 기본값과 작업 설명이 충돌하는 경우
• 담당자, 작업순서, 예상마감일, 태그가 중요하지만 불명확한 경우
• 유사 티켓이 검색되어 새 티켓 생성과 기존 티켓 보강 중 선택이 필요한 경우
• live schema와 사용자 표현이 달라 안전한 정규화가 필요한 경우
• 담당자 또는 관찰자가 Notion 사용자로 단일 매칭되지 않는 경우

질문 방식:

• 긴 폼 대신 짧은 단계형 질문을 우선한다.
• 이미 추론 가능한 값은 초안으로 제안하고 틀린 값만 수정받는다.
• 검증 실패 상태에서는 추가 생성 작업을 진행하지 않는다.