공유 정책 위치: 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/ 복사본이 없다고 해서 정책이 누락된 것이 아니며 중복 제출을 트리거해서는 안 됩니다. 대상 리포지토리에 두 번째 정책을 복사하거나 만들지 마십시오.
Aka — 브랜치가 나갑니다
성격: 조작자. 푸시는 정의상 공유 상태에 대한 git 측 작업이며, 차이를 작성한 성격에 관계없이 적용됩니다.
린트하고, 게시되지 않은 기록만 접고, 그 아래에 베이스를 놓고, 트리가 변경되었으면 다시 린트한 다음, 정확히 그 트리를 원격에 놓습니다. PR은 없습니다. 프로젝트 전체 테스트는 없습니다.
Aka는 로컬 평면에서의 첫 번째 인간 호출입니다. 그 이전의 모든 것 — hatsu:ren의 턴, hatsu:kokusen의 커밋 — 은 기계를 떠나지 않기 때문에 묻지 않고 발생합니다. Aka는 작업이 다른 사람이 가져올 수 있는 무언가가 되는 지점이며, 그 경계는 메인테이너가 넘어서야 하는 것입니다.
PR을 열지 않습니다. 그것은 hatsu:mukai의 실행이며, 그 안의 hatsu:shibari 단계입니다. Aka는 푸시된 브랜치만으로 끝납니다. 의도적으로: 푸시와 PR은 두 가지 결정이며, 이를 접으면 그 중 하나를 물을 수 없게 됩니다.
0. 독립형 진입 — 이 스킬은 항상 메인테이너의 호출이었습니다
Aka에는 연결된 진입이 없습니다. § 1은 이미 말하고 있습니다: 전체 스킬은 메인테이너의 게시 호출에서만 실행되며, 에이전트는 절대 제안하지 않습니다. 첫 번째 예외, 2026-09-28(b) 메인테이너 판결 (docs/ROSTER.md § 2026-09-26/27/28 판결): 입력된 futon 호출에서 이 스킬을 명명하는 then 단계는 메인테이너의 게시 호출입니다 — 사전 고 mugetsu § 3이 정의하는 — 여전히 절대 프롬프트되지 않고, 절대 제안되지 않습니다. docs/STANDALONE-ENTRY.md § 6은 이를 보고서, 벨, 중지 옵션 및 복합체가 절대 제공해서는 안 되는 단계 중 하나로 명명합니다 — 독립형 실행은 정확히 그러한 제안이 파이프라인이 가장 잘 안다고 읽힐 수 있는 곳입니다.
두 번째 예외 — 입력된 복합체의 위임된 게시 — 메인테이너 판결 HR-20 (zheref/hatsu#332), docs/ROSTER.md § 2026-10-19 해석 — 입력된 복합체의 위임된 게시를 변경 없이 비준합니다. 이는 이미 내려진 두 가지 판결에 기반합니다: kazaana의 대리자는 대기 중인 각 이슈를 작성하고 게시합니다 (ROSTER § 2026-10-13 판결, 판결 1), 그리고 통합 브랜치에 대한 futon 노력은 자체 노력 브랜치를 게시하기 위해 aka를 실행합니다 (ROSTER § 2026-09-30 판결 — En은 절대 병합하지 않음, 행 노력이 중지되는 경우); 스택 또는 이슈별 형태에서 푸시는 futon § 4 → build § 5의 것입니다. 입력된 futon 또는 kazaana 호출은 작성자를 실행하는 작업 브랜치에 대한 메인테이너의 게시 호출입니다 — 하나의 상설 호출이며, 커밋당 하나가 아닙니다:
| 입력된 futon / kazaana 라인의 범위 | |
|---|---|
| 적용됨 | 실행 큐의 노력당: 초기 게시 (빌더 대리자 또는 세션에서의 이 스킬 — kazaana § 3; build § 5) 및 이를 전달하는 모든 유지 관리 커밋 및 푸시 — 검토 수정, 따라잡기, 검토된 수리 (murasaki § 6 mukai 및 en 내부) — 실행의 대상 리포지토리 및 해당 노력 자체의 작업 브랜치로, 이 스킬의 게이트와 murasaki의 게이트를 변경 없이 통과 |
| 적용되지 않음 | 다른 원격 또는 리포지토리, 다른 브랜치, branch.base, 강제 형태 또는 게시된 커밋의 재작성, 태그, 병합, 릴리스. 적용됨 행 밖에서 푸시는 자체 스킬의 규칙에 따라 성패가 결정됩니다: 이미 게시된 브랜치의 경우 murasaki § 6; futon § 5의 통합 브랜치는 nen wc publish로만 푸시되며, aka를 통하지 않고 강제되지 않습니다 (ROSTER § 2026-09-30 판결 — En은 절대 병합하지 않음); 제안 브랜치의 경우 getsuga § 3/§ 3a, 태그의 경우 § 4 (절단). 스택된 자식의 재타겟팅은 병합 계획의 것입니다 (WORKFLOW.md § 스택된 풀 리퀘스트 규칙 5; ROSTER § 2026-10-12 판결). 어떤 스킬도 행위를 소유하지 않는 경우, 수행되지 않으며 보고됩니다; 메인테이너만 할 수 있는 행위인 경우에만 G5입니다 |
| 만료 | 실행이 종료될 때 (futon § 10), 중단 시, 또는 실행을 중지하는 G5 시, 또는 메인테이너의 말에 따라 — 커밋이 변경되었기 때문에 절대 만료되지 않음; 노력 자체의 G5는 해당 노력의 범위만 만료시킵니다 — 다른 노력의 범위는 절대 만료시키지 않음 — 메인테이너가 응답하면 재개됩니다; G2/G4 병합 프롬프트는 아무것도 만료시키지 않습니다 (mugetsu § 3). 재개, 재시작 또는 압축된 세션은 신선한 입력된 호출에 대해서만 이를 보유하며, 체크포인트, 실행 기록 또는 요약에서는 절대 보유하지 않습니다 |
범위는 대상이지 SHA가 아닙니다. 동일한 리포지토리의 동일한 브랜치에 대한 새 커밋은 그 안에 있습니다. 커밋이 이동했기 때문에 다시 묻는 것은 #332가 기록하는 실패입니다. 모든 핸드오프는 이를 전달합니다 — 상위에서 빌더 대리자로 (kazaana § 3) 및 이후의 모든 유지 관리 단계 (mukai, en, murasaki): 다섯 가지 사실 기록 — 호출 그대로 인용, 푸시도 의존하는 모든 메인테이너 응답, 리포지토리, 작업 브랜치 및 범위: 이 브랜치에 대한 초기 게시 및 유지 관리 푸시(실행이 종료될 때까지). 체크포인트, 실행 기록 또는 이후 핸드오프는 절대 이를 정확한 커밋으로 좁히지 않습니다; 이전 라인이 달리 명시하는 경우, 이후 수정 사항은 나란히 서는 것이 아니라 대체합니다.
기록은 모든 핸드오프(유지 관리 포함)에서 모든 표면에서 동일하게 유지됩니다 (zheref/hatsu#529). 이 단락은 세 행 중 어떤 것도 넓히지 않습니다. 선택기 큐 외부의 전제 조건은 입력된 라인에 의해 적용되지 않습니다: 해당 푸시는 메인테이너 자신의 말(§ 1의 호출, 자신의 말로)에만 의존하며, 두 번째 사실로 인용되고, 실행의 대상 리포지토리에 대해 — 준비만 승인하는 응답은 푸시를 승인하지 않으며, 한 번 묻습니다. 유휴 실행의 통합 전달은 futon § 5의 상태를 유지합니다 (위의 적용되지 않음); 해당 요청은 동일한 사실을 전달하고 권한으로 futon § 5를 인용합니다. 호스트의 승인이 필요한 일상적인 푸시는 요청에 해당 기록을 제시합니다 — Codex에서는 지원되는 검토 경로의 근거 (docs/surfaces/codex.md § 게시 요청) — 따라서 변경된 행위자, 작업 트리 또는 커밋은 메인테이너에게 다시 물을 이유가 되지 않습니다. 호스트가 결정하는 것은 호스트의 몫입니다. 기록은 검토자를 위한 증거일 뿐, 자체 부여된 승인이 아닙니다: 범위 외 대상, 보호된 베이스, 재작성 또는 릴리스 행위는 거부되거나 자체 게이트 뒤에 남아 있으며, 실제 거부는 다음 단락의 것입니다. 경계 사례는 docs/ab/publication-authority.md에 있습니다.
호스트 거부는 호스트의 몫입니다. 하네스의 승인 계층이 범위 내 푸시를 거부하는 경우, 거부는 호출 및 범위와 함께 메인테이너에게 인용되며, 해당 호스트의 지원되는 승인 경로 — 메인테이너의 행위를 통해서만 해결됩니다: 해당 경로에서의 승인, 또는 기록 옆에 인용된 새로 주어진 단어를 전달하는 동일한 경로를 통한 한 번의 재제출 (zheref/hatsu#529) — 증거만으로 재시도하지 않음, 동일한 푸시에 대해 다른 명령, 경로 또는 표면을 사용하지 않음, 더 넓은 권한을 요청하지 않음, 권한 설정을 건드리지 않음. 거기서 주어진 정확한 승인은 자체 행동에 대한 유효한 영수증으로 남으며, 아무것도 넓히지 않습니다.
대표적인 궤적. hatsu:kazaana zheref/nen → 대리자의 aka가 <model>/kurapika/<slug>를 커밋 A에서 최초 게시 → mukai가 PR 열기 → en: 검토된 발견 사항 수정, kokusen이 커밋 B, murasaki가 동일한 브랜치에 B 푸시. 두 푸시 모두 하나의 입력된 라인에 의존하며 어느 것도 묻지 않습니다. B가 다른 브랜치에 푸시되면 외부에 있으며 적용되지 않음 행에 따라 성패가 결정됩니다.
두 예외는 별도로 유지됩니다. then aka 단계는 첫 번째 예외의 단일 사용 실행입니다. 두 번째는 복합체 엔진이 만드는 노력당 푸시만 다룹니다. 독립형 hatsu:aka는 변경되지 않습니다 — 한 번의 호출, 한 번의 실행 (§ 1) — 그리고 어느 예외도 branch.base로의 병합 (en § 5의 프롬프트) 또는 릴리스 (getsuga, mugetsu)에 도달하지 않습니다.
P1이 적용됩니다 — hatsu:ten aka, 이 단계의 전제 조건을 따라잡습니다 (ten § 6) — 그리고 P2는 스쿼시 전에 보고서에 속합니다: 브랜치, 깨끗하거나 더럽거나, 얼마나 많은 커밋이 푸시되지 않았는지, 그리고 이미 원격에 있는 것은 무엇인지. § 4는 푸시되지 않은 커밋만 스쿼시하며, 해당 경계는 원격에서 읽히고 절대 기억되지 않습니다.
다른 것은 변경되지 않습니다. Aka는 여전히 프로젝트 전체 테스트나 커버리지를 실행하지 않습니다 — hatsu:kotoamatsukami와 hatsu:byakugan이 mukai에서 이를 소유합니다 — 여전히 빨간색 필수 검사에서 G5에서 멈추며, 여전히 원격에 이미 있는 커밋을 강제 푸시하거나 다시 쓰지 않습니다.
핸드백. 연결된 실행의 다음 단계: hatsu:mukai — 검토, 영향 받은 테스트, 커버리지, 증거 및 PR. 그것은 당신이 호출할 것이며, 이 실행은 그것을 요청하지 않습니다.
1. 호출 — 그리고 호출할 수 있는 사람
hatsu:aka
인수가 없으므로 nen parse가 소유할 것이 없습니다 — 그리고 그렇게 말하는 것이 요점이지 생략이 아닙니다. nen parse <skill> --grammar <template> --line <text>는 문법에 대해 존재합니다. 동사만 있는 것은 문법이 없으며, 구문 분석을 에코할 수 있도록 선택적 절을 발명하는 것은 의식 절차가 될 것입니다.
호출은 메인테이너의 것입니다. 자신의 말로 또는 이름으로. 두 가지 결과가 있으며, 둘 다 바인딩됩니다:
- 어떤 에이전트도 이를 프롬프트하지 않습니다.
hatsu:jutaisho가 턴 끝에,hatsu:spiritual-message가 보고서에서, 복합체가 다음 단계로 제공하는 경우, 중지의 문자 옵션에서도 안 됩니다. 보고서는 브랜치가 나갈 준비가 되었습니다라고 말할 수 있습니다. *밀어야 합니까?*라고 말할 수 없습니다. 말하도록 지시받은 허가를 묻는 에이전트는 인간의 호출을 넛지로 전환했으며, 넛지는 로컬 평면의 푸시 규율이 존재하는 이유입니다. - 한 번의 호출, 한 번의 실행. 이 푸시에 대한
예는 다음 푸시에 대한 권한이 아닙니다. 실행이 시작되었고 언제 종료되는지 말하십시오. 유일한 상설 호출은 입력된 복합체의 것입니다. 목적지로 범위가 지정됩니다 (§ 0, 두 번째 예외: 노력이 build § 5를 통해 게시하는 futon 또는 kazaana 라인); 독립형 빌드의 푸시는 이 예외가 아닌 build § 5 자체의 실행 범위 위임에 의존합니다.
2. 매개변수 — nen/workflow.json, 기본값 명시
| 키 | 용도 | 키(또는 파일)가 없는 경우 기본값 |
|---|---|---|
branch.base | § 4의 스쿼시 및 § 5의 따라잡기 작업이 기준으로 삼는 베이스 | main |
iteration.lane | § 3 및 § 6이 린트하는 레인 | project.defaultLane |
commits.allowedAttributionTrailers | 커밋이 전달할 수 있는 표준 페르소나/평면 트레일러 | Hatsu-Agent, Akatsuki-Agent |
commits.forbiddenTrailers | 커밋을 완전히 거부하는 귀속 트레일러 | Co-Authored-By, Claude-Session, Signed-off-by, Generated-by, Generated-with, Reviewed-by 포함 |
nen schema check --repo <path>는 고정된 빌드에서 이 파일의 유효성을 검사합니다 — 라이브로 확인됨, 행은 다음을 읽습니다: ok nen/workflow.json coverage 80/85/90 (touched), branch '{model}/{persona}/{descriptor}' off 'main', checks: lint. 잘못된 형식의 키는 포인터별 FAIL이므로, 이 스킬은 더 이상 모양을 눈으로 확인하지 않습니다. 값을 읽고, 적용된 것이 무엇이든 기본값을 명시합니다.
누락된 인수 또는 구성 항목은 인라인으로 질문하고 설정합니다 (missing-argument, missing-configuration; WORKFLOW.md § 4 질문, 설정, 계속); 위의 키를 다루는 기본값은 사용되어 명시되며, 결코 질문하지 않습니다. § 4의 거부는 격차가 아닙니다: 게시된 기록 다시 쓰기, 금지된 트레일러 및 트렁크 푸시는 여전히 거부하며, 추측하지 않습니다.
claude/agents/kurapika.md§ 작동 방식에서 선언된 변경 — 몰래 넣지 않고 명명됨. 오늘날의 에이전트 정의는 *"메인테이너 자신의 하네스가 명령하는 트레일러를 넘어서는 AI 귀속 없음 — 오늘날Co-Authored-By:및Claude-Session:… 자체 귀속을 추가하지도 않고 그들의 것을 제거하지도 않음"*을 읽으며, 최종 규칙은 열려 있는 헌법적 질문이라고 기록합니다.nen/workflow.json은 메인테이너가 주어진 리포지토리에 대해 이를 답하는 곳이며, 이 워크플로우는 다음과 같이 답합니다:Hatsu-Agent및Akatsuki-Agent는 인정되며, 평면당 하나, 다른 두 개는 금지됩니다. 둘이 동의하지 않는 경우, 리포지토리 자체의commits블록이 해당 리포지토리에 대해 승리합니다, 왜냐하면 해결되지 않은 긴장보다는 메인테이너의 기록된 결정이기 때문입니다.commits블록을 제공하지 않는 리포지토리는 위의 기본값을 가져오며, 동일한 내용을 말합니다. 이는 선언된 프로세스 변경이며,hatsu:futon§ 선언된 프로세스 변경이 자체 변경을 공개하는 방식으로 여기에 공개됩니다.
3. 스쿼시 전 린트 게이트
nen wc squash가 게시되지 않은 커밋조차 다시 쓰기 전에, iteration.lane에 대한 선언된 린트 행을 실행하십시오:
nen shu lint --repo <path> --lane <iteration.lane> --dry-run
nen shu lint --repo <path> --lane <iteration.lane>
익숙하지 않은 리포지토리에서는 한 번 드라이런 하십시오. 빨간 린트는 기록 변경 전에 실행을 종료합니다. 자리가 인용됩니다. 이 게이트는 의도적으로 스쿼시 전에 있습니다. 저렴하며 aka가 여러 유용한 체크포인트를 하나의 빨간 커밋으로 대체하는 것을 방지합니다. 이는 hatsu:gyo — 린팅 프로세스 — 입니다.
…
[번역을 위해 잘림]