Kronuz/campaign

캠페인

리드(메인 세션)는 소유자의 목표를 퀘스트로 전환합니다. 기여자 에이전트는 각 퀘스트를 자체 브랜치에서 완료합니다. 기계 작업은 에이전트가 기다리지 않고 정확한 커밋에서 실행되는 작업 큐로 전송됩니다. 검토자 에이전트는 위험 수준에 따라 새로운 컨텍스트에서 퀘스트를 검사합니다. campaign land 는 모든 검사가 정확한 코드에서 통과되고, 각 기준에 명시된 증거가 있으며, 각 필수 검토가 해당 코드에 대해 수락된 경우에만 퀘스트를 main에 배치합니다. 중요한 모든 것은 저장소에 있으므로 리드를 포함한 모든 에이전트를 교체할 수 있습니다.

goals ─► PLAN ─► quests ─► campaign start ─► contributor ─► jobs (quiet) ─► evidence
                                                  │                              │
                                                  └─► reviewer (by risk) ─► accept ─► campaign land

불변 규칙

1. 증거, 서술이 아님. 검사는 작업이 병합되는 코드에서 실행한 경우에만 유효합니다. 저널 항목이나 검토자의 진술은 결코 통과된 테스트가 아닙니다.
2. 파일 세트당 하나의 작성자. campaign start 는 중복되는 파일 세트를 거부하고, land 는 퀘스트의 세트 외부 변경과 리드 파일 편집을 거부합니다.
3. 코드보다 먼저 기준. 리드는 각 퀘스트의 승인 기준과 각 기준에 필요한 증거를 작성합니다. 기여자는 이를 절대 편집하지 않으며, 변경된 퀘스트 파일은 이전 승인을 무효화합니다.
4. 검토는 위험을 따릅니다. 필요로 하는 위험당 하나의 새로운 검토자; 승인은 검토자가 본 코드와 검토의 정확한 내용을 포함합니다.
5. 어떤 것도 조용히 약화되지 않음. 위험 낮추기, 렌즈나 검사 제거, 검토 면제, CI 없이 병합 또는 수동 병합 기록은 사유가 필요하며 도구가 이를 기록합니다.
6. 상태는 파일에 저장됨. .campaign/<campaign>/ 와 git은 캠페인 실행 방식을 보유합니다. 제품의 내용은 설명하는 저장소의 docs/ 로 갑니다.
7. 에이전트는 기계를 기다리지 않으며, 측정은 격리 없이 실행되지 않습니다.
8. 소유자는 목표, 범위, 사용자에게 보이는 동작의 제거나 축소를 결정합니다. 리드는 나머지를 결정하고 PLAN.md 에 기록합니다. 캠페인은 기계를 임대하지 않거나 다른 과금 가능한 리소스를 생성하지 않습니다.

역할

역할	하는 일	작성하는 것
소유자 (사람)	목표, 비목표, 유보된 결정	PLAN.md 목표
리드 (메인 세션)	퀘스트 계획, 에이전트 실행, 검토 수락, 병합, 소유자에게 보고	state.json (campaign 을 통해서만), 퀘스트 파일, PLAN.md, main
기여자 (campaign-contributor 에이전트)	할당된 하나의 퀘스트 또는 작업	자신의 브랜치 및 저널
검토자 (campaign-reviewer 에이전트)	새로운 컨텍스트에서 하나의 렌즈를 통해 하나의 퀘스트	하나의 검토 파일

기여자의 할당은 작업 유형을 지정합니다. 구현 외 각 유형은 references/assignments/<name>.md 에 메서드가 있습니다. 리드는 매 실행 시 할당, 모델 계층 및 노력을 지정하며, 습관이 아닌 작업에 따라 선택합니다:

할당	용도	계층, 노력
implementation	구체적인 기준이 있는 기능 및 수정	economical, medium (낮은/보통 위험); strong, high (높음/심각, 또는 economical 시도가 중단된 후)
design	중요한 계획을 위한 퀘스트 목록, 형식, 프로토콜, 내구성, 동시성	strong, high; 고정 직전의 디자인은 max
research	드물게: 메커니즘 자체가 한계인 경우	strong, max
performance	프로파일링 및 최적화	strong, high
exploration	탐색 배치의 한 대상 또는 빠른 질문	economical, medium
documentation	문서, 가이드, README	economical, medium
maintenance	저장소 전체에 걸친 하나의 기계적 변경	economical, medium

검토자는 high 노력(심각한 퀘스트는 max)의 strong 계층을 사용합니다. 심각한 퀘스트 및 계획 검증의 경우, 하네스가 제공하는 경우 다른 모델 패밀리의 검토자를 사용합니다. 각 하네스의 계층별 모델은 references/harness.md 에 있습니다. 결과(campaign 사용량, 기준 충족, 재작업)에 따라 기본값을 변경하고 가격만으로 변경하지 마십시오. 리드는 작은 편집(5줄 수정, 사소한 충돌)을 직접 수행합니다. 실행에는 더 많은 비용이 듭니다.

캠페인 시작

1. 홈 저장소의 메인 체크아웃에서: campaign init --name NAME [--ci github]. 소유자는 .campaign/<campaign>/PLAN.md 에 목표, 비목표, 제약 조건 및 유보된 결정을 작성합니다.
2. 목표를 퀘스트로 분할: campaign new ID --title T --risk R --files GLOBS [--needs IDS] [--after IDS] [--provides C] [--consumes C] [--milestone M] --check NAME[:LEVEL[:MIN]]=CMD. 각 퀘스트 파일 (.campaign/<campaign>/quests/ID.md) 을 작성: 결과, 각각 필요한 증거가 있는 기준 A1... (아래 증거 참조), 계약, 결정, 조기 병합 가능한 내용.
3. 아키텍처가 중요한 경우, 한 명의 검토자(렌즈 design)가 어떤 것도 빌드되기 전에 계획과 퀘스트 목록을 검증합니다. 이것이 기다릴 가치가 있는 유일한 검토입니다.

퀘스트

• 크기: 검토자가 염두에 둘 수 있는 완전하고 의미 있는 동작을 전달하는 가장 작은 변경, 일반적으로 수백 줄에서 약 1,500줄. 더 큰 것은 분할; 자체 병합 가치가 없는 변경은 제공하는 퀘스트에 포함.
• needs 는 퀘스트가 시작되기 전에 병합되어야 함; after 는 퀘스트가 병합되기 전에 병합되어야 함. 퀘스트는 해당 의존성의 퀘스트 파일이 계약을 고정하는 경우에만 after 의존성에 대해 시작할 수 있음.
• 계약 (--provides, --consumes) 은 API, 형식 및 프로토콜을 지정하므로 campaign check 는 두 퀘스트가 하나를 건드리는 것을 감지.
• 작업: 하나의 퀘스트 내 병렬 작성자 (campaign start ID --task T --files GLOBS), 리드에 의해 퀘스트 브랜치에 병합됨. 퀘스트는 여전히 한 번 검토됨.
• 증분: campaign land ID --upto COMMIT --reason R 은 퀘스트 파일의 "조기 병합 가능"이 허용하는 접두사(동작 보존 리팩터, 테스트, 사용되지 않는 내부 API, 비활성화된 스위치 뒤의 코드)를 병합. 절대 조기 병합 금지: 디스크 또는 와이어 상의 바이트, 공개 API, 사용자에게 보이는 동작, 또는 검토가 존재하는 부분.
• 저장소 간 작업은 여러 퀘스트 (--repo PATH) 로 after 로 순서가 지정되며, 각 저장소의 커밋을 고정하는 통합 작업 (--ref NAME=PATH@REF) 이 있음. 병합은 순서대로, 원자적이지 않음: 각 중간 상태는 작동해야 함.
• 메시지: 기계의 모든 캠페인에서 작업 중이 아닌 퀘스트에 대한 발견 사항이 있는 에이전트는 campaign message NAME:ID "text" --from WHO 를 전송. 퀘스트는 해당 저널 중 하나가 id (msg-N) 로 응답하거나 리드가 닫을 때까지 (campaign message ID --close msg-N --reason R) 병합 불가; NAME: 는 해당 캠페인의 리드에 쓰며 병합을 차단하지 않음. 세부 사항 및 다른 기계: references/host.md, 메시지.
• 범위 변경: 새로운 요청은 먼저 퀘스트 파일(기준 또는 자체 병합 가능한 경우 자체 퀘스트)에 들어간 다음 기여자에게 전달; 대체된 작업은 campaign set ID status=dropped reason=....

직접 경로 우선

다음 단계를 결정하는 것만 차단합니다. 퀘스트의 게이트 검사 (--check: 빌드, 테스트, 위험이 요구하는 증거) 는 병합을 차단합니다. 지연 검사 (--later: 다른 플랫폼, 긴 담금, 전체 매트릭스, 확장 퍼징) 는 병합된 코드에서 낮은 우선순위로 대기열에 추가되며 마일스톤이 닫히기 전에 반드시 통과해야 합니다. 빨간색은 campaign check 의 오류입니다. 전진 수정 또는 되돌리기, 그런 다음 campaign verify ID --deferred 가 main 에서 다시 실행합니다. 높은 또는 심각한 위험이 필요한 증거(동시성을 위한 TSan, 디코더를 위한 퍼징, 내구성을 위한 충돌 모델)는 항상 게이트입니다. 느린 CI 워크플로우도 동일한 방식으로 게이트가 아닌 것으로 만들 수 있습니다 (campaign config ci_later=NAME,...).

퀘스트 실행

1. campaign start ID 는 자체 작업 트리에 저널과 함께 quest/<campaign>/ID 를 생성합니다. 기여자를 백그라운드에서 실행하여 메시지로 재개할 수 있도록 "기여자" 프롬프트 (references/prompts.md) 와 함께; 퀘스트가 준비되고, 분리되어 있으며, 동일한 기계를 기다리지 않는 경우에만 병렬로 실행합니다.
2. 기여자는 작업 트리에서 작업하고, 저널을 최신 상태로 유지하며, 작업으로 증거를 생성: campaign job submit --quest ID --level L --minutes M -- CMD 및 campaign verify ID. 작업만 남으면 해당 id를 기록하고 차례를 종료합니다.
3. 리드는 하나의 백그라운드 campaign wait --commits (작업 종료, 브랜치 이동 또는 메시지 도착까지 토큰 없음) 로 기다린 다음, 컨텍스트가 작을 때(약 150k 토큰) 메시지로 기여자를 재개합니다. 더 큰 컨텍스트 또는 재개할 수 없는 하네스는 저널 및 작업 기록에서 재구성하는 "재개" 프롬프트로 새 기여자를 얻습니다.
4. 저널이 "검토 준비"라고 말하면 리드는 status=review 를 설정하고 위험이 요구하는 검토자를 실행합니다. 각각 .campaign/<campaign>/reviews/ID-LENS.md 를 작성합니다. 리드는 차단 발견 사항을 id별로 기여자에게 전달합니다.
5. 검토가 승인하거나, 확인 작업(위험 및 검토) 후 변경 사항이 있는 경우 campaign accept ID LENS. 승인과 함께 검토 파일을 커밋합니다. 그런 다음 campaign land ID 는 퀘스트의 작업 트리, 병합된 브랜치 및 빌드 슬롯을 제거하고 유지한 것을 지정합니다.

탐색 배치

탐색할 가치가 있는 목록(새로운 벤치마크의 하위 행, 프로필의 핫스팟, 얇게 증명된 코드, 작은 버그의 백로그)의 경우, 현재 main 의 새로운 측정에서 여러 economical 기여자를 동시에 보냅니다. 각각 하나의 대상을, references/assignments/exploration.md 의 대상을 사용합니다. 배치 크기는 대상과 리드가 검토 및 병합할 수 있는 것에 따라 결정하며, 유휴 할당량에 따라 결정하지 않습니다.

위험 및 검토

위험 (첫 번째 일치 승리)	빌드 전	최종 병합 전
심각: 되돌릴 수 없음 (릴리스를 위한 형식 또는 프로토콜 고정, 사용자 데이터 마이그레이션, 사용자에게 보이는 동작 제거)	소유자 승인; design 검토	높은 위험 검토, 더하기 검토자가 직접 실행한 승인 증거
높음: 영구 형식, 와이어 프로토콜, 내구성, 동시성, 보안 표면, 공유 공개 API	결정을 되돌리기 어려운 경우 design 검토	주요 위험(durability, security 또는 correctness) 의 렌즈에 의한 한 번의 검토
보통: 일반 기능 및 수정	—	한 번의 correctness 검토, 또는 강력한 증거가 있는 작은 변경의 경우 --waive REASON
낮음: 문서, 테스트, 도구, 기계적 편집, 동작 보존 리팩터	—	검사 통과; 리드가 diff를 읽음

• 기본적으로 한 명의 검토자, 퀘스트가 제기하는 모든 위험 질문을 수용(프롬프트는 3~5개를 지정). 두 번째는 별도의 전문성 또는 독립성이 필요한 질문에 대해서만.
• 검토는 본 내용에 바인딩됨. 검토한 커밋(Commit:), 판정, 및 행당 ID, 차단 여부(예/아니오) 및 종류(결함, 격차, 사소함)가 있는 발견 사항 테이블을 지정. APPROVE는 해당 커밋의 코드를 포함; .campaign/ 만 건드리는 커밋은 유지. 승인 후 검토 편집은 승인을 무효화.
• 수정은 재검토가 아닌 작업으로 확인됨. 각 차단 발견 사항에 대해, 수정된 커밋에서 작업으로 프로브 또는 새 테스트를 다시 실행한 다음 campaign accept ID LENS --confirm C1=JOB --confirm C2=JOB. 작업은 퀘스트 저장소의 승인된 코드에서 통과한 경우에만 확인; 차단 결함은 변경된 코드가 필요; 도구는 동일한 프로브가 검토된 커밋에서 실패했는지 기록. 검토가 본 적 없는 파일을 변경하는 수정은 검토자에게 돌아감(검토는 수정된 커밋을 지정하고 승인), --fix-scope REASON 이 메커니즘을 추가하지 않는 이유(발견 사항에 대한 회귀 테스트)를 설명하지 않는 한.
• 두 번의 수정 라운드 후 중지. 세 번째는 퀘스트 또는 디자인이 잘못되었음을 의미: 재계획 또는 소유자에게 문의. 차단되지 않는 발견 사항은 후속 퀘스트가 되거나 사유와 함께 폐기.
• 디자인은 한 번 검토됨. 분쟁 동작은 다른 텍스트 라운드가 아닌 실행 가능한 모델 또는 테스트로 해결.
• 퀘스트가 통과해야 하는 것은 기록에 의해서만 변경됨: campaign set ID ... --weaken REASON 은 위험을 낮추거나, 렌즈를 제거하거나, 검사를 제거, 변경 또는 연기; 변경은 기록에 보관되며, campaign status ID 에 표시되고 승인을 무효화. 위험이 요구하는 검토(낮음 이상의 코드 검토, 심각한 경우 디자인 검토)는 제거할 수 없으며, 검토가 존재하면 면제가 거부됨.
• 이벤트에 따른 시스템 검토, 달력이 아님: campaign check 가 두 퀘스트가 하나의 파일 또는 하나의 계약을 변경한다고 보고할 때, 한 명의 검토자(렌즈 system)에게 특정 질문.
• 수율: campaign status --reviews 는 판정 및 차단 결함을 계산. 특정 종류의 약 5개 퀘스트에서 실질적인 것을 찾지 못한 선택적 검토(보통 위험)는 해당 종류에 대해 폐기; 높음 및 심각한 검토는 수율에 의해 폐기되지 않음.

증거

퀘스트 파일의 각 기준은 필요한 증거를 지정; 저널의 증거 테이블은 기준당 한 행을 제공하며, 병합은 병합되는 코드에서 각 행을 확인:

기준	행은 다음을 지정해야 함
- A1 ... (태그 없음)	해당 코드에서 통과한 작업(동일하거나 다시 실행된 작업)
- A2 [artifact] ...	퀘스트 저장소에 커밋된 path
- A3 [decision] ...	PLAN.md 의 결정 테이블에 있는 id
- A4 [manual] ...	수동으로 확인한 사람 및 내용; 수동으로 표시되며 자동 증거가 아님

증거는 주장에 비례합니다 (references/review.md): 테스트는 값이지 개수를 확인; 수정에는 없으면 실패하는 테스트가 있음; 주장에는 돌연변이를 죽이는 테스트가 있음; 별도 빌드의 새니타이저. 성능 주장은 references/measurement.md 를 따릅니다: 지정된 커밋에서 이전 및 이후, 무엇이든 결정하는 숫자에 대해 exclusive, 정직한 크기.

기계 작업

수준	용도	격리 (quiet)
none	아주 작은 단일 스레드 프로브	보류 없음
light	빌드, 테스트 스위트, 퍼징	한 번에 몇 개, nice 19
strict	연기 타이밍, 동작 실행	Linux에서 자체 코어; macOS에서 단독
exclusive	결정하는 숫자 (측정)	전체 기계 (다른 작업 대기)

작업 격리: campaign job submit --level L (또는 --check 의 MIN) 은 필요한 격리를 설정. campaign wait --commits 는 작업이 완료되면 깨어납니다. campaign status --jobs 는 실행 중인 작업을 보여줍니다.

병합

campaign land ID:

• 퀘스트의 files 와 일치하고 어떤 after 의 files 와도 일치하지 않는 커밋된 파일만 가져옴.
• 각 기준에 대해: 저널의 증거 행이 병합되는 커밋에서 유효한 증거를 지정하는지 확인.
• needs 및 after 의 체크가 여전히 녹색인지 확인.
• 검토가 필요한 경우: 최근 승인된 검토 파일이 존재하고 해당 커밋을 포함.
• 모든 게이트 검사 통과. 지연 검사는 대기열에 추가.
• main 에 빠르게 병합하고, 작업 트리와 브랜치를 정리.

병합이 실패하면(충돌, CI 실패) campaign land 가 롤백하고 문제를 기록합니다.

명령어

명령어	용도
init	새 캠페인 생성
new	퀘스트 정의
start	퀘스트 작업 트리 생성 및 기여자 시작
job submit	작업 제출
job status	작업 상태 확인
wait	작업 완료 대기
status	캠페인 상태 표시
accept	검토 승인
land	퀘스트 병합
message	에이전트 간 메시지 전송
set	퀘스트 속성 변경
check	캠페인 일관성 확인
verify	증거 재확인

참조

• references/prompts.md: 에이전트 프롬프트
• references/assignments/: 할당 메서드
• references/harness.md: 하네스 모델
• references/host.md: 호스트 세부 사항 -references/review.md: 검토 가이드라인 -references/measurement.md: 측정 규칙