defer: 무인 루틴 실행 가드레일 (중복 락·draft cap·재시도 상한·Stop 조건 표)

[JeremyDev87]

Source

• 사내 repo에서 관찰된 스케줄드 daily-tidy 에이전트 워크플로우의 운영 가드레일 패턴 (일반화 증류, 세부 식별자 비수록)
• Generalized failure class: 무인(스케줄드) 실행에서 사람 확인 게이트 없이 반복 실행될 때의 중복 작업·산출물 폭주·무한 재시도
• Detection signal: 동일 대상 브랜치/PR 중복 생성, open draft 산출물 누적, 같은 대상의 연속 실패 반복, Stop 사유 없는 강행

Proposed surface (defer 상태)

• 후보 내용: ① 중복 락 (git ls-remote 동일 대상 브랜치 검사) ② open draft cap(임계 초과 시 수리 skip + 대기 보고) ③ 동일 대상 연속 실패 N회 시 보류 ④ Stop 조건 표(조건→행동 명시, 강행 금지, 조용한 skip 금지) ⑤ 작업 큐(backlog)는 지속 문서가 아닌 호출 주입 파라미터로
• 후보 위치: references/unattended-run-guardrails.md (신규, 필요 시 start/자동화 경로에 배선)

Why defer

• ddalggak의 현행 실행 계약은 대화형 issue-driven이며 무인 루틴(cron/스케줄드) 운영 계획이 확정되지 않았다. wiki-growth-triage의 Defer/reject lane 기준("not on the current execution path") 해당.
• 루틴 운영이 확정되면 이 이슈를 GitHub issue candidate lane으로 승격해 착수한다.

Safety boundaries

• Must not change: 기존 subcommand 권한 표, Manual merge only 원칙
• Issue-PR topology impact: none

Validation (착수 시)

• npm test, npm run verify:projections, npm run verify:codex-skill, npm run verify

[nbeai]

이 defer 방향 좋아 보입니다. 나중에 착수할 때 Stop 조건 표에 조건 → 관찰 가능한 신호 → 허용 행동 → 금지 행동 → 재시도 reset 조건까지 넣어두면 무인 루틴에서 훨씬 덜 애매해질 것 같습니다.

특히 중복 락 / draft cap / 연속 실패 상한은 각각 evidence key를 남기면 좋겠습니다. 예: target branch, target issue/PR, run id, attempt count, last failure class. 그래야 “skip했다”와 “조용히 놓쳤다”가 구분되고, 다음 실행이 같은 결정을 재현할 수 있습니다.