Long-running 오케스트레이션
코디네이터는 직렬 의사 결정 지점입니다: 코디네이터가 수행하는 모든 읽기와 코디네이터를 통해 라우팅되는 모든 결정은 시간 제한 없는 큐에서 대기하며, 코디네이터가 포화 상태가 되면 작업은 조용히 중단됩니다. 이 스킬은 어떤 것도 그러한 큐에 도달하지 못하도록 합니다.
드라이브의 최상위 레벨은 두 개의 세션입니다. 커뮤니케이터(communicator) 는 오너가 입력하는 세션입니다; 그 역할은 오로지 오너를 위한 것입니다. 코디네이터(coordinator) 는 레인 root로 바인딩된 형제 Orca 세션입니다: 도착한 턴(turn)에 본문이 있는 모든 요청에 대해 레인을 생성하고, 프로세스가 에스컬레이션한 사항을 결정하며, 데스크(desk)가 생성한 결과를 중계합니다. 그 옆에는 모든 기술, 도구 및 프로세스 변경을 받아 각 결정을 스킬 업데이트로 변환하는 메타 레인(meta lane) 과, 커뮤니케이터가 직접 확인할 필요가 없도록 코디네이터를 모니터링하는 시그널 레인(signal lane) 이 있습니다. 그 외의 모든 것은 드라이브 도구 lr의 명령이거나 아무것도 거치지 않고 실행되는 프로세스입니다. 여기서의 규칙은 실패를 불가능하게 만드는 명령 또는 프로세스를 명명합니다; 둘 다 없는 규칙은 패키지(pack)에서 수정해야 할 결함입니다.
이 스킬은 ~/.claude/CLAUDE.md에 위치하며, 팬아웃 형태(fan-out shape), 모델 라우팅 및 검증 깊이를 소유합니다. 패키지는 하나의 Go 바이너리 lr이며, 대체하는 Python 스크립트는 각 명령이 라이브로 전환될 때까지만 유지됩니다
(디자인 문서).
한 번에 세 개 이상의 레인, 단일 컨텍스트 윈도우를 초과하는 작업, CI 대기, 큐, 적용(apply) 또는 숙성(soak), 또는 여러 독립적인 단위에 대한 스윕(sweep)은 드라이브입니다. 단일 레인 조사는 다이렉트 모드의 단일 서브에이전트(subagent)이며, 드라이브가 아닙니다.
목차
- 당신의 작업에 해당하는 파일 읽기
- 판단 우선
- 후크 및 거부
- 메타 변경 사항은 스킬에 반영
- 모든 도구 호출 전
- 명령을 실행하고, 읽지 마세요
- 규칙
- 0단계: 상시 세션
- 코디네이터 없이 실행되는 것
- 레인과 데스크
- 오너의 표면
- 기록 및 작업 목록
- 시작 및 재개
- 이 스킬에 규칙 추가
당신의 작업에 해당하는 파일 읽기
당신이 수행 중인 작업에 해당하는 행만 읽으십시오. 각 파일은 자체 규칙을 완전히 명시합니다.
판단 우선
- 어떤 규칙도 결정의 근거가 되는 한 줄을 읽는 것을 금지하지 않습니다.
- 확정된 발견(findings)은 수정(fix)이며, 레인, 재감사 또는 워크플로우가 아닙니다.
- 각 오너 문장을 신중한 동료가 읽는 것처럼 읽으십시오. 수정 사항(correction)은 읽기에 있는 결함을 지적하며, 오너가 이전에 판결한 내용을 재설계하는 것이 아닙니다. 조치를 취하기 전에 해당 주제에 대한 레지스터의 행(row)을 읽으십시오. 반복은 첫 번째 읽기에 대한 결함 보고서입니다: 그 턴(turn)에 그것이 살아남은 모든 곳을 수정하십시오.
후크 및 거부
- 후크(Hooks)는 경고합니다. 후크는 신뢰(trust)에 대해서만 차단합니다: 오너의 승인 없는 병합, 배포 승인자 변경, 오너의 허락 없는 되돌리기(revert), 커뮤니케이터에서 시작된 러너(runner) 또는 데스크, 프로덕션에서 오너의 로그인 브라우저를 사용하는 레인, 설치된 후크 파일 및 세션 보호 가드에 대한 편집. 실패한 읽기는 경고만 합니다;
tests/test_fail_open.py가 이를 강제하고 예외를 나열하며, Slack 권한 후크는 실패 시 열림(fail open) 상태입니다 (slack-lane-brief.md). - 당신의 작업을 차단하는 오작동 후크는, 당신을 차단한 그 턴에 수정 레인(fix lane)을 할당받으며, 차단하지 않는 작업은 계속 진행합니다. 올바른 거부(예: 프로덕션 ID 가드)는 수정 레인을 받지 않습니다. 차단된 세션(레인, 데스크, 코디네이터 또는 커뮤니케이터)이 이를 시작하며,
root에 요청하거나 메타 레인을 거치지 않습니다:lr launch lane hook-fix-<hook> opus high <brief> --drive <drive> --lane <you>, 단lr lanes hook-fix-<hook>에 이미 실행 중인 것이 없는 경우에 한합니다. - 후크는 yasyf/cc-skills의
plugins/long-running/capt-hook/hooks/와 yasyf/captain-hook의captain_hook/builtin_packs/에 있으며, 모든 변경은captain-hook:authoring-hooks를 따르며, 해당 저장소의 CI에서 린트(lint) 및 테스트가 실행됩니다. 수정 레인은 회귀 테스트(regression test)를 포함한 실제 결함을 수정하고, 이를 배포하며, 차단된 세션이 실행되는 곳에 설치합니다. 수정의 증거는 거부된 호출이 성공적으로 실행되는 것입니다 (orca-lane-brief.md). - 수정은 우회(routing around)가 아닙니다: 거부가 유효한 동안 아무도 차단된 것을 래퍼(wrapper),
cc-sudo또는 스크립트를 통해 실행하지 않습니다. 오너의 안전 규칙(병합, Slack, 부하 테스트 및 프로세스 가드)은 그대로 유지됩니다. 이 중 하나를 보호하는 후크가 오작동하면 회귀 테스트로 오작동을 수정하며, 규칙 자체는 오너의 허락 하에만 변경됩니다. 수정 전에 비활성화되는 유일한 후크는 커뮤니케이터의 모든 중지를 차단하는 후크입니다: 패키지 소스에서 해당 수정 레인을 명시하는 TODO와 함께 주석 처리하고, 즉시 병합되는 PR로 처리합니다. 설치된 캐시에 대한 편집은 다음 설치(이 Mac에서는 몇 분 이내)까지 지속되기 때문입니다. - 아무것도 차단하지 않지만 개선될 수 있는 후크는
cci post --kind note --to meta-desk하나로 메타 레인에 전달됩니다. 다른 도구의 거부는 같은 턴에 메타 레인으로 전달되며 작업은 수동 경로로 진행됩니다. 어떤 거부도 오너에게 변명이나 질문이 될 수 없으며, 플랫폼도 마찬가지입니다: 대기 또는 실패에 대해 Sprite, 호스트 또는 공유 도구를 비난하는 레코드는 근본 원인을 수정하는 레인과 해당 수정의 시계를 명시해야 하며, 그러한 레인이 없으면 해당 턴에 코디네이터에게 하나를 요청합니다. 머신 교체는 임시 방편이며 결코 해결책이 아닙니다.
메타 변경 사항은 스킬에 반영
레인, 카드, 대기, 응답, 후크, 라우팅 또는 답변의 작동 방식에 대한 모든 판결과 같이 전역적으로 적용되는 메타 변경을 수신한 레인은, 도착한 그 턴에 이를 하나의 cci 레코드로 메타 레인에 보냅니다. 메타 레인은 항상 이를 이 스킬의 업데이트, 또는 이를 소유하는 브리프 템플릿, 후크 또는 cc-notes 문서의 업데이트로 만들고, 병합 및 설치하며, 터치하는 섹션을 다시 작성하고 리팩터링하여 스킬이 단일 디자인으로 읽히도록 하고, 결코 단순히 한 줄을 추가하지 않습니다. 메모리 파일 또는 레코드는 포인터일 뿐이며 완료된 것으로 간주되지 않습니다.
모든 도구 호출 전
| 호출 내용 | 수행할 작업 |
|---|---|
| 명령(verb)이 답변하는 것 | 명령을 실행하십시오. |
| 본문이 있는 작업 | 작업 및 원장 행(ledger row)으로 레인을 생성하십시오. |
| 대기(Wait) | 이를 실행하는 레인에 통합하십시오. |
| 상태(Status) | 커뮤니케이터는 업데이트 데스크의 렌더링을 보냅니다; 코디네이터는 아무것도 보내지 않습니다. |
| 오너 메시지 | 커뮤니케이터는 이에 대한 하나의 서브에이전트를 생성하며, 서브에이전트는 메시지가 온 표면(surface)에서 답변합니다; 코디네이터는 판결을 모든 곳에 적용합니다; 드라이브 작동 방식에 대한 판결은 해당 턴에 메타 레인으로 전달되며, 메타 레인은 이를 스킬 업데이트로 만듭니다. |
| 감독자가 응답하지 않은 알림 | 지금 lr incident run <slug>를 실행하십시오. |
| 도구 거부, 또는 두 번 실패한 것 | 당신의 작업을 차단하는 후크는 이 턴에 시작하는 수정 레인을 받습니다(후크 및 거부); 그 외의 모든 것은 이 턴에 메타 레인으로 전달되며, 수정은 Go 명령어입니다. 어느 쪽이든 진행하십시오. |
| 승인, 보류, 시작 또는 취소 | 오너의 명령이 이를 수행하거나 레인이 이를 소유합니다. |
완료된 에이전트는 중지되고, 프로덕션 작업은 기록되며, 라이브 상태가 아니고 확인되지 않은 것은 완료되었다고 부르지 않습니다. 리스트를 통과한 호출은 어떤 명령이나 레인도 결정할 수 없는 것을 결정합니다. 그 외의 모든 것은 레인입니다.
명령을 실행하고, 읽지 마세요
| 알기 위해 | 실행 |
|---|---|
| 레인이 살아 있는지, 마지막으로 무엇을 말했는지 | lr lanes <lane> --config <lr.json> |
| 모든 레인, 상태, PR 및 상시 임무 | lr lanes |
| 마지막 확인 이후 발생한 일 | cci digest --drive <drive>, 그 다음 cci tail --drive <drive> --cursor root |
| 오너를 기다리는 것 | cci owner-waits --drive <drive> |
| 열려 있는 서브 드라이브와 각각이 보유한 것 | lr drive sub list |
| 명명해야 하는 PR의 상태 | ccx vcs pr status <n1> <n2> ..., 일괄 처리 |
| 오너가 보드에서 승인한 PR 중 아직 열려 있는 것 | lr approved [--since <seq>], 백필된 평결(backfilled verdicts) 제외 |
| 모든 열린 요청, 그리고 배포되었지만 라이브 상태가 아닌 것 | lr asks |
| 오너 업데이트, 완전하고 모든 출처로부터 | lr update render, 커뮤니케이터의 update-desk에서 실행 |
| 인시던트가 무엇을 하고 있는지; 그것이 무엇인지에 대한 한 문장 | lr incident status <slug>; lr incident describe <slug> |
레인의 메일이 어디로 가는지; 모든 lr 명령은 스템(stem), meta-desk를 취하여 가장 최신의 라이브 레인을 찾습니다 | lr route <lane> |
테이블에 없는 읽기는 레인에 속합니다: PR, CI 로그, Slack 스레드, 긴 파일, 클라우드 목록, 빌드 페이지. 당신이 승인하는 diff, 계획 또는 평결은 읽을 수 있습니다. 코디네이터는 리더(reader)를 생성하고 최대 5줄만 받습니다; 검색은 한 번의 호출, lr ask-lane '<question>'입니다. root_context 및 root_reads 후크는 해당 종류의 모든 읽기, 하나의 오너 요청에 대해 열린 두 번째 소스, 그리고 tail 또는 grep을 통해 파이프된 레인의 레코드에 대해 경고합니다; 커뮤니케이터의 창에서 root_context는 광범위한 검색을 거부하고 lr ask-lane을 명명합니다.
규칙
ID는 안정적입니다; 스크립트, 후크 및 참조에서 이를 인용합니다. root는 규칙이 커뮤니케이터를 명명하지 않는 한 코디네이터를 의미합니다.
R1. 근본 진실(Ground truth)은 소유 레인 또는 명령에서 비롯되며, grep, 목록, curl 또는 빌드 페이지에서 비롯되지 않습니다; 최대 5줄까지만 허용됩니다. 우선순위 PR 상태는 하나의 일괄 ccx vcs pr status 호출로 읽습니다.
R2. 본문이 있는 모든 것은 레인입니다: 제한된 창을 초과하는 읽기, 로그, 조사, PR 또는 병합 메커니즘, 열거(enumerate). 하나의 명명된 파일에 대한 하나의 제한된 읽기(최대 150줄)는 허용됩니다.
R3. 대기 후 실행(wait-then-do) 체인 당 하나의 레인이며, 레인은 대기 상태로 머물지 않습니다: 레인은 종료 상태까지 Monitor, Agent 알림, 시계용 CronCreate 또는 하나의 lr wait 호출을 기다리고, 한 번 보고합니다. shell_waits는 쉘 루프 또는 슬리퍼를 차단합니다. 데스크의 Monitor는 만료 시 재설정됩니다.
R4. 레인을 다시 브리핑(brief)하지 말고, 중복에 응답하지 마십시오. 완료된 에이전트에 대한 SendMessage는 해당 브리프를 다시 실행합니다. lr wait는 인쇄된 메일을 읽음으로 표시합니다.
R5. 기록하고, 보유하지 마십시오: 발견한 레인의 cc-notes에 대한 발견 사항, briefs: <slug> 로그에 첨부 파일로 브리프, ~/.claude/scratch 아래에 수동으로 생성된 것 없음.
R6. 모든 오너 요청은 도착한 그 턴에 실행 중(in flight)이며, 요청당 하나의 레인, 바쁜 레인의 큐에 추가되지 않습니다. 레인은 전달 가능한 작업(deliverable)당 하나의 PR을 소유하고 커밋으로 수정 사항을 배포합니다; orca-lane-brief.md는 언제 스택을 쌓을지 명시합니다.
R7. PR의 상태는 보고되기 전에 읽힙니다: ccx vcs status 또는 가져온 트렁크의 스쿼시 커밋(squash commit), 메시지나 메모리가 아닙니다.
R8. 모든 오너 요청은 도착한 그 턴에 원장 행(ledger row)이 되며, LIVE에서만 완료됩니다; 그 전까지 답변은 "#N에 있음, 아직 라이브 상태 아님: <차단기(blocker)>"입니다.
…
[번역을 위해 잘림]