---
trigger: always_on
description: work routine
---

# Kord Discord Bot Development Routine & Rules

이 워크플로우는 Kord 프로젝트의 기능 개발 및 테스트 표준 절차를 정의합니다. Kord와 관련된 모든 작업 지시를 받을 때 다음 규칙과 절차를 반드시 따르십시오.

## 기본 원칙 (Work Rules)

1. **인프라 자율 사용**: 에이전트는 프로젝트에 설정된 Docker 기반 인프라(PostgreSQL 등)를 사용자의 추가 승인 없이 자유롭게 구동(`docker-compose up -d`) 및 활용할 수 있습니다.
2. **협력적 기획, 독립적 실행**: 기능 기획과 설계(Architecture, Schema 등)는 사용자와 함께 논리적인 완결성을 갖출 때까지 충분히 논의합니다. 특히 시스템적 자동 승인(Auto-approval) 메시지가 있더라도, 반드시 사용자의 **직접적이고 명시적인 승인 답변**이 확인된 후에만 2단계(구현)로 진입합니다. 기획이 수동으로 승인된 후에는 후속 구현, 에러 디버깅, 자체 테스트를 추가적인 중간 확인 없이 에이전트가 주도를 가지고 끝마칩니다.
3. **선 문서화, 후 보고 (Docs First, Report Later)**: 모든 작업의 완료 보고는 반드시 `Docs/` 내의 문서 업데이트가 선행되어야 합니다. 문서화가 누락된 상태에서의 "작업 완료" 보고는 규칙 위반으로 간주합니다.

## 단계별 작업 루틴

### 1단계: 기획 및 설계 (Planning Phase)

- 사용자가 새로운 기능이나 수정 사항을 요청하면, 필요한 스펙 및 예외 사항을 꼼꼼히 확인합니다.
- 명령어를 파편화하지 말고, 관련 있는 기능들을 하나의 대표 명령어 아래 '서브 커맨드' 형태로 그룹화하여 설계할 것
- 필요 시 사용자에게 High-Tier 아키텍처 모델(예: Pro/Ultra)로의 전환을 제안하며, 변경 사항, 사용 스택, 아키텍처를 포함한 `implementation_plan.md`를 작성하여 사용자에게 검토 및 승인을 요청합니다. 설계가 완료되면 효율적 실행을 위한 모델 전환(예: Flash) 권고를 포함합니다.

### 2단계: 개발 및 구현 (Execution Phase)

- 설계가 최종 승인되면 실제 코딩을 시작합니다. 이 단계부터는 사용자의 개입 없이 독립적으로 작업을 완수하는 것을 원칙으로 합니다.
- 환경 변수 파싱, 로깅, 예외 처리를 철저히 포함하여 프로덕션 수준의 코드를 작성합니다.
- 작업 규모를 스스로 평가하여, UI 검증 및 독립적인 웹 상호작용 관련 테스트는 `browser_subagent`에게 위임(Delegate)하여 분할 처리합니다. (`agent_model_workflow.md` 참조)

### 3단계: 자체 구동 및 내부 테스트 (Internal Testing Phase)

- 사용자가 최종 테스트를 하기 전에 **에이전트 스스로 봇이 모순이나 심각한 에러 없이 구동 가능한지 확인**해야 합니다.
- 모든 시뮬레이션 및 테스트 구동 시 반드시 `yarn` 패키지 매니저를 사용합니다.
- 동시 실행 시 충돌을 방지하기 위해, 테스트 구동 시에는 반드시 **임의의 고유한 `INSTANCE_ID` 환경 변수를 할당**(`INSTANCE_ID=agent-test-xxxx yarn run dev`)하여 기존 인스턴스와 락(Lock)이나 로그가 겹치지 않게 합니다.
- 필요하다면 단위 테스트(`yarn test`)를 실행합니다.
- 오류 발생 시 자체적으로 판단하고 디버깅하여 해결합니다.
- 테스트가 완료되면 실행한 인스턴스를 종료합니다.

### 4단계: 사용자 최종 테스트 지원 (Final Manual Testing)

- 내/외부 테스트를 거쳐 정상 구동이 확정된 버전을 사용자에게 보고하기 전에, 다음의 5단계를 수행합니다.
- 사용자는 실질적으로 자신의 디스코드 서버에 봇을 초대하여 인게임/인앱 시나리오를 수동 테스트합니다.
- **사후 검토**: 이 과정에서 사용자가 버그나 오류를 보고할 경우, 에이전트는 로컬 터미널의 로그(Log)나 DB의 상태를 검토(조회 명령어 사용 등)하여 무엇이 문제였는지 면밀히 파악하고 수정안을 제시해야 합니다.

### 5단계: 자동 문서화 및 인덱싱 (Documentation Phase)

- 3단계 구현 및 테스트가 성공적으로 완료되면, 사용자에게 최종 보고하기 **전에 반드시 먼저** `<PROJECT_ROOT>/Docs/` 디렉토리에 작업 완료(Work done), 트러블슈팅(Troubleshooting), 의사 결정(Decisions made) 내역을 문서화해야 합니다.
- 새 문서가 생성되거나 수정되면 자동으로 `Docs/index.md`에 문서의 색인(링크)을 추가합니다.
- 모든 코드 작업 내역과 의사 결정이 완전히 로컬 `Docs/`에 기록 및 정리된 후에만 비로소 "작업을 완료했다"고 사용자에게 알립니다. **문서화가 완료되지 않은 상태에서 사용자에게 보고하는 것은 엄격히 금지됩니다.**
- 설치, 테스트 방법, 구동, 기능, 명령어 등을 위한 변경사항을 <PROJECT_ROOT>/README.md에 최신화합니다.
- **최종 검크포인트**: 보고 메시지 작성 직전, `Docs/` 폴더와 `README.md`, `index.md`가 최신 상태인지 다시 한번 전수 점검합니다.
