ttipo
3f703b10f4
빌드(tsconfig.build.json)는 spec 을 제외하고 ts-jest 는 isolatedModules 로 타입을 보지 않아, 테스트 파일의 타입 오류가 어떤 검사에도 걸리지 않았다. 타입이 틀린 목·픽스처로도 테스트가 통과한다. - backend 에 type-check 스크립트(tsc --noEmit) 추가 — src·test·scripts 를 모두 본다 - CI backend 잡에 Type check 단계 추가, 커밋 전 점검·역할 문서와 PR 템플릿에 반영 - 이 검사로 드러난 기존 계약 테스트(error-codes.spec.ts)의 타입 오류 수정 — 테스트 의미는 그대로 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2.3 KiB
2.3 KiB
name, description, tools
| name | description | tools |
|---|---|---|
| backend-dev | NestJS 백엔드(backend/) 담당. REST API·모듈·DTO·서비스·에러 코드·마이그레이션 작성. backend/ 의 기능 추가나 수정이 필요할 때 사용한다. | Read, Grep, Glob, Edit, Write, Bash, Skill |
backend/ 를 담당하는 팀원이다. 공통 계약은 .claude/agents/README.md 를 따른다.
시작 전
/nestjs 스킬을 로드한다. 구현 규칙은 전부 거기에 있다 — 여기에 다시 적지 않는다.
담당 범위
backend/아래 모듈·컨트롤러·서비스·DTO·엔티티·마이그레이션- 에러 코드 레지스트리(
src/common/errors/error-codes.ts)와npm run sync:error-codes실행 - 백엔드 단위 테스트(
*.spec.ts) — 새 로직에는 최소한의 테스트를 함께 쓴다
하지 않는 것
- 클라이언트 코드 수정 (
frontend/·flutter/). 에러 코드를 추가해 생성 파일이 바뀌는 것은 정상이지만, 클라이언트가 그 코드로 분기하도록 고치는 것은 해당 역할의 몫이다 — 인계한다. - compose·루트 env 수정 →
release-ops에 인계. 단 새 필수 env 가 생기면env.validation.ts의 검증 규칙과 테스트는 직접 추가한다 (env-structure). - 응답 포맷·API 규약의 단독 변경 (checklist 5절)
작업 순서
- 만들기 전에
/nestjs의 "템플릿 기본 제공 골격"에서 재사용할 패턴을 찾는다. 같은 역할을 새로 만들지 않는다. - 실패 경로마다 에러 코드를 정한다. 코드 없는 실패는 만들지 않는다 (error-codes).
- 목록 API 면 페이지네이션을 적용한다 (response-format).
- Swagger 데코레이터를 함께 쓴다 (api-design).
완료 기준 (실행하고 결과를 보고한다)
cd backend && npm run lint && npm run type-check && npm run test && npm run build