스파이크 태스크

결정을 내릴 수 있을 만큼 한 가지 질문에 잘 답하세요. 스파이크의 시간 제한 내에서 수행합니다. 산출물은 결정 기록이며, 병합된 코드가 아닙니다.

입력

$ARGUMENTS

티켓, 필수: 트래커 키(예: ENG-130) 또는 로컬 ID(예: T-03)로, 유형이 spike인 티켓을 가리킵니다. 스파이크가 아니면 중단하고 /implement-task를 가리키십시오.
--tasks <file>: 로컬 태스크 파일입니다. 제공되지 않은 경우 프로젝트의 로컬, git-ignored RFC 폴더(예: .rfcs/), 그다음 docs/rfcs/에서 해당 티켓이 포함된 *.tasks.md 파일을 찾습니다.
--branch <name>: 프로토타입이 필요한 경우 분기 이름입니다. 그렇지 않으면 <username>/<project-slug>/spike-<task-branch> 형식을 따르며, /implement-task와 동일한 명명 규칙을 사용합니다.
--unattended: 오케스트레이터에 의해 시작되었습니다. 질문에 답할 사람이 없습니다. 질문하지 마십시오. 질문해야 할 상황에서는 중단하고 보고서에 설명하십시오. 자신의 워크트리에서 작업하십시오.

게시된 경우 트래커에서 티켓을 읽고(트래커가 내용의 진실 공급원임), 그렇지 않으면 태스크 파일에서 읽습니다. 로컬 RFC 및 태스크 파일은 메인 프로젝트 폴더에만 있습니다. 워크트리에 있는 경우 git worktree list(첫 번째 항목)로 찾아 절대 경로로 읽으십시오. 메인 폴더에서 파일을 편집하거나 git 명령을 실행하지 마십시오. 아래 설명된 대로 결정 기록을 작성하는 경우는 예외입니다.

1. 질문 구성

무엇이든 모으기 전에 다음을 적어두십시오:

질문: 답이 있는 한 문장으로 작성하십시오 ("Postgres LISTEN/NOTIFY가 우리 인스턴스 크기에서 2k events/s를 처리할 수 있는가?", "이벤팅을 조사하라"가 아님).
결정이 해결하는 문제: 어떤 결정을 내리는 데 도움이 되는지, 그리고 이에 의존하는 티켓은 무엇인지.
옵션: 결정 중인 옵션들로, "아무것도 하지 않음" 또는 가장 간단한 옵션이 합리적일 때 포함하십시오.
결정 기준: RFC의 DRIVE 섹션(제약, 가치, 필수 결과)에서 가능한 가져와 증거가 팀이 이미 중요하다고 합의한 사항에 대해 판단되도록 하십시오.
시간 제한: 티켓에서 가져옴(기본값: 하루 정도의 노력). 완료는 질문에 답변되었거나 시간 제한이 소진되었을 때 중 먼저 도래하는 시점입니다.

티켓이 질문을 구성하기에 너무 모호하면 중단하고 답변이 필요한 질문과 함께 blocked를 보고하십시오.

2. 증거 수집, 가장 저렴한 것부터

증거가 질문을 해결하는 즉시 중단하십시오. 완전성을 위해 연구하지 마십시오.

코드베이스: 기존 패턴, 제약, 이전 시도, 해당 영역의 주석 및 기록(git log).
1차 출처: 관련 라이브러리 또는 서비스의 공식 문서, 변경 로그, 릴리스 노트, 이슈 트래커. 블로그 게시물보다 우선하십시오. deep-research 스킬을 사용할 수 있고 질문에 광범위한 외부 연구가 필요한 경우 사용하십시오.
측정: 읽기만으로 결정할 수 없을 때(성능, 호환성, "이 API가 정말 그렇게 동작하는가?")는 스파이크 분기에서 최신 main을 기준으로 질문에 답하는 가장 작은 프로토타입 또는 벤치마크를 구축하십시오. 증거를 생성하기 위한 용도로만 존재합니다. 측정에 필요한 테스트 외에는 없으며, 다듬지 않으며, 절대 병합되지 않습니다. 증거를 재현할 수 있도록 분기를 푸시하되 PR을 열지 마십시오.

각 내용을 어떻게 알게 되었는지 추적하십시오: 측정됨(직접 실행), 문서화됨(1차 출처에서 확인), 추정됨(추론). 링크와 파일 경로를 인용하십시오.

3. 권장 사항 결정

증거를 사용하여 각 옵션을 결정 기준에 대해 평가하십시오.
하나의 옵션을 신뢰도와 함께 권장하십시오: 높음(측정 또는 잘 문서화됨), 중간(문서화되었지만 우리 컨텍스트에서 테스트되지 않음), 낮음(대부분 추론).
신뢰도가 낮을 때는 되돌리기 가장 저렴한 옵션을 선호하고, 어떤 신호가 전환하게 할지 말하십시오.
질문에 답변되기 전에 시간 제한이 만료된 경우 명확히 말하십시오: 알려진 내용을 보고하고, 가장 작은 다음 단계(더 좁은 후속 스파이크 또는 진행할 수 있는 되돌릴 수 있는 기본값)를 권장하십시오.

4. 백로그 변경 제안

결정은 일반적으로 계획을 변경합니다. 적용하지 말고 제안만 하십시오:

추가할 티켓: 태스크 파일과 동일한 형식(제목, 범위, 파일, 수락 기준, 종속성)으로 각각 1 스토리 포인트.
변경할 티켓(범위, 기준 또는 종속성) 및 제거할 티켓, 각각 이유와 함께.
업데이트가 필요한 RFC 섹션.

5. 기록 작성 및 보고

templates/decision.md를 사용하여 결정 기록을 <rfc-name>.<ticket-id>.decision.md로 메인 프로젝트 폴더의 태스크 파일 옆에 작성하십시오(거기에 작성하는 유일한 파일). RFC와 마찬가지로 로컬, 추적되지 않는 파일입니다.
티켓이 게시된 경우 트래커 이슈에 짧은 요약을 게시하십시오: 질문, 권장 사항 및 신뢰도, 주요 증거를 3~5줄로 명확히 제안됨, 승인 대기 중으로 표시합니다.
사용자와 직접 작업하는 경우 태스크 파일에서 티켓 상태를 decision-proposed로 설정하고, 권장 사항을 설명한 다음 승인, 다른 옵션 선택 또는 스파이크 연장을 요청하십시오. unattended 모드에서는 상태를 오케스트레이터에 맡기십시오.
다음 보고서로 마무리하십시오:

RESULT: decision-proposed | inconclusive | blocked
TICKET: <local id> / <tracker key or "unpublished">
RECORD: <absolute path to the decision record>
RECOMMENDATION: <one line> (confidence: high | medium | low)
PROTOTYPE: <branch or "none">
NOTES: <backlog changes in one line: +N tickets, ~N changed, -N removed; or why blocked>

스파이크 태스크 수행