작업

에이전트가 실제로 처리하는 작업 보드 — 배정하면 터미널이 뜨고, 실행되고, 마무리 전에 당신에게 묻습니다.

대부분의 작업 보드는 하려는 일을 적어 두는 곳입니다. 이 보드는 일을 실제로 내보냅니다.

작업을 배정한다는 것은 대상 에이전트를 고르고, 그 터미널을 띄우고, 작업을 보내고, 그 실행을 작업에 묶는다는 뜻입니다. 그래서 보드와 터미널과 Mission Control이 같은 일을 이야기하지, 같은 일에 대한 서로 다른 세 가지 이야기를 하지 않습니다.

보드 열기

작업은 Git 클라이언트처럼 창 전체를 쓰는 워크스페이스로 열립니다. 상태별 열, 에이전트마다 하나씩의 레인, 그리고 계획 하나를 다 읽을 만큼 넓은 상세 패널.

뷰 레일은 같은 일을 보는 세 가지 방식을 오가며, 각각 자기 개수를 함께 보여 줍니다.

모든 카드는 누가 맡았는지, 그 터미널이 지금 무엇을 하는지 보여 줍니다 — 실행 중, 당신 대기, 유휴, 또는 연결 끊김.

작업은 일곱 가지 상태를 거칩니다.

작업 상세 패널에서 대상을 고릅니다. 그 한 번의 동작이 터미널을 띄우고, 작업을 전달하고, 실행을 카드에 다시 연결합니다.

그때부터 카드는 실행을 따라갑니다. 터미널이 일하고 있으면 카드도 그렇게 말하고, 에이전트가 멈춰 기다리면 카드도 그렇게 말합니다.

에이전트는 계획을 구현하기 전에 한 번, 작업을 닫기 전에 한 번 더 묻습니다. 당신의 판정은 에이전트가 어디에 있든 도달하고, 당신의 말은 그대로 전달됩니다 — 요약이 아니라 당신이 실제로 쓴 문장이 갑니다.

전용 검토 대화상자가 계획에 제대로 된 읽기 공간을 줍니다. 승인과 수정 요청은 동등하게 놓이고, 의견 상자는 언제나 열려 있습니다 — 이유를 쓰려고 뭔가를 먼저 눌러야 하지 않습니다.

판정은 세 곳에서 당신을 찾아옵니다. 보드의 검토 큐, 상태 표시줄의 배지, 그리고 Remote Control의 휴대폰 페이지 — 부엌에 선 채로도 계획을 승인할 수 있습니다.

자동으로 승인되는 것은 없습니다. 아무도 제때 답하지 않으면 작업은 차단 상태가 됩니다. 침묵은 동의가 아니기 때문입니다.

각 작업은 프로젝트의 .1devtool/tasks/ 아래에 있는 markdown 파일이며 이름은 <id>-<slug>.md입니다. 즉 diff에 나타나고, 리뷰를 거치며, 저장소의 다른 것들처럼 브랜치를 따라 움직입니다.

에이전트가 무엇을 해도 되는지 결정하는 부분 — 누구에게 배정되었는지, 어떤 게이트가 열려 있는지, 어떤 실행 기록이 있는지 — 은 파일이 아니라 앱이 쥐고 있습니다. 승인 경계를 넘는 파일 편집은 결정이 아니라 제안입니다.

열 개의 MCP 도구가 전체 루프를 덮습니다. 작업 조회와 읽기, 생성과 수정, 댓글, 연결, 다음 작업 요청, 승인 요청, 판정 대기, 그리고 완료. 설정이 아니라 규칙으로 내장된 것이 하나 있습니다. 에이전트는 자신에게 일을 배정할 수 없습니다.

대부분의 작업은 앉아서 작성한 것이 아니라 우연히 눈에 띈 것에서 시작합니다.

담긴 항목은 출처로 돌아가는 포인터(파일과 줄 번호, 또는 터미널 이름)를 지닙니다. 그래서 일주일 뒤에도 그 작업은 당신이 어디서 그것을 발견했는지 말해 줍니다.

원하는 결과를 설명하면 에이전트가 작업 묶음을 제안하고, 당신이 고쳐서 받아들입니다. 당신이 받아들이기 전에는 저장소에 아무것도 쓰이지 않으므로, 잘못된 분해는 클릭 한 번의 손해일 뿐 .1devtool/tasks/ 청소로 이어지지 않습니다.

같은 일이 두 번 담겼다면 카드를 병합하세요. 하나가 살아남고 나머지는 묘비가 되지만 그 id는 여전히 해석됩니다 — 옛 id를 쥔 에이전트는 막다른 길로 보내지지 않고 리디렉션됩니다.

병합도 평범한 파일 변경이므로, 커밋 전이라면 git checkout -- .1devtool/tasks/로 되돌릴 수 있습니다.

작업이 돌고 있는 프로젝트는 터미널 위 Mission Control에, 누가 누구와 대화하는지 보여 주는 맵과 나란히 작업을 띄웁니다.