다른 언어: English, Español, Português, 日本語, Deutsch, Français, 简体中文, Italiano, हिन्दी · 한국어 가이드 전체
공개: 저희는 100monkeys.ai에서 Carbon Forge와 그 곁의 AEGIS를 만들고 있으므로 이 글은 만든 쪽의 설명으로 읽어 주세요. 이 가이드는 저희 AI 에이전트 하나가 공개 문서(영어), 주로 Working in lanes의 8단계, Source control settings, MCP tools catalog: Lanes, continued, Source control: how it is built and why를 바탕으로 초안을 쓰고 회사가 검토했으며, 이 한국어판은 영어 원문 가이드의 번역입니다. 표, 호출, 거부 메시지는 문서에 있는 그대로입니다. 문서가 답하지 않은 질문은 마지막 절에서 밝힙니다.
왜 규칙을 기록 안에 두는가
문서는 이유를 두 문장으로 말합니다. "Landing rules are the code-owners rule kept in the record. The approvers a path needs are named on a page of the workspace, and each approval binds to the lane's composition hash, so review is the record's and not a forge's."(랜딩 규칙은 기록 안에 둔 코드 오너 규칙입니다. 경로에 필요한 승인자는 워크스페이스의 한 페이지에 적히고, 각 승인은 lane의 composition 해시에 묶이므로, 리뷰는 포지가 아니라 기록의 것이 됩니다.) 이것이 없으면 "a landing can carry code no approver saw."(랜딩이 어느 승인자도 보지 못한 코드를 실어 나를 수 있습니다.) 먼저 한계 하나: "Carbon runs no review itself."(Carbon은 스스로 리뷰하지 않습니다.) 누가 무엇을 승인했는지 기록할 뿐이고, 리뷰는 사람과 여러분이 지정한 워크플로가 합니다.
1단계. trunk 보호하기
규칙은 보호된 trunk에서만 읽힙니다. 워크스페이스 관리자가 Settings, Workspace, Source control 아래에서 Protect the trunk를 켜고, 필요하면 Protect pages and atoms too도 켭니다. 에이전트는 다음으로 설정을 확인합니다.
workspaces.get_settings {}
→ { "workspaceId": "…", "trunkProtected": true, "trunkProtectedEntities": false }그때부터 "the trunk moves only by a lane's landing"(trunk는 lane의 랜딩으로만 움직이며), 직접 쓰기는 workspace <slug> protects its trunk: the trunk lands by lanes.land only; write on a lane으로 거부됩니다.
2단계. .landing-rules 페이지 쓰기
예약된 경로 .landing-rules에 페이지를 만들고, 첫 번째 Markdown 표의 머리글을 glob | approvers | gate로 하세요. 문서의 예시:
| glob | approvers | gate |
| --- | --- | --- |
| app/src/billing/** | <user id>, <user id> | |
| docs/** | <user id> | docs-review |glob: 가져오기 무시 규칙 문법으로 쓴 규칙 하나이며,!로 시작하지 않습니다.approvers: 쉼표로 구분한 사용자 ID이며, 각각 워크스페이스의 멤버여야 합니다. 게이트를 지정한 행에서는 비어 있어도 됩니다.gate: 선택 항목으로, AEGIS 워크플로의 이름이며 최대 128자입니다. "Carbon never runs it."(Carbon은 그것을 절대 실행하지 않습니다.)
이 페이지는 워크스페이스 관리자만 trunk나 lane에서 쓸 수 있고, 다른 사람은 The landing rules page .landing-rules is reserved: only a workspace admin writes it.로 거부됩니다.
3단계. 서버가 유효하다고 읽는지 확인하기
설정 대화 상자의 Landing rules 절은 <n> rules, valid.를 보여 주거나, 잘못된 행을 Every landing is refused until it is fixed.와 함께 지목합니다. 멤버가 아닌 사람을 적었거나, 승인자도 게이트도 적지 않은 행은 잘못된 행입니다. 망가진 페이지는 모든 랜딩을 멈추므로, 믿고 쓰기 전에 이것부터 확인하세요.
4단계. lane에서 작업하기
Working in lanes에 나온 대로 lane을 열고 그 위에서 쓰세요. 랜딩 때 lane이 건드린 모든 경로가 각 행과 대조됩니다. 페이지는 그 경로로, 옮겨진 페이지는 두 경로 모두로, 트리 파일은 <tree path>/<entry path>로 대조됩니다.
5단계. lane에 아직 필요한 것 읽기
lanes.create { "label": "agent/7/fix-login" }
lanes.get { "label": "agent/7/fix-login" }
lanes.export { "lane": "agent/7/fix-login" } // header line: # composition: <hash>
lanes.approve { "lane": "agent/7/fix-login" }lanes.get은 누가 승인했는지, 누가 빠졌는지, 각 게이트가 pending인지 satisfied인지를 보여 줍니다. 앱에서는 lane의 Overview가 같은 내용을 보여 줍니다. 해당하는 규칙, m명 중 n명 승인, 그리고 게이트에서 온 승인에는 "via gate <workflow>" 표시가 붙습니다.
6단계. 정확한 변경을 승인하기
리뷰어는 # composition: <hash>로 시작하는 하나의 unified diff인 lanes.export를 읽고 lanes.approve를 호출합니다. 승인은 그 해시에 묶이므로 "a reviewer who reads the export and approves at its # composition: value has approved exactly that change."(export를 읽고 그 # composition: 값에서 승인한 리뷰어는 정확히 그 변경을 승인한 것입니다.) 이후의 패치, 충돌 해결, trunk 이동이 랜딩될 내용을 바꾸면 해시가 바뀌고, 이전 승인은 더 이상 셈하지 않습니다. 마지막 변경 뒤에 승인하고, 그 전에 하지 마세요.
7단계. AEGIS 워크플로가 게이트로서 승인하게 하기
게이트는 워크플로 자신만 충족할 수 있습니다. 실행의 토큰은 tokens.mint_execution으로 발급하되, 선택 인자 workflow를 게이트의 이름(1~128자)으로 설정합니다. 그러면 실행이 그 토큰으로 lanes.approve를 호출합니다. 일치는 정확해야 하며 "case included"(대소문자까지 포함)입니다. "A person's approval, and one given through a token minted without workflow, satisfies no gate."(사람의 승인, 그리고 workflow 없이 발급된 토큰으로 한 승인은 어떤 게이트도 충족하지 않습니다.) 실행 토큰은 호출자 토큰의 자식으로, 워크스페이스 하나, 트리 경로 하나, lane 하나, 도구 목록, 최대 하루로 제한됩니다. AEGIS by 100monkeys.ai, in beta를 쓰면 게이트는 여러분이 직접 만든 워크플로입니다. 행이 그것을 지정하고, Carbon Forge는 그 워크플로의 실행이 승인했는지만 확인합니다.
8단계. 랜딩하기
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links", "dry_run": true }
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links" }승인이 모자란 랜딩은 무엇이 빠졌는지 밝히며 통째로 거부됩니다.
Lane <label> touches <path> under landing rule <glob> (line <n>), which needs approval from <user ids> and gate <name> at the lane's current composition. Approve with lanes.approve; nothing was written.랜딩되면 소비된 승인은 게이트의 것까지 포함해 "follow its intent as Approved-by: lines"(그 의도 뒤에 Approved-by: 줄로 붙고), changeset은 다른 changeset과 똑같이 봉인됩니다. dry_run 랜딩은 규칙을 확인하지 않는다는 점에 유의하세요. 그것은 lanes.get으로 읽으세요.
문서가 답하지 않은 것
- AEGIS 쪽. 문서는 "the execution service"(실행 서비스)가
workflow를 넣어 실행의 토큰을 발급한다고 하지만, 그런 토큰을 가지고lanes.approve를 호출하는 AEGIS 워크플로는 보여 주지 않습니다. - 승인자는 사용자 ID뿐입니다. 그룹이나 팀은 없고, 설계 문서는 "No per-directory permissions"(디렉터리별 권한 없음)라고 밝힙니다.
- 실행 토큰으로 한 승인이, 그 토큰의 사용자가 지정된 승인자일 때 그 사용자의 승인으로도 셈하는지.