공유 정책 위치: docs/DISCOVERY.md, docs/WORKFLOW.md,
docs/LAUNCH-MIGRATION.md, docs/STANDALONE-ENTRY.md, docs/PROCESS.md, docs/using/README.md 및 docs/using/mirrors.md는
해당 Hatsu 플러그인 루트에 속하며, 소비 저장소에 속하지 않습니다.
설치된 서페이스에서는 ten이 출력하는 절대 루트 경로를 사용하여 해당 파일을 읽으십시오(사용 불가 시 해당 스킬을 통해 다시 확인).
아래의 상대 링크는 소스 위치를 식별합니다. 소비 저장소에 docs/ 복사본이 없다고 해서 정책이 누락된 것이 아니며,
중복 파일링을 유발해서는 안 됩니다. 대상 저장소에 두 번째 정책을 절대 복사하거나 생성하지 마십시오.
En — 하나의 PR이 Ready 상태가 될 때까지 그것을 중심으로 유지하는 순환
성격: 조작자(Manipulator). En이 하는 모든 일은 보드(boad-facing) 중심입니다 — 주도(driving), 보고(reporting), 알림(ringing), 관찰(watching). Kurapika가 실행할 때 그렇게 말합니다. 주기가 그를 다시 변경 자체로 보낼 때 — 즉, 코드 수정이 필요한 리뷰어의 소견(finding)이 있을 때 — 그 수정을 위한 모드는 변경 사항 자체의 모드(강화자(Enhancer), 구체화자(Conjurer), 변환자(Transmuter))이며, 해당 주기에 대해 큰 소리로 명명되고 이후 다시 핸드오프됩니다.
이 PR에 집중하십시오: 보고하고, 모든 현재 헤드 체크와 리뷰를 관찰하고, 검증된 Ready 상태로 주도하고, 인간 게이트에 한 번 알리고 — 최대 N번의 실행 주기 후에 중단하십시오.
En은 로컬 플레인의 마지막 합성체이며, PR이 열린 순간 이후에도 주의를 유지해야 할 수 있는 유일한 스킬입니다.
$mukai는 이 핸드오프를 제안하며 종료됩니다 — nen/workflow.json → mukai.autoEn 설정 하에서만 스스로 시작합니다(판결 2026-09-28);
그 시점부터 PR은 En에 속합니다 — 그리고 autoEn 경로에서만 여전히 활성화된 사용자 턴을 가지며, 제안에서의 입력된 시작은 그 자체의 턴입니다 — Sharingan이 Ready를 증명하거나,
구체적인 차단/상한/종료 상태/취소가 En의 실행을 끝낼 때까지입니다. 병합은 § 5의 기록된 Futon 딜리버리 예외를 제외하고는 메인테이너의 이후 행위입니다. 이 실행은 수확(harvest)하지 않고 정리(clean)하지 않습니다. En이 완료되면, 호출자는
마무리 단계(wrap-up) 를 선택기(picker)를 통해 제안합니다(cleanup § 2, 행 wrap-up; 판결 2026-10-13) — 오직
cleanup § 2의 두 가지 전제 조건 하에서만 가능합니다(HR-366); § 5의 프롬프트에서 Ready PR은 어느 전제 조건도 충족하지 않습니다:
$cleanup, 필수, $third-hand는 선택 사항으로 함께 제공됩니다 —
별개의 스킬들이며, 이 파일의 프로토콜이 반환된 후에 시작되며, En의 단계로 절대 시작되지 않습니다.
이 파일은 구성(compose)합니다. 재명세(re-specify)하지 않습니다. 아래의 모든 단계는 다른 스킬의 것이며, 이름이 명시되고 링크되며, 그 절차, 종료 코드 반응, 거부 및 잔여물은 해당 위치에 있습니다. 여기서 실제로 그 스킬의 규칙을 발견했다면, 그것은 잘못된 파일에 있는 것입니다 — 해당 규칙이 작성된 곳으로 가서 읽으십시오. 두 곳에 재진술된 규칙은 그중 하나에서 표류하기 때문입니다.
진정으로 En 고유의 것은 상한(cap), 감시의 형태(watch's shape), 그리고 세션 종료 시의 경계(boundary)입니다. 이 세 가지는 § 2, § 6 및 § 7이며, 이 파일이 무언가를 주장하는 유일한 곳입니다. Third-Hand는 그 경계 안에 있지 않습니다.
1. 호출(Invocation)
P1 — 이 실행은 $ten en으로 시작됩니다 (ten § 6이 이 단계의
누락된 전제 조건을 자체 이름으로 따라잡습니다(catches up); 이 실행이 호출하는 단계들은 자신의 것을 건너뜁니다).
$en [on <CODE>#<N>]
$mukai에 의해 절(clause) 없이 mukai.autoEn 하에서 시작됨 — PR은 방금 8단계가 연 것입니다 —
$getsuga § 3에 의해 방금 연 릴리스 제안을 위해 시작됨 (거기서 en은 1-5단계를 실행하고 인용된 평결(verdict)을 getsuga에 반환합니다; 6단계의 종은 울리지 않습니다.
왜냐하면 getsuga § 3a가 해당 PR의 병합이기 때문입니다), futon의 이슈별 체인에 의해 해당 노력이 연 PR을 위해,
또는 통합→메인 PR을 위해 시작됨 (futon § 5는 통합 브랜치로 PR을 열지 않습니다; 거기에 로컬로 병합합니다), 또는 메인테이너에 의해,
이미 열려 있는 PR을 명명하며 시작됨 (mukai의 제안 라인). 세션이 열거나 열게 하는 모든 PR이
이 실행을 통해 또는 평결을 인용하여 메인테이너에게 도달해야 한다는 규칙은 docs/PROCESS.md § 단계 보고(Reporting a phase) 의
(zheref/hatsu#103) 인용이며, 재진술되지 않습니다:
nen parse en --grammar "on [<ref>]" --line "<호출, $en 접두사 제외>"
v0.3.0 (docs/ab/en.md § 2.1)에서 라이브 검증됨: on HA#41 → ref: HA#41 종료 0, 그리고 베어
on은 절이 없이 파싱되며, 역시 종료 0입니다. 절은 리터럴 뒤에 고정됩니다. 그 이유는
$spiritual-message § 1이 기록하는 바와 같습니다 — 괄호로 묶인 단일 슬롯은 템플릿에서 거부됩니다.
빈 줄은 거부되며, 이것이 합성체가 전혀 파싱되지 않는 이유입니다. 라이브 검증됨:
--line ""은 종료2와 함께 "라인은 리터럴 'on'으로 열려야 합니다 — 그것이<ref>를 도입하기 때문입니다" 를 출력합니다. 고정된 선택적 절은 앵커가 필요합니다; "절 없음"과 "빈 줄"은 서로 다른 입력이며, 첫 번째만 파싱됩니다. 따라서mukai는autoEn하에서 PR을 직접 핸드오프하고nen parse en을 전혀 호출하지 않습니다 — 아무도 입력하지 않은 라인의 파싱을 에코하는 것은 연극(theatre)일 것이며,""을 제공하는 것은 아무 의미 없는 거부를 생성할 것입니다. 파싱은 메인테이너가 절을 입력했을 때에만 실행됩니다.
누락된 인수 또는 구성 항목은 인라인으로 요청되고 설정됩니다 (missing-argument,
missing-configuration; WORKFLOW.md § 4 질문하고, 설정하고, 계속(Ask, set up, continue)):
메인테이너의 라인이 종료 2이거나, 세션이 보유한 PR이 없는데 PR을 명명하지 못한 경우, 피커에서 세션의 열린 PR을 제공하고
답변에 따라 재개하는 트리거가 되며, 실행 종료가 아닙니다.
코드를 한 번, 사전에 확인하고, 이후 모든 호출을 위해 슬러그(slug)를 유지하십시오 — 절대 두 번째 방식으로 다시 유도하지 마십시오 (claude/agents/kurapika.md § How you work):
nen repo resolve <CODE> --repo <대상 저장소 자체 체크아웃 경로>
nen ref format --code <CODE> --kind PR --number <N>
닫히거나 병합된 PR은 그 PR에 일어난 일과 함께 즉시 실행을 종료합니다. 대기할 것이 없습니다.
헤드가 이미 게시된(published) 열린 PR은 모든 연속(continuation)에서 En에 남아 있습니다. 해당 브랜치가 PR 베이스보다 뒤처지거나,
리뷰 수정 사항을 게시해야 하는 경우, En의 현재 트리 증거 단계와
$murasaki의 보호된 빨리 감기 푸시(§ 3 및 murasaki § 6)를 실행하십시오.
게시된 브랜치를 $aka의 스쿼시를 통해 보내지 마십시오. 첫 번째 게시는
호출 워크플로우가 이미 가지고 있는 권한을 따릅니다. 직접 Aka 호출이든 Futon과 같은 합성체든 상관없습니다.
En은 여전히 § 5의 별도 인간 병합 게이트에서 중단됩니다. 예를 들어, PR #274는
b5fddea에서 이미 게시된 상태였고 #273이 main을 진행시켰을 때; 그 따라잡기 병합은
그 게시된 계보를 보존했고 Murasaki는 검증된 후손 5de39c5를 푸시했습니다.
이 합성체가 호출하는 단계들은 자신의 ## 0. 독립 실행 진입(Standalone entry) 섹션을 건너뜁니다. docs/STANDALONE-ENTRY.md는
임의의 체크아웃에 수동으로 입력된 단계에 대한 계약입니다. 여기서 도달한 단계는 이 실행의 P1–P4(워밍업, 오리엔테이션, 변경 세트 및 모든 파생 인수)를
상속받으며, 이를 다시 유도하는 것은 이 합성체가 이미 해결한 질문에 대한 두 번째 답변을 생성할 것입니다.
각 단계는 어떤 합성체가 대신 그것을 보유하고 있는지 명시합니다.
2. 상한(Cap) — 문법, 기본값 아님
En은 행동합니다. 2단계와 4단계는 주도합니다(drive); 새로운 리뷰 소견을 발견한 주기는 변경 사항으로 돌아가서
수정을 푸시합니다. 이것은 en을 루프 쌍의 변이(mutating) 절반으로 만들며,
$izanagi의 전체 규율이 바인딩됩니다: 쓰기가 필요한 루프는 읽기만 하는 루프가 필요로 하지 않는 바인딩(bound)이 필요하며,
바인딩을 문법의 일부로 만드는 것은 그것이 절대 기본값으로 설정되거나, 상속되거나, 잊혀질 수 없음을 의미합니다.
| 키 | 파일 | 용도 | 키(또는 파일)가 없을 때의 기본값 |
|---|---|---|---|
monitor.maxCycles | nen/workflow.json | 상한 — 실행(acting) 주기(§ 6)의 횟수 | 20 |
monitor.pollSeconds | nen/workflow.json | 관찰 간 간격, --interval-ms로 전달 | 300 (→ --interval-ms 300000) |
branch.base | nen/workflow.json | § 5가 프롬프트하는 베이스. 3단계가 따라잡고, "뒤처짐"은 PR 자체의 baseRefName(gh pr view <N> --json baseRefName)에 대해 측정되며, 이는 en이 프롬프트하는 모든 PR에 대한 branch.base입니다 | main |
reports.dir / .sections / .retain | nen/workflow.json | 7단계의 파일 — backlog-board § 3의 키 | Reports / 필수, 기본값 없음 (WORKFLOW § 2 → reports) / final-only |
notifications.rungs / .sound | nen/workflow.json | 6단계의 단계(rungs) — $jutaisho의 키 | ["push","os","sound"] / Glass |
주기 1 전에, 상한은 누락된 것을 거부하는 동사를 통해 명시됩니다:
nen parse izanagi "take <CODE>-PR-#<N> to its human gate until it is Ready up to <monitor.maxCycles>"
v0.3.0 (docs/ab/en.md § 2.2)에서 라이브 검증됨, 양방향:
$ nen parse izanagi "take HA-PR-#41 to its human gate until it is Ready up to 20"
task: take HA-PR-#41 to its human gate
until: it is Ready
cap: 20
exit=0
$ nen parse izanagi "take HA-PR-#41 to its human gate until it is Ready"
nen: no 'up to <N>'. Izanagi is the MUTATING half of the loop pair and the cap is required grammar,
never defaulted or inferred -- an invocation without it is refused rather than run once 'to see'.
try: take HA-PR-#41 to its human gate until it is Ready up to <N>
exit=2
값은 monitor.maxCycles에서 옵니다; 요구 사항은 문법에서 옵니다. 이것들은 두 가지 다른 것이며, 그 구분이 핵심입니다:
파일은 숫자를 제공하고, 동사는 숫자 없이 실행을 거부합니다. monitor 블록이 누락된 저장소는 20을 큰 소리로 명시하여 받습니다 —
무제한 감시를 받지 않습니다. "파일이 아무 말도 하지 않았다"는 경우가 정확히 상속되고 잊혀진 기본값이 위험한 경우이기 때문입니다.
nen
0.7에서 폐기됨: 실행 주기를 수동으로 계산하기모든 실행 주기는 행동하기 전에 CLAIM(청구)되며, 상한은 청구가 거부됨으로써 강제됩니다 —
izanagi§ 3의 폐기, 전체 상속:git rev-parse --path-format=absolute --git-common-dir # <common>, 작업 워크트리 내 nen loop iterate --id en-<CODE>-<N> \ --line "take <CODE>-PR-#<N> to its human gate until it is Ready up to <monitor.maxCycles>" \ --repo <common>종료
0은iteration <n>/<cap>과 남은 횟수를 출력합니다 — 동사 자체의 단어는 iteration이며, en의 주기가 그것이 청구하는 것입니다; 종료1이 상한(CAP) 이며, § 6의 상한 도달 행에서 실행을 종료하고, nen 자체 거부에 명명된 호출과 함께합니다.--line은 위에서nen parse izanagi가 에코한 동일한 문자열이며, 매 청구마다 재진술되므로,monitor.maxCycles는 실행 중에 조용히 올려질 수 없습니다: 다른N을 운반하는 청구는 두 라인을 모두 명명하며 종료2입니다 (정확히 이 형태에 대해 라이브 검증됨 —up to 3실행 중,up to 20청구 —docs/ab/izanagi.md§ Retired at nen 0.7).
--id는 세션이 아닌 풀 리퀘스트(PULL REQUEST)입니다, 그리고 이는 언급할 가치가 있는 결과를 가진 결정입니다: 원장(ledger)은 git 공통 디렉토리 아래의.nen/loop/en-<CODE>-<N>.json이므로, 세션(§ 7)과 정리가 제거하는 작업 워크트리보다 오래 지속됩니다 (docs/ab/en.md§ The cap outlives the worktree), 따라서 동일한 PR에 대해 다시 호출된$en은 주기 1부터 다시 시작하는 대신 동일한 상한을 재개합니다. 그것이 "이 PR을 Ready 상태로 만들기 위한 20번의 실행 주기"의 정직한 해석입니다 — 세션 경계 재설정이 있을 경우 아무도 갖지 못할 상한입니다. 준비 상태 유도가 진정으로 종료될 때 — Ready, 종료됨, 또는 게이트에서 메인테이너에게 핸드오프됨 — 다음으로 원장을 닫으십시오:nen loop iterate --id en-<CODE>-<N> --line "<같은 라인>" --release "<이유>" --repo <common>; 상한에 도달한 루프는 항상 해제될 수 있으며, 그 후의 새로운 상한은 새로운--id이며, 신중하게 선택되고 큰 소리로 말해지며, 절대 다시 입력된 라인이 아닙니다.
상한은 목표가 아니라 최대치(ceiling)입니다. 상한에 도달하는 것은 Ready 도달 실패이며, 그렇게 보고됩니다:
무엇이 여전히 참이 아니고, 다음 주기가 무엇을 했을 것인지. izanagi § 4의 규칙, 변경 없음.
리뷰어 라운드 정책은 $sharingan § 6의 것이며, 거기에 한 번 명시되고 여기에 인용되며, 절대 재진술되지 않습니다:
- Copilot 라운드 하나는
$hanten이 안정된 후에 요청되며, 절대 그 전에 요청되지 않습니다. - 도착(arrivals)은 수정(remediated)되고, 지불된 라운드는 sharingan § 6의 두 가지 범위 내에서만 묻지 않고 재요청됩니다 (
round_policy.maxRounds요청,round_policy.minRounds해결됨; 행cap-reached), 그 후 en은 계속 관찰합니다; 어느 범위에 도달하면 § 6의 다섯 번째 중지입니다. - 재요청 전에,
nen wake verify --repo-slug <소유자/이름> --now <ISO> --author-pattern <메인테이너 로그인> --run이 한 번 삼켜진 실행을 다시 주도합니다 (action_required또는startup_failure로 실행되지 않은 것); Copilot 봇에 의한action_required실행은 재시도할 수 없으며 그렇게 보고됩니다. 그런 다음 무작동 동기화 가드: 마지막으로 리뷰된 헤드보다 앞선 커밋 수를 계산하고 (git rev-list --count <reviewed-head>..HEAD, 읽기 전용) diff 통계를 계산합니다; 리뷰 가능한 변경 사항이 0이면 요청이 없습니다. - Copilot은 모든 푸시를 자동 리뷰하므로, 상한은 요청을 제어하고 도착을 제어하지 않습니다; 상한을 지난 도착은 여전히 수정되고 해당 스레드는 해결됩니다.
최대치를 넘으면 실행은 not-ready 상태로 보드와 함께 종료됩니다. 어느 쪽도 G5가 아닙니다. nen/workflow.json →
monitor.maxCycles는 en의 실행 주기 상한이며, 다른 숫자입니다.
3. 실행 순서(The run, in order)
| # | 단계 | 해당 스킬 | 시기 |
|---|---|---|---|
| 1 | 착륙 보고(landing report) | $spiritual-message as landing | 한 번, 시작 시 — 00–07 및 08 PR 본문 및 09 준비 상태(Readiness). 이 En이 mukai(autoEn)에 의해 시작되었거나 동일한 자리에서 더 새로운 인간 요청 없이 그 제안에서 입력된 경우, 00은 여전히 해당 mukai 요청에 응답합니다 |
| 2 | 주도(drive) | $sharingan | 첫 번째 차단 조건... |
...(본문이 길어 일부 생략됨)...