공유 정책 위치: 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 플러그인
루트에 속합니다. 설치된 표면(surface)에서는 ten이 출력한 절대 루트를 사용하여 해당 파일을 읽으십시오(사용 불가 시 해당 스킬을 통해 재확인). 아래의 상대 링크는 소스 위치를 식별합니다. 소비자의 docs/ 사본이 없다고 해서 정책이 누락된 것은 아니며, 중복 신고를 유발해서는 안 됩니다. 대상 저장소에 두 번째 정책을 복사하거나 생성하지 마십시오.
Ren — 하나의 요청, 하나의 턴, 항상
고정 모드 없음. Ren은 구성된 실행(run)입니다. 모드는 요청이 무엇이냐에 따라 결정됩니다 —
프로덕션 코드의 경우 Enhancer, 표준(캐넌)의 경우 Conjurer, 기계(메커니즘)의 경우 Transmuter — 턴 동안 유지되며 응답에 명명되고, 턴의 보고 단계가 실행되는 동안 Manipulator가 함께 명명됩니다. 현재 적용 중인 모드를 명명하고, 전환 시점과 이유를 설명하며, 하나의 헤더 아래 두 모드를 혼용하지 마십시오(claude/agents/kurapika.md).
요청을 받으십시오. 첫 번째 요청이면 준비하고, 작성하고, 증명하고 커밋한 다음, 런치를 처리하고, 보고서를 보여주고, 한 번 알람을 울리십시오. 그런 다음 대기하십시오.
Ren은 로컬 플레인에서의 일반적인 작업 형태입니다. 배치 실행기나 감시자가 아닙니다: 한 번의 호출은 하나의 요청이며, 하나의 요청은 하나의 턴입니다. 루프는 다음 요청이 다음 턴을 시작하며, 준비 단계는 이미 수행된 상태입니다.
이 파일은 구성을 제공합니다. 재명세하지 않습니다. 아래의 각 단계는 다른 스킬에 속하며, 이름과 링크가 명시되어 있고, 그 절차, 종료 코드 반응, 거부 및 잔여물은 해당 스킬에 정의되어 있습니다. 여기서 해당 스킬의 규칙을 발견했다면, 이 파일이 잘못된 위치에 있는 것입니다 — 해당 스킬이 작성된 곳으로 가서 읽으십시오. 두 곳에 반복된 규칙은 그중 하나에서 부정확해집니다.
1. 호출
P1 — 이 실행은 $ten ren으로 시작합니다 (ten § 6은 이 단계의 누락된 전제 조건을 자체 이름으로 보충합니다; 이 실행이 호출하는 단계들은 자체 전제 조건을 건너뜁니다).
$ren <request> [--profile fast|standard|thorough]
nen parse ren --grammar "<request> [--profile <profile:fast|standard|thorough>]" \
--line "<the request, minus the $ren prefix>"
profile: (clause absent)는 profile.default를 의미합니다(§ 2a). 요청 내의 "fast turn" 또는 "thorough turn"이라는 단어는 동일한 재정의로 간주됩니다.
v0.3.0(docs/ab/ren.md § 2.1)에서 라이브 검증됨: 요청 라인은 종료 코드 0에서 request: <전체 라인>으로 파싱되며, 빈 라인은 종료 코드 2에서 거부합니다 — "는 필수이며 라인에서 제공되지 않습니다" — 수정된 라인이 출력됩니다. 요청이 없는 턴은 세션이 마지막에 수행 중이던 작업에서 유추되지 않습니다. 자유 텍스트로 요청됩니다: 요청은 메인테이너의 말입니다(행 missing-maintainer-choice, nen stop answer를 통해 기록됨, docs/WORKFLOW.md § 4 메인테이너의 말은 절대 유추되지 않음). 따라서 세션이 제안하는 모든 해석은 참조용으로 나열되며, 별표 표시나 선택 옵션이 없으며, 턴은 메인테이너가 입력한 내용에 따라 실행됩니다.
Ren은 명시적 호출뿐만 아니라 기본 형태이기도 합니다. nen/workflow.json이 이 루프를 설명하는 저장소에서 메인테이너의 일반 요청은 ren 턴입니다. 첫 번째 요청에서 이를 명시하여, 마지막에 보고서와 알람이 제공되는 것에 누구도 놀라지 않도록 하십시오.
2. 턴의 순서
| # | 단계 | 소유 스킬 | 여기에 있는 이유 |
|---|---|---|---|
| 1 | 준비(warm up) | $breath | 모든 진입 시 격리 바인딩/재확인 WORKFLOW § 워크트리가 위치한 곳에 따라, Ten 보충(catch-up) 또는 변경 전에 수행; 해당 체크아웃에서 새로운 effort당 한 번 신선한 브랜치를 준비하고 증명 — 관찰된 훅 거부(HR-374) 시 세션 자체 하니스 워크트리. 명시적 연속(continuation)은 검증된 effort 소유 워크트리만 재사용합니다. 빨간색 베이스는 작성 전 G5입니다; 구성 확인(breath § 4a)의 충돌 절도 마찬가지이며, 이 단계의 원장 항목에 기록됨 |
| 2 | 변경 사항 작성 | $rasengan | 메인테이너가 요청한 내용을 이 저장소가 선언한 스택에 작성: 편집, 그 옆의 테스트, 컨벤션이 요구하는 문서 및 변경 로그 — 선언된 iteration.checks를 작성자의 피드백으로 실행하면서 작업 진행 중 |
| 3 | 검증 및 커밋 | $kokusen | 모든 저렴한 iteration.checks 동사와 완료된 트리에 대한 선언된 집중 테스트 실행, 빨간색은 거부됨; 그런 다음 분류, 플래그가 지정된 항목에 대한 질문, 하나의 정형화된 커밋 — 로컬 전용 |
| 4 | 런치 | $amaterasu | 격리된 effort가 dry-run 명령을 보고하고 core launch deferred; explicit maintainer call required를 기록한 다음, 질문하지 않고 계속 진행, 직렬인 경우에도 마찬가지. 대상 없음 → no launch target declared; skipped. 코어 런치는 작성이나 전달을 바인딩된 워크트리 밖으로 이동시키지 않음 |
| 5 | 보고 | $spiritual-message as turn | 페이지: 완료된 사항, 과제, 전달되지 않음, 아키텍처, 스크린샷, 정확한 런치 명령, 결정 사항 |
| 6 | 알람 | $jutaisho (§ 1은 페이지의 요청이 중단(stop)인지 결정) | 워크플로우가 선언한 단계 — 그리고 진정으로 중단이 필요한 경우에만 중단 |
2단계는 변경 사항 그 자체이며, 2026-09-10부터 절반 번호가 매겨지지 않았습니다. 이 테이블은 이전에
1.5단계 — "작업", 소유 스킬 없음 —를 2단계 옆에 가지고 있었으며, 2단계는 빌드라고 불리며rasengan을 빌드 명령 실행이 아닌 *빌드(제작)*으로 읽었습니다. 메인테이너의 판결(docs/ROSTER.mdHR-55)이 이를 확정합니다:rasengan은 작성 단계입니다. 따라서 작업에는 스킬이 있고, 여섯 개의 정수는 다시 여섯 개의 스킬이며, 커밋 전 컴파일은 트리를 스테이징하는 단계에 속합니다.
순서는 다섯 곳에서 중요하며, 그 다섯 곳만이 ren이 주장하는 유일한 순서입니다:
- 1 다음 2 — 검증되지 않은 베이스에서 작성하지 않음. Breath는
origin/<branch.base>의 새로 가져온 최신 커밋에서 브랜치를 생성하고 선언된 검사를 실행합니다. 따라서 변경 사항의 첫 줄은 이미 빌드가 확인된 트리에 적용되며, 누구나 보는 첫 번째 빨간색은 이 effort가 발생시킨 것입니다. 빨간색 베이스 최신 커밋은 그 시점에서 G5 중단이며, 한 줄도 작성되기 전입니다. 이 effort 내에서 수리되지 않습니다. breath § 4a의 구성 확인도 마찬가지이며, 그 게이트는 breath § 6에 명시되어 있습니다(WORKFLOW.md§ 구성 확인). - 2 다음 3 — 이 턴에서 작성되고 검증되지 않은 것은 커밋되지 않음. Rasengan은 변경 사항을 작성하고 자체 내부 루프를 정직하게 유지합니다; 그런 다음 kokusen은 완료된 트리에서 선언된 검사를 실행하고 빨간색에서는 커밋을 거부합니다. 두 실행은 중복이 아닙니다: 작성자의 마지막 검사 이후 작성된 모든 라인에 따라 트리가 이동하므로, 커밋이 의존할 수 있는 유일한 실행은 인덱스를 보유하는 단계가 수행한 것입니다. 턴이 반복되는 경우(작성, 확인, 다시 작성), 이는 2단계가 자체적으로 반복되는 것이며, 3단계는 한 번만 진입합니다.
- 3 다음 4. 런치 처리는 커밋된 결과를 따릅니다; 격리는 코어 런치를 승인하지 않습니다. 지연된 명령은 이 effort의 트리 시연이 아닙니다.
- 4 다음 5. 보고서는 지연된 dry-run 명령과 실제 실행된 argv를 구분합니다.
- 5 다음 6. 알람은 보고서의 링크를 전달합니다. 페이지가 존재하기 전에 울리는 알람은 메인테이너를 빈 곳으로 보냅니다.
이 복합체가 호출하는 단계들은 자체의 ## 0. 독립 실행 항목 섹션을 건너뜁니다. docs/STANDALONE-ENTRY.md는 임의의 체크아웃에 수동으로 입력된 단계에 대한 계약입니다; 여기에서 도달한 단계는 이 실행의 P1–P4를 상속받습니다 — 준비, 방향 설정, 변경 세트 및 모든 파생 인수 — 재파생은 이 복합체가 이미 해결한 질문에 대한 두 번째 답변을 생성할 것입니다. 각 단계는 대신 어떤 복합체가 이를 보유하고 있는지 명시합니다.
1단계 내에서, 분류된 effort당 한 번, $direct가 실행됩니다 — 요청에 이슈(<CODE>#<N>)를 명명하거나 이미 레이블이 지정된 텍스트 분류가 있는 effort의 경우 — 이 세션의 --surface, --model 및 --effort(하니스가 숨긴 경우 unread)를 사용하여, build § 2b와 동일하게 수행합니다; § 6은 비교와 한 번의 질문을 소유하며, 입력된 $ren은 이미 여기서 작업하기로 한 결정이므로 절대 차단하지 않습니다. 답변 B는 이 턴을 종료하지만 루프는 종료하지 않습니다: 5단계와 6단계는 계속 실행되며 보고서는 재시작 라인을 명명합니다. job/ 레이블이 없는 effort는 undirectable, 한 줄이며 턴은 계속됩니다. 이것은 일곱 번째 단계가 아니며 자체 순서를 주장하지 않습니다: 준비 내에서 읽고, 최대 한 번 질문하며, 아무것도 작성하지 않습니다 — 그리고 § 7 게시 단계는 여기서 실행되지 않습니다: Ren은 머신을 떠날 수 없으므로(§ 3), 판결은 보고서와 로컬 원장에 남으며, direct.publish는 build, file(파일링 후) 또는 독립 실행에서만 작동합니다.
준비는 effort당 한 번 실행됩니다; 체크아웃 선택은 모든 진입 시 확인됩니다. 이후 턴과 PR 단계는 바인딩된 절대 effort 경로를 $hatsu_root/docs/WORKFLOW.md § 워크트리가 위치한 곳에 따라 재확인합니다, 2단계 또는 보충 전에. 경로, 원래 프롬프트 면제 상태, Breath가 준비했는지 또는 재확인만 했는지 보고하십시오. 연속은 절대 격리를 우회하지 않습니다.
새 요청은 호출자가 현재 effort를 명시적으로 계속하지 않는 한 새로운 effort입니다. 이전 effort의 깨끗한 기능 브랜치에 앉아 있는 것은 연속이 아닙니다
(zheref/hatsu#60; $breath
§ 2a). Breath는 여전히 실행되고, 구성된 베이스를 가져오고, 새로 렌더링된 브랜치를 생성합니다. 재사용은 명시적인 "계속" / "동일 effort" / "이 브랜치에서" 또는 1단계가 이미 이 브랜치를 이 세션에서 생성한 루프의 2+ 턴에서만 가능합니다.
이 effort의 이후 턴, 또는 $mukai가 $hanten에 재진입할 때, 동일한 사이클 원장을 재사용합니다 —
.nen/hanten/<branch-slug>.cycle.json. 수정(remediation)은 리뷰어 수를 재설정하지 않습니다. Breath가 새 브랜치를 생성하는 것만이 새로운 사이클입니다
(zheref/hatsu#63; hanten § 2a).
2a. 프로파일 및 단계 원장
**nen/workflow.json의 profile.default**는 턴의 형태를 결정합니다(없으면 standard); § 1의 --profile이 이를 재정의하며, profile.allowed 외부의 값은 허용 목록을 선택기 옵션으로 하여 다시 요청되고, 턴의 첫 줄은 현재 적용 중인 프로파일을 명명합니다.
| 프로파일 | § 2에서 변경되는 사항 |
|---|---|
fast | 1단계는 바인딩을 확인합니다; 준비는 여전히 한 번 실행됩니다; 2단계와 3단계는 선언된 대로; 4단계는 건너뛰고, 런치 라인은 deferred by profile fast; isolation still requires an explicit maintainer core-launch call; 5단계는 --variant turn-fast로 렌더링 |
standard | 오늘의 턴, 위 테이블에 명시된 대로 |
thorough | standard, 그리고 3단계 후 kotoamatsukami의 영향받은 스위트가 모든 턴에서 실행됨 |
프로파일은 어떤 단계가 실행되고 5단계가 어떤 변형을 렌더링하는지를 결정하며, 단계 내부에서 일어나는 일에는 절대 영향을 미치지 않습니다. 2단계와 3단계는 모든 프로파일에서 해당 스킬이 정의한 대로 실행됩니다. fast에서는 영향받은 스위트가 실행되지 않습니다(이는 mukai의 것이며, 거기 4단계); thorough에서는 kotoamatsukami의 영향받은 스위트가 3단계 후에 실행됩니다, ren이 해당 스킬의 세 번째 호출자이기 때문입니다. 런치는 건너뛰어지며, 이동되지 않습니다: mukai에는 런치 단계가 없고, amaterasu § 1a는 건너뛴 런치가 어떻게 처리되는지 명시합니다. 커버리지는 어떤 ren 프로파일에도 의해 캡처되지 않습니다; 그것은 byakugan의 것이며, mukai에서 사용됩니다.
랜딩(mukai)은 항상 thorough로 실행됩니다, 그 이전 턴이 무엇을 명명했든 상관없습니다.
모든 단계는 하나의 원장 항목입니다(WORKFLOW.md § effort의 원장이 메커니즘을 소유합니다; ren의 것은 어떤 단계와 언제인지입니다). 단계 전에, nen phase begin --effort <branch> --phase <step-name> --surface <s> [--model <reported-model>] --dial <level>; 모델이 하니스가 보고한 제공된 ID인 경우, --note "model-kind=served; registry alias <alias>"를 추가합니다(WORKFLOW § effort의 원장); 첫 번째 단계 기록 시 nen session record를 하니스의 제목/ID가 노출될 때 사용하여 세션당 한 번 기록합니다; 단계 후에, nen phase end --effort <branch> --phase <step-name> --exit <code>, 따라서 .nen/phases/<effort>.json은 단계당 하나의 시간 기록 항목을 가지며, 거부된 단계도 포함됩니다. 1단계의 end는 breath § 4a의 기록을 --note로 전달합니다, 1단계가 시작된 노트와 함께 구성됩니다. 왜냐하면 end --note가 이를 대체하기 때문입니다(스크립트의 --begin-note; WORKFLOW § 구성 확인, 3, 5, 6단계가 형식을 소유합니다). 확인은 자체 항목이 아니므로, 여섯 단계는 여섯 개의 항목을 유지합니다(HR-58). 사용량 항목은 5단계에서 기록됩니다: nen usage record --effort <branch> --surface <s> [--model] --dial <level> [--input] [--output] [--cache-read] [--cache-write] [--minutes] 표면 자체 비용 판독값에서, 노출된 것이 없는 표면의 경우 --not-reported.
재개된 effort는 쓰기 전에 읽습니다 (zheref/hatsu#444, zheref/hatsu#445; nen 0.28, 핀). 브랜치에 이미 단계 원장이 있거나 PR이 있는 effort는 재개입니다: 먼저, PR이 있는 경우 — 열려 있는 것: 후속 번호, 기본 삭제로 닫힌 PR이 아님(en § 6) — nen pr ledger read --target <owner/name> --pr <n> --effort <branch> --repo <checkout> --json, nen phase show가 로컬 원장을 찾지 못하는 경우에만 --restore 추가; 그런 다음 nen phase show --effort <branch> --json. WORKFLOW § effort의 원장, 지속 가능한 조각이 판결과 하나의 건너뛰기 행 형식을 소유합니다; 건너뛴 breath 항목의 노트는 2단계 전에 읽힙니다(WORKFLOW § 구성 확인, 7단계). 단계별로 순서대로: 종료 코드 0으로 종료됨 → **
…[번역을 위해 잘림]