병렬 기능 관리자(Parallel feature managers)
라이브 Cotal 메시를 계층 구조로 사용하세요:
- 현재 세션은 코디네이터입니다. 격리를 생성하고, 정책을 설정하며, 진행 상황을 모니터링하고 결정을 중계합니다. 구현이나 패널 검토를 중복하지 않습니다.
- 각 기능은 자체 Git 워크트리와 브랜치에 루트를 둔 하나의 관리자를 갖습니다. 관리자는 전체 계획 -> 구현 -> 검토 -> 테스트 -> 커밋 주기를 소유합니다.
- 각 관리자는 하나의 전용 채널에서 세 명 이상의 읽기/검토 전용 피어를 스폰합니다: 최소 엔지니어, 보안, 비평가.
- 최종 게이트 근처에서 각 관리자는
cold-review스킬에 따라 브리핑된 하나의 독립적인 콜드 리뷰어를 추가합니다. 이 스킬은 해당 좌석이 어떻게 브리핑되고, 격리되며, 평가되는지에 대한 단일 소스입니다. 이는 패널에 대한 통제 수단이지 네 번째 패널리스트가 아닙니다.
모델: 교차 벤더 패널은 정확성 규칙이지 선호도가 아닙니다
합의가 하중을 지탱하는 두 좌석은 모델 제품군을 공유할 수 없습니다. 동일한 제품군의 좌석이 확인한 결과는 에코일 뿐, 확인이 아닙니다. 세 명의 동일 모델 검토자로 구성된 패널은 세 명 모두가 놓친 결함을 가진 헤드를 승인했으며, 이를 표면화한 것은 네 번째 검증자가 아닌 다른 방식으로 구성된 읽기였습니다.
이를 인원 수가 아닌 그런 방식으로 명시하세요. 가용성은 순간의 속성이지 벤더의 속성이 아닙니다: 동일한 모델이 한 시간 동안 참여하여 전달하고 다음 시간에는 동일한 호스트와 동일한 도구로 참여하지 못할 수 있습니다. "N개의 고유 벤더"로 표현된 규칙은 성능이 저하된 함대에서는 만족시킬 수 없으며 조용히 그렇게 되고, 시계에 의해 깨질 수 있는 규칙은 조용히 무시되거나 준수되지 않습니다. cold-review는 성능 저하 순서와 최소 기준을 전달합니다.
스폰 시점과 페르소나 모두에서 모델을 명시적으로 고정하세요. 기록되지 않은 기능은 사실상 평가되지 않기 때문입니다: 노력이나 모델이 기록되지 않은 검토자는 이후에 누구도 평가할 수 없는 평결을 생성합니다.
관리자는 검토자보다 더 강력한 모델을 실행할 수 있습니다. 검토자는 코디네이터와 동일한 모델을 실행해서는 안 됩니다. 패널이 코디네이터의 맹점을 상속받을 수 없도록 하기 위함입니다.
스폰하기 전에 정확한 모델 식별자를 커넥터 자체 카탈로그와 비교하여 확인하고, 선언된 추론 노력 계층은 좌석이 실제로 해당 계층으로 시작될 때까지 확인되지 않은 것으로 처리하세요: 카탈로그는 공급자가 거부하는 계층을 선언할 수 있으며, 거부된 계층은 시작 시 좌석을 죽입니다.
엄격한 규칙
- 코디네이터의 브랜치를 절대 전환하지 마세요. 명명된 커밋된 베이스에서 워크트리를 생성하세요.
- 기능당 하나의 관리자, 채널 레인당 하나의 검토자, 기능당 하나의 독립적인 콜드 리뷰어.
cold-review에 따라 해당 좌석의 연락처와 대상을 선택하세요. 파일 대상은 규범적 대체 수단일 뿐이며 브로커가 증명한 게시자 신원을 요구하는 게이트를 충족할 수 없습니다. 사용자가 요청하지 않는 한 형제 인스턴스나 테스터 팬아웃은 없습니다. - 관리자만 기능 워크트리를 편집합니다. 검토자는 읽기, 비변경 검사 실행, 파일/라인 참조와 함께 결과 게시만 합니다.
- 각 기능은 하나의 패널 채널
review.<feature-slug>과 하나의 전용 콜드 기록 채널review.<feature-slug>.cold-record를 사용합니다. 확인 및 상태 잡담은 패널 채널에서 피하고, 계획, 결과, 이유 있는 처분, 코드 검토 요청 및 최종 결과에 사용하세요. - 독립적인 콜드 리뷰어는 해당 채널에 있지 않습니다. 그 격리, 브리핑 및 보고는
cold-review가 소유합니다; 레인마다 다시 설명하지 말고 거기서 시행하세요. - 제품/설계 결정은 DM을 통해 이동합니다: 관리자 -> 코디네이터 -> 사용자 -> 코디네이터 -> 관리자. 관리자는 해결되지 않은 중요한 선택을 추측해서는 안 됩니다.
- 사용자가 요청하지 않는 한 절대 병합, 푸시, PR 열기 또는 워크트리 제거를 하지 마세요.
- 라이브 메시 브로커를 방해하지 마세요. 테스트는 일회용 공간과 임의의 높은 포트를 사용합니다; 정확한 PID로 테스트 프로세스를 종료하고, 광범위한
pkill을 사용하지 마세요.
1. 기능 매트릭스 설정
요청된 모든 기능에 대해 다음을 선택하고 기록하세요:
| 필드 | 예시 |
|---|---|
| 기능 | channels export |
| 슬러그 | channels-export |
| 브랜치 | feat/channels-export |
| 워크트리 | 형제 경로(예: Cotal-feature-channels-export) |
| 관리자 페르소나 | mgr-channels-export |
| PR | 정확한 번호, 또는 존재하지 않으면 none |
| 채널 | review.channels-export |
| 계약 | 구체적인 동작, 경계, 테스트 및 알려진 비목표 |
무엇이든 생성하기 전에 브랜치/경로 충돌을 해결하세요. git status, git worktree list --porcelain 및 기존 브랜치를 검사하세요. 관련 없는 더티 상태를 정리하거나 되돌리지 마세요.
공유 Git 메타데이터를 변경하므로 워크트리를 순차적으로 생성하세요:
git worktree add -b feat/<slug> /absolute/sibling/Cotal-feature-<slug> <base>
사용자가 명시적으로 스택 작업을 원하지 않는 한 모든 기능에 동일한 베이스 커밋을 사용하세요.
2. 비공개 리포지토리 컨텍스트를 사용 가능하게 만들기
시작하기 전에 각 워크트리가 .internal/plans/STATUS.md 및 관련 지침을 읽을 수 있는지 확인하세요. 일반적으로 git submodule update --init .internal이면 충분합니다.
슈퍼프로젝트가 사용 불가능한 커밋을 고정하여 초기화가 실패하는 경우:
- 커밋된 포인터(
git ls-tree <base> .internal)를 활성 로컬 서브모듈 HEAD(git -C .internal rev-parse HEAD)와 비교하세요. 이는 리포지토리 상태 드리프트이지 Cotal ACL 문제가 아닙니다. - 권한이 있을 때 의도된 서브모듈 커밋 및 슈퍼프로젝트 포인터를 수정/게시하는 것을 선호하세요.
- 임시 병렬 실행의 경우, 활성 로컬 서브모듈 리포지토리에서 알려진 양호한 로컬
.internal커밋을 각 기능 워크트리에 독립적으로 구체화하세요. - 관리자에게 슈퍼프로젝트가
M .internal을 표시할 수 있지만 읽기만 하고 스테이징, 편집 또는 기능 커밋에 포함하지 않아야 한다고 알리세요.
새 워크트리가 이미 로컬에서 사용 가능하고 확인된 비공개 커밋을 가져올 수 없다고 해서 관리자가 차단되도록 두지 마세요. 불일치가 깔끔한 것처럼 가장하지 마세요; 필요한 영구 수리를 보고하세요.
3. 먼저 정책으로 관리자 및 검토자 페르소나 생성
관리자 에이전트는 capabilities: [spawn]과 채널 ACL이 필요합니다. 검토자 에이전트는 채널 ACL이 필요하고 spawn이 없어야 합니다. cotal_persona는 정책을 부여할 수 없고, cotal_spawn은 allowSubscribe 또는 allowPublish를 재정의할 수 없으므로 스폰하기 전에 모든 페르소나 파일을 작성하세요. 이 파일들은 이 리포지토리에서 로컬/무시됩니다. 기본 페르소나만 있는 깨끗한 머신은 패널을 구성할 수 없습니다: 아래 스폰 이름은 해당 파일이 존재하지 않으면 실패하며, 남은 로컬 페르소나는 대체물이 아닙니다. 부여가 누락되거나 레인보다 넓을 수 있기 때문입니다.
---
name: mgr-<slug>
role: feature-manager
model: <pinned manager model>
description: <기능> 및 해당 검토 패널을 소유합니다.
tags: [manager, <slug>]
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>, review.<slug>.cold-record]
allowPublish: [review.<slug>]
capabilities: [spawn]
---
세 패널 좌석 및 콜드 좌석에 대해 스폰하기 전에 일치하는 파일을 작성하세요. 모든 검토자 페르소나에 review-<slug>-engineer와 같은 레인 범위의 파일 이름을 지정하세요; 페르소나 카탈로그는 동시 레인에서 공유되므로 일반 파일 이름은 워크트리와 채널이 충돌하지 않더라도 충돌합니다. 패널 페르소나는 review.<slug>에서만 구독 및 게시합니다. 콜드 페르소나는 빈 구독 및 allowSubscribe를 나열하여 비참여가 좌석의 속성이고 명령이 아니도록 하고, review.<slug>.cold-record에만 게시할 수 있습니다. 다른 레인에서 검토자 페르소나를 재사용하거나 재정의하지 마세요.
---
name: review-<slug>-engineer
role: reviewer
model: <pinned panel model, family A>
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>]
allowPublish: [review.<slug>]
capabilities: []
---
---
name: review-<slug>-freelance
role: reviewer
model: <pinned cold model, not the author's family>
subscribe: []
allowSubscribe: []
allowPublish: [review.<slug>.cold-record]
capabilities: []
---
패널 템플릿을 review-<slug>-security 및 review-<slug>-critic에 대해 다른 모델 제품군으로 반복하세요. 이후에 심판이 필요한 경우 review-<slug>-referee를 콜드 좌석과 같은 방식으로 빈 구독 및 allowSubscribe와 하나의 전용 기록 채널 allowPublish 부여로 작성한 후 스폰하세요.
관리자 프롬프트는 다음을 모두 포함해야 합니다:
- 정확한 기능 계약, 브랜치 및 절대 워크트리 경로.
- 기능을 종단 간 소유하고 의도된 기능 파일만 커밋합니다.
- 편집하기 전에 리포지토리 지침, 현재 문서 및
.internal을 읽습니다. - 먼저
review.<slug>에 참여합니다. - 이 섹션에서 작성된 페르소나만 스폰합니다.
review-<slug>-engineer,review-<slug>-security및review-<slug>-critic을 스폰하고, 하중을 지탱하는 합의를 가진 두 좌석이 모델 제품군을 공유하지 않도록 배치합니다. 이는 위의 서수 규칙이지 인원 수가 아닙니다. 벤더 세트가 부족한 경우 충돌을 기계적으로 명명하고 그로 인해 커버되지 않는 클래스를 명명하세요. 명명은 공개이지 완료가 아닙니다: 하중을 지탱하는 승인이 동일 제품군 에코인 패널은 완료할 수 없습니다. 여기에는 A, A, A 및 A, B, A가 포함됩니다. 직원이 배치되었지만 충돌이 있는 패널을 통과 게이트로 취급하지 마세요. 각각 자체 분리된 워크트리를cwd로 제공하세요. 검토자는 자체 트리에서 평가하고, 평가 중인 트리에서는 절대 평가하지 않으며, "읽기 전용"은 명시적으로 git 쓰기 동사(checkout,switch,stash,reset,clean,restore)를 "소스 편집 금지"라고만 말하는 대신 명명해야 합니다. - 반환된 각 검토자 ID를 DM하여 채널에 참여하고 읽기/검토 전용으로 유지하도록 합니다.
- 편집 전에 계획 검토, 구현 후 코드/테스트 검토, 유효한 결과를 반영하고 세 명 모두에게 최종 처분을 요청합니다.
- 패널과 구현이 수렴된 후, 정확히 하나의
review-<slug>-freelance를 자체 분리된 워크트리에서 스폰하고cold-review스킬에 따라 브리핑합니다. 이 스킬은 해당 좌석에 무엇이 주어지고, 그 평결이 어디로 가며, 평결이 무엇을 바인딩하며, 벤더 세트가 부족할 때 규칙이 어떻게 저하되는지 소유합니다. 여기서는 그 어떤 것도 다시 설명하지 마세요. cold-review의 표준 규칙에 따라 콜드 결과를 해결하고, 해당 좌석에게 재고하라고 말하지 마세요. 관리자가 변경 사항을 작성했고 차단 요인이 독립적인 반박이 필요한 경우, 코디네이터에게 정확한 sha 결과와 아티팩트만 보내세요. 코디네이터는 자체 분리된 워크트리에서 새로운review-<slug>-referee를 프로비저닝합니다. 해당 좌석은 레인 작성, 평가 또는 감독에 참여하지 않았으며 작성자와 모델 제품군을 공유하지 않으며 작성자의 근거를 받지 않습니다. 코디네이터는 심판을 프로비저닝하지만 그 역할을 수행하지는 않습니다. 반영이 코드를 변경하는 경우, 결과를 채널 패널로 반환하여 다른 최종 패스를 수행하고 콜드 좌석을 새로운 sha로 다시 고정하며 전달 한도를 서면으로 명시적으로 재설정하세요. 해당 좌석이 사라진 경우, 빈 구독 및 allowSubscribe와 전용 기록 채널 allowPublish 부여만 있는 새로운 콜드 페르소나를 작성하고, 스폰한 후cold-review에 따라 새로운 sha에 대해 새로운 일회 전달 좌석으로 브리핑하세요. 이는 후속 좌석이지 이전 sha에 대한 세 번째 종료 경로가 아닙니다.- 헤드를 나중에 주장이 아닌 행동으로 재해결하세요. 브리핑 시, 완료 주장 시 및 병합 전에 관리자 또는 코디네이터가 먼저 검토 대상을 해결합니다. PR의 경우
git ls-remote origin refs/pull/<n>/head를 실행하고gh pr view <n> --json headRefOid를 교차 확인하세요. PR이 없는 브랜치의 경우git ls-remote origin refs/heads/<branch>를 해결하고 PR 전용 API 교차 확인은 생략하세요. 해결된 객체를 분리된 검토 워크트리로 가져오고(아직 없는 경우), 해당 객체에서git cat-file -t를 실행하고 알려진 양호한 제어 및 알려진 누락된 전체 너비 객체 ID(예: 40개의 0)로 실패해야 합니다. 실제 ID에 문자를 추가하여 음성 제어를 만들지 마세요: Git은 유효한 선행 객체 ID를 해결하고 성공을 반환할 수 있습니다. 도구를 실행한 행위자를 명명하세요. 해당 도구가 동의하지 않으면 중지하세요. 다른 sha를 명명하는 평결이나 반박은 이 헤드를 종료하지 않습니다. - 관련 테스트를 직접 실행하세요. 검토자는 소스를 편집하지 않습니다.
- 해결되지 않은 중요한 선택만 다음 정확한 구조로 에스컬레이션하세요:
DECISION NEEDED: <한 줄 질문>
Options: <A>; <B>; ...
Recommendation: <관리자의 권장 사항 및 이유>
Impact: <관찰 가능한 동작 / 호환성 / 위험>
Blocked: <진행할 수 없는 것>; Continuing: <진행할 수 있는 것>
- 완료 시 코디네이터에게 커밋 ID, 실행된 테스트, 세 패널 처분, 최종 콜드 평결 및 모든 공개 반박, 잔여 위험을 DM으로 보내세요.
4. 채널 시드 및 관리자 시작
팀을 초대하기 전에 패널 채널과 전용 콜드 기록 채널을 만들고, 재생을 활성화하고 짧은 운영자 메모를 추가하세요. 그런 다음 cotal_spawn을 통해 각 관리자를 스폰하세요:
name: mgr-<slug>
role: feature-manager
agent: <connector>
model: <pinned manager model>
cwd: /absolute/path/to/feature-worktree
모든 워크트리, 페르소나 및 채널이 존재한 후에만 관리자를 병렬로 시작하세요. 반환된 검토자 ID를 추적하고 가정된 이름이 아닌 것으로 하세요; 다시 시작되거나 중복된 시작은 페르소나 파일 이름이 레인 범위라도 여전히 자동 번호가 매겨질 수 있습니다.
cotal_roster로 모든 관리자가 나타나고 전체 패널을 보유하는지 확인하세요. 누락된 것처럼 보이는 중복을 조기에 스폰하지 마세요; 시작 시간을 허용하고 먼저 다시 확인하세요.
시간 초과를 보고하는 스폰은 스폰이 실패했다는 증거가 아닙니다. 이미 성공했을 수 있으며 재시도하면 효과를 중복하는 두 번째 목표를 제출합니다. 행동하기 전에 프로세스 목록에서 결과를 읽고 시간 초과만으로 재시도하지 마세요.
좌석을 REPLY로 확인하고 PRESENCE로 확인하지 마세요. 좌석이 실행 중으로 보고되면서 조용히 연결할 수 없을 수 있습니다. 좌석이 생성해야 하는 논스 아티팩트(예: 좌석이 있는 짧은 커밋에 결합된 임의 토큰의 echo)를 요청하고 원시 출력을 확인하세요. 예상 답변을 명시하는 핸드셰이크("당신이 에 에 있는지 확인하세요")는 유도적입니다: 에코 호환 응답은 무언가가 텍스트를 미러링할 수 있음을 증명하지만 셸이 실행되었음을 증명하지는 않습니다.
독립 검토자는 의도적입니다.
...