AmanVarshney01/tcut - 변경 계획 수정 도구

변경 사항의 기존 계획 아티팩트를 수정하고 일관성을 유지합니다. 코드를 절대 편집하지 마세요.

저장소 선택: 사용자가 저장소(이 머신에 등록된 독립형 OpenSpec 저장소)를 언급하거나 작업이 저장소에 있는 경우, openspec store list --json을 실행하여 등록된 저장소 ID를 찾은 다음, 사양 및 변경 사항을 읽거나 쓰는 명령(new change, status, instructions, list, show, validate, archive, doctor, context)에 --store <id>를 전달하세요. 다른 명령어는 이 플래그를 사용하지 않습니다. 명령어에 의해 출력되는 힌트에는 이미 플래그가 포함되어 있습니다. 후속 작업에서도 이를 유지하세요. 저장소가 없으면 명령어는 가장 가까운 로컬 openspec/ 루트에서 작동합니다.

입력: 선택적으로 변경 이름을 지정합니다. 생략된 경우 대화 컨텍스트에서 유추할 수 있는지 확인합니다. 모호하거나 불명확한 경우 사용 가능한 변경 사항을 묻는 메시지를 반드시 표시해야 합니다.

단계

1. 변경 이름이 제공되지 않은 경우, 선택을 위해 프롬프트 표시

   openspec list --json을 실행하여 가장 최근에 수정된 순서로 정렬된 사용 가능한 변경 사항을 가져옵니다. 그런 다음 AskUserQuestion 도구를 사용하여 사용자가 업데이트할 변경 사항을 선택하도록 합니다.

   가장 최근에 수정된 상위 3-4개의 변경 사항을 옵션으로 제시하고 다음을 표시합니다.

   • 변경 이름
   • 스키마 (schema 필드가 있으면 해당 필드에서, 없으면 "spec-driven")
   • 상태 (예: "0/5 tasks", "complete", "no tasks")
   • 마지막 수정 시간 (lastModified 필드에서)

   가장 최근에 수정된 변경 사항을 "(Recommended)"로 표시합니다. 사용자가 업데이트하려는 대상일 가능성이 높기 때문입니다.

   중요: 변경 사항을 추측하거나 자동으로 선택하지 마세요. 항상 사용자가 선택하도록 하세요.

2. 변경 사항의 아티팩트 가져오기

   openspec status --change "<name>" --json
   

   JSON을 파싱하여 현재 상태를 이해합니다. 응답에는 다음이 포함됩니다.

   • schemaName: 사용 중인 워크플로우 스키마 (예: "spec-driven")
   • artifacts: 상태("done", "ready", "blocked")가 포함된 아티팩트 배열
   • isComplete: 모든 아티팩트가 완료되었는지 나타내는 부울 값
   • planningHome, changeRoot, artifactPaths, actionContext: 경로 및 범위 컨텍스트. 저장소-로컬 경로를 가정하는 대신 이를 사용하세요.

   아티팩트 ID와 경로는 활성 스키마에서 가져옵니다. 이를 가정하지 말고, 하드코딩된 아티팩트 이름에 따라 분기하지 마세요. 사용자 정의 스키마도 변경 없이 작동해야 합니다.

   편집할 파일은 artifactPaths.<id>.existingOutputPaths입니다. 이는 디스크에 존재하는 구체적인 파일로, 글로브 아티팩트(예: specs/**/*.md)에 대해 이미 글로브 확장되었습니다. resolvedOutputPath에는 쓰지 마세요. 글로브 아티팩트의 경우 여전히 글로브 패턴이지 실제 파일이 아닙니다.

3. 요청 이해

   • 사용자가 특정 수정 사항("이제 디자인이 X를 사용함")을 요청한 경우, 그것이 시작 편집입니다.
   • "업데이트" / "일관성 유지"만 요청한 경우, 일관성 검토로 처리합니다. 기존 아티팩트를 읽고 서로 모순, 누락, 중복이 있는지 확인합니다.

4. 읽고 조정

   • 요청이触及하는 아티팩트와 변경 사항의 기타 기존 아티팩트를 읽습니다.
   • 요청된 편집을 적용합니다. 그런 다음 모든 기존 아티팩트를 이에 대해 확인합니다. 어떤 방향으로든: 이후 아티팩트에 대한 편집은 이전 아티팩트를 수정해야 할 수 있으며, 그 반대의 경우도 마찬가지입니다. 빌드 순서는 유용한 읽기 순서일 뿐, 수정될 수 있는 아티팩트에 대한 제약 조건이 아닙니다.
   • 이제 일관성이 없거나, 누락되었거나, 모순되는 모든 사항을 기록합니다.
   • 이미 존재하는 파일(existingOutputPaths)만 수정합니다. 아직 존재하지 않는 아티팩트를 생성하지 말고, 글로브 아티팩트 아래에 새 파일을 발명하지 마세요. 이를 기록하고 사용자에게 /opsx:continue를 가리켜 생성하도록 안내하세요.
   • 변경 사항이 이미 일관된 경우, 그렇게 말하고 편집하지 마세요.

5. 한 번에 하나의 아티팩트씩 확인 및 적용

   • 각 제안된 수정 사항과 그 이유를 보여줍니다. 사용자가 확인한 후에만 작성합니다.
   • 사용자가 수정 사항을 거부하면 작성하지 마세요. 해당 아티팩트를 변경하지 않은 상태로 둡니다.
   • 상당한 재작성이 필요한 경우, 먼저 해당 아티팩트의 규칙과 템플릿을 가져옵니다.

     openspec instructions <artifact-id> --change "<name>" --json
     

6. 다음 단계 제시 (지침 전용 - 절대 실행하지 마세요)

   • 아직 없는 아티팩트 -> 생성하려면 /opsx:continue를 제안합니다.
   • 변경 사항이 이미 구현됨(작업이 체크 해제되었거나 이미 적용됨) -> 코드가 수정된 계획과 더 이상 일치하지 않을 수 있습니다. 델타를 코드에 반영하려면 /opsx:apply를 제안합니다.
   • 모든 작업이 완료되고 구현됨 -> /opsx:archive를 제안합니다.

출력

각 호출 후 다음을 표시합니다.

• 수정된 아티팩트 (및 거부된 제안 수정 사항)
• /opsx:continue로 연기된 모든 항목 (아직 생성되지 않은 아티팩트 또는 파일)
• 변경 사항의 현재 상태 및 권장되는 다음 명령어

보호 장치

• 계획 아티팩트만 해당 - 구현 코드를 절대 편집하지 마세요. 수정된 계획이 코드 변경을 암시하는 경우 중단하고 /opsx:apply를 가리키세요.
• openspec status에서 보고된 아티팩트 ID와 경로를 사용하세요. 하드코딩된 아티팩트 이름으로 분기하지 마세요.
• existingOutputPaths의 구체적인 파일만 편집하세요. 글로브 resolvedOutputPath에는 절대 쓰지 마세요.
• 빌드 경계를 넘지 마세요. 새 아티팩트 없음, 글로브 아티팩트 아래에 새 파일 없음 - 이는 /opsx:continue의 작업입니다.
• 쓰기 전에 모든 편집을 사용자에게 확인받으세요.
• 요청이 변경 사항의 의도를 구체화하는 것이 아니라 변경하는 경우, /opsx:new로 새로 시작하는 것을 권장합니다("Update vs. Start Fresh" 휴리스틱).