위키 · 구현 참조
작업 흐름(JOB)
이 페이지는 바로 답하는 simple 경로와 기록을 남기는 JOB의 차이, JOB 폴더와 단계별 계약, 전이 게이트가 확인하는 항목을 설명합니다.
여기에 나오는 로컬 운영 경로와 명령은 설치별 좌표이며 p-hermes 저장소에 포함되지 않습니다. 구성요소의 공개 범위는 구성과 범위에서 확인합니다.
simple과 JOB을 고르는 기준
simple은 기록할 JOB을 만들지 않고 요청에 답하는 경로입니다. 일반적인 매니저 요청은 simple로 분류되며, 기존 기록을 남기거나 여러 요청을 함께 다루거나 나중에 근거로 확인할 결정은 JOB에 기록합니다. 새 light JOB은 하나의 가역적이고 한정된 작업으로 완료조건을 측정할 수 있으며 별도 승인 경계를 갖지 않는 경우에 사용합니다. simple은 JOB tier가 아니며, registry에 남은 simple-v2-prototype은 비활성 메타데이터입니다.
별도 사용자 승인이 필요한 네 범주는 permanent_deletion, external_publication, credential_security, policy_amendment입니다. 매니저 요청이 이 범주에 해당하면 simple로 처리하지 않고 승인 경계를 따릅니다. JOB 기록이나 tier 선택은 그 승인을 대신하지 않습니다.
JOB 폴더에서 보는 기록
아래 트리는 실제 light-v2 JOB 폴더 한 건의 구조를 바탕으로 이름과 내용을 익명화했습니다. 항목은 그 JOB에 실제로 존재했던 파일만 표시합니다.
JOB-예시/
├── .workflow-state
├── approval-policy.json
├── approval.md
├── artifacts/
│ ├── check.png
│ ├── req-terms.md
│ ├── shots/
│ │ ├── 00-01.png
│ │ └── 01-05.png
│ └── shots2/
│ └── 02-06.png
├── manifest.yaml
├── request.md
└── result.md
요청과 승인 기록은 JOB의 범위와 근거를 보존하고, artifacts/는 분석·중간 자료를 담습니다. 실행·검증을 마친 작업에는 단계별 기록 파일도 놓입니다. 폴더 모양은 기록 예시이며, 전이마다 필요한 파일은 현재 pinned 계약과 게이트가 정합니다.
light-v2 단계 계약
신규 light JOB의 실행 가능한 graph는 light-v2이며 순서는 request → execution → verification → done입니다. 계약의 필수 파일과 통과 조건은 다음과 같습니다.
| 단계 | 필수 파일 | 계약의 통과 조건 |
|---|---|---|
request | request.md | 범위와 완료조건이 명확합니다. |
execution | execution.md | 허용 범위를 지키고 수행 행동을 기록합니다. |
verification | verification.md | 수용조건을 확인하고 산출물을 다시 읽습니다. |
done | result.md | 근거와 결과가 일치합니다. |
단계 계약은 각 단계의 입력, 필수·선택 산출, 확인과 다음 단계를 함께 정의합니다. 게이트 구현은 request에서 다음 단계로 갈 때 approval.md도 확인하며, 각 필수 파일이 비어 있지 않은지 검사합니다.
전이 게이트와 승인 기록
게이트는 JOB의 .workflow-state에서 tier·schema·graph digest·현재 단계를 읽고, registry의 활성 graph와 맞는 전이인지 확인합니다. 허용된 전이에서 상태 digest와 revision을 다시 대조하고 원자적으로 상태를 바꾼 뒤 read-back digest를 확인합니다. light-v2의 초기 실행 확인은 start, 다음 단계 전이는 advance를 사용합니다.
approval.md에는 approved_by:와 evidence:가 있어야 합니다. 이 두 줄은 light JOB의 시작 범위를 뒷받침하는 사용자 지시 원문 또는 메시지 식별 근거를 가리킵니다. 승인 파일은 별도 사용자 승인이 필요한 네 범주의 실제 사용자 승인을 대체하지 않습니다.
실패·timeout 뒤의 보존과 복구
전이 검사에 실패하면 게이트는 상태를 바꾸지 않고 차단 사유를 돌려줍니다. 요청 파일·승인 기록 또는 실행·검증 기록이 빠졌다면 해당 파일과 근거를 보완한 뒤 현재 상태에서 다시 확인합니다. timeout은 성공으로 간주하지 않으며 이미 만든 산출물은 보존합니다.
복구할 때는 실행 기록과 파일을 다시 읽어 실제 완료 여부를 확인합니다. 필수 산출이 남아 있으면 결과와 근거를 정합시킵니다. 실패·부분 완료의 표기는 실제 산출과 검증 상태에 맞추며, 상태 파일을 직접 바꾸거나 게이트를 건너뛰지 않습니다.
부분 완료를 이어갈 때는 원 목표를 유지하고 직전 실패 원인, 바꾼 점, 남은 항목을 기록합니다. timeout 뒤 재시도는 실행 여건을 늘리거나 작업을 나누어 진행합니다. 같은 목표에서 차단이 두 번 반복되거나 부분 완료가 세 번 연속되면 반복 실행 전에 원인을 진단합니다.
JOB 생성과 단계 전이 명령
완료조건을 정한 뒤 create-job.sh로 신규 light JOB을 만듭니다. 단계 전이는 해당 JOB의 pinned graph에 맞는 gate 명령으로 요청합니다.
bash <로컬 운영 루트>/core/scripts/create-job.sh --tier light --goal "측정 가능한 완료조건" -y 개선 "작업 제목"
bash <로컬 운영 루트>/core/skills/custom/workflow/scripts/workflow-gate.sh <JOB-ID> start
bash <로컬 운영 루트>/core/skills/custom/workflow/scripts/workflow-gate.sh <JOB-ID> advance
실제 단계와 다음 허용 전이는 JOB의 상태·registry·계약으로 결정됩니다. 명령 예시는 안내이며 이 페이지를 읽는 것만으로 실행되지 않습니다.
근거 파일
| 이 페이지의 내용 | 정본 경로 |
|---|---|
| simple과 JOB, 승인 네 범주, 기록 단위 | <로컬 운영 루트>/orchestration/POLICY.md §(a-2), §(f), §(i) |
| 단계별 필수 파일·통과조건, light-v2 기준 | <로컬 운영 루트>/core/skills/custom/workflow/v2/contract.yaml, tiers/light.yaml, registry-v2.json |
| 상태 검사·전이·필수 파일·승인 파일 확인 | <로컬 운영 루트>/core/skills/custom/workflow/v2/runner.py, <로컬 운영 루트>/core/skills/custom/workflow/scripts/workflow-gate.sh |
| 생성 명령 인수와 신규 tier | <로컬 운영 루트>/core/scripts/create-job.sh |
| 실제 폴더 구조 예시 | <로컬 운영 루트>/workspace/jobs/의 JOB 폴더 |
확인 기준: 2026-10-13. 공개 문서에는 로컬 운영 경로를 상대 좌표로 표시했습니다.