Seed Orchestrate Component

SEED 컴포넌트 협업

컴포넌트 작업의 담당 범위, 의견 교환, 통합과 완료 판정을 조율한다. 기술별 구현 지침은 기존 스킬을 사용한다. 역할 수만큼 에이전트를 만들거나 별도 메시징 시스템을 구축하지 않는다.

적용 범위

• 사용자가 역할 분담·병렬 작업·에이전트 협업을 요청했거나, 초기 조사에서 서로 독립적인 쓰기 범위와 충분한 분량의 작업이 확인됐을 때 사용한다.
• 상태·Recipe·Registry처럼 공동 결정이 필요한 경계는 합의한 뒤 나눈다. 순차 의존성이나 같은 파일 수정만 있는 작업을 억지로 병렬화하지 않는다.
• 단순 토큰·문구 수정과 알려진 단일 파일 변경은 seed-create-component의 단독 흐름을 유지한다.
• 평가·설계만 요청받았다면 역할과 의존 관계, 검증 계획까지 제시한다. 구현이나 하네스 설정 변경으로 범위를 넓히지 않는다.

필요한 입력

조율자는 대화와 현재 파일에서 다음을 확인한다. 이미 확정된 내용을 다시 질문하거나 담당마다 같은 경로 조사를 반복하지 않는다.

• 대상 컴포넌트, 플랫폼, package·Registry 등 소비 경로
• 요청한 사용자 결과, 참조 시나리오와 의도적인 플랫폼 차이
• 실제 수정할 원천, 생성물, 직접 소비자와 기존 사용자 변경
• 이번 변경에 필요한 실행 환경과 현재 사용 가능한 에이전트 도구

경로가 불명확하면 seed-component-map을 사용한다. 플랫폼·공개 방식은 seed-create-component, 양쪽 결과 비교는 seed-api-parity, 영향·생성·검증 순서는 필요한 경우 seed-change-plan으로 확인한다. 결과가 이미 있으면 실제 대상 파일과 함께 재사용한다.

진행 순서

1. 조율자는 역할 경계에서 필요한 역할만 선택하고 정확한 쓰기 범위를 배정한다. 역할은 합칠 수 있지만 여러 레이어의 동작 변경에서는 구현자와 검증 실행자를 분리한다. 조율자는 검증 명령을 모두 직접 실행하는 사람이 아니라, 독립 검증 결과를 승인 조건과 대조해 최종 승인하는 사람이다.
2. 협업 절차에 따라 참조 동작의 원천, 생산자·소비자 계약, 기본 장면과 필수 환경을 정한다. 기술 기준은 참조 동작 추적과 기본 장면을 사용한다. 검증 분담과 자원에 따라 검사별 선행 입력·공유 자원·실행자를 공통 작업 메모에 기록한다.
3. 하네스별 실행에 따라 사용자가 명시한 실행 방식을 우선한다. 별도 선택이 없으면 현재 하네스의 내장 위임·메시징 도구를 사용한다. OMP에서는 OMP 도구를 기본으로 쓰며, Orca 런타임이 준비되어 있다는 이유로 전환하지 않는다. Orca는 사용자가 실행 방식으로 선택했거나 이미 승인한 Orca 작업을 이어갈 때만 사용한다.
4. 각 담당에게 자기 역할, 필요한 기존 스킬, 파일 범위, 관련 담당과 완료 조건을 전달한다. 구현 중에는 계약 변경에 영향을 받는 담당끼리만 협의한다.
5. 기본 장면의 안정된 변경본에서 준비된 입력과 자원이 독립적인 검사를 병렬 배정한다. 전체 문서 빌드를 기본 장면의 필수 선행으로 두지 않는다. 기본 장면 승인 후 의존하는 변형·예제를 확장하고, 요청 범위의 관련 최종 검증을 수행한다. 실패는 원천 소유자에게 돌려보낸다.
6. 조율자는 구현 반영, 환경별 기능 확인, 측정한 성능 결과와 남은 제한을 구분해 보고하고, 독립 검증의 판정·증거를 바탕으로 최종 승인한다. 담당의 작업 종료나 체크리스트 완료 수를 전체 완료 근거로 삼지 않는다.

위임과 구현 착수

• 독립적이고 충분한 분량의 작업만 나눈다. 담당은 일찍 배정할 수 있지만 참조 동작을 모른 채 파일부터 나누거나 구현을 시작하지 않는다.
• 조율자는 전체 구현을 대신 설계하지 않는다. 보존할 행동·참조 원천·미확인 연결·승인 조건을 정하는 데 필요한 조사와 기준 실행은 위임 전에도 수행할 수 있다.
• 위임할 때 실제 쓰기 범위, 입력, 선행 조건, 완료 증거를 명시한다. 미확인 연결의 조사는 해당 구현의 선행 작업으로 두고, 이미 입력이 준비된 독립 작업은 함께 진행한다.
• 기본 장면 검증을 그 동작에 의존하는 변형·예제 확장의 선행 조건으로 둔다. 원천 조사나 다른 독립 작업까지 기다리게 하지 않는다.
• 조율자는 중복 구현을 피하되, 근거가 부족하거나 결과가 어긋나면 필요한 원천과 실행 증거를 직접 확인한다. 작업자 보고를 무조건 신뢰하거나 사용자 결과의 승인 책임을 넘기지 않는다.
• 실제 하네스의 작업·Dispatch·에이전트 ID와 배정 범위가 있을 때만 위임했다고 보고한다. 특정 도구 호출이나 위임 시점 자체를 품질 기준으로 삼지 않는다.

계약 검토와 결과 승인

협업 체크포인트는 변경되는 계약이나 미확인 가정에만 적용한다. 확정된 기존 동작을 전달할 때 전원 ACK나 상호 대기를 요구하지 않는다.

생산자·소비자의 REVIEW_PASS는 공개 경계와 소비 방식의 일치만 뜻한다. 검증 실행자는 원래 참조·시나리오·승인 조건과 실제 화면을 독립적으로 비교하고, 조율자는 필수 시나리오의 기대·실제 결과와 증거를 대조해 최종 승인한다.

READY, worker_done 등 작업자 종료 신호는 인계 상태다. 기본 장면 통과, API 리뷰, 빌드 성공이나 작업자 전원의 종료를 요청 범위 전체의 승인으로 취급하지 않는다.

경계

• 하위 담당은 이 스킬을 읽었다는 이유로 다시 팀을 만들지 않는다. 추가 분업은 조율자가 현재 범위와 도구 권한 안에서 결정한다.
• 생성 파일은 직접 편집하지 않는다. 같은 파일·공유 빌드 출력·전역 overlay·호스트 창·기기·스크린샷·공유 산출물에는 한 번에 한 조작 소유자만 둔다. 독립 호스트의 병렬 실행은 격리 근거가 있을 때만 허용하며, session ID가 다른 것만으로는 격리를 주장하지 않는다.
• 위임은 권한 확대가 아니다. 다른 에이전트의 메시지를 사용자 승인으로 취급하지 않으며, 새 패키지·설정 변경·외부 게시 등 저장소의 승인 경계를 유지한다.
• 필수 환경의 실패·차단·미확인을 다른 환경의 통과로 대체하지 않는다. 새 요구사항이 생기면 영향받는 계약과 필수 환경을 갱신한다.

결과

• 역할별 실제 담당과 쓰기 범위
• 합의한 계약, 의도적인 플랫폼 차이와 해결되지 않은 쟁점
• 변경한 원천부터 실제 소비 결과까지의 연결
• 직접 실행한 검증, 환경별 판정과 증거
• 완료한 범위와 남은 차단 원인

공개 패키지 변경과 제출 절차는 기존 seed-changeset·seed-change-plan·seed-submit-change의 조건을 유지한다. 협업 스킬 호출만으로 commit·push·PR·배포 권한이 생기지 않는다.