SHARED-APPROVAL-PATTERN-EVIDENCE

요약

• 승인 UX의 최소 상태는 approval-required, hold, deny, approved-execute 4개로 정리된다.
• 근거는 Google Tasks 승인 루프 문서, approval monitor cron 프롬프트, 주간 운영 브리핑 cron 프롬프트, JYP Labs 운영 표준/Loop 표준, P0 agent SOUL 문서다.
• 핵심 원칙은 승인 요청 문구와 상태 전이, 실행 허용 범위를 분리하고, 비가역·외부 영향 작업은 승인 전 자동 실행하지 않는 것이다.

사용 근거 범위

1. /home/administrator/.hermes/profiles/sophie/docs/jyp-labs-google-tasks-approval-loop.md
2. /home/administrator/.hermes/profiles/sophie/cron/jobs.json의 dd6a3cc55a53 (JYP Labs Google Tasks approval monitor)
3. /home/administrator/.hermes/profiles/sophie/cron/jobs.json의 f1c16d59af26 (weekly-five-ops-doc-action-briefing)
4. /home/administrator/projects/jyp-garden/wiki/work/standards/jyp-labs-ai-skill-operating-standard-v0.1.md
5. /home/administrator/projects/jyp-garden/wiki/work/standards/jyp-labs-loop-engineering-standard-v0.1.md
6. /home/administrator/.hermes/skills/productivity/jyp-labs-operating-system-operations/SKILL.md
7. /home/administrator/projects/jyp-garden/wiki/work/agents/p0/mason/SOUL.md

근거별 핵심 추출

1) Google Tasks 승인 루프 문서

• 태스크 분류/상태 표준이 이미 정의돼 있다: [승인], [결정], [검토], [위임], [정보] + [대기], [진행], [완료], [보류].
• 대표님 승인 방식은 완료 처리 = 승인/진행 허가, 미완료 = 대기, decision: hold = 보류, decision: reject = 반려로 명시돼 있다.
• 자동 시작 가능 범위는 내부 초안, OMW/로컬 문서 정리, 읽기 전용 조사, 추가 Google Tasks 생성 등이다.
• 추가 승인 필요 범위는 외부 메일/메시지 발송, 일정 생성/변경/삭제, Drive 공유/삭제, 공개 게시, 결제, 고객 전달 최종본 발송이다.
• 금지 사항은 완료 처리만으로 비가역 작업을 바로 실행하는 것이다.

2) approval monitor cron (dd6a3cc55a53)

• 새 완료 항목이 없으면 정확히 [SILENT]만 반환하도록 설계돼 있다.
• 새 완료 항목이 있으면 SOPHIE_TASK_V1 완료를 대표 승인 신호로 해석하되, 시작 가능한 후속처리는 safe follow-up으로 한정한다.
• safe follow-up 범위는 내부 초안, OMW/로컬 문서 업데이트, 읽기 전용 조사, 추가 Google Tasks, 체크리스트, 실행계획이다.
• 외부 메시지, 일정 변경, Drive 삭제/공유, 공개 게시, 결제, 비가역 작업은 금지하고 새 approval-needed task로 올리도록 되어 있다.
• notes의 if_approved를 시작 계약으로 삼고, 불명확하면 확인 필요로 보고하도록 설계돼 있다.

3) weekly-five-ops-doc-action-briefing cron (f1c16d59af26)

• 이 cron은 문서 읽기와 다음 액션 추출, 우선순위 산정, 실행 전 브리핑까지만 수행한다.
• 어떤 액션도 실행하지 말고, 어떤 문서도 수정하지 말라가 명시돼 있다.
• 후속 실행은 대표님의 명시적 승인을 받은 뒤에만 허용된다.
• 외부 메일 발송, 삭제, 공개 게시, 결제/권한 변경, 캘린더·태스크 생성 등은 승인 요청 목록에만 올리고 자동 실행하지 않도록 분리돼 있다.
• 즉, 브리핑 문구와 실행 문구를 한 메시지로 섞지 않는 운영 패턴의 직접 근거다.

4) AI Skill Operating Standard

• 좋은 스킬은 입력 자료, 판단 기준, 실행 절차, 출력 형식, 검증 기준, 실패/예외 처리, 인간 승인 경계를 명확히 가져야 한다.
• 검증 불가능한 자동화는 금지되며 승인 필요 작업의 명시가 필수다.
• Evidence Package에 Risk와 Memory가 포함되고, 인간 승인 경계와 Stop 조건을 별도 섹션으로 두도록 요구한다.
• 따라서 승인 UX 문서는 상태 정의와 문구 예시뿐 아니라 무엇이 승인 전 실행 금지인지를 함께 표기해야 한다.

5) Loop Engineering Standard

• 사람은 반복 실행자가 아니라 기준·승인·검증 책임자다.
• 사람이 소유해야 하는 핵심 항목에 비가역 작업의 승인 경계와 최종 QA/E2E 판단이 포함된다.
• 상위 루프로 올릴 정보는 산출물 경로, 검증 결과, 핵심 요약, 확인 필요, 실패 사유, 다음 액션 후보로 제한된다.
• 즉 승인 결과 보고는 장문 reasoning이 아니라 상태, 허용 범위, 다음 액션, 확인 필요 중심으로 구조화돼야 한다.

6) JYP Labs Operating System Operations skill

• 추가 승인 없이 가능한 작업과 불가능한 작업을 운영 차원에서 재정의한다.
• 추가 승인 없이 가능한 작업: internal drafts, private OMW updates, read-only research, evidence packages, approval monitoring, checklists.
• 명시적 승인 없이는 불가능한 작업: external emails/messages, public posts, customer delivery, pricing/contract/납기 commitments, calendar mutation, Drive sharing/deletion, payments, permission changes.
• 이 문서는 approved-execute 상태가 곧 전체 실행 허가가 아니라 승인된 안전 범위만 실행을 의미한다는 근거다.

7) P0 agent SOUL (Mason)

• 가격, 일정, 계약, 성과는 대표님 승인 전 확정하지 않는다.
• 후속 메일 초안을 만들 수는 있지만 발송하지 않는다.
• 외부 영향, 공개 게시, 고객 전달, 가격/계약/납기, 고객 데이터 사용은 대표님 승인 전 수행하지 않는다.
• 산출물은 사실, 추정, 제안, 승인 필요 항목, Evidence Package를 분리해야 한다.
• 이는 승인 메시지 안에서 확정 표현을 줄이고 승인 필요 항목을 별도로 분리해야 한다는 문체/UX 근거다.

상태 전이 정의

state	진입 조건	허용 행동	다음 상태
approval-required	근거와 실행안은 준비됐지만 사람 승인 전	승인 요청, 범위 설명, 리스크/확인 필요 표시	approved-execute / hold / deny
hold	근거 부족, 범위 모호, 추가 자료 필요	보강 근거 요청, 재정리, 추가 확인	approval-required / deny
deny	현재 범위·조건에서 실행 중단 결정	실행 종료, backlog 이동 또는 종료 기록	closed / backlog
approved-execute	명시적 승인 또는 SOPHIE_TASK_V1 완료 신호 수신 후	승인된 안전 범위 내 내부 작업만 실행	in-progress / done / approval-required

표준 문구 예시

approval-required

• 승인 필요: 아래 범위만 확인해 주시면 승인된 범위만 실행하겠습니다.
• 승인 전 상태입니다. 외부 발송·공개·일정 변경은 포함되지 않습니다.

hold

• 보류: 근거 또는 범위 확인이 더 필요합니다.
• 확인 필요: 현재 자료만으로는 안전한 실행 범위를 확정할 수 없습니다.

deny

• 거절/중단: 현재 범위에서는 실행하지 않습니다.
• 반려 기준으로 기록만 남기고 후속 실행은 하지 않습니다.

approved-execute

• 승인 확인: 승인된 안전 범위만 실행합니다.
• 후속처리를 시작하되, 외부 발송·공개·삭제 등 추가 승인 필요 항목은 별도로 다시 올리겠습니다.

상태와 문구를 섞지 말아야 하는 이유

• approval-required는 상태이고, 승인 필요: ...는 표현이다.
• hold는 상태이고, 확인 필요: ...는 보고 문구다.
• approved-execute는 상태이지 전체 작업 완료 선언이 아니다.
• 따라서 Slack/브리핑 UX에서는 현재 상태와 실행/비실행 범위, 다음 상태 후보를 별도 줄로 분리하는 편이 안전하다.

권장 Slack UX 패턴

1. 상태
   • 예: 상태: approval-required
2. 요청 요약
   • 예: 요청: OPS-A003 승인 문구 표준 초안 검토
3. 승인 시 자동 실행 범위
   • 예: 승인 시: 내부 문서 업데이트와 체크리스트 정리만 수행
4. 추가 승인 필요 항목
   • 예: 추가 승인 필요: 외부 공유, 공개 게시, 일정 변경
5. 확인 필요/리스크
   • 예: 확인 필요: hold와 deny를 카드 상태로 분리할지

금지 패턴

• 승인된 것으로 보고 진행하겠습니다처럼 승인 여부를 추정하는 문구
• 승인 요청과 실행 완료를 한 메시지에 혼합하는 문구
• 승인 완료와 외부 발송 완료를 같은 단계처럼 보이게 쓰는 문구
• 비가역 작업이 이미 예정된 것처럼 보이게 쓰는 문구
• approved-execute를 모든 후속 작업 허용으로 해석하게 만드는 문구

결정 변수

• Slack 본문에 !approve, !deny 같은 축약 명령을 표준으로 노출할지 여부
• hold와 deny를 카드 상태 수준에서도 분리할지 여부
• approved-execute 뒤 내부 작업 완료를 별도 done 상태로 나눌지 여부