ticket-runner

한국어

English

한국어

English

테마

일 계획하기 ​

파이프라인은 계획하지 않습니다. Planning은 사람 몫으로 두고, 파이프라인은 Planning이 넘겨준 것만 받아 Ticket을 고르는 데서 merge까지 사람 없이 처리합니다(ADR-0001). 넘겨받은 것을 믿고 일하는 만큼, 이슈에서 읽는 것은 몇 가지뿐이고 그것도 엄격하게 읽습니다. 그중 하나라도 어긋난 이슈는 짐작하지 않고 거절합니다.

Ticket에 필요한 것이유
ready-for-agent 라벨Run이 Ticket을 찾는 방법
담당자 없음누군가 지정되어 있으면 이미 claim한 것
Acceptance Criteria: 본문이나 코멘트의 - [ ] 줄verify Stage가 판정하는 유일한 대상
네이티브 blocked by 연결로 적은 blocker, 모두 닫힘어떤 Ticket을 어떤 순서로 돌릴지 정함
네이티브 sub-issue 없음sub-issue가 있는 이슈는 Ticket이 아니라 Spec

같은 목록을 계획을 맡는 에이전트용으로 적어 둔 것이 conventions 문서 docs/agents/pipeline-conventions.md입니다. init이 모든 Target에 넣어 둡니다.

Spec과 Ticket ​

Planning은 mattpocock-skills 플러그인의 스킬을 차례로 쓰는 일이고, 내 세션에서 직접 돌립니다.

스킬만드는 것
grilling에이전트가 아니라 내가 질문에 답한 계획
to-specSpec: 기능 하나를 통째로 설명하는 부모 이슈
to-ticketsTicket: Spec의 네이티브 sub-issue. 하나가 에이전트 세션 하나 분량이고, ready-for-agent 라벨이 붙음
triage다른 경로로 들어온 이슈를 Ticket으로. 브리프(와 그 기준)는 코멘트로 올라감

Spec은 언제나 하위 Ticket을 통해서만 구현됩니다. Ticket은 implement Stage 한 번에 끝날 만큼 작아야 합니다. implement Stage는 기본으로 300턴, 60분입니다(설정).

to-tickets를 돌린 뒤에는, 그대로 두면 guard가 거절할 것들을 확인하세요.

  • Ticket마다 - [ ] 기준과 ready-for-agent 라벨이 있는지
  • 본문이 Blocked by 아래 적은 이슈마다 네이티브 연결도 있는지(blocker)
  • Spec에 ready-for-agent가 없는지. to-spec이 이 라벨을 붙이는데, Ticket이 생기기 전까지 Run은 Spec을 no-criteria로 건너뛰고, Ticket이 생기면 spec guard가 라벨을 뗍니다.

부모와 blocker까지 달아서 직접 만들려면:

bash
gh issue create --title "Drain the Frontier" --parent 12 --blocked-by 14,15 --label ready-for-agent

Acceptance Criteria ​

기준 하나는 줄 맨 앞에 있는, 체크되지 않은 task list 항목입니다. 들여쓰기(있어도 되고 없어도 됨), -, *, + 중 하나의 불릿, 공백 하나, 그리고 [ ]. 아무리 약속처럼 읽혀도 그 밖의 것은 기준이 아닙니다.

markdown
- [ ] `run 3 7` takes only #3 and #7            ← 기준
  * [ ] a nested item counts too                ← 기준
- [x] already ticked                            ← 아님: 더 판정할 게 없음
The command must refuse bad input.              ← 아님: 산문
1. [ ] a numbered item                          ← 아님: 불릿이 없음

verify Stage는 기준마다 met, unmet, unverifiable 중 하나로 판정합니다(Ticket 하나가 merge되기까지).

기준은 세션이 코드를 돌려 보거나 읽어서 확인할 수 있게 쓰세요. 사람의 눈이 필요한 기준(스크린샷, 느낌)은 unverifiable로 돌아옵니다.

blocker ​

GitHub의 네이티브 blocked by 연결만 셉니다(ADR-0003). 그래서 Run이 가져가는 것은 GitHub 화면에서 막힘이 풀렸다고 보이는 것과 같습니다.

bash
gh issue edit 23 --add-blocked-by 14,15      # 기존 이슈에 연결 추가
gh issue edit 23 --remove-blocked-by 15      # 하나 떼기

blocker 중 하나라도 열려 있으면 Ticket은 기다립니다. 같은 Run의 다른 Lane이 아직 작업 중인 blocker도 열려 있는 것이고, 두 Ticket이 서로 방해하지 않게 하는 장치는 이것뿐입니다. 어떤 Ticket끼리 나란히 돌려도 되는지를 따로 판단하는 것은 없습니다. blocker가 merge되는 순간, 그 blocker에 막혀 있던 Ticket을 같은 Run 안에서 가져갈 수 있게 됩니다. 그러니 같은 코드를 바꾸는 Ticket 사이에는 blocker를 연결하세요. 그러면 두 번째 Ticket이 첫 번째 위에서 만들어집니다. 연결이 없으면 둘이 나란히 돌고, 나중 것의 rebase는 conflict Stage로 갑니다.

본문의 Blocked by 섹션은 사람이 읽을 사본으로 두어도 괜찮습니다. 다만 거기 적힌 이슈마다 네이티브 연결도 있어야 합니다. 연결이 없는 이슈를 적어 두면 body-only-blockers guard가 Ticket을 거절합니다. guard는 그 섹션만 읽으니, 본문의 다른 곳에 있는 이슈 참조는 그냥 산문입니다.

쓰는 방식섹션이 끝나는 곳
한 줄에 Blocked by: #14, #15그 줄 끝
## Blocked by 제목 다음의 목록제목 아래 첫 목록의 끝

다른 저장소를 가리키는 참조(other/repo#12)는 blocker로 읽지 않습니다.

라벨 ​

라벨은 triage 상태 기계입니다. 이슈 하나에는 한 번에 상태 라벨 하나만 붙습니다. init이 여섯 개를 모두 만들고, labels로 이름을 바꿀 수 있습니다.

라벨붙이는 쪽파이프라인이 하는 일
needs-triage사람. 파이프라인은 상설 Notes 이슈에그 라벨로 Notes 이슈를 여는 것 말고는 없음
needs-info사람없음
ready-for-agentPlanning, Release, Ticket을 돌려주는 사람후보로 가져감. claim할 때 뗌
in-progressRun만, claim할 때Run이 맡고 있는 Ticket 표시. merge, Hand-off, Release 때 뗌
ready-for-humanHand-off사람이 라벨을 바꿀 때까지 건드리지 않음
wontfix사람없음

파이프라인이 어떤 Ticket을 건드리지 않게 하려면 ready-for-agent를 떼거나 누군가를 담당자로 지정하세요. 담당자가 있는 후보는 이미 claim된 것으로 보고 조용히 넘어갑니다. 내 세션에서 Spec에 플러그인의 /implement-spec을 돌리기 전에도 이렇게 해 두세요. /implement-spec은 작업하는 Ticket에 아무 표시도 남기지 않으니, Run도 그 Ticket을 가져가 다른 branch에서 같은 일을 또 하게 됩니다.

guard ​

Planning은 몇 가지 알려진 방식으로 어긋납니다. guard는 이런 후보를 claim하기 전에 건너뛰고, 그 이유를 한 번 알려 줍니다. 이슈를 대신 고치지는 않으니, Planning 결과를 고친 뒤 다시 돌리면 됩니다. Run이 살펴보는 열린 ready-for-agent 이슈는 모두 후보이고, Frontier는 후보 중 claim된 것과 막힌 것을 뺀 나머지입니다.

이유후보의 상태파이프라인이 하는 일
spec네이티브 sub-issue가 있으니 Spec건너뛰고 ready-for-agent를 뗌. 하위 Ticket은 하나씩 가져감
no-criteria본문과 코멘트에 - [ ] 줄이 없어 verify가 판정할 게 없음건너뛰고 라벨은 둠. 코멘트로 기준을 더할 수 있으니까
body-only-blockersBlocked by 섹션이 네이티브 연결 없는 이슈를 적음건너뛰고 라벨은 둠. 본문의 줄은 blocker로 읽지 않음

건너뛸 때는 무엇을 고치면 되는지 적은 경고 코멘트를 남기되, 같은 이유로는 한 번만 답니다. Run 요약에는 skipped #<n> <reason>으로 남습니다. 이슈를 고치면 다음 Run이 가져갑니다.

참고 자료 ​