lenneTech/grilling-decisions

미결 결정 분석 (Grilling Open Decisions)

사용자가 계획, 티켓 또는 디자인에 대해 완전히 동의할 때까지 끊임없이 질문합니다. 목표는 작업 시작 전에 의견을 일치시키는 것입니다. 잘못된 가정 위에 구축된 변경 사항은 전체 구현 비용은 물론 리뷰, 브라우저 워크, 병합까지 모두 낭비하게 됩니다. 초기에 한 번 묻는 질문은 클릭 한 번으로 끝나지만, 구현 중에 같은 질문을 하면 사용자의 맥락 전환을 유발하고, 사용자가 돌아올 때까지 실행이 지연됩니다.

사용자가 공동 이해를 확인할 때까지 분석 대상에 대해 어떠한 조치도 취하지 마십시오.

루프

1. 모든 사실을 스스로 확인하십시오 (사실 vs 결정 참조). 이미 코드를 알고 있는 상태로 인터뷰에 임하십시오.
2. 결정 트리를 매핑하십시오. 모든 미결 결정은 그에 종속된 결정들로 분기됩니다.
3. 티켓과 증거가 결정하는 바를 확정하십시오. 결정 브리핑의 다섯 부분을 통해 모든 미결 결정을 처리하십시오. 티켓이 명확히 명시한 사항은 그대로 기록하고, 증거가 정확히 하나의 옵션만 남긴 간격은 Beleg: 줄과 함께 기록하며, 나머지는 모두 사용자에게 맡깁니다 (확정 또는 질문).
4. 모든 남은 질문을 소스에 대해 다시 확인하십시오 (질문 전 재확인). 소스가 이미 답변한 질문은 사용자에게 필요 없는 결정을 강요하게 됩니다.
5. 최전선 질문을 하나의 라운드로 제시하십시오. 최전선이란 선결 조건이 이미 확정된 모든 미결 결정, 즉 지금 답을 추측하지 않고 물어볼 수 있는 질문들입니다. 이번 라운드에서 아직 답을 듣지 못한 다른 질문에 종속된 질문은 이후 라운드에 속합니다.
6. 각 질문을 브리핑과 함께 제시하십시오. 브리핑은 권장 사항으로 끝나므로, 사용자가 코드를 먼저 읽거나 처음부터 설계를 구성할 필요 없이 사실을 한눈에 보고 한 번의 클릭으로 결정할 수 있습니다.
7. 각 라운드 후 최전선을 재계산하십시오: 확정된 결정은 최전선을 확장하고, 이에 종속되었던 질문을 차단 해제하며, 종종 질문을 제거하거나 증거만으로 충분히 명확해지게 만듭니다. 다음 라운드를 위해 다시 확인하고 질문하십시오.
8. 최전선이 비어 있으면 중단하십시오: 모든 분기를 방문했고, 조용히 가정된 것은 아무것도 없습니다. 결정 기록을 작성하고 사용자가 확인하도록 하십시오.

확정 또는 질문

티켓(또는 분석 대상인 계획이나 명세)은 명령이며 우선권을 가집니다: 명확히 명시된 사항은 가능한 한 정확하게 그대로 구현됩니다. 티켓은 종종 부정확하거나, 모순되거나, 사항을 누락하며, 이러한 지점이 결정되어야 할 부분입니다. 사용자가 결정해야 하는 사항이 적을수록 좋으며, 불명확한 모든 사항은 사용자의 몫입니다. 결정 브리핑이 경계를 그립니다: 모든 미결 결정에 대해 아무에게도 묻기 전에 브리핑을 작성하고, 그 결과에 따라 지점을 세 가지 경우 중 하나로 분류하십시오.

1. 티켓이 명확히 답변하는 경우: 작성된 대로 구현하십시오. 해당 지점은 확정되며 [Ticket <ID>]로 표시됩니다. 인접 기능이 다르게 수행하거나 자신이 다른 선택을 했더라도 마찬가지입니다. 아무도 묻지 않습니다.

2. 티켓이 부정확하거나, 모순되거나, 결과를 누락한 경우: 사용자가 결정합니다. 다음 경우에 브리핑과 함께 질문하십시오: 문구가 두 가지로 해석되거나 '완료'의 의미가 불명확할 때; 설명, 댓글, 승인 기준, 설계가 서로 다를 때; 현재 코드에 대한 티켓의 묘사가 실제 코드와 다를 때; 또는 문자 그대로 따르면 티켓에 언급되지 않은 부분(다른 기능이 의존하는 동작, 보안, 기존 데이터)을 손상시킬 때. 티켓의 의미는 사용자의 판단에 달려 있으므로, 자신이 한쪽으로 기울더라도 이러한 사항은 사용자에게 전달됩니다.

3. 티켓이 아무 말도 하지 않는 경우: 증거가 명확할 때 간격을 확정하고, 그렇지 않으면 질문하십시오. 다음 조건이 정확히 하나의 옵션에 해당할 때 스스로 확정하십시오:

• 다른 소스(링크된 문서, 설계, 프로젝트 문서)가 답변을 제공하거나, 코드가 이 정확한 사례를 하나의 확립된 방식으로 처리하는 경우 (path:line),
• 소스나 코드에서 다른 방향을 가리키는 것이 없는 경우,
• 다른 옵션이 합리적으로 더 높게 평가될 수 있는 이점이 없는 경우, 그리고
• 지속적인 영향(데이터 모델, 마이그레이션, 권한 기본값, 다른 모듈이나 팀에서 사용하는 계약)이 없는 경우. 이러한 사항은 티켓이 침묵할 때마다, 자신의 추론이 아무리 확신하더라도 사용자에게 전달됩니다.

확정된 간격은 Beleg: 줄에 증거와 함께 Annahme로 기록하고 (결정 기록), 사용자는 기록을 확인할 때 이를 보고 뒤집을 수 있습니다. 다른 모든 간격은 브리핑과 함께 사용자에게 전달되며, 자신이 확신하지 못하는 모든 지점도 마찬가지입니다: 지점이 명확한지에 대한 의심은 그것이 명확하지 않다는 것을 의미합니다.

질문 전 재확인

사용자에게 도달하는 질문은 결정을 요청하는 것이므로, 라운드가 나가기 전에 해당 질문을 염두에 두고 소스로 돌아가십시오. 첫 번째 읽기는 요구 사항을 찾기 위한 것이었습니다. 이번 읽기는 특정 질문에 대한 답변을 찾기 위한 것이며, 일반적인 읽기에서 놓칠 수 있는 것을 발견합니다: 댓글 스레드 깊숙한 곳의 답변, 디자인의 두 번째 프레임, 한 가지 방식으로만 작동하는 승인 기준 등.

1. 티켓을 다시 전체적으로 읽으십시오, 라운드의 질문을 염두에 두고: 설명, 승인 기준, 모든 댓글과 답변(가장 최근 것만이 아님), 그리고 그 안의 이미지.
2. 각 질문의 용어에 대해 다른 소스를 검색하십시오, 독일어와 영어로 그리고 동의어(해당 엔터티, 필드, 역할, 화면 또는 상태)를 사용하여: 상위, 하위 및 연결된 이슈, 첨부 문서, 이전 결정 댓글 및 질문 문서, 디자인의 모든 프레임과 상태, 흐름, 프로젝트 문서.
3. 이미 확정된 사항에서 도출되는 답변을 찾으십시오: 하나의 옵션으로만 작동하는 다른 승인 기준, 이 분석에서 이전에 내린 결정, 티켓이 변경하지 않은 동작을 이미 고정하는 테스트 또는 검증.

그런 다음 각 질문을 확정 또는 질문에 따라 다시 분류하십시오: 티켓이 명확히 명시한 답변은 작성된 대로 확정합니다. 다른 소스의 답변은 Beleg:와 함께 간격을 확정할 수 있습니다. 재확인 중 발견된 모순은 이제 두 인용문과 함께 질문으로 남습니다. 오직 살아남은 질문만이 라운드에 들어가며, 브리핑의 3부는 재확인이 다룬 내용을 명시하여 사용자가 질문이 실제임을 알 수 있도록 합니다.

결정 브리핑

이 순서대로 다섯 부분으로 구성되며, 각 부분은 이 세션에서 수집한 증거(브랜치의 현재 코드, 오늘 날짜의 소스)를 기반으로 답변됩니다.

1. Ist-Stand im Code (코드의 현재 상태): 결정이 적용되는 지점의 코드가 오늘날 수행하는 작업과 path:line. 아직 존재하지 않는 항목에 대해서는 그렇게 말하고 조사한 위치를 명시합니다. 티켓이 현재 동작을 코드와 다르게 설명하는 경우, 둘 다 명시하십시오: 그 차이가 종종 실제 질문입니다.
2. Geplante Änderung (계획된 변경 사항): 무엇이 변경, 추가 또는 제거되는지, 어떻게, 왜(이를 요구하는 승인 기준 또는 소스)인지 설명합니다. 이미 확정된 사항과 옵션이 결정하는 분기를 분리하십시오.
3. Ticket und Quellen (티켓 및 소스): 티켓, 그 댓글, 연결된 티켓 및 문서, 디자인 및 프로젝트 문서가 이 지점에 대해 말하는 내용을 티켓을 먼저, „…“ 안에 축어적으로 인용하고 출처(티켓 및 섹션, 댓글 날짜, 문서 제목, Figma 노드, CLAUDE.md:<line>)를 괄호 안에 표시합니다. 단락이 아닌 중요한 문장을 인용하십시오. 소스가 일치하지 않는 경우, 각 측을 인용하십시오. 어떤 소스도 지점을 다루지 않는 경우, 그렇게 말하고 재확인이 다룬 내용을 나열하십시오: 그 침묵이 왜 이것이 질문인지입니다.
4. Optionen (옵션): 2~4개, 질문이 제공하는 동일한 옵션들로, 각각 구체적인 의미, 장점, 단점 및 영향: 수정되는 파일 및 모듈, 기존 데이터, 다른 역할 또는 소비자, 테스트, 노력, 그리고 나중에 되돌리기 어려운지 여부. 프레임워크가 이미 제공하는 옵션도 그중 하나입니다.
5. Empfehlung (권장 사항): 선택할 옵션과 그 이유, 1~3부를 근거로 설명합니다.

각 부분을 한 줄에서 세 줄로 유지하십시오: 브리핑은 하나의 결정을 위한 맥락이지 보고서가 아닙니다. 브리핑을 작성하는 것은 확정 또는 질문의 테스트이기도 합니다: 3부에서 지점에 답변하는 인용문을 찾거나, 1부에서 코드가 이미 결정했음을 보여주면, 해당 지점은 확정되어 라운드에서 제외됩니다.

**F1 송장 삭제 동작**

1. **Ist-Stand im Code:** `InvoiceService.delete()`는 `deleteOne`으로 하드 삭제(`projects/api/src/server/modules/invoice/invoice.service.ts:88`)하지만, 지금까지는 어디에서도 호출되지 않습니다. `Payment.invoice`는 송장을 참조합니다(`payment.model.ts:31`). 프로젝트에는 두 가지 패턴이 모두 있습니다: `Order`는 `deletedAt`을 통한 소프트 삭제(`order.service.ts:54`), `Customer`는 하드 삭제(`customer.service.ts:71`).
2. **Geplante Änderung:** 관리자는 송장 목록에서 삭제 작업을 받습니다 (AK 3): 새 엔드포인트 `DELETE /invoices/:id`, `InvoiceList.vue`의 버튼. 누가 삭제할 수 있는지는 확정되었으며, 레코드가 사라지는지 여부는 미정입니다.
3. **Ticket und Quellen:**
   - „관리자는 잘못된 송장을 삭제할 수 있어야 합니다.“ (DEV-1234, 설명)
   - "삭제는 관리자만 가능합니다." (DEV-1234, 2026-10-02 댓글)
   - 삭제된 송장이 유지되는지에 대해서는 소스에서 확인할 수 없습니다 (확인된 사항: 설명, 댓글 3개, Figma 노드 12:345, `docs/`).
4. **Optionen:**
   - **A 소프트 삭제** `deletedAt` 사용, `Order`와 같이. 장점: 기록 및 `Payment` 참조가 유효하게 유지됩니다. 단점: 모든 쿼리에 필터가 필요합니다. 영향: 모델, 서비스 및 세 개의 목록 쿼리가 변경됩니다. 마이그레이션은 필요 없으며, 필드는 선택 사항입니다.
   - **B 하드 삭제**, `Customer`와 같이. 장점: 추가 필드 없음, 필터 없음. 단점: 송장이 영구적으로 사라집니다. 영향: `Payment` 참조가 끊어져 별도 처리가 필요합니다.
5. **Empfehlung:** A, 결제가 송장을 참조하고 삭제된 송장을 추적할 수 없게 되기 때문입니다.

티켓은 침묵하고, 프로젝트에는 두 가지 선례가 있으며, 선택이 데이터 모델을 결정하므로 이 간격은 사용자에게 전달됩니다. 설명에 "삭제된 송장은 저장되고 숨겨집니다"라고 명시되어 있었다면 티켓이 해결했을 것입니다: 소프트 삭제, 작성된 대로 구현, [Ticket DEV-1234] 표시, 질문 없음. 댓글이 반대를 요구했다면 모순이 사용자에게 전달되었을 것이며, 두 인용문이 3부 아래에 표시됩니다.

라운드 형식

AskUserQuestion을 사용하십시오: 라운드당 한 번 호출, 최대 4개의 질문, 각 질문은 권장 옵션을 먼저 접미사 (Recommended)와 함께 표시하고, 각 옵션의 설명은 영향을 한 줄로 나열합니다. 자동 제공되는 "기타" 항목은 자유 텍스트 답변을 처리합니다. 최전선에 4개 이상의 질문이 있는 경우, 가장 상류의 질문을 먼저 물어보십시오. 그 답변은 일반적으로 나머지 중 일부를 제거합니다.

라운드의 브리핑은 호출과 동일한 메시지에, 바로 앞에 F1, F2, …로 번호를 매겨 배치하여 사용자가 질문이 열려 있는 상태로 읽을 수 있도록 합니다.

사용자만 알고 있는 사실(관찰한 내용, 사용한 계정) 또는 워크플로 선택(리뷰 실행, 병합 방법)만 수집하는 질문은 브리핑이 필요 없습니다. 옵션 레이블에 중요한 내용이 포함되어 있습니다.

AskUserQuestion 없이(일반 채팅, 비대화형 러너) 실행하는 경우, 같은 형식으로 라운드를 인쇄하고 답변을 기다리십시오.

사실 vs 결정

사실을 찾는 것은 당신의 임무입니다. 읽었어야 할 것을 사용자에게 묻는 것은 인터뷰를 심문처럼 느끼게 만들며, 기억에서 얻은 답변은 리포지토리의 답변보다 신뢰성이 떨어집니다.

스스로 확인	결정 (증거를 통해 확정하거나 질문)
서비스가 이미 허용하는 역할 (@Restricted, @Roles, securityCheck)	허용되어야 하는 역할
엔터티, DTO 또는 생성된 타입의 현재 형태 (types.gen.ts, sdk.gen.ts)	필드가 추가, 이름 변경 또는 교체되는지 여부
엔드포인트, 페이지 또는 컴포저블이 이미 존재하는지 여부	확장할지 아니면 옆에 새로 구축할지
티켓, 그 댓글 및 연결된 Figma 노드가 실제로 말하는 내용	티켓이 모호한 부분에서 의미하는 바
인접 기능이 동일한 문제를 어떻게 해결했는지	이 기능이 그 선례를 따라야 하는지
오늘날 영향을 받는 경로를 다루는 테스트	새 테스트가 위치해야 할 경계점
설명된 결함이 여전히 재현되는지 여부	대신 올바른 동작

질문을 던지기 전에 Read, Grep, Glob, Linear MCP 및 Figma MCP를 사용하십시오. 조회 범위가 넓은 경우, 서브 에이전트에 위임하고 차단하지 마십시오: 실행 중인 조회는 확정되지 않은 선결 조건이므로, 그것에 종속된 질문만 대기하고 나머지 최전선은 지금 질문합니다.

질문 품질

• 해피 패스가 아닌 경계를 탐색하십시오. 빈 값, null, 매우 큰 값, 동시성, 권한 없음, 오프라인. 해피 패스는 모두가 이미 동의하는 부분입니다.
• 티켓보다 오래 지속되는 결과를 표면화하십시오: 나중에 마이그레이션하기 어려운 데이터 모델, 선례가 될 권한 기본값, 다른 팀이 사용할 계약.
• 새로운 nest-server 프로젝트는 이번 라운드에서 데이터베이스를 확정합니다. 티켓이나 루트 CLAUDE.md의 ## Database 섹션에서 데이터베이스 이름을 지정하지 않는 한, 데이터베이스와 SQL 엔진은 질문입니다 (모든 티켓보다 오래 지속됨). generating-nest-servers → reference/choosing-a-database.md의 절차에 따라 브리핑됩니다: 3부의 소스 신호, 5부의 결정 단계, MySQL/MariaDB의 경우 프로젝트가 포기하는 것. 자체 데이터가 있는 새 모듈은 질문 없이 프로젝트 데이터베이스에 남습니다. 소스가 다른 데이터베이스(하이브리드)를 가리킬 때만 질문이 됩니다. 확인된 답변은 결정 기록과 루트 CLAUDE.md의 ## Database에 들어갑니다.
• 구현이 달리 중단될 부분을 다루십시오. 마무리하기 전에 계획된 작업을 머릿속으로 한 번 실행하고 (모델, 엔드포인트, 권한, UI 상태, 테스트), 확정 또는 질문을 통해 달리 멈출 모든 지점을 처리하십시오. 이것이 이후 실행을 질문 없이 만드는 방법입니다.

사용자에게 연락할 수 없는 경우

불명확한 결정은 사용자에게 속하므로, 차단 결정은 대신 응답되지 않습니다.

…

[번역을 위해 잘림]