felipevale23/sddkit

/sdd-stack

입력: $ARGUMENTS. 스택에 대한 인터뷰를 진행하며, 사용자가 요약을 확인한 후에만 파일을 작성합니다.

0. 질문 전: 사실을 먼저 파악하세요

환경에 대한 사실은 당신의 작업이며, 절대 사용자에게 묻지 마세요. 다음을 확인하거나 하위 에이전트에 위임하세요:

• 기존 매니페스트 및 코드 (package.json, pyproject.toml, go.mod, Dockerfile, .github/workflows/, 최상위 폴더);
• .agents/specs/stack.md 및 architecture.md (이미 작성되어 있고 --revisar 옵션이 없다면 요약을 보여주고 누락된 부분만 질문);
• .specify/memory/constitution.md (이미 결정된 제약 사항, 예: LGPD, 단일 데이터베이스);
• sddkit suggest --json (감지된 스택).

코드에 이미 결정된 사항은 질문이 아닌 결정된 사항으로 처리합니다.

1. 방법

• 스킬 grilling이 .agents/skills/에 설치되어 있음 → 해당 스킬의 방법을 따릅니다 (의사 결정 트리의 경계를 따라 라운드 진행, 각 질문에 권장 답변 제시, 경계가 사라질 때까지).
• 설치되지 않음 → 동일한 형식: 각 라운드마다 전제 조건이 이미 충족된 모든 질문을 번호를 매겨 제시합니다:

❓ **Q1 — <제목>**: <질문, 2-4개 옵션과 각각의 트레이드오프를 1줄로>

➡️ <권장 사항과 그 이유, 1-2줄>

각 질문은 "예"라고 답하면 권장 사항을 수락하는 방식으로 작성하세요. 최신 기술보다는 팀이 이미 알고 있는 안정적이고 성숙한 기술을 선호하세요. 강력한 이유가 없다면 프로젝트 전체에 하나의 언어를 사용하고, 범위를 충족하는 최소한의 구성 요소를 사용하세요 (서비스 하나 추가는 운영 비용 증가). 답변이 이전 답변이나 헌법과 모순된다면 지적하고 어느 것이 우선인지 질문하세요.

2. 스택 의사 결정 트리

다음 의존성 순서대로 진행하세요. 해당하지 않는 가지는 건너뜁니다 (예: UI 없음 → 프론트엔드 질문 없음).

1. 제품: 무엇인가 (웹 앱, API, 모바일 앱, 데스크탑, CLI, 라이브러리, 워커), 사용자, 예상 규모 (사용자, 데이터, 피크), 제약 사항 (LGPD, 오프라인, 비용, 기한).
2. 팀: 팀이 익숙한 언어, 유지보수 담당자.
3. 형태: 모듈형 모놀리스, 모노레포 패키지 또는 분리된 서비스; 비동기가 필요한 부분.
4. 언어 및 런타임 (주 버전): 예: TypeScript/Node 22, Python 3.12.
5. 프론트엔드 (UI가 있는 경우): 프레임워크 (React/Next, Vue/Nuxt, Svelte, Astro…), 렌더링 방식 (SPA, SSR, 정적), 컴포넌트 및 스타일 라이브러리 (MUI, shadcn+Tailwind…), 서버 상태 관리 (TanStack Query…), i18n, 접근성.
6. 모바일/데스크탑 (있는 경우): 네이티브, React Native/Expo, Flutter, Tauri, Electron.
7. 백엔드/API: 프레임워크 (Express, Fastify, NestJS, Hono, FastAPI, Django…), 스타일 (REST, GraphQL, tRPC), 계약 및 유효성 검사 (Zod, Pydantic, OpenAPI). 7b. 백엔드 패러다임 (백엔드가 있는 경우에만; 절대 프론트엔드에는 적용하지 않음, 프론트엔드는 프레임워크 관용어를 따름):
   • 스타일: OOP with SOLID (불변 조건을 가진 엔티티, 인터페이스에 의존하는 서비스), 함수형 (순수 함수, 불변 데이터, 경계에서의 효과) 또는 실용적 (단순 모듈, 2개 이상의 구현이 있을 때만 추상화 — ponytail의 기본값).
   • 아키텍처: 단순 계층 (controller → service → repository), 클린/헥사고날 (프레임워크 의존성이 없는 도메인, 포트 및 어댑터) 또는 DDD (바운디드 컨텍스트, 애그리게이트). 도메인이 감당할 수 있는 가장 단순한 것을 권장: 클린/DDD는 풍부한 비즈니스 규칙이 있을 때만.
   • 어떤 폴더가 백엔드인지 (예: server/**, services/**, modules/**). 이것이 패러다임을 백엔드로 제한합니다.
8. 데이터: 데이터베이스 (PostgreSQL, MySQL, MongoDB, SQLite), ORM/액세스 (Prisma, Drizzle, SQLAlchemy…), 마이그레이션, 캐시.
9. 비동기: 대기열/작업 (BullMQ, Celery, pg-boss…), 이벤트, 실시간 (WebSocket/SSE).
10. 인증 및 인가: 제공자 또는 자체 구현, 세션/JWT, 역할/권한.
11. 외부 통합: 결제 (PIX…), 이메일, AI (Anthropic SDK…), MCP.
12. 호스팅 및 운영: 실행 위치 (Vercel, Docker VPS, 관리형 클라우드), 환경, 시크릿, 관찰 가능성 (로그, 오류, 메트릭).
13. 품질: 테스트 (단위, 통합, Playwright를 사용한 E2E), 린트/포맷, 타입체크, CI (GitHub Actions), 커밋 (Conventional Commits/commitlint).

3. 확인

경계가 비워지면 표(계층 · 선택 · 버전 · 이유 · 기각된 대안)로 요약을 보여주고 "이대로 확정할까요?"라고 질문하세요. "예"라고 답하기 전에는 아무것도 작성하지 마세요.

4. 기록

1. .agents/specs/stack.md: 내용을 다음으로 대체하세요 ([PREENCHER 마커 포함):
   • ## Por componente — 각 계층의 기술, 주 버전 및 주요 라이브러리를 패키지 이름으로 표시 (예: react, @prisma/client, bullmq, fastapi): sddkit이 이 이름을 사용하여 역할과 스킬을 제안합니다;
   • ## Infraestrutura — 데이터베이스, 대기열, 캐시, 호스팅, CI, 관찰 가능성;
   • ## Decisões — 각 중요한 선택과 그 이유 및 기각된 대안 (오늘 날짜).
2. .agents/specs/architecture.md: ## Visão geral 섹션을 작성하세요 (구성 요소와 그들이 통신하는 방식; 2개 이상의 구성 요소가 있으면 mermaid 다이어그램) 그리고 [PREENCHER를 제거하세요. 이미 코드가 있으면 ## Mapa do código도 작성하세요 (영역별 한 줄: 진입점, 주요 폴더, 테스트). 나머지 섹션은 코드가 생기면 작성합니다.
3. 백엔드 패러다임 (7b에서 결정되었고 "실용적"이 아닌 경우):
   • .agents/specs/coding-standards.md: ## Backend — paradigma 섹션에 스타일, 아키텍처, 백엔드 폴더, 3-5개의 구체적인 규칙과 각각의 짧은 예제, 그리고 규칙을 적용하는 도구를 포함하세요. 프론트엔드는 이 섹션을 따르지 않음을 명확히 하세요.
   • 모든 세션에서 에이전트가 범위를 알 수 있도록 sddkit 메모리:

     sddkit memory add "패러다임 <스타일>/<아키텍처>는 백엔드(<폴더>)에만 적용; 프론트엔드에서는 프레임워크 관용어를 따르세요" -t paradigma
     sddkit memory add "백엔드에서는 coding-standards.md의 'Backend — paradigma' 섹션이 인터페이스 및 계층에 대한 ponytail을 재정의합니다" -t paradigma
     sddkit memory add "<가장 중요한 구체적인 규칙>" -t paradigma-backend --paths "<백엔드 폴더>"
     

   • 스킬 (카탈로그에서 선택 사항이며, 백엔드 역할 api, data, event-module, queue-worker에 의해서만 로드됨): OOP/SOLID → sddkit add solid; clean/hexagonal → sddkit add clean-architecture; DDD → sddkit add domain-driven-design. 함수형: 좋은 일반 스킬은 없음; coding-standards.md의 규칙과 린트가 그 역할을 합니다.
   • 결정론적 강제 (백엔드 폴더로 제한된 린트; 아직 코드가 없으면 /sdd-feature 설정의 첫 번째 작업이 됨):
     • 계층/클린/헥사고날/DDD: dependency-cruiser 또는 eslint-plugin-boundaries (TypeScript), import-linter (Python) — 도메인이 인프라나 프레임워크를 임포트하지 않음;
     • TypeScript 함수형: files: ["<백엔드 폴더>"]가 있는 ESLint 블록의 eslint-plugin-functional (클래스 없음, 변이 없음, let 없음);
     • OOP: OOP를 요구하는 린터는 없음; 위의 계층 규칙과 코드 리뷰를 사용하세요.
4. 헌법: 타협할 수 없는 제약 사항이 발생한 경우 (예: "PostgreSQL이 유일한 진실 공급원"), 텍스트를 제안하고 /speckit-constitution을 제안하세요 — 헌법을 직접 편집하지 마세요.
5. 사용자에게 터미널에서 다음을 실행하라고 알리세요:

   sddkit init        # 선언된 스택을 읽고 해당 역할과 스킬을 제공합니다 (기존 항목은 삭제되지 않음)
   sddkit doctor
   

최종 보고서 (≤ 8줄)

계층별 한 줄씩 결정된 스택 · 백엔드 패러다임 및 강제 방법 · 기록된 파일 · 헌법에 제안된 제약 사항 · 다음 단계 (sddkit init, 그 다음 /sdd-feature).