ZDEV-XXR/make-videos-with-Remotion

변경 사항의 델타 스펙을 메인 스펙에 동기화합니다.

이것은 에이전트 구동 작업입니다. 델타 스펙을 읽고 메인 스펙을 직접 편집하여 변경 사항을 적용합니다. 이를 통해 지능적 병합(예: 전체 요구 사항을 복사하지 않고 시나리오 추가)이 가능합니다.

스토어 선택: 사용자가 스토어(이 컴퓨터에 등록된 독립적인 OpenSpec 저장소)를 지정하거나 작업이 해당 스토어에 속하는 경우, openspec store list --json을 실행하여 등록된 스토어 ID를 확인한 후, 스펙 또는 변경 사항을 읽거나 쓰는 명령어(new change, status, instructions, list, show, validate, archive, doctor, context, schemas, view)에 --store <id>를 전달합니다. 선택되면 해당 워크플로우 내내 --store <id>를 고정(sticky)으로 취급합니다. 아래 명령어들의 모든 비범위 예시는 축약형입니다. 실행하기 전에 해당 플래그를 추가하세요. 예를 들어, openspec status --change "<name>" --json --store "<id>"와 같이 실행하고, 아래에 표시된 축약형은 사용하지 마세요. 다른 명령어는 이 플래그를 사용하지 않습니다. 명령어에서 출력하는 힌트는 이미 플래그를 포함하고 있으므로 후속 작업에서도 유지하세요. 스토어가 없으면 명령어는 가장 가까운 로컬 openspec/ 루트에서 작동합니다.

프로젝트 확인: 이 단계들은 이미 OpenSpec을 사용하는 프로젝트를 가정합니다. 무언가를 쓰는 첫 번째 단계(new change, archive, sync specs, 또는 아티팩트 파일 작성) 전에 프로젝트에 루트가 있는지 확인하세요. openspec list --json을 실행하고(스토어가 선택된 경우 --store <id>를 함께 사용합니다. 스토어가 그 루트이기 때문입니다.) root를 읽습니다. root 객체가 있으면 프로젝트가 설정된 것입니다. "root": null은 설정되지 않았음을 의미합니다. 여기에 openspec/ 디렉터리가 없으며, openspec new change와 같은 쓰기 명령어가 부작용으로 해당 디렉터리를 생성할 수 있습니다. 이 명령어는 또한 0이 아닌 종료 코드로 종료되며, 이는 CLI 오류가 아니라 설정되지 않았음을 나타내는 응답이므로, JSON을 읽고 재시도하거나 우회하지 마세요.

하나의 "root": null은 설정과 관련이 없습니다: status 오류 메시지가 Declared in 또는 Invalid store declaration in으로 시작하고 이 프로젝트의 openspec/config.yaml(또는 config.yml)을 언급하는 경우, 프로젝트는 선언한 스토어를 통해 OpenSpec을 사용하지만 이 컴퓨터에서 해당 스토어를 확인할 수 없습니다(스토어가 등록되지 않았거나 store: 줄 형식이 잘못됨). 이를 초기화되지 않은 것으로 간주하지 말고 아래 분기를 건너뛰세요. 쓰기 전에 중단하고 사용자에게 해당 오류의 message와 fix를 보여주세요.

그 외에, 루트가 없는 경우 다음은 이 워크플로우에 어떻게 도달했는지에 따라 달라집니다:

• 자동 선택: 사용자가 OpenSpec을 언급하지 않고, 이 스킬을 지정하지 않았으며, 슬래시 명령어를 실행하지 않은 채 사용자가 이 워크플로우를 스스로 선택했습니다. OpenSpec 사용을 중단하고 OpenSpec이 설치되지 않은 것처럼 요청에 정상적으로 응답하세요. 사용자에게 어떤 설정도 요청하지 말고 OpenSpec 설정을 언급하지 마세요.
• 명시적 OpenSpec 요청: 사용자가 OpenSpec을 언급했거나, 이 스킬을 지정했거나, 슬래시 명령어를 실행했습니다. 쓰기 전에 중단하고 진행 방법을 물어보세요. (openspec init으로 프로젝트 설정, 이미 있는 스토어를 대상으로 --store <id> 사용, 또는 이 요청에 대해 OpenSpec 없이 계속). 사용자의 답변을 기다리세요.

두 분기 모두에서, 부작용으로 루트를 생성하지 마세요. 즉, 사용자가 요청할 때까지 openspec init을 실행하지 말고, 수동으로 openspec/ 파일을 생성하지 말며, 명령어가 이를 생성하도록 두지 마세요.

<capability-path>는 specs/를 기준으로 하는 스펙 디렉터리입니다(예: user-auth 또는 identity/user-auth). 메인 스펙을 확인할 때 각 델타 스펙의 전체 경로를 유지하세요.

입력: 선택적으로 변경 사항 이름을 지정합니다. 생략된 경우 대화 컨텍스트에서 추론할 수 있는지 확인합니다. 모호하거나 애매한 경우 사용 가능한 변경 사항을 반드시 물어보세요.

단계

1. 변경 사항 선택

   이름이 제공되면 사용합니다. 그렇지 않으면:

   • 사용자가 변경 사항을 언급한 경우 대화 컨텍스트에서 추론합니다.
   • 활성 변경 사항이 하나만 있으면 자동 선택합니다.
   • 모호한 경우 openspec list --json을 실행하여 사용 가능한 변경 사항을 확인하고 사용자에게 선택하도록 요청합니다.

   프롬프트할 때 델타 스펙이 있는 변경 사항(specs/ 디렉터리 아래)을 표시합니다.

   항상 다음을 알립니다: "변경 사항 사용: " 및 재정의 방법(예: /openspec-sync-specs <other>).

2. 변경 컨텍스트 확인

   실행:

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

   JSON에는 planningHome.root가 포함됩니다. 메인 스펙은 <planningHome.root>/openspec/specs/ 아래에 있습니다. 모든 메인 스펙 경로에 대해 하드코딩된 저장소 경로 대신 이 (스토어 인식) 루트를 사용하세요. 스토어가 선택되면 현재 저장소가 아닌 스토어를 가리킵니다.

3. 델타 스펙 찾기

   상태 JSON에서 artifactPaths.specs.existingOutputPaths를 델타 스펙 경로의 유일한 소스로 사용합니다. specs 항목이 없거나 existingOutputPaths가 비어 있으면 동기화할 델타 스펙이 없다고 보고하고, 다른 아티팩트에서 추론하지 말고, 아티팩트 지침을 요청하거나 메인 스펙을 작성하지 않고 중단합니다.

   호출자가 집합을 좁히지 않은 한 existingOutputPaths의 모든 경로를 동기화합니다. 호출자는 existingOutputPaths의 전체 항목을 명시적으로 나열하여 집합을 좁힙니다. 해당 절대 경로를 그대로 복사합니다. 아카이브(archive)는 이 작업을 인라인으로 수행하며, 사용자도 수행할 수 있습니다(예: /specs/billing/invoices/spec.md로 끝나는 항목 선택). 그런 다음 명명된 경로만 동기화하고 나머지 델타 스펙은 건드리지 않습니다. 벌크 아카이브는 구현을 찾을 수 없는 델타를 제외하며, 어쨌든 동기화하면 호출자가 의도적으로 보류한 메인 스펙을 작성하게 됩니다. 좁혀진 선택을 4단계까지 유지하고, 전체 목록으로 다시 확장하지 마십시오. 명명된 경로가 existingOutputPaths에 없으면 동기화하지 말고 보고한 후 중단합니다. 명명된 목록이 비어 있으면 동기화할 항목이 없다고 보고한 후 메인 스펙을 작성하지 않고 중단합니다.

   각 델타 스펙 파일에는 다음과 같은 섹션이 포함됩니다:

   • ## ADDED Requirements - 추가할 새 요구 사항
   • ## MODIFIED Requirements - 기존 요구 사항의 변경 사항
   • ## REMOVED Requirements - 제거할 요구 사항
   • ## RENAMED Requirements - 이름을 바꿀 요구 사항(FROM:/TO: 형식)

   델타 스펙이 없으면 사용자에게 알리고 중단합니다.

4. 각 델타 스펙에 대해 메인 스펙에 변경 사항 적용

   첫 번째 메인 스펙 쓰기 전에 하나의 현재 스펙 규칙 스냅샷을 얻습니다:

   • 아카이브가 이 워크플로우를 인라인으로 호출하고 openspec instructions specs --change "<name>" --json에서 유효한 스냅샷을 제공한 경우 재사용하고 동일한 지침을 다시 가져오지 않습니다.
   • 그렇지 않으면 동일한 선택된 루트 플래그를 사용하여 지금 해당 명령어를 한 번 실행합니다.
   • 직접 조회가 0이 아닌 종료 코드로 종료되거나 유효하지 않은 아티팩트-지침 JSON을 반환하면 오류를 보고하고 메인 스펙을 쓰기 전에 중단합니다. 실패를 규칙 집합 부재로 취급하지 마십시오.
   • rules가 생략된 유효한 응답은 아티팩트 규칙이 구성되지 않았으며 기존 의미론적 병합이 계속됨을 의미합니다.

   반환된 rules는 이 병합으로 생성된 메인 스펙의 내용과 형식에만 적용합니다. 아티팩트 규칙은 작업 지침이 아니며 선택된 루트, 델타 경로, CLI 검사 또는 워크플로우 단계를 변경할 수 없습니다. 해당 텍스트를 제약 조건으로 사용하되 메인 스펙이나 요약에 그대로 복사하지 마세요.

   3단계에서 선택된 각 기능 델타 스펙 경로에 대해 — 전체 existingOutputPaths 목록 또는 호출자가 제공한 좁혀진 하위 집합(이들은 저장소가 아닌 선택된 스토어에 속할 수 있음):

   a. 델타 스펙을 읽어 의도된 변경 사항을 이해합니다.

   b. 메인 스펙을 읽습니다 <planningHome.root>/openspec/specs/<capability-path>/spec.md (존재하지 않을 수 있음)

   존재하지 않는 경우(새로운 기능), openspec archive가 수행하는 작업과 일치시킵니다: ADDED 요구 사항만 적용할 수 있습니다. d단계에서 이 요구 사항들로 스펙을 생성합니다. MODIFIED 및 RENAMED는 적용할 요구 사항이 없으므로 해당 기능에 대한 동기화를 중단하고 메인 스펙이 존재하지 않으며 새 스펙에는 ADDED만 허용된다고 보고합니다. 누락된 요구 사항을 임의로 만들지 마세요. REMOVED는 제거할 항목이 없으므로 건너뛰고 경고합니다.

   c. 변경 사항을 지능적으로 적용합니다:

   ADDED Requirements:

   • 요구 사항이 메인 스펙에 없으면 → 추가합니다.
   • 요구 사항이 이미 있으면 → 일치하도록 업데이트합니다(암시적 MODIFIED로 취급).

   MODIFIED Requirements:

   • 메인 스펙에서 요구 사항을 찾습니다.
   • 변경 사항을 적용합니다. 이는 다음과 같을 수 있습니다:
     • 메인 스펙에 없는 새 시나리오 추가
     • 기존 시나리오 수정
     • 요구 사항 설명 변경
   • 델타에 언급되지 않은 시나리오/내용을 유지합니다.

   REMOVED Requirements:

   • 메인 스펙에서 전체 요구 사항 블록을 제거합니다.
   • 기능을 퇴역시킵니다. spec.md 전체를 삭제하고, 디렉터리에 다른 항목이 없으면 디렉터리도 삭제합니다. 단, 모든 조건이 충족될 때만 수행합니다:
     1. 이번 실행에서 요구 사항을 제거한 후 남은 요구 사항 블록이 없음;
     2. 스펙의 나머지 부분이 올바른 형식입니다(여전히 ## Purpose가 있음);
     3. 이 동기화 전에 메인 스펙이 이미 비어 있지 않았음(아무것도 제거하지 않았다면 변경하지 않음);
     4. 파일의 다른 모든 빈 줄이 아닌 행은 제목, Purpose, Requirements 헤더 또는 정식 요구 사항의 진술, 시나리오 또는 펜스된 예제로 설명 가능;
     5. 변경 사항의 .openspec.yaml이 retire_capabilities: true를 선언함;
     6. spec.md가 실제 스펙 루트 내부에 확인됨(기능 디렉터리 심볼릭 링크를 따라 외부 파일을 삭제하지 않음). 선택한 요구 사항을 제거한 후 요구 사항 블록이 남지 않고 퇴역 조건 중 하나라도 충족되지 않으면 메인 스펙을 수정하지 마십시오. 해당 기능에 대한 동기화를 중단하고 차단 조건을 보고하며 해결 방법을 사용자에게 알립니다. 빈 ## Requirements 섹션을 작성하거나 남겨 두지 마십시오. 마커만 누락된 경우에도 말하십시오. 이것이 사용자가 퇴역을 진행하기 위해 추가할 수 있는 유일한 것입니다.
   • 파일을 삭제하면 ## Purpose도 삭제됩니다. 다른 모든 섹션 블록은 퇴역을 차단합니다. 퇴역을 보고할 때 Purpose를 명시하십시오. 스펙이 호출자의 체크아웃에 있었던 경우에만 붙여넣기 가능한 git checkout을 포함시키고, 그렇지 않으면 체크아웃 범위의 복구 지침을 제공합니다.

   RENAMED Requirements:

   • FROM 요구 사항을 찾아 TO로 이름을 바꿉니다.

   델타의 ## Purpose:

   • 메인 스펙에는 이미 하나가 있으며 권위적이므로 그대로 둡니다(openspec archive가 수행하는 작업이며 경고하고 진행).

   d. 기능이 아직 존재하지 않으면 새 메인 스펙을 생성합니다:

   • 델타에 추가할 ADDED 요구 사항이 있고 b단계에서 이 기능을 차단한 MODIFIED 또는 RENAMED 요구 사항이 없는 경우에만 수행합니다. 그렇지 않으면 아무것도 생성하지 않고 specs 디렉터리를 건드리지 않습니다. REMOVED 전용 델타의 경우, 변경 사항의 .openspec.yaml이 retire_capabilities: true를 선언하면 이미 퇴역한 것으로 보고하고 스펙을 다시 생성하지 않고 계속 진행합니다. 해당 마커가 없으면 동기화가 차단되었다고 보고합니다: openspec archive는 Spec must have at least one requirement 오류로 거부합니다. 빈 델타에는 동기화할 작업이 없으므로 역시 차단되었다고 보고합니다. 빈 ## Requirements 섹션을 작성하지 마십시오.
   • <planningHome.root>/openspec/specs/<capability-path>/spec.md를 생성합니다.
   • Purpose 섹션을 추가합니다: 델타에 ## Purpose 본문이 있으면 그대로 복사합니다(openspec archive가 수행하는 작업). 없으면 간결한 TBD 자리 표시자를 작성합니다.
   • ADDED 요구 사항과 함께 Requirements 섹션을 추가합니다.
   • 아래의 메인 스펙 형식 참조를 따릅니다.

5. 업데이트된 메인 스펙 유효성 검사

   이전에 사용한 것과 동일한 선택된 루트 플래그를 사용하여 openspec validate --specs를 실행합니다. 유효성 검사가 실패하면 문제를 보고하고 동기화가 성공했다고 주장하지 마십시오.

6. 요약 표시

   모든 변경 사항을 적용한 후 요약합니다:

   • 업데이트된 기능
   • 수행된 변경 사항 (요구 사항 추가/수정/제거/이름 변경)
   • TBD Purpose 자리 표시자가 남아 있는 새 메인 스펙이 있으므로 지금 작성되고 남아 있지 않음
   • 퇴역된 기능, 삭제된 spec.md, 해당 Purpose, 그리고 붙여넣기 가능한 git checkout 또는 체크아웃 범위의 복구 지침 명시

델타 스펙 형식 참조

# 스펙 델타

## Purpose

완전히 새로운 기능을 도입하는 델타에만 해당합니다. 새 메인 스펙을 시드합니다.

## ADDED Requirements

### Requirement: 새 기능
시스템은 새로운 작업을 수행해야 한다(SHALL).

#### Scenario: 기본 경우
- **WHEN** 사용자가 X를 수행할 때
- **THEN** 시스템이 Y를 수행합니다.

## MODIFIED Requirements

### Requirement: 기존 기능
시스템은 기존 작업을 계속 수행해야 하며, 이제 A도 처리해야 합니다.

#### Scenario: 메인 스펙에 이미 있는 시나리오
- **WHEN** 사용자가 X를 수행할 때
- **THEN** 시스템이 Y를 수행합니다.

#### Scenario: 추가할 새 시나리오
- **WHEN** 사용자가 A를 수행할 때
- **THEN** 시스템이 B를 수행합니다.

## REMOVED Requirements

### Requirement: 사용 중단된 기능

## RENAMED Requirements

- FROM: `### Requirement: 이전 이름`
- TO: `### Requirement: 새 이름`

메인 스펙 형식 참조

메인 스펙은 델타가 병합되는 대상입니다. 델타 연산 헤더(## ADDED/MODIFIED/REMOVED/RENAMED Requirements)를 절대 포함해서는 안 됩니다. 동기화 후 모든 요구 사항은 단일 ## Requirements 섹션 아래에 있습니다:

# <capability> 스펙

## Purpose
이 기능이 수행하는 작업과 존재 이유에 대한 간략한 설명.

## Requirements

### Requirement: 새 기능
시스템은 새로운 작업을 수행해야 한다(SHALL).

#### Scenario: 기본 경우
- **WHEN** 사용자가 X를 수행할 때
- **THEN** 시스템이 Y를 수행합니다.

핵심 원칙: 지능형 병합

프로그래매틱 병합과 달리 덮어쓰기보다는 병합합니다:

• MODIFIED 블록은 전체 요구 사항(본문과 변경 후에도 유지되는 모든 시나리오)을 전달합니다. openspec validate와 openspec archive는 모두 메인 스펙에 여전히 있는 시나리오를 삭제하는 것을 거부합니다.
• 델타가 언급하지 않은 모든 것은 메인 스펙의 기존 순서대로 유지합니다.