# OSCODE 결과 기반 서비스 (RaaS)

고객에게 블록 파일 자체보다 **검증된 작업 결과와 납품 지원**을 판매하는 흐름입니다. `/packs`는 운영자의 재사용 작업 레시피이고 `/jobs`는 견적·실행·납품·검수 승인 기록입니다.

현재 구현은 **로컬 운영자용 프로토타입**입니다. 웹 주문, 고객 인증, 결제, 서버 청구 원장은 없습니다. `ready_to_invoice`는 운영자의 청구 준비 기록이며 실제 돈을 받았다는 뜻이 아닙니다.

## 첫 상품 2종

| 상품 | 고객 입력 | 제공 결과 | 성공으로 주장하지 않는 항목 |
| --- | --- | --- | --- |
| 반도체 LOT 수율 보고서 | 지정된 형식의 검사 CSV | LOT별 PASS/FAIL/미검사·수율 보고서 | 불량 원인 규명, 수율 개선, 공정 최적화 |
| ERP 전표 사전 검증 | KRW 전표 JSON | 전표별 차대변 차이·불일치 보고서 | 회계 적정성, 세무 검토, SAP 전기 |

ERP에서 불일치를 발견한 보고서도 정상 납품 결과입니다. 고객이 의뢰한 것은 검증 결과이며, 데이터가 모두 정상이라는 결과를 보장하는 상품이 아닙니다. 금액은 정수 문자열로 입력하고 BigInt로 합산합니다. 전체 차대변이 맞더라도 전표별 불일치는 따로 표시합니다.

## 운영 순서

1. 고객과 입력 형식, 결과 범위, 납기, 검수 기준, 금액을 합의합니다. 가격은 코드에 임의로 정하지 않았습니다.
2. `/jobs quote`로 견적을 만듭니다. 샘플 아래 10,000원은 기능 확인용 예시이며 권장 가격이 아닙니다.
3. `/jobs run`에서 견적·연결을 확인하고 실행합니다. 파일 쓰기는 기존 권한을 따릅니다.
4. `/jobs show`에서 결과 경로와 SHA-256을 확인하고 결과물을 고객에게 전달합니다. 자동 전송하지 않습니다.
5. 고객 검수·승인을 별도로 받은 뒤 `/jobs accept`로 그 사실을 기록합니다.
6. 실제 청구·결제는 현재 별도의 판매 채널에서 처리해야 합니다. OSCODE는 결제를 요청하지 않습니다.

```text
/packs list
/jobs quote erp-voucher {"parameters":{"input":"examples/packs/ledger.json","output":"erp-result.md"},"priceKrw":"10000"}
/jobs show
/jobs run
/jobs accept
/jobs list
```

반도체 예:

```text
/jobs quote semiconductor-yield {"parameters":{"input":"examples/semiconductor/inspection.csv","output":"yield-result.md"},"priceKrw":"10000"}
/jobs run
```

작업 ID를 생략하면 현재 세션의 최근 작업을 사용합니다. 최대 30개 작업을 세션에 보관합니다. 다른 세션에는 작업이 자동 공유되지 않습니다.

## 상태와 청구 기준

```text
quoted → running → delivered → accepted
             └→ failed / cancelled
```

- 견적: 금액·팩 버전·그래프·결과 경로를 해시로 묶습니다. 수정되면 새 견적을 요구합니다.
- 실행: 로컬 블록 코드만 사용하며 모델 호출이 없습니다. 고객별 경로 설정은 파라미터로 전달합니다.
- 전달 준비: 모든 단계 성공, 결과 파일 존재, 비어 있지 않음, 해시 기록이 필요합니다. `delivered`는 결과 파일 준비 상태이며 고객에게 자동 전달했다는 뜻이 아닙니다.
- 승인: 운영자가 고객 검수 승인을 확인했다고 기록하며, 저장된 결과 해시가 일치해야 합니다. 고객 본인 인증을 대체하지 않습니다.
- 실패·취소: `not_billable`. 이전 단계에서 생성된 파일이 있으면 남아 있을 수 있으며 체크포인트로 검토합니다.
- 승인 반복: 같은 작업에는 같은 참조 ID를 사용해 승인 기록을 중복 생성하지 않습니다. 결제사 수준의 중복 결제 방지를 구현한 것은 아닙니다.
- 중간 종료로 running에 남은 작업은 수동 확인 후 새 견적으로 진행합니다. 자동 청구·자동 재실행하지 않습니다.

## 전문 팩 제작·납품

기본 팩은 MIT 샘플입니다. 가격·라이선스 강제 장치로 무료 코드를 잠그지 않습니다. 고객별 입력 변환, 검증 조건 설계, 실행·납품·지원 등 실제 추가 가치를 상품에 포함하세요.

```text
/packs show erp-voucher
/packs build examples/packs/erp-voucher.manifest.json customer-pack.json
/packs import customer-pack.json
/packs use erp-voucher-delivery@1.0.0 {"input":"examples/packs/ledger.json","output":"customer-report.md"}
/blocks show
/blocks run
```

명세는 `schema`, `id`, `version`, `title`, `description`, `publisher`, `license`, `delivery`, `parameters`, `graph`를 포함합니다. 파라미터는 특정 블록의 리터럴 입력에만 연결할 수 있습니다. 패키지 파일에는 정규화된 그래프와 SHA-256을 넣습니다. 이 해시는 손상 검출용이며 판매자 서명·구매 인증·DRM이 아닙니다. 가져온 팩은 자동 실행하지 않습니다.

기본 팩 ID와의 충돌 및 같은 ID·버전 중복 설치는 거절합니다. 고객용 팩은 별도 ID로 작성하세요. 여러 버전이 있으면 `id@버전`으로 지정합니다. 설치된 팩은 프로젝트 `.oscode/block-packs.json`, 작업 기록은 기존 세션 파일에 저장합니다.

## 실제 유료 웹 서비스로 전환할 때

현재 로컬 파일은 사용자가 수정할 수 있으므로 청구의 권위 있는 근거로 사용하면 안 됩니다. 외부 판매를 자동화하려면 고객 로그인·서버 작업 원장·변경 불가능한 납품 증빙·고객 승인 화면·결제사 연동과 웹훅 검증이 필요합니다. 판매 계정, 고객이 접속할 서버와 도메인, 합의한 검수·환불 조건을 정한 후 연결해야 합니다. 현재 코드는 매출이나 고객 수요를 보장하지 않습니다.