Kord/.agents/rules/kord_routine.md

5.2 KiB

trigger description
always_on 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가 최신 상태인지 다시 한번 전수 점검합니다.